通过CDK创建DynamoDB等有状态资源的标准方式咨询

数据老陈

2026-4-27

使用AWS CDK管理有状态资源的标准实践

我来帮你梳理下用CDK处理有状态资源（比如DynamoDB）的核心思路，同时也解决你提到的SNS不必要重建的问题——其实不管是有状态还是无状态资源，CDK的底层都是CloudFormation，所以核心是利用CloudFormation的资源生命周期规则来避免数据丢失和不必要的重建。

首先，为什么你的SNS会被重新创建？

SNS本身是无状态的，但如果每次部署都重建，大概率是这两个原因：

你没有给SNS主题指定物理名称（topicName），CDK会自动生成一个带有随机后缀的物理名称，当你修改CDK代码中主题的逻辑ID或者某些核心属性时，CloudFormation会认为这是一个新资源，从而重建。
你修改了SNS的某些会触发重建的属性（比如突然把FIFO主题改成标准主题）。

解决方法很简单：给SNS指定固定的topicName，只要物理名称不变，CloudFormation只会更新属性而不会重建主题。

处理有状态资源的核心原则

对于DynamoDB这类存储数据的有状态资源，核心目标是避免意外重建导致数据丢失，同时允许安全的属性更新。下面是标准实践：

1. 配置`removalPolicy`保护资源

这是最关键的一步，通过设置removalPolicy来控制当CDK栈被删除或者资源从栈中移除时的行为：

RemovalPolicy.RETAIN：保留物理资源，即使栈被删除或资源被从CDK代码中移除，数据也不会丢失。适合生产环境。
RemovalPolicy.SNAPSHOT：如果资源支持（比如DynamoDB），会先创建资源快照，再删除物理资源。适合测试环境或者需要保留备份的场景。
RemovalPolicy.DESTROY：删除物理资源，仅建议在临时测试环境使用。

示例代码（TypeScript）：

import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as cdk from 'aws-cdk-lib';

const myTable = new dynamodb.Table(this, 'UserTable', {
  partitionKey: { name: 'userId', type: dynamodb.AttributeType.STRING },
  removalPolicy: cdk.RemovalPolicy.RETAIN, // 生产环境必设
  tableName: 'Production-UserTable', // 指定固定物理名称
});

2. 分离有状态与无状态资源到不同栈

把DynamoDB、RDS这类有状态资源单独放在一个CDK栈里，而Lambda、SNS、API Gateway等无状态资源放在另一个栈。这样部署无状态资源时，完全不会影响有状态栈，从根源上避免误操作导致的有状态资源重建。

跨栈引用的方式也很简单：在有状态栈中导出资源，无状态栈通过构造函数参数接收并引用。比如：

// 有状态栈
export class StatefulStack extends cdk.Stack {
  public readonly userTable: dynamodb.Table;

  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);
    this.userTable = new dynamodb.Table(this, 'UserTable', {
      partitionKey: { name: 'userId', type: dynamodb.AttributeType.STRING },
      removalPolicy: cdk.RemovalPolicy.RETAIN,
      tableName: 'Production-UserTable',
    });
  }
}

// 无状态栈
export class StatelessStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props: { statefulStack: StatefulStack }) {
    super(scope, id, props);
    // 创建带固定名称的SNS主题
    const userTopic = new sns.Topic(this, 'UserTopic', {
      topicName: 'Production-UserTopic',
    });

    // Lambda引用有状态栈的表
    const userLambda = new lambda.Function(this, 'UserLambda', {
      runtime: lambda.Runtime.NODEJS_20_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('lambda'),
      environment: {
        TABLE_NAME: props.statefulStack.userTable.tableName,
        TOPIC_ARN: userTopic.topicArn,
      },
    });
    // 给Lambda添加表访问权限
    props.statefulStack.userTable.grantReadWriteData(userLambda);
  }
}

// 初始化栈
const app = new cdk.App();
const statefulStack = new StatefulStack(app, 'StatefulStack-Prod');
new StatelessStack(app, 'StatelessStack-Prod', { statefulStack });

3. 避免修改会触发重建的属性

有些属性一旦创建就无法修改，否则会导致CloudFormation重建资源。比如DynamoDB的：

主键结构（分区键、排序键的名称或类型）
表的类型（比如从标准表改成全局表）

如果必须修改这些属性，你需要通过数据迁移的方式：先创建新表，把旧表的数据迁移过去，然后更新无状态资源的引用，最后再删除旧表。

4. 用变更集预览部署影响

每次部署前，使用CDK的cdk diff命令查看变更，或者在AWS控制台创建CloudFormation变更集，确认不会对有状态资源执行重建操作后再部署。这能帮你提前发现风险。

总结一下

无状态资源（SNS、Lambda）：指定固定物理名称避免不必要重建，或者接受CDK的自动命名但确保逻辑ID稳定。
有状态资源（DynamoDB）：配置removalPolicy、分离到独立栈、避免修改核心属性、提前预览变更。

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

通过CDK创建DynamoDB等有状态资源的标准方式咨询

首先，为什么你的SNS会被重新创建？ #

处理有状态资源的核心原则 #

1. 配置removalPolicy保护资源