通过CloudFormation升级Aurora PostgreSQL引擎版本的问题咨询

这是个很常见的CloudFormation与Aurora版本管理冲突的场景，我来分享几个经过验证的可行方案：

1. 先修复资源漂移，再同步模板与实际状态 #

你手动通过CLI升级集群到9.6.12后，CloudFormation的栈期望状态和资源的实际状态已经产生了漂移。这时候直接修改模板的EngineVersion为9.6.12，CloudFormation可能会误判需要替换资源来对齐状态。

解决步骤：

• 打开CloudFormation控制台，找到你的集群栈，运行漂移检测
• 确认DBCluster资源的EngineVersion确实显示为漂移状态（实际值9.6.12 vs 期望值9.6.11）
• 更新模板中的EngineVersion为9.6.12，然后执行栈更新
• 在更新预览中，确认CloudFormation只会更新EngineVersion属性，不会触发集群替换

如果控制台还是显示要替换，可以尝试用CLI执行更新：

aws cloudformation update-stack --stack-name your-cluster-stack --template-body file://your-template.yml --parameters ParameterKey=EngineVersion,ParameterValue=9.6.12

2. 检查模板中触发资源替换的隐藏属性 #

有时候看似无关的模板属性会导致CloudFormation触发集群替换，尤其是和版本绑定的配置：

• 检查DBClusterParameterGroupName：如果参数组是针对9.6.11创建的，确保它兼容9.6.12，或者更新参数组到对应版本（小版本参数组通常兼容，但如果是自定义参数组，需要确认）
• 确认Engine属性设置为aurora-postgresql，而非其他值
• 检查是否有硬编码的DBClusterIdentifier或其他Immutable属性被修改（不过版本升级和这些无关，但需要排除）

3. 利用AutoMinorVersionUpgrade自动化小版本管理 #

如果你的场景允许自动小版本升级，可以在模板的AWS::RDS::DBCluster中添加：

AutoMinorVersionUpgrade: true

这样CloudFormation会自动管理小版本升级，不需要手动指定EngineVersion。之后如果需要固定版本，再关闭这个属性并设置具体的EngineVersion即可。

4. 极端情况：保留现有资源重建栈 #

如果上述方法都无效，可以采用“保留资源+重建栈”的方式：

1. 修改原模板，给AWS::RDS::DBCluster添加DeletionPolicy: Retain和UpdateReplacePolicy: Retain
2. 删除原栈（这一步只会删除栈的元数据，不会删除实际的DB集群）
3. 创建新栈，模板中指定现有集群的DBClusterIdentifier，并设置EngineVersion为9.6.12
4. 新栈会直接关联现有集群，不会创建新资源

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