Resilience, Migration, and Business Continuity · Topic 4 of 6
Multi-Region Failover and Resilient Architectures
Build self-healing AWS designs and multi-Region failover with Route 53 health checks, Global Accelerator, ARC, and multi-cluster Amazon EKS and Amazon ECS.
- 6 min
- Includes a diagram
- Self-healing in a Region is Auto Scaling plus load balancer health checks across AZs.
- ARC zonal shift and autoshift move traffic away from one impaired AZ.
- Route 53 failover uses DNS and health checks; Global Accelerator uses static anycast IPs.
What it is
A resilient architecture keeps working when parts of it fail. Redundancy removes single points of failure, fault tolerance absorbs a failure without user impact, and self-healing replaces what broke without a person stepping in.
Multi-Region designs extend this to the loss of a whole Region. They need two things: data already present in the second Region, and a reliable way to move traffic there.
How it works
Redundancy and self-healing inside a Region
Spread every tier across at least two Availability Zones. An Auto Scaling group behind an Elastic Load Balancing load balancer replaces instances that fail health checks, which is the basic self-healing loop.
| Layer | Resilient pattern |
|---|---|
| Compute | Auto Scaling group across AZs with ELB health checks |
| Containers | ECS services or EKS deployments spread across AZs |
| Database | RDS Multi-AZ or Aurora with replicas in other AZs |
| Messaging | Amazon SQS between tiers so a slow consumer does not drop work |
| Dependencies | Timeouts, retries with backoff and jitter, circuit breakers |
Loose coupling is part of fault tolerance. A queue between tiers means the front end keeps accepting work while the back end recovers.
Amazon Application Recovery Controller (ARC) zonal shift moves traffic for supported resources away from an impaired AZ to healthy AZs in the same Region. A zonal shift is manual and temporary. Zonal autoshift lets AWS start the shift for you when its internal telemetry detects an AZ impairment.
Multi-Region traffic failover
| Option | How it fails over | Choose it when |
|---|---|---|
| Route 53 failover routing with health checks | DNS answers change when the primary endpoint is unhealthy | Simple active/passive with DNS |
| AWS Global Accelerator | Static anycast IP addresses route to the healthy endpoint group | Clients cache DNS or need fixed IPs; fast failover |
| ARC routing control | Operator flips on/off controls that drive Route 53 health checks, with safety rules | Controlled, human-approved Regional failover |
| ARC Region switch | Plans orchestrate recovery steps across Regions and accounts | Large, multi-step Regional recovery |
Global Accelerator avoids DNS caching delays because the client keeps the same IP addresses. Route 53 health checks are simple and cheap but depend on clients honoring TTLs.
ARC routing control adds safety rules, for example that only one of the active or standby replicas is enabled. ARC readiness check closed to new customers on April 30, 2026, and AWS now points multi-Region applications to ARC Region switch instead.
Data in the second Region
Traffic failover is useless without data. Use Aurora Global Database, DynamoDB global tables, S3 Cross-Region Replication or cross-Region backup copies, as covered on the DR strategies page.
A failover runbook must also promote the database, for example promoting a secondary Aurora cluster to accept writes, before traffic shifts.
Multi-cluster container strategies
A single cluster is a single blast radius: a bad upgrade, a broken add-on or a control plane problem can affect every workload in it. Running more than one cluster limits that.
| Pattern | Description | Trade-off |
|---|---|---|
| One cluster per AZ (cell based) | Independent clusters, traffic spread across them | Smaller blast radius, more clusters to run |
| Active/passive across Regions | Standby cluster in a second Region | Lower cost, slower recovery |
| Active/active across Regions | Clusters in two Regions both serve traffic | Fastest recovery, needs multi-Region data |
Keep clusters identical through infrastructure as code and GitOps style deployment, so the standby is not a hand-built copy that drifted. Replicate images with Amazon ECR cross-Region replication so the second Region does not depend on the first.
Put Route 53 or Global Accelerator in front of the per-cluster load balancers to move traffic between clusters. State must live outside the cluster, in a replicated data store.
For Amazon ECS, deploy the same service and task definitions in each Region and front them the same way. ECS with Fargate removes cluster node management in both Regions.
How the exam asks about this
- "Clients hard-code IP addresses and Regional failover must not wait on DNS caches." -> AWS Global Accelerator with endpoint groups in two Regions.
- "Regional failover must be a deliberate, operator-approved action with guardrails against both Regions being active." -> ARC routing control with safety rules.
- "A failed EKS upgrade once took down every application in the cluster." -> Run multiple clusters (per AZ or per Region) behind Route 53 or Global Accelerator, deployed from the same code.
What to remember for the exam
- Self-healing in a Region is Auto Scaling plus load balancer health checks across AZs.
- ARC zonal shift and autoshift move traffic away from one impaired AZ.
- Route 53 failover uses DNS and health checks; Global Accelerator uses static anycast IPs.
- ARC routing control gives safe, manual Regional failover; Region switch orchestrates multi-step plans.
- Data must already be in the second Region; traffic failover alone is not DR.
- Multiple container clusters reduce blast radius; keep them identical with code and replicate images.
Do not rely on creating or editing resources in the impaired Region during an event. Failover should depend on actions that work from the healthy Region.
Common mistakes
Calling Multi-AZ a DR plan for a Region outage. Multi-AZ protects against an AZ failure only. A Regional event needs data and capacity in another Region.
Building a standby cluster by hand. A manually built cluster drifts from production and fails when needed. Deploy both from the same templates and pipelines.
Forgetting the database promotion step. Shifting traffic to a Region whose database is still read-only causes write failures, so promote it first.
Check yourself
Why does AWS Global Accelerator fail over faster for clients than DNS based failover?
Clients keep the same static anycast IP addresses, so there is no wait for cached DNS records to expire.
What does an ARC safety rule add to routing control?
A guardrail you define, such as allowing only one of the active or standby replicas to be enabled at a time.
How do multiple EKS clusters improve availability?
They limit the blast radius of a cluster level failure, and traffic can move to a healthy cluster through Route 53 or Global Accelerator.
Topic 4 of 6 in Resilience, Migration, and Business Continuity
Test yourself on Resilience, Migration, and Business Continuity
The full AWS SAP-C03 question bank has 850 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by AWS. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.