为AWS CloudFormation自定义资源部署构建多区域弹性
内容提要
本文介绍了一种为AWS CloudFormation自定义资源构建多区域高可用架构的方案。该方案采用主动-主动模式，通过DynamoDB全局表实现分布式锁和幂等性，防止重复执行；利用SNS跨区域订阅将事件扇出到主备区域；并借助Amazon Application Recovery Controller实现自动故障转移。此架构旨在解决自定义资源缺乏原生多区域支持的问题，确保业务连续性和可靠性。
延伸解读
为什么需要多区域自定义资源架构
CloudFormation自定义资源本身不支持多区域协调，当堆栈在不同区域触发事件时，缺乏内置的扇出、分布式锁和自动故障转移机制。这导致重复执行和单点故障风险。本文提出的架构通过DynamoDB全局表实现分布式锁和幂等性，利用SNS跨区域订阅扇出事件，并用ARC自动故障转移，解决了这些关键问题，为需要高可用和灾难恢复的多区域部署提供了可行方案。
主动-主动模式的关键设计
该架构采用主动-主动模式，主备区域同时处理事件，但通过DynamoDB全局表确保每个事件仅被处理一次。主区域立即处理，备区域延迟后检查锁状态，若主区域未完成则接管。这种设计既避免了单点故障，又防止了重复执行。延迟队列和条件写入是实现幂等性的核心，确保在故障转移时不会产生重复副作用。
实施注意事项与成本
部署此架构需要至少两个区域，并涉及多个服务（SNS、SQS、Lambda、DynamoDB、ARC等），成本较高。文章强调清理资源以避免额外费用。此外，延迟窗口的设置需权衡：过短可能导致备区域过早接管，过长则影响故障转移速度。建议根据业务对延迟的容忍度调整SQS延迟或可见性超时。
Q&A
AWS CloudFormation自定义资源在多区域部署中面临哪些挑战？
主要挑战包括：没有原生多区域支持，无法跨区域协调事件；多个区域处理同一事件可能导致重复执行；缺乏分布式锁机制来确保只有一个处理器处理事件；没有自动故障转移；幂等性需要开发者自行实现。
如何实现CloudFormation自定义资源的多区域弹性？
通过构建一个主动-主动架构，使用DynamoDB全局表实现分布式锁和幂等性，利用SNS跨区域订阅将事件扇出到主备区域，并借助Amazon Application Recovery Controller实现自动故障转移。
该架构如何防止重复执行自定义资源事件？
通过DynamoDB全局表实现分布式锁，使用条件写入确保只有一个区域能获取锁并处理事件。同时，每个请求的状态被记录在全局表中，实现幂等性，即使事件被重复触发，也能避免重复副作用。
该架构中主备区域是如何协同工作的？
事件通过SNS同时扇出到主备区域的SQS队列。主区域立即处理，备区域延迟处理。如果主区域在延迟窗口内未完成，备区域会检查锁并接管处理。如果主区域故障，ARC会自动触发故障转移。
该架构中使用了哪些AWS服务？
使用了AWS CloudFormation、AWS Lambda、Amazon SNS、Amazon SQS、Amazon DynamoDB全局表、Amazon CloudWatch、Amazon Application Recovery Controller等。
该架构的适用场景是什么？
适用于对业务连续性要求高的任务关键型工作负载，需要满足严格的灾难恢复目标、数据驻留要求、跨地域低延迟需求，以及需要多区域高可用性的场景。
