Building a Highly Available Multi-Region Web Application on AWS with Global Accelerator

Adesanya Adedeji Stephen — Tue, 14 Jul 2026 20:14:25 +0000

Learn how to build a fault-tolerant web application that automatically redirects users to a healthy AWS Region during regional outages using Amazon EC2, Application Load Balancer, Route 53 Health Checks, and AWS Global Accelerator.

Author: Adedeji Adesanya

Difficulty: Intermediate

Estimated Time: 2–3 Hours

AWS Services Used:

Amazon VPC
Amazon EC2
Application Load Balancer (ALB)
Amazon Route 53 Health Checks
AWS Global Accelerator

Introduction
What You Will Build
Solution Architecture
Prerequisites
Understanding the Architecture
Project Overview

Introduction

Imagine you've built an e-commerce website hosted in the us-east-1 AWS Region.

Everything works perfectly—until an unexpected regional outage occurs.

Suddenly, your application becomes unreachable. Customers can't browse products, place orders, or make payments. Every minute of downtime affects user experience and can result in lost revenue.

This is why modern cloud applications are designed with high availability and disaster recovery in mind.

Instead of relying on a single Region, organizations deploy applications across multiple AWS Regions so that if one becomes unavailable, traffic can automatically be redirected to another healthy Region.

In this tutorial, you'll build exactly that.

By the end of this guide, you'll have a multi-region web application capable of automatically failing over between two AWS Regions using AWS Global Accelerator and Amazon Route 53 Health Checks.

Rather than simply deploying infrastructure, you'll learn how multiple AWS services work together to create a resilient architecture suitable for production environments.

What You Will Build

By the end of this tutorial, you'll have an architecture that looks like this:

At a high level, the architecture consists of:

Two independent AWS Regions
Separate networking infrastructure in each Region
One EC2 instance running the application in each Region
One Application Load Balancer per Region
Route 53 Health Checks for continuous monitoring
AWS Global Accelerator providing a single global entry point
Automatic traffic failover during outages

The end result is a web application that continues serving users even when an entire AWS Region becomes unavailable.

Why AWS Global Accelerator?

Many engineers assume Amazon Route 53 is the only solution for routing users globally.

While Route 53 is an excellent DNS service, DNS-based failover has one important limitation: DNS caching.

Because DNS records are cached by clients and Internet Service Providers, changes may not take effect immediately.

AWS Global Accelerator solves this differently.

Instead of relying on DNS propagation, it provides:

Two static Anycast IP addresses
Intelligent traffic routing through the AWS Global Network
Faster failover
Improved latency
Better user experience

For applications requiring high availability and low latency, Global Accelerator is often the preferred choice.

Prerequisites

Before beginning this project, ensure you have the following:

Requirement	Status
AWS Account	✅
Basic understanding of EC2	✅
Basic understanding of Amazon VPC	✅
Two AWS Regions enabled	✅
IAM User with AdministratorAccess (or equivalent permissions)	✅

Services Used

Throughout this project, you'll work with several AWS services.

Amazon VPC

Amazon VPC provides an isolated virtual network where your AWS resources will run. Each Region will have its own dedicated VPC to ensure complete isolation.

Amazon EC2

Amazon EC2 hosts the web application in both Regions.

Each EC2 instance runs the same application, allowing either Region to serve user requests independently.

Application Load Balancer

The Application Load Balancer distributes incoming traffic to healthy EC2 instances.

It also serves as the endpoint monitored by Route 53 Health Checks.

Amazon Route 53 Health Checks

Health Checks continuously monitor the application's availability.

If a Region becomes unhealthy, Route 53 reports the failure, allowing Global Accelerator to redirect traffic automatically.

AWS Global Accelerator

Global Accelerator acts as the application's single global entry point.

Instead of users connecting directly to a specific Region, they connect to Global Accelerator, which routes traffic to the nearest healthy endpoint.

This makes regional failover seamless and transparent to users.

Building the Network Foundation

Before we can deploy our application, we need to build the network that will host it.

In AWS, every resource lives inside a Virtual Private Cloud (VPC). Since we're building a multi-region architecture, we'll create a separate VPC in each AWS Region.

This ensures that each Region operates independently, eliminating a single point of failure.

