适配内部多区域EC2实例的AWS Pub/Sub模式服务选型咨询

核心思路 #

利用SNS的扇出（Fanout）能力结合跨区域SQS订阅，配合VPC端点实现全私有网络内的消息传递，完全规避公网暴露需求，同时避免Lambda批量维护的问题。

具体实施步骤 #

• 按区域创建SQS队列：在每个部署应用B的AWS区域，创建专属的SQS标准队列。通过SQS访问策略授权对应SNS主题的消息发送权限，允许跨区域SNS主题向队列推送消息。
• 配置SNS跨区域订阅：在发布者A所在区域的SNS主题中，添加每个目标区域SQS队列的订阅（SNS原生支持跨区域订阅SQS，无需额外路由逻辑）。
• 部署VPC端点：为每个涉及的VPC创建SNS和SQS的Interface类型VPC端点，并关联到EC2实例所在的子网。所有EC2实例（A和B）将通过私有IP访问SNS/SQS，无需公网IP或NAT网关。
• 应用改造：
  • 应用A：通过VPC端点的私有解析域名向SNS主题发布消息。
  • 应用B：在各自区域内，通过本地SQS的VPC端点轮询对应队列获取消息，无需暴露自身服务地址。

方案优势 #

• 全私有网络流量：所有消息传递都在AWS私有网络（VPC+AWS骨干网）内完成，完全符合内部服务不可暴露公网的要求。
• 无Lambda运维负担：不需要为每个订阅者EC2创建Lambda，也无需在Lambda内维护路由逻辑，所有分发由SNS原生完成。
• 跨区域原生支持：SNS到SQS的跨区域订阅由AWS原生维护，可靠性和延迟都有保障，无需自行搭建跨区域消息链路。
• 弹性扩展：SQS自动处理消息堆积，应用B可根据负载调整轮询频率，适配N台订阅者的规模。

备选方案对比 #

• AWS MQ：托管的RabbitMQ/ActiveMQ，虽支持私有网络访问，但需要自行维护集群配置，运维成本高于SNS/SQS的Serverless模式。
• AppSync + VPC端点：适合实时推送场景，但需要应用B适配GraphQL订阅协议，改造复杂度高于SQS轮询。

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