CloudFormation：如何在不影响现有资源的情况下部署变更

一、部署变更且不影响指定资源的操作方法 #

要确保角色、安全组、集群等现有资源不受影响，核心是让CloudFormation不对这些资源执行修改、替换或删除操作，具体步骤如下：

• 保持资源逻辑ID和属性一致：在修改后的模板中，保留这些资源的原逻辑ID（Logical ID），并且不要修改它们的核心属性（比如安全组的VPC关联、角色的信任策略等）。CloudFormation通过逻辑ID识别资源，只要逻辑ID不变且属性与现有资源匹配，就会跳过对这些资源的处理。
• 使用变更集预览变更：在执行更新前，先创建变更集（Change Set），查看变更详情。重点确认目标资源的变更类型为No change或No interruption，确认无误后再执行变更。
  • 控制台操作：进入CloudFormation栈详情页，选择「创建变更集」，上传修改后的模板，完成配置后查看变更预览。
  • CLI命令：aws cloudformation create-change-set --stack-name <你的栈名> --template-body file://<修改后的模板路径> --change-set-name <变更集名称>，之后用aws cloudformation describe-change-set查看详情，确认后用aws cloudformation execute-change-set执行。
• 配置资源保留策略：如果模板中需要移除某些资源，但又不想删除现有实体，可以给这些资源添加DeletionPolicy: Retain；如果属性修改会触发资源替换，添加UpdateReplacePolicy: Retain可以保留旧资源直到新资源创建完成（不过针对你要保护的核心资源，建议尽量避免触发替换的属性修改）。

二、替换当前模板是否会影响现有资源？ #

替换模板的影响完全取决于新模板与现有栈资源的匹配情况：

• 无影响的情况：新模板保留了原有资源的逻辑ID，且属性与现有资源一致，CloudFormation会忽略这些资源，不会有任何操作。
• 有影响的情况：
  • 如果新模板删除了原有资源的逻辑ID，默认会删除该资源（除非设置了DeletionPolicy: Retain）。
  • 如果新模板修改了原有资源的属性，要看属性是否支持增量更新：比如给安全组添加入站规则属于增量更新，不会替换资源；但修改安全组关联的VPC、集群的实例类型这类属性，会触发资源替换（删除旧资源，创建新资源），直接影响现有运行。
• 结论：替换模板前必须用变更集预览，确认所有核心资源的变更类型符合预期，再执行操作。

三、开发环境删栈测试正常，生产环境不删栈导入变更的方法 #

开发环境是删除栈后重建验证的，生产环境要保留现有栈，需分两种场景处理：

• 新功能仅新增资源：直接执行栈更新即可。确保修改后的模板中，原有资源的逻辑ID和属性完全保留，新增资源使用全新的逻辑ID。CloudFormation会只创建新增资源，不会触动现有资源。
• 新功能涉及修改原有资源：
  1. 先在生产环境创建变更集，仔细核对每个原有资源的变更内容，确认角色、安全组、集群等核心资源没有被修改、替换或删除。
  2. 若修改的是支持增量更新的属性（比如给IAM角色添加权限），确认变更预览无问题后执行更新。
  3. 若修改的属性会触发资源替换，建议评估是否有替代方案：比如创建新的资源实例，逐步将流量迁移过去，待验证正常后再通过更新栈删除旧资源（需配置DeletionPolicy避免意外删除）。

内容的提问来源于stack exchange，提问作者NGK