AWS::RDS::DBInstance替换类属性修改时的数据保留方法（附Postgres快照报错）

报错根因说明 #

你当前遇到的DBName must be null when Restoring for this Engine报错，本质是PostgreSQL引擎的固定校验规则：当RDS实例通过DBSnapshotIdentifier从已有快照恢复时，快照本身已经存储了原实例的DBName、主账号名等元数据，不允许用户在恢复请求里显式传入这些参数，否则会被直接拒绝。
而你需要修改的Requires: Replacement类属性（比如Postgres的DBName、存储加密开关、数据库端口等），本身就不存在原地修改的可能，必须通过「销毁旧实例-从快照恢复新实例」的路径完成替换，不存在单次原地修改的捷径。

分步操作流程 #

• 前置准备：确认现有RDS实例的快照可用性。可以手动触发一次即时快照，验证快照可正常恢复、数据完整，把这个快照ID作为恢复数据源，避免依赖自动快照的时间差导致数据不一致。
• 模板逻辑修正：调整DBInstance资源的参数判断逻辑，把快照恢复路径下RDS禁止显式传入的参数（DBName、MasterUsername、MasterUserPassword）做条件置空，从根源上解决参数校验报错。修正后的模板片段如下：

DBInstance:
    DeletionPolicy: Snapshot
    UpdateReplacePolicy: Snapshot
    Type: 'AWS::RDS::DBInstance'
    Properties:
      AllocatedStorage: !Ref DBAllocatedStorage
      # 走快照恢复路径时不传入DBName，匹配Postgres校验规则
      DBName: !If [IsRestoringFromSnapshot, !Ref 'AWS::NoValue', !Ref DBInstanceName]
      DBSnapshotIdentifier:
        !If [
          HasDBSnapshotIdentifier,
          !Ref DBSnapshotIdentifier,
          !Ref 'AWS::NoValue',
        ]
      # 快照恢复路径下不传入主账号配置，所有账号元数据从快照自动继承
      MasterUsername: !If [IsRestoringFromSnapshot, !Ref 'AWS::NoValue', !Ref DBMasterUsername]
      MasterUserPassword: !If [IsRestoringFromSnapshot, !Ref 'AWS::NoValue', !Ref DBMasterUserPassword]
      DBParameterGroupName:
        !If [
          HasDBParameterGroupName,
          !Ref DBParameterGroupName,
          !Ref 'AWS::NoValue',
        ]
      OptionGroupName:
        !If [HasDBOptionGroupName, !Ref DBOptionGroupName, !Ref 'AWS::NoValue']
      BackupRetentionPeriod: 14
      CopyTagsToSnapshot: true
      DBInstanceClass: 'db.t3.micro'
      DBSubnetGroupName: !Ref DBSubnetGroup
      EnableIAMDatabaseAuthentication: true
      Engine: 'postgres'
      EngineVersion: '13.1'
      PreferredBackupWindow: !Ref PreferredBackupWindow
      PreferredMaintenanceWindow: !Ref PreferredMaintenanceWindow
      StorageType: gp2
      VPCSecurityGroups:
        - !Ref DBInstanceSecurityGroup

注：需要在模板的Conditions段新增IsRestoringFromSnapshot条件，判断逻辑为当HasDBSnapshotIdentifier为真时，即判定为快照恢复路径。

• 配置目标修改值：把你需要调整的Requires: Replacement类属性，设置为你需要的新值。这里要明确：RDS从快照恢复时，只会从快照继承数据、DBName、主账号这类元数据，你在模板里显式指定的其他非元数据配置（比如安全组、参数组、备份窗口、实例规格、存储类型等），都会按你配置的新值生效，不会被快照里的旧配置覆盖。
• 提交栈更新：把准备好的快照ID填入DBSnapshotIdentifier参数，触发CloudFormation栈更新。此时CloudFormation会走「旧实例快照备份-新实例从快照恢复-替换旧实例」的流程，全程所有业务数据会完整从旧实例迁移到新实例，不会丢失。
• 更新后校验：新实例启动完成后，依次校验三类内容：一是业务数据的完整性，对比关键表的行数、核心业务配置；二是本次需要修改的Requires: Replacement属性是否已经按预期在新实例上生效；三是数据库连接、IAM认证、备份策略是否符合原有业务要求。

关键避坑点：

1. 不要在未指定DBSnapshotIdentifier的情况下直接修改Requires: Replacement类属性提交更新。这种操作下CloudFormation会直接销毁旧实例、新建一个空的全新RDS实例，虽然依靠你配置的UpdateReplacePolicy: Snapshot可以找回销毁前的快照，但是会产生不必要的业务中断和操作复杂度。
2. 如果你本次要修改的Requires: Replacement属性本身是DBName，因为快照恢复时不允许覆盖快照里存储的旧DBName值，不要试图通过CloudFormation在快照恢复阶段传入新的DBName值，该操作会被RDS接口直接拦截。你需要在新实例启动完成后，通过数据库原生操作（比如CREATE DATABASE + 数据迁移、pg_dump/restore的方式）完成DBName的切换。

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