Resilient Multi-Region Infrastructure in AWS

AWS Multi-Region Failover Options

Introduction

On October 20, 2025, AWS experienced a major regional outage in the us‐east‐1 region (Northern Virginia) that caused widespread disruption across applications and websites worldwide. The root cause was reportedly a DNS resolution failure tied to internal networking systems within that region. Amazon News.

There is much discussion about where the blame should lie, and many fingers are pointed at AWS. Yes, one of their services caused a major outage in one of their primary regions, but AWS didn’t force companies to use only that region for their resources. Many companies that use AWS services did not experience a full outage, as they had architected their infrastructure to remove the single point of failure that reliance on one region brings.

This incident underscores a key lesson: major cloud providers and their primary regions can fail, so building for multi-region resilience is increasingly vital. As Werner Vogels (CTO at Amazon) has said many times, even back to 2016, “Failures are a given and everything will eventually fail over time”

Let’s see how you can design a multi-region infrastructure on AWS that improves availability and fault tolerance without simply doubling your cloud spending. The idea is to pick a realistic, “resilient but cost-aware” architecture.

Why multi-region matters

• If you deploy your resources to a single AWS region, then you are relying on that region to keep your application or service running. A failure in just one of the key components in that region could render your app unusable.
• Deploying to multiple regions gives you a level of fault tolerance. If a component in one region fails, you can route traffic to another region.
• Deploying to multiple regions also comes with trade-offs: higher cost, added complexity, compliance/regulation issues, and operational overhead.
• Aim for a right-sized multi-region architecture, but not necessarily complete duplication from day one.

Cost-aware multi-region design principles

Here’s how you can approach this in a cost-sensitive way:

1. Classify workloads by criticality

Not all applications need full multi-region redundancy.

• Tier 1 (business‐critical, downtime very costly) → full multi-region.
• Tier 2 (important but some downtime acceptable) → warm standby or active/passive.
• Tier 3 (non-critical) → single region with a disaster recovery plan.

2. Select an appropriate multi-region strategy

Depending on your needs and business requirements, you could investigate several different multi-region strategies. These are listed from the most complex to deliver to the least complex, but also the least capable.

• Active-Active: Both regions serve traffic concurrently; higher resilience and lower failover time, but more cost/complexity.
• Active-Passive: Primary region handles traffic; secondary region is warmed up and ready to take over in failure. Lower cost, less complexity.
• Disaster Recovery: The primary region handles all the workload, but backups are copied to a secondary region, and infrastructure-as-code is in place to build the secondary region from those backups when needed.
• You can split these approaches across the various services you provide. Adopt active-passive for less critical workloads, such as monthly reporting or time-sheet completion, and reserve active-active only for your most critical ones, such as online sales or order processing.

3. Decouple data and compute where possible

Compute (e.g., EC2, containers) could be stood up in a secondary region only on failure to save cost, or keep a pilot-light solution running that can be scaled up as required. Data replication is more complicated and is covered in more detail later.

• Use cross-region replication only for critical data.
• For less critical data, use cross-region copies of snapshots

4. Use infrastructure as code and repeatable templates

Using infrastructure-as-code solutions such as CloudFormation or Terraform, you can spin up an alternate region quickly that closely matches your primary region.

Be careful with naming standards and network layouts, as some resources are global, such as IAM roles. Either add the region name in the resource identifier so that both can exist, or separate the creation of those resources so that they are not part of the complete build

5. Practise your regional fail-overs regularly

You must practise regional failovers — it’s not enough to just know that you can create your infrastructure in another region; you have to know that it works! Use health checks, traffic routing, and data restoration from backups.

Where possible, use automation for failovers, and document the process in a runbook that all engineers have access to.

Example architecture: cost-aware multi-region setup

Here’s how you might build a multi-region architecture without just doubling your costs.

Regions

• Primary region: Choose the region based on your business requirements — we will use us-east-1
• Secondary region: select another region, such as us-west-2, that can still meet your business requirements (regulatory, latency).

Networking & DNS / routing

• Use Amazon Route 53 with health checks and failover/weighted routing so that traffic can be directed to the secondary region when the primary fails.
• Use global load-balancing services such as CloudFront or Global Accelerator where possible to minimise user-impact and regional dependency.

Compute & services

In the primary region, run your full production stack (web/API servers, databases, caches).

In the secondary region, either;

• Keep minimal baseline resources running (e.g., autoscaling group with minimal capacity + database replica) — so cost is lowered.
• Have resources defined and deployable via IaC, but only scale up on failover. This is the lowest cost, but it has the longest failover time.
• Use serverless / managed services where possible. AWS advice shows that this can help optimise cost in a multi-region batch/serverless scenario. Amazon Web Services, Inc.

Data and replication

• For databases: decide on your data replication consistency and cost implications.
• You might use active-active multi-region (if supported) for your highest critical DBs.
• Or use an active-passive solution: a primary database in your primary region, and a secondary replica in your secondary region kept up-to-date via asynchronous replication.
• For caches/session data: design so that session data can be shared globally or gracefully degraded if a region fails.

Failover process

• Use automated runbooks triggered by health checks.
• Configure DNS TTLs and failover settings in Route 53.
• During failover: monitor traffic as it flows to the secondary region, ensure database replication is not lagging.
• After failover, continue to test and fail back to the primary region when it is healthy again. An alternative would be to remain in the secondary region for a few months to ensure that all services can run properly there.

Cost-control levers

• Use minimal capacity in the secondary region.
• Use spot instances and auto-scaling where available.
• Use serverless resources such as AWS Lambda where possible.
• Use AWS Cost Explorer to monitor the cost impact of your multi-region setup and adjust as you go.

Lessons from the October 2025 outage

The recent outage of us-east-1 offers a few concrete lessons:

• Even highly mature cloud regions can suffer non-trivial failures — in this case, “DNS resolution issues within EC2 internal network” triggered widespread impact. [Reuters]
• Many services were down because they had a regional dependency and no fallback. Make sure your architecture avoids a “single point of failure” for the critical path.
• The incident emphasises the importance of routing/failover mechanisms when a region fails.
• Cost-/complexity tradeoffs matter: you might not need full active-active everywhere, but you do want a credible fallback plan so that your business doesn’t grind to a halt.

Pitfalls & trade-offs

• Latency & performance: replicating across regions may introduce higher latency.
• Data consistency: active-active multi-region introduces complexity around data consistency and conflict resolution.
• Cost: resource duplication and data transfer across regions increase costs without a direct benefit. Minimising this additional cost means making conscious trade-offs.
• Operations: multi-region means more complex monitoring, deployment pipelines, and a chance of configuration drift.
• Compliance/governance: data residency, legal, and regulatory issues may restrict your region choices or replication architecture.
• Testing & readiness: Many teams build for multi‐region but never test a failover scenario — you need to rehearse regularly.

Conclusion

Building a multi-region infrastructure on AWS doesn’t mean automatically doubling your cost or needing enterprise-level budgets. Choosing an appropriate architecture (active-passive vs active-active), designing data replication, and using infrastructure-as-code go a long way to providing a resilient solution.

Running Game Days to practise your failover readiness can significantly increase your resilience — and in light of events like the AWS us-east-1 outage of October 20, 2025, that resilience isn’t really optional any more.

References

I used ChatGPT to assist in preparing the draft for this article, but I’ve carefully read and revised each section to ensure accuracy, leveraging my 30 years in the industry and over 10 years working with multi-region solutions.

• Werner Vogels: All Things Distributed
• AWS — “Multi-Region Fundamentals”
• AWS — Multi-region batch/serverless scenarios
• Reuters — DNS resolution issues within EC2 internal network