Step 1: Create the Primary VPC (us-east-1)

Switch your AWS Region to US East (N. Virginia) – us-east-1.

From the AWS Management Console, navigate to:

VPC
→ Your VPCs
→ Create VPC

Choose VPC only and configure it as shown below.

Setting Value
Name primary-vpc
IPv4 CIDR Block 10.0.0.0/16
IPv6 None
Tenancy Default

After entering the values, click Create VPC.

Once the VPC has been created successfully, you should see it listed in the VPC dashboard.

Why a /16 CIDR Block?

You might be wondering why we chose 10.0.0.0/16.

A /16 network provides 65,536 IP addresses, giving plenty of room for future expansion.

Although our lab only uses a few EC2 instances, production environments often require additional subnets for:

Application servers
Databases
NAT Gateways
Private services
Kubernetes clusters

Planning your IP address space early helps avoid costly network redesigns later.

💡 Pro Tip: Always leave room for growth when designing cloud networks.

Step 2: Create the Secondary VPC (us-west-2)

Next, switch your AWS Region to US West (Oregon) – us-west-2.

Repeat the same process.

Navigate to:
VPC
→ Your VPCs
→ Create VPC

Use the following configuration.

Setting Value
Name secondary-vpc
IPv4 CIDR Block 10.1.0.0/16
IPv6 None
Tenancy Default

Notice that we used a different CIDR block (10.1.0.0/16) instead of 10.0.0.0/16.

This is intentional.

Each VPC must have a unique address range to avoid overlapping IP addresses. Using distinct CIDR blocks makes future networking tasks—such as VPC Peering or AWS Transit Gateway—much simpler.

Step 3: Create Public Subnets

With both VPCs in place, the next step is to create public subnets.

A subnet divides a VPC into smaller, manageable networks.

Our EC2 instances and Application Load Balancers will reside in these public subnets so they can receive traffic from the internet.

Primary Region (us-east-1)

Navigate to:

VPC
→ Subnets
→ Create subnet

Select primary-vpc and create the following subnet.

Setting Value
Name primary-public-subnet
Availability Zone us-east-1a
CIDR Block 10.0.1.0/24

Click Create subnet

Secondary Region (us-west-2)

Repeat the process in us-west-2.

Setting Value
Name secondary-public-subnet
Availability Zone us-west-2a
CIDR Block 10.1.1.0/24

Why Use a /24 Subnet?

Each /24 subnet provides 256 IP addresses.

This is more than enough for our project while leaving room for additional EC2 instances, load balancers, or other resources in the future.

Separating the VPC into smaller subnets also improves network organization and scalability.

Step 4: Attach Internet Gateways

By default, a VPC has no internet connectivity.

To allow resources inside the VPC to communicate with the internet, we need an Internet Gateway (IGW).

We'll create one for each VPC.

Navigate to:

VPC
→ Internet Gateways
→ Create Internet Gateway

For the primary Region:

Setting Value
Name primary-igw

After creating it, choose Actions → Attach to VPC, then select primary-vpc.

*Repeat the same process in us-west-2.
*
Setting Value
Name secondary-igw

What's Next?

we'll configure Route Tables, launch our EC2 instances, install the web application, and prepare the environment for load balancing.

Deploying the Web Application and Configuring the Load Balancer

At this stage, our networking foundation is complete.

Each AWS Region now has its own VPC, public subnet, and Internet Gateway. The next step is to deploy the application that users will access.

To keep the architecture consistent, we'll deploy an identical web application in both Regions. Each application will run on an Amazon EC2 instance and sit behind an Application Load Balancer (ALB).

Using identical deployments ensures that either Region can serve traffic if the other becomes unavailable.

Step 5: Create a Security Group for the Web Server

Before launching the EC2 instances, we'll create a security group that controls inbound traffic.

In the AWS Management Console, navigate to:

VPC
→ Security Groups
→ Create Security Group

Use the following configuration for the Primary Region (us-east-1).

Setting Value
Name web-server-sg
Description Security group for EC2 web servers
VPC primary-vpc

Inbound Rules
Type Protocol Port Source
HTTP TCP 80 0.0.0.0/0
SSH TCP 22 Your Public IP

