# Building multi-Region resiliency for AWS CloudFormation custom resource deployment

[AWS](https://yomu.fyi/company/aws) · Raman Pujani · Jul 22, 2026

**Type:** Problem & solution

## Summary

AWS CloudFormation custom resources extend template provisioning capabilities but lack built-in multi-Region coordination, risking duplicate executions and unhandled failures during regional outages. To solve this limitation, an active-active architecture leverages Amazon Simple Notification Service topics to fan out lifecycle events across primary and secondary infrastructure Regions. The primary Region processes events immediately, whereas the secondary Region processes incoming messages after a deliberate delay implemented via Amazon Simple Queue Service. Coordination relies on Amazon DynamoDB Global Tables with conditional writes to manage distributed locking and enforce idempotency. When failures occur in the primary Region, Amazon CloudWatch alarms signal Amazon Application Recovery Controller to automate failover without manual intervention.

## Context

CloudFormation custom resources lack native multi-Region support, which creates challenges including the absence of cross-Region fan-out mechanisms, risks of duplicate executions from redundant Lambda handlers, lack of distributed locking, and no automated failover during regional outages.

## Approach / What changed

An active-active multi-Region architecture fans out custom resource events from local SNS topics to SQS queues in primary (us-east-1) and secondary (us-west-2) Regions. The primary Lambda processes immediately while the secondary Lambda waits on an SQS delay. Handlers coordinate through DynamoDB Global Tables using conditional writes for distributed locking and idempotency, with Amazon Application Recovery Controller and CloudWatch managing automated failover.

## Takeaways

- DynamoDB Global Tables use conditional writes to implement distributed locking and idempotency tracking across Regions, preventing race conditions and duplicate side effects.
- Local SNS topics in customer Regions use cross-Region subscriptions to simultaneously fan out lifecycle events to SQS queues in primary and secondary central infrastructure Regions.
- The secondary infrastructure Region applies an SQS delay queue or visibility timeout to allow the primary Region to process events first, acquiring the lock only during failover scenarios.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [AWS](https://yomu.fyi/topic/aws), [Deployment](https://yomu.fyi/topic/deployment), [Reliability](https://yomu.fyi/topic/reliability), [Serverless](https://yomu.fyi/topic/serverless)

[Read original post](https://aws.amazon.com/blogs/architecture/building-multi-region-resiliency-for-aws-cloudformation-custom-resource-deployment)