Skip to main content

Command Palette

Search for a command to run...

What Happens When an AWS Region Goes Down?

Designing a simple multi-region failover architecture using Amazon Route 53 and custom API domains.

Updated
4 min read
What Happens When an AWS Region Goes Down?
A
Software Engineer specializing in full-stack web development using Angular, Node.js, and React. I build scalable web applications, design RESTful APIs, and work with cloud technologies on AWS. I’ve worked on real-world platforms across healthcare and hospitality, integrating AI-powered features like chatbots and document automation using AWS services. I enjoy simplifying complex frontend and backend concepts into practical guides for developers. Here I write about: • Web development • Backend architecture & APIs • Cloud & AI integrations • Lessons from building real-world projects Basically, documenting my journey as a developer.

Introduction

When building applications on AWS, many developers deploy their backend in a single region. It works perfectly most of the time, but what happens if that region becomes unavailable?

AWS outages are rare, but they do happen. If your application depends on only one region, your entire system may go offline.

In this article, we will understand:

  • What happens when an AWS region goes down

  • Which AWS services are global vs regional

  • How to design a simple failover architecture


Understanding AWS Regions

AWS infrastructure is divided into regions, and each region contains multiple Availability Zones (AZs).

Example regions:

  • ap-south-1 – Mumbai

  • us-east-1 – Virginia

  • eu-west-1 – Ireland

If your backend runs entirely in one region and that region fails, your entire application can become unavailable.


Global vs Regional AWS Services

Some AWS services are global, while others operate in a specific region.

Global Services

  • Amazon Route 53 – Global DNS and traffic routing

  • Amazon CloudFront – Global content delivery network

These services are not tied to a single region and can route users to different regions.

Regional Services

  • AWS Lambda

  • Amazon API Gateway

  • Amazon RDS

These services run inside specific regions.

Mixed Behavior

  • Amazon S3

S3 buckets exist in a region, but the service has a global namespace and high availability across AZs.


The Problem with Hardcoded Region Endpoints

Many frontend applications directly call API Gateway URLs like:

https://abc123.execute-api.ap-south-1.amazonaws.com

This tightly couples your application to one region.

If that region goes down, the frontend cannot reach the backend.

Architecture:

Problem:

If the Mumbai region (ap-south-1) goes down:

  • The frontend cannot reach the API

  • Users see errors

  • Your entire application becomes unavailable

Your whole application stops.


Better Approach: Use a Custom Domain

Instead of calling a regional API URL, use a domain like:

https://api.example.com

The frontend always calls this domain, while DNS decides where the request goes.

Architecture:

Solution:

If Region A fails:

Route53 → automatically routes traffic → Region B

Users barely notice.


Request Flow Example

If the primary region fails, Route53 automatically routes traffic to the secondary region.


Benefits of This Architecture

  • No region dependency in the frontend

  • Automatic failover

  • Improved availability

  • Global performance improvements

Architecture Risk Complexity
Single Region Region outage breaks app Simple
Multi-AZ Data center failure protected Medium
Multi-Region Region failure protected Complex

Practical Tip for Developers

A simple way to implement this architecture:

  1. Deploy your backend in two regions

  2. Use Amazon Route 53 health checks

  3. Configure failover routing

  4. Use Amazon CloudFront or a custom domain like:

https://api.example.com

Now, if the primary region fails, traffic automatically shifts to the backup region.


How You Can Implement This in AWS (Step-by-Step)

Here is a simplified way to implement this architecture using Amazon Web Services.

1. Deploy Backend in Two Regions

Deploy the same backend stack in two regions:

  • Primary region: ap-south-1 (Mumbai)

  • Secondary region: ap-southeast-1 (Singapore)

Each region contains:

2. Create a Custom API Domain

Instead of calling the regional endpoint:

https://abc123.execute-api.ap-south-1.amazonaws.com

Create a custom domain like:

https://api.example.com

You can configure this using Amazon API Gateway.

3. Configure DNS Failover

Use Amazon Route 53 to manage DNS routing.

Create two records:

Primary Record

api.example.com → Region A API

Routing: Failover (Primary)

Health Check: Enabled

Secondary Record

api.example.com → Region B API

Routing: Failover (Secondary)

If the primary region fails, Route53 automatically routes traffic to the backup region.

4. Optional: Add Global CDN

For even better performance and caching, you can place Amazon CloudFront in front of the API.

Benefits:

  • Faster global latency

  • Additional resilience

  • Edge caching


Final Thoughts

While full multi-region setups can be complex, understanding global services like Route53 and CloudFront helps you design more resilient systems.

Even simple architectural decisions like using a custom domain instead of regional endpoints can significantly improve reliability.

Have you ever implemented a multi-region architecture on AWS, or are you still running everything in a single region? I’d love to hear how you handle reliability in your systems.