Why restrict SSH?

Allowing SSH from 0.0.0.0/0 exposes your server to the entire internet. Restricting it to your public IP significantly improves security while still allowing you to administer the instance.

Repeat the same process in us-west-2, ensuring the security group is associated with secondary-vpc.

Step 6: Launch the EC2 Instances

Now we'll deploy the application servers.

Navigate to:

EC2
→ Instances
→ Launch Instance
Primary Region (us-east-1)

Use the following configuration.

Setting Value
Name primary-web-server
AMI Amazon Linux 2023
Instance Type t2.micro
Key Pair Select your existing key pair
Network primary-vpc
Subnet primary-public-subnet
Auto-assign Public IP Enabled
Security Group web-server-sg

Repeat the same steps in us-west-2, changing only the instance name to:
secondary-web-server

Step 7: Install Apache and Deploy a Simple Web Page

Once the EC2 instances are running, connect to each instance using SSH.

The output should display:

Active: active (running)

Step 8: Create the Application Homepage

Instead of using Apache's default page, we'll create a simple HTML page so it's easy to identify which Region is serving requests.

Step 9: Verify the Web Servers

Open a web browser and enter the public IP address of each EC2 instance.

You should see the custom page indicating which Region is serving the request.

This simple verification confirms that Apache is running correctly and the application is reachable before introducing the load balancer.

⚠️ Don't skip this step.

Verifying the application directly helps isolate problems early. If the page doesn't load now, it certainly won't work behind the load balancer later.

Step 10: Create an Application Load Balancer

Now we'll place each EC2 instance behind an Application Load Balancer.

Navigate to:

EC2
→ Load Balancers
→ Create Load Balancer
→ Application Load Balancer

For the Primary Region, use the following configuration.

Setting Value
Name primary-alb
Scheme Internet-facing
IP Address Type IPv4
VPC primary-vpc
Subnets Select the public subnet(s)

Listener
Protocol Port
HTTP 80

Step 11: Create a Target Group

Before the ALB can forward traffic, it needs a target group.

Configure it as follows.

Setting Value
Target Type Instances
Name primary-target-group
Protocol HTTP
Port 80
Health Check Path /

*Repeat the process in us-west-2, creating:
*
secondary-alb
secondary-target-group

Step 12: Verify Load Balancer Health

Once the Application Load Balancer has been created, wait a few minutes while it performs health checks against the registered EC2 instance.

When everything is configured correctly, the target status should change to:

Healthy

If the target remains Unhealthy, check the following:

Is Apache running?
Does the security group allow inbound HTTP (port 80)?
Is the health check path set to /?
Is the EC2 instance registered with the correct target group?

Configuring Amazon Route 53 Health Checks

So far, we've built two identical application environments:

A Primary Region in us-east-1
A Secondary Region in us-west-2

Both applications are running successfully behind their respective Application Load Balancers.

However, our architecture still has one major limitation.

If the primary application goes offline, AWS has no way of knowing that it should stop sending traffic to it.

This is where Amazon Route 53 Health Checks come into play.

They continuously monitor the health of your application's endpoints. If an endpoint becomes unhealthy, other AWS services—such as Global Accelerator—can use that information to automatically redirect traffic to a healthy endpoint.

How Route 53 Health Checks Work

At regular intervals, Route 53 sends requests to your application's endpoint.

If the application responds successfully, the endpoint is considered healthy.

If it fails to respond after a specified number of consecutive checks, Route 53 marks it as unhealthy.

In our project, we'll configure a health check for each Region's Application Load Balancer.

Step 13: Copy the Load Balancer DNS Names

Before creating the health checks, we need the DNS name of each Application Load Balancer.

Navigate to:

EC2
→ Load Balancers

Select primary-alb.

Copy the value under DNS name.

It should look similar to:

primary-alb-123456789.us-east-1.elb.amazonaws.com

Repeat the process for secondary-alb.

Step 14: Create the Primary Health Check

Navigate to:

Route 53
→ Health Checks
→ Create Health Check

Configure it using the following settings.

Setting Value
Name Primary-ALB-Health-Check
What to monitor Endpoint
Specify endpoint by Domain Name
Domain Name Primary ALB DNS Name
Protocol HTTP
Port 80
Path /
Request Interval 30 Seconds
Failure Threshold 3

