如何使用CDK实现跨账号SQS订阅SNS及Lambda轮询SQS架构

这个跨账号SNS→SQS→Lambda的链路是AWS官方原生支持的标准架构，用MonoCDK（AWS CDK v2的单包分发版本，无需单独安装各服务依赖包）完全可以落地，没有技术层面的卡点，核心是做好跨账号资源的访问策略配置即可。相比SNS跨账号直连Lambda，中间加SQS做缓冲的架构更稳定，能避免Lambda限流、投递失败丢消息的问题，也是生产环境的推荐实践。

• 栈拆分建议：拆成两个独立的CDK栈分别部署，不需要在单个栈里同时持有两个账号的全量权限
  • 账号A栈：仅部署SNS主题，配置主题策略允许账号B的资源调用发布接口
  • 账号B栈：部署SQS队列、Lambda函数、SQS到Lambda的触发配置，同时配置SQS队列策略允许账号A的SNS发消息，最后绑定跨账号SNS订阅
• 权限配置不要依赖默认策略：AWS默认资源策略仅开放同账号访问权限，跨账号场景必须显式添加资源策略，SQS策略建议加SourceArn条件，避免其他账号伪造SNS主题发消息的安全风险
• 部署顺序要求：先部署账号A的SNS栈，拿到SNS主题的完整ARN后，将ARN填入账号B栈的配置项，再部署账号B的栈，避免跨账号订阅创建时找不到目标资源
• 新手前置准备：第一次在对应账号、对应区域部署CDK前，先执行cdk bootstrap命令，初始化CDK部署所需的基础资源，否则会出现部署失败的问题

账号A部署栈代码：

import { Stack, StackProps, Topic, iam } from 'monocdk';
import { Construct } from 'constructs';

export class AccountASnsStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);
    // 创建业务SNS主题
    const crossAccountTopic = new Topic(this, 'CrossAccountBizTopic', {
      topicName: 'biz-event-topic'
    });
    // 配置主题策略，允许账号B的资源发布消息
    crossAccountTopic.addToResourcePolicy(
      new iam.PolicyStatement({
        effect: iam.Effect.ALLOW,
        principals: [new iam.AccountPrincipal('替换为账号B的12位账号ID')],
        actions: ['sns:Publish'],
        resources: [crossAccountTopic.topicArn]
      })
    );
  }
}

账号B部署栈代码：

import { Stack, StackProps, Queue, Function, Runtime, SqsEventSource, iam, Code } from 'monocdk';
import { Construct } from 'constructs';
import * as sns from 'monocdk/aws-sns';
import * as snsSubscriptions from 'monocdk/aws-sns-subscriptions';

export class AccountBBizStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);
    // 1. 创建接收消息的SQS队列
    const eventReceiveQueue = new Queue(this, 'EventReceiveQueue', {
      queueName: 'sns-event-receive-queue'
    });
    // 2. 配置SQS策略，允许账号A的SNS主题发送消息
    eventReceiveQueue.addToResourcePolicy(
      new iam.PolicyStatement({
        effect: iam.Effect.ALLOW,
        principals: [new iam.AccountPrincipal('替换为账号A的12位账号ID')],
        actions: ['sqs:SendMessage'],
        resources: [eventReceiveQueue.queueArn],
        conditions: {
          ArnEquals: {
            'aws:SourceArn': '替换为账号A创建的SNS主题完整ARN'
          }
        }
      })
    );
    // 3. 引入跨账号SNS主题，绑定SQS订阅
    const remoteSnsTopic = sns.Topic.fromTopicArn(
      this,
      'RemoteSnsTopic',
      '替换为账号A创建的SNS主题完整ARN'
    );
    remoteSnsTopic.addSubscription(new snsSubscriptions.SqsSubscription(eventReceiveQueue));
    // 4. 创建业务处理Lambda函数
    const bizProcessLambda = new Function(this, 'BizProcessFunction', {
      runtime: Runtime.NODEJS_18_X,
      handler: 'index.handler',
      code: Code.fromAsset('./lambda-code'), // 替换为本地Lambda代码目录路径
      functionName: 'biz-event-process-func'
    });
    // 5. 配置SQS触发Lambda
    bizProcessLambda.addEventSource(new SqsEventSource(eventReceiveQueue, {
      batchSize: 10 // 可根据业务并发需求调整批处理大小
    }));
  }
}

部署完成后分层验证问题，不要直接走全链路测试：

1. 先在账号A的SNS控制台发送测试消息，检查账号B的SQS队列是否能收到对应消息，收不到就排查两边的资源策略、订阅配置是否正确
2. SQS能收到消息后，再检查Lambda的触发配置、CloudWatch日志，确认Lambda能正常消费消息、执行业务逻辑

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