devgo.cn核心观点
- CloudFormation自定义资源是扩展基础设施即代码能力的关键，用于第三方API集成、复杂初始化、跨账户编排、自定义合规检查等，但缺乏原生多区域支持，带来重复执行、无故障转移、无分布式锁等挑战。
- 本文提出Active-Active多区域架构，通过SNS跨区域扇出到主次两个SQS队列，主Lambda立即处理，次Lambda延迟处理，结合DynamoDB Global Table分布式锁和ARC自动故障转移，实现高可用和幂等性。
- 分布式锁机制：DynamoDB Global Table通过条件写入确保仅一个区域获取锁，避免重复执行；幂等性通过状态追踪保证重试和故障转移不产生重复副作用。
- 自动故障转移：CloudWatch监控SQS队列深度和Lambda健康，触发ARC自动将流量切换到次区域，无需人工干预。
- 该架构适用于对区域故障不能容忍的关键任务工作负载，支持多个客户区域同时使用，具有可扩展性。
内容精讲
CloudFormation自定义资源允许用户在模板中嵌入自定义逻辑，通过Lambda处理Create/Update/Delete生命周期事件。典型用例包括：第三方API集成（如DNS提供商、SaaS）、数据库初始化与密钥生成、跨账户编排、自定义合规检查、以及尚未原生支持的资源类型。自定义资源将CloudFormation从单纯的资源预配器转变为可扩展的编排引擎。
然而，多区域部署时面临一系列硬伤：无原生扇出机制（各区域独立触发）、重复执行风险（同一Lambda部署多区域可能重复处理）、无分布式锁（无法确保仅一个处理器处理）、无自动故障转移（主区域失败无法自动路由）、幂等性完全依赖开发者自行实现。这些缺口迫使团队要么接受单区域风险，要么构建复杂定制方案。
本文提出的Active-Active架构基于四个核心原则：双区域始终在线、无重复执行（DynamoDB Global Table分布式锁）、幂等性机制（状态追踪）、全自动故障转移（ARC）。架构使用主区域us-east-1和次区域us-west-2作为基础设施区域，客户区域（如us-east-1、eu-west-1、ap-southeast-1）的CloudFormation栈触发事件时，通过SNS发布到本地主题，该主题配置跨区域订阅，同时将事件扇出到主次两个SQS队列。
主SQS队列立即触发主Lambda处理：先检查DynamoDB Global Table中该请求的锁状态，通过条件写入获取锁（仅当无锁时成功），然后执行业务逻辑，通过预签名URL向CloudFormation发送成功或失败响应，最后更新DynamoDB状态标记为已处理。次SQS队列配置延迟（SQS延迟队列或可见性超时），延迟后触发次Lambda：检查DynamoDB副本中的锁，若主已处理则跳过；若主未处理则获取锁并执行（故障转移场景）。延迟的目的是给主区域优先处理时间。
DynamoDB Global Table是协调核心，双向复制保持主次区域状态一致。表记录锁状态（哪个区域持有锁）、幂等性记录（请求是否已处理）、请求状态（完整生命周期）。CloudWatch监控SQS队列深度和Lambda健康，作为故障转移的早期预警。当主区域故障时，CloudWatch触发ARC自动故障转移到次区域，无需人工干预。
该架构避免了单区域设计的单点故障，也防止了朴素多区域方案的重复处理。适用于对区域故障不能容忍的关键任务工作负载，支持多个客户区域同时使用。清理时需删除所有区域的相关资源（ARC、SNS、SQS、DynamoDB、Lambda、CloudWatch日志、IAM角色等）以避免额外费用。
阅读价值
适合AWS基础设施工程师、云架构师和平台工程团队。读完可掌握构建多区域CloudFormation自定义资源高可用架构的方法，理解分布式锁、幂等性设计、自动故障转移等关键模式，并可直接参考架构图进行实现。
内容与图片版权归原作者所有 · 原文: https://aws.amazon.com/blogs/architecture/building-multi-region-resiliency-for-aws-cloudformation-custom-resource-deployment/