Leave all other settings at their default values.

Click Create Health Check.

Step 15: Create the Secondary Health Check

Repeat the same process for the Application Load Balancer in us-west-2.

Use the following configuration.

Setting Value
Name Secondary-ALB-Health-Check
Domain Name Secondary ALB DNS
Protocol HTTP
Port 80
Path /
Request Interval 30 Seconds
Failure Threshold 3

Step 16: Verify the Health Checks

Once both health checks have been created, wait a few minutes.

Route 53 needs time to send its first requests and determine the health of each endpoint.

Initially, the status may display:

Checking...

After a short period, both health checks should report:

Healthy

Understanding the Health Check Results

When Route 53 marks an endpoint as Healthy, it means:

The endpoint is reachable.
The application is responding successfully.
The configured path (/) returned a successful HTTP response.

If an endpoint becomes Unhealthy, Route 53 will stop considering it available.

This health information becomes especially important in the next part of the tutorial, where AWS Global Accelerator uses it to decide where incoming traffic should be routed.

Troubleshooting Health Checks

If your health check doesn't become healthy after several minutes, don't panic. The issue is usually one of the following:

Problem Solution
Apache is not running Start the Apache service using sudo systemctl start httpd

Port 80 is blocked Verify the EC2 security group allows inbound HTTP traffic

Incorrect health check path Ensure the path is /

Wrong DNS name Confirm you're using the ALB DNS name, not the EC2 public IP

Target group is unhealthy Verify the EC2 instance is healthy behind the ALB

Taking a few minutes to troubleshoot now will save time later when configuring Global Accelerator.

What We Accomplished

At this point, we've successfully:

Created health checks for both Application Load Balancers.
Verified that both application endpoints are healthy.
Enabled continuous monitoring of our application.
Prepared the architecture for automatic failover.

In the next part, we'll configure AWS Global Accelerator and connect it to both Application Load Balancers. This will provide users with a single global entry point and enable automatic traffic failover whenever a Region becomes unavailable.

Configuring AWS Global Accelerator

Up to this point, we've built two independent application environments:

Primary Region (us-east-1)
Secondary Region (us-west-2)

Each environment has its own:

Amazon VPC
EC2 Instance
Application Load Balancer
Route 53 Health Check

The final piece is giving users one consistent entry point regardless of which Region is serving the application.

This is where AWS Global Accelerator comes in.

Unlike DNS-based routing, Global Accelerator provides two static Anycast IP addresses and uses the AWS global network to direct users to the best available endpoint. If a Region becomes unhealthy, traffic is automatically routed to another healthy Region with minimal disruption.

In this section, we'll configure AWS Global Accelerator and connect it to the Application Load Balancers we created earlier.

How AWS Global Accelerator Works

When a user accesses your application, they don't connect directly to an EC2 instance or an Application Load Balancer.

Instead, they connect to the Global Accelerator endpoint.

Global Accelerator evaluates the health of each configured endpoint and routes traffic to the optimal Region.

If an endpoint becomes unavailable, traffic is redirected automatically without requiring DNS updates.

Step 17: Create a Global Accelerator

From the AWS Management Console, navigate to:

AWS Global Accelerator
→ Create Accelerator

Configure the accelerator using the following settings.

Setting Value
Name Multi-Region-Web-App
IP Address Type IPv4
Enabled Yes

Leave the remaining settings at their default values.

Click Create Accelerator.

After a few moments, AWS will provision your accelerator and assign two static Anycast IP addresses.

These IP addresses remain the same even if the backend infrastructure changes.

Step 18: Configure the Listener

Once the accelerator has been created, the next step is to configure a listener.

A listener defines which ports Global Accelerator accepts from clients.

Use the following configuration.

Setting Value
Protocol TCP
Port 80

Click Next.

Step 19: Create an Endpoint Group

Global Accelerator organizes endpoints into Endpoint Groups.

Each endpoint group represents an AWS Region.

We'll create one endpoint group for each Region.

Primary Endpoint Group
Setting Value
Region us-east-1
Traffic Dial 100%
Health Check Protocol HTTP
Health Check Port 80
Health Check Path /

