首先得澄清一个误区：DeletionPolicy: Retain 是用来在删除CloudFormation栈时保留指定资源的，完全不影响重复执行栈的场景——这就是为什么它没解决你的问题。要实现多次执行（哪怕100次）后资源状态和第一次完全一致，核心要保证CloudFormation模板本身的幂等性，再配合Ansible模块的正确配置，具体可以按以下步骤来：

1. 让CloudFormation模板具备幂等性 #

这是最关键的一步，模板本身要能重复执行而不创建新资源或引发冲突：

• 固定资源逻辑ID：模板里每个资源的LogicalID必须稳定，不能动态生成（比如不要用随机字符串）。CloudFormation是通过逻辑ID来识别资源的，只要逻辑ID不变，它就会尝试更新现有资源而非创建新的。
• 避免动态生成唯一资源名：比如S3桶名、CodeCommit仓库名，绝对不要用每次执行都会变化的变量（比如时间戳、随机数）。如果需要唯一命名，可以结合栈名（!Ref AWS::StackName）生成固定的唯一名称，比如：

  MyS3Bucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "${AWS::StackName}-my-bucket"
  

• 匹配现有资源属性：模板里定义的资源属性要和第一次创建后的实际状态完全一致。比如如果S3桶开启了版本控制，后续模板里也要明确写VersioningConfiguration: {Status: Enabled}，不然CloudFormation会尝试修改属性引发冲突。
• 合理使用UpdateReplacePolicy：如果某些资源的属性修改必须替换旧资源（比如S3桶的存储类），可以设置UpdateReplacePolicy: Retain，这样替换时旧资源会被保留，避免数据丢失。

2. 正确配置Ansible的CloudFormation模块 #

Ansible的community.aws.cloudformation模块本身支持幂等性，但要配置对参数：

• 使用state: present：这个参数会确保栈存在，并且模板和参数与当前定义一致。如果栈已经存在且状态正常，模块不会做任何操作；如果模板有合法的更新，会执行更新而非重新创建。
• 固定栈名：不要动态生成栈名，比如不要用{{ ansible_date_time.iso8601 }}作为栈名的一部分，固定的栈名是Ansible识别现有栈的关键。
• 明确指定权限能力：如果模板里包含IAM资源（比如桶策略、CodeCommit权限），必须加上capabilities: [CAPABILITY_NAMED_IAM]，否则更新时会报错。
• 禁用回滚（可选）：设置disable_rollback: true可以避免在更新失败时回滚到之前的状态，方便排查问题，但不影响幂等性。

举个实用的Ansible剧本片段：

- name: Provision S3 and CodeCommit resources via CloudFormation
  community.aws.cloudformation:
    stack_name: my-persistent-resources-stack
    state: present
    template_body: "{{ lookup('file', './templates/s3-codecommit-cfn.yml') }}"
    capabilities:
      - CAPABILITY_NAMED_IAM
    parameters:
      RepoDescription: "My application code repository"
      BucketVersioning: "Enabled"
    disable_rollback: true

3. 处理特殊资源的冲突 #

• S3桶：如果桶里已经有对象，CloudFormation默认无法修改某些属性（比如删除桶策略、关闭版本控制）。这时候要么确保模板不修改这些属性，要么先清空桶内容（但这可能不符合你的需求），或者在模板里用DeletionPolicy: Retain保障删除栈时不丢数据，但重复执行时还是要靠模板属性匹配。
• CodeCommit仓库：如果仓库已经有提交，修改默认分支等属性是允许的，但要确保模板里的定义和你期望的最终状态一致，避免每次执行都触发不必要的更新。

4. 验证幂等性的小技巧 #

• 执行前用cloudformation_info模块检查栈状态，如果栈已经处于CREATE_COMPLETE或UPDATE_COMPLETE状态，可以选择性跳过执行（不过state: present已经会自动处理，这步是可选的）。
• 把CloudFormation模板和Ansible剧本都放到版本控制里，确保每次执行的内容完全一致，避免手动修改导致的不一致。

总结一下：只要模板是幂等的，Ansible模块配置正确，多次执行后资源状态会和第一次完全一致——不会创建新资源，也不会引发异常。DeletionPolicy在这里确实帮不上忙，它的作用是在删除栈时保护资源，和重复执行栈的场景无关。

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