CloudFormation漂移检查触发时机及堆栈更新相关技术咨询

问题1：CloudFormation漂移检查的触发时机是什么？ #

漂移检查不会自动定期执行，主要触发时机为：

• 用户手动通过AWS管理控制台、AWS CLI、AWS SDK或CloudFormation API主动发起检查
• 执行「检测并修复漂移」操作时，会先触发漂移检查，再尝试修复可恢复的漂移资源

问题2：除了AWS管理控制台中的「检查漂移」功能外，是否存在其他漂移检查触发方式？ #

存在多种触发方式：

• AWS CLI：使用aws cloudformation detect-stack-drift命令触发整个堆栈的漂移检查，或用aws cloudformation detect-stack-resource-drift针对单个资源执行检查
• AWS SDK/CloudFormation API：调用DetectStackDrift或DetectStackResourceDrift接口发起检查
• 自动化脚本：结合CLI或SDK编写定时任务（比如通过CloudWatch Events触发），实现周期性的漂移检查
• 「检测并修复漂移」功能：该操作会先完成漂移检查，再对支持修复的漂移资源进行还原

问题3：CloudFormation在堆栈更新前是否会自动执行漂移检查？ #

不会。堆栈更新操作的核心逻辑是对比提交的模板与堆栈的预期状态（即模板定义的状态），不会自动触发漂移检查来校验实际资源的当前状态。如果需要在更新前确认漂移情况，必须手动发起检查。

问题4：场景说明：通过CloudFormation堆栈创建一个S3存储桶后，通过控制台手动修改该S3桶的部分属性，随后使用创建堆栈时的原模板执行堆栈更新操作。请问该堆栈更新操作是否会触发漂移检查并检测到需要还原被修改的属性？还是会因模板未发生变化而不执行任何操作，即便S3桶已处于漂移状态？ #

该操作既不会触发漂移检查，也不会执行任何还原操作。

原因是：CloudFormation的堆栈更新仅对比提交的模板与堆栈的预期状态，当两者完全一致时，会判定为无变更需要执行，不会去校验实际资源的当前状态是否已偏离预期。若要还原被修改的S3桶属性，需手动触发漂移检查确认状态后，通过「检测并修复漂移」功能或针对该资源执行修复操作。

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