Repeat the process for the secondary Region.

Secondary Endpoint Group
Setting Value
Region us-west-2
Traffic Dial 100%
Health Check Protocol HTTP
Health Check Port 80
Health Check Path /

Step 20: Add the Application Load Balancers

Within each endpoint group, add the corresponding Application Load Balancer.

Endpoint Group 1
Endpoint Weight
primary-alb 128
Endpoint Group 2
Endpoint Weight
secondary-alb 128

The endpoint weight determines how traffic is distributed among endpoints within the same group. Since each group contains only one ALB, the default weight is appropriate.

Step 21: Deploy the Accelerator

Review your configuration and click Create Accelerator.

Provisioning typically takes a few minutes.

Once complete, you'll receive:

A Global Accelerator DNS name
Two static Anycast IP addresses

Your application can now be accessed through a single global endpoint instead of directly through either Application Load Balancer.

Verifying the Configuration

Open a browser and navigate to the Global Accelerator DNS name.

You should see your application load successfully.

Depending on your location and routing policies, the request may be served from either the primary or secondary Region.

At this point, everything appears normal—but the real value of this architecture becomes evident when a Region fails.

We'll test that in the next section.

Why Use AWS Global Accelerator Instead of DNS Failover?

This is a common question among engineers.

Traditional DNS failover relies on DNS record updates and caching.

Because DNS responses are cached by clients and Internet Service Providers, failover may not happen immediately.

AWS Global Accelerator takes a different approach.

Instead of relying on DNS changes, it uses the AWS global network and continuously monitors endpoint health.

This allows traffic to be redirected much faster, improving both availability and user experience.

For applications where uptime is critical, Global Accelerator is often a better choice than DNS-only failover.

What We Accomplished

At this point, we've successfully:

Created an AWS Global Accelerator
Configured a listener
Added endpoint groups for two AWS Regions
Registered both Application Load Balancers
Verified that the accelerator is healthy and ready to serve traffic The architecture is now fully configured.

In the next section, we'll intentionally simulate a regional outage to validate the failover process and observe how Global Accelerator automatically redirects traffic to the healthy Region.

Testing Automatic Failover

A highly available architecture isn't complete until it's been tested.

Up to this point, we've deployed our application across two AWS Regions, configured health checks, and set up AWS Global Accelerator to route traffic intelligently.

Now it's time to answer the most important question:

What happens if the primary Region becomes unavailable?

Instead of assuming the architecture will work as expected, we'll intentionally simulate a failure and observe how AWS responds.

Testing failover is a critical part of any disaster recovery strategy. It provides confidence that your application can continue serving users even when unexpected failures occur.

Step 22: Verify the Application Before Testing

Before simulating a failure, open the AWS Global Accelerator DNS name in your browser.

The application should load successfully.

Depending on your location and Global Accelerator's routing decisions, you should see the page served from your primary Region.

This confirms that the application is healthy and ready for testing.

Step 23: Simulate a Regional Failure

There are several ways to simulate a failure.

For this lab, we'll stop the Apache web server running on the EC2 instance in the Primary Region.

Connect to the primary EC2 instance using SSH.

At this point, the Application Load Balancer in the primary Region will no longer receive successful responses from the web server.

After several failed health checks, the target will be marked as Unhealthy.

Step 24: Observe Automatic Failover

Wait a few moments while Route 53 Health Checks detect the failure.

Once the endpoint is marked as unhealthy, AWS Global Accelerator automatically stops routing traffic to the primary Region.

Refresh your browser using the same Global Accelerator DNS name.

You should now see the application being served from the Secondary Region (us-west-2).

Notice that the URL remains exactly the same.

No DNS changes are required.

No manual intervention is needed.

From the user's perspective, the application remains available despite the failure of one Region.

This seamless transition is one of the key advantages of AWS Global Accelerator.

Step 25: Restore the Primary Region

Now let's bring the primary application back online.

Reconnect to the EC2 instance in us-east-1 and start the Apache service.

After a few successful health checks, Route 53 will mark the endpoint as healthy again.

Global Accelerator will automatically resume routing traffic to the primary Region based on its endpoint health.

What We Observed

This test demonstrates several important concepts about highly available architectures:

Application health is continuously monitored.
Failed endpoints are automatically removed from service.
Traffic is redirected without requiring DNS changes.
Users continue accessing the application through the same global endpoint.
Once the failed Region recovers, it is automatically added back into service.

These behaviors are essential for building resilient cloud applications that can withstand infrastructure failures with minimal impact on end users.

Key Takeaway

One of the biggest lessons from this project is that high availability isn't just about deploying resources across multiple Regions.

It's about designing an architecture that can detect failures, respond automatically, and recover without requiring manual intervention.

That's exactly what we've accomplished by combining Route 53 Health Checks with AWS Global Accelerator.

Cleaning Up Your AWS Resources

Congratulations! You've successfully built and tested a highly available multi-region web application on AWS.

If you created these resources in your own AWS account, it's important to remove them once you're done with the lab. Leaving resources running can result in unexpected charges, especially for services such as AWS Global Accelerator and Application Load Balancers.

In this section, we'll clean up the environment in a logical order.

Step 26: Delete the AWS Global Accelerator

Navigate to:

AWS Global Accelerator
→ Accelerators

Select the accelerator you created and choose Delete.

Deleting the accelerator first ensures that it no longer references your Application Load Balancers.

Step 27: Delete the Route 53 Health Checks

Next, navigate to:

Route 53
→ Health Checks

Delete both health checks:

Primary-ALB-Health-Check
Secondary-ALB-Health-Check

Since these health checks are no longer needed, removing them prevents unnecessary monitoring costs.

Step 28: Delete the Application Load Balancers

Navigate to:

EC2
→ Load Balancers

Delete:

primary-alb
secondary-alb

Keep in mind that AWS may take a few minutes to completely remove each load balancer.

Step 29: Delete the Target Groups

After the load balancers have been deleted, navigate to:

EC2
→ Target Groups

Delete:

primary-target-group
secondary-target-group

Target groups cannot be deleted while they are still associated with an active load balancer, which is why this step comes after deleting the ALBs.

Step 30: Terminate the EC2 Instances

Navigate to:

EC2
→ Instances

Select both EC2 instances and choose:

Instance State
→ Terminate Instance

Wait until their status changes to Terminated before proceeding.

Step 31: Delete the Security Groups

Navigate to:

VPC
→ Security Groups

Delete the custom security groups you created for this project.

If AWS prevents you from deleting a security group, double-check that no resources are still attached to it.

Step 32: Delete the Internet Gateways

Navigate to:

VPC
→ Internet Gateways

Before deleting each Internet Gateway, you'll need to detach it from its VPC.

Select the Internet Gateway, then choose:

Actions
→ Detach from VPC

Once detached, delete the Internet Gateway.

Repeat this process for both Regions.

Step 33: Delete the Subnets

Navigate to:

VPC
→ Subnets

Delete the public subnet in each Region.

AWS will prevent subnet deletion if resources still exist within it, so ensure all EC2 instances have been terminated first.

Step 34: Delete the VPCs

Finally, navigate to:

VPC
→ Your VPCs

Delete:

primary-vpc
secondary-vpc

At this point, all resources created during this project should have been removed from your AWS account.

Cleanup Checklist

Use this checklist to verify that you've removed everything:

✅ AWS Global Accelerator deleted
✅ Route 53 Health Checks deleted
✅ Application Load Balancers deleted
✅ Target Groups deleted
✅ EC2 Instances terminated
✅ Security Groups deleted
✅ Internet Gateways detached and deleted
✅ Public Subnets deleted
✅ VPCs deleted

Completing this checklist helps ensure you don't incur unnecessary AWS charges after finishing the lab.

Conclusion and Lessons Learned

Building cloud infrastructure is one thing.

Building infrastructure that can withstand failure is another.

_In this tutorial, we went beyond deploying a simple web application. We designed and implemented a highly available architecture capable of automatically redirecting traffic when an AWS Region becomes unavailable.
_
Along the way, we explored how several AWS services work together to deliver a resilient solution:

Amazon VPC provided isolated networking environments.
Amazon EC2 hosted the application in each Region.
Application Load Balancers distributed traffic and performed health checks on application instances.
Amazon Route 53 Health Checks continuously monitored endpoint availability.
AWS Global Accelerator provided a single global entry point and intelligent traffic routing.

The most valuable part of this project wasn't creating the infrastructure—it was validating that the architecture behaved as expected during a simulated regional outage. Watching traffic automatically shift to the healthy Region reinforced an important principle of cloud engineering:

A resilient architecture isn't defined by the resources you deploy. It's defined by how those resources respond when failures occur.

This project also highlighted the importance of testing disaster recovery plans. Designing for failure is only part of the process; regularly validating your recovery strategy is what builds confidence in production systems.

Production Considerations

Although this project demonstrates the core concepts of high availability and multi-region failover, there are several ways it could be enhanced for a production environment:

Replace standalone EC2 instances with Auto Scaling Groups to improve scalability and resilience.
Use Amazon RDS Multi-AZ or Amazon Aurora Global Database for highly available databases.
Secure the application with HTTPS using AWS Certificate Manager (ACM).
Protect the application using AWS WAF and AWS Shield.
Improve global performance with Amazon CloudFront.
Provision the infrastructure using Terraform or AWS CloudFormation instead of manually creating resources.
Centralize monitoring and alerting with Amazon CloudWatch and AWS CloudTrail.

These enhancements reflect how similar architectures are commonly implemented in production environments.

Final Thoughts

This project deepened my understanding of high availability, disaster recovery, and global traffic management on AWS. More importantly, it reinforced the value of designing systems with failure in mind rather than treating resilience as an afterthought.

I hope this guide has helped you understand not only how to build a multi-region architecture, but also why each component plays a critical role in delivering a reliable application.

If you followed along, I'd love to hear about your experience. Did you encounter any challenges? Were there any improvements or alternative approaches you explored? Feel free to share your thoughts in the comments, I'd be interested to learn how you approached the project.

DEV Community: Adesanya Adedeji Stephen

Building a Highly Available Multi-Region Web Application on AWS with Global Accelerator

Table of Contents

Introduction

What You Will Build

Why AWS Global Accelerator?

Prerequisites

Services Used

Amazon VPC

Amazon EC2

Application Load Balancer

Amazon Route 53 Health Checks

AWS Global Accelerator

Building the Network Foundation

Why a /16 CIDR Block?

Step 3: Create Public Subnets

Secondary Region (us-west-2)

Why Use a /24 Subnet?

Step 4: Attach Internet Gateways

What's Next?

Deploying the Web Application and Configuring the Load Balancer

Step 5: Create a Security Group for the Web Server

Step 6: Launch the EC2 Instances

Step 7: Install Apache and Deploy a Simple Web Page

Step 8: Create the Application Homepage

Step 9: Verify the Web Servers

Step 10: Create an Application Load Balancer

Step 11: Create a Target Group

Step 12: Verify Load Balancer Health

Configuring Amazon Route 53 Health Checks

How Route 53 Health Checks Work

Step 13: Copy the Load Balancer DNS Names

Step 14: Create the Primary Health Check

Step 15: Create the Secondary Health Check

Step 16: Verify the Health Checks

Understanding the Health Check Results

What We Accomplished

Configuring AWS Global Accelerator

How AWS Global Accelerator Works

Step 17: Create a Global Accelerator

Step 18: Configure the Listener

Step 19: Create an Endpoint Group

Step 20: Add the Application Load Balancers

Step 21: Deploy the Accelerator

Verifying the Configuration

Why Use AWS Global Accelerator Instead of DNS Failover?

What We Accomplished

Testing Automatic Failover

Step 22: Verify the Application Before Testing

Step 23: Simulate a Regional Failure

Step 24: Observe Automatic Failover

Step 25: Restore the Primary Region

What We Observed

Key Takeaway

Cleaning Up Your AWS Resources

Step 26: Delete the AWS Global Accelerator

Step 27: Delete the Route 53 Health Checks

Step 28: Delete the Application Load Balancers

Step 29: Delete the Target Groups

Step 30: Terminate the EC2 Instances

Step 31: Delete the Security Groups

Step 32: Delete the Internet Gateways

Step 33: Delete the Subnets

Step 34: Delete the VPCs

Conclusion and Lessons Learned

Production Considerations

Final Thoughts