Multi-Region Failover with Global Accelerator

Route traffic across two AWS regions with automatic failover using Global Accelerator.

Introduction

30 Second Summary

Think about apps that need to respond instantly no matter where you are. Online games, financial trading platforms, and video calls all rely on traffic being routed to the closest healthy server, with automatic failover when something breaks.

In this project, you will build a multi-region architecture on AWS using Global Accelerator. You'll route traffic through a single static IP address, shape traffic distribution between regions, and trigger automatic cross-region failover.

What You'll Build

You'll point your browser at one static IP address, see a response from whichever AWS Region is closest to you, then break a region on purpose and watch traffic instantly reroute to the survivor.

By the end of this project, you'll have:

A single static IP address you can hit from your browser and get a response identifying which AWS Region served you.
Working traffic dials and endpoint weights that let you shift requests between regions in real time.
A proven cross-region failover setup where stopping a server causes Global Accelerator to reroute traffic to the healthy region within seconds, ignoring the traffic dial you set.
Secret Mission: Configure client affinity and fine-tune health check timing for faster failover detection.

Are there any prerequisites?

You need an AWS account and basic familiarity with launching EC2 instances and configuring security groups. Completing Project 1 (CloudFront) in this series is recommended but not required.

Before We Start

Before We Start...

Before we dive in, let's lock in what you're about to build and why it matters.

You're about to create a multi-region architecture fronted by AWS Global Accelerator, routing traffic across two AWS Regions and proving automatic failover when one region goes down.

Launch Web Servers in Two Regions

Before Global Accelerator can route traffic across regions, it needs actual endpoints to route to. Without servers responding in multiple AWS Regions, there is nothing to accelerate or fail over between.

In this step, you will launch two EC2 web servers: one in us-east-1 (N. Virginia) and one in us-west-2 (Oregon). Each server runs Apache HTTP Server and displays which region served the response.

In this step, get ready to:

Launch an EC2 instance in us-east-1 with a user data script that installs Apache.
Launch a second EC2 instance in us-west-2 with a matching setup.
Verify both instances respond in your browser with their regional greetings.

Launch an EC2 instance in us-east-1

Your first web server will live in us-east-1 (N. Virginia). You will configure the instance, open port 80 for web traffic, and supply a startup script that installs Apache automatically.

In the AWS Management Console, check the region selector in the top-right corner. Make sure it shows US East (N. Virginia) us-east-1. If it shows a different region, click the dropdown and select it.
Type EC2 in the top search bar and select EC2 from the results.
Click Launch instance.
Under Name and tags, enter GA-Web-East in the Name field.
Under Application and OS Images (Amazon Machine Image), choose Amazon Linux from the Quick Start tabs. Confirm the AMI shows Amazon Linux 2023.
Under Instance type, select t3.micro from the dropdown.
Under Key pair (login), select Proceed without a key pair (Not recommended). You will not need SSH access for this project.

Now configure the security group so that web traffic can reach your server on port 80.

Under Network settings, find the Firewall (security groups) subsection. Select Create security group.
You will see a default SSH rule already added. Click Add security group rule.
In the new rule row, set Type to HTTP. This automatically sets the port to 80 and the protocol to TCP.
Set Source type to Anywhere so the value reads 0.0.0.0/0.

Why allow traffic from anywhere?

Global Accelerator routes traffic from edge locations worldwide. For health checks and user traffic to reach your server, the security group must allow inbound HTTP from any IP address.

In a production environment, you would typically place instances behind a load balancer and restrict access further.

Finally, add the startup script that installs and configures Apache when the instance first boots.

Scroll down to the Advanced details section and click to expand it.
Scroll to the bottom of Advanced details. In the User data text field, paste the following script:

#!/bin/bash
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello from us-east-1 (N. Virginia)</h1><p>This response was served by your US East endpoint.</p>" > /var/www/html/index.html

What does this script do?

This script runs automatically when the instance starts for the first time. It installs Apache (httpd), starts the web server, enables it to survive reboots, and writes a custom HTML page identifying the region.

User data scripts run as the root user during the first boot. You never need to SSH in. The server is ready by the time the instance passes its status checks.

Review the Summary panel on the right. Confirm it shows Amazon Linux 2023 and t3.micro.
Click Launch instance.

You should see a success banner with a link to your new instance ID. Your first server is launching.

Launch failed or instance went to terminated?

If the launch fails, check that your AWS account does not have a t3.micro vCPU limit of 0 in us-east-1. Go to Service Quotas and search for "Running On-Demand Standard instances" to confirm you have at least 1 vCPU available.

Help me troubleshoot my EC2 launch failure

Launch a second EC2 instance in us-west-2

Your second web server goes in us-west-2 (Oregon). The configuration is identical except for the region greeting in the HTML page.

Click the region selector in the top-right corner of the console.
Select US West (Oregon) us-west-2.
Type EC2 in the search bar and select EC2.
Click Launch instance.
Under Name and tags, enter GA-Web-West.
Under Application and OS Images, choose Amazon Linux and confirm Amazon Linux 2023 is selected.
Under Instance type, select t3.micro.
Under Key pair (login), select Proceed without a key pair (Not recommended).

Under Network settings, select Create security group.
Click Add security group rule. Set Type to HTTP and Source type to Anywhere (0.0.0.0/0).

Expand Advanced details and scroll to the User data field. Paste the following script:

#!/bin/bash
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello from us-west-2 (Oregon)</h1><p>This response was served by your US West endpoint.</p>" > /var/www/html/index.html

What changed in this script?

The only difference is the HTML content. This instance identifies itself as us-west-2 (Oregon) so you can tell which region served your request when you test through Global Accelerator later.

Click Launch instance.

You should see a success banner confirming the instance is launching in us-west-2.

Verify both instances respond in your browser

The user data script takes 1-2 minutes to finish installing Apache after the instance starts. You need to wait for both instances to pass their status checks before testing.

In the us-west-2 EC2 console, click the instance ID link from the success banner (or go to Instances in the left sidebar).
Wait until the Instance state shows Running and the Status check column shows 2/2 checks passed. This can take 1-2 minutes. Use the refresh icon to check.
Select your GA-Web-West instance. In the details panel below, find Public IPv4 address and copy the IP address.
Open a new browser tab and paste the IP address into the address bar. Make sure the URL starts with http:// (not https://). Press Enter.

Before you look at the page, what do you expect to see based on the user data script you pasted?

You should see a page with the heading "Hello from us-west-2 (Oregon)" and a paragraph confirming the US West endpoint served the response.

Now switch back to the us-east-1 region using the region selector in the top-right corner.
Go to Instances in the EC2 sidebar. Wait for your GA-Web-East instance to show 2/2 checks passed.
Copy its Public IPv4 address and open it in a new browser tab (using http://).

You should see "Hello from us-east-1 (N. Virginia)" with its regional message.

Seeing a connection timeout or refused error?

If the page does not load, check these common causes:

Make sure you are using http:// and not https:// in the browser address bar. Apache is not configured for HTTPS.
Confirm the security group has an inbound rule for HTTP (port 80) from 0.0.0.0/0. Select the instance, click the Security tab, and check the inbound rules.
Wait a full 2 minutes. The user data script needs time to install and start Apache after the instance boots.

Help me troubleshoot my EC2 instance not responding on port 80

Both of your web servers are live and responding from separate AWS Regions. Next up, you will create a Global Accelerator that unifies them behind a single static IP address.

Create the Global Accelerator

Your two web servers are running in separate regions, each with its own public IP address. A client would need to know both addresses and manually switch between them if one server goes down.

AWS Global Accelerator solves this by providing a single pair of static anycast IP addresses that automatically route traffic to the nearest healthy endpoint. In this step, you'll create an accelerator and wire both of your servers behind it.

In this step, get ready to:

Create a standard Global Accelerator with a TCP listener on port 80.
Add endpoint groups for us-east-1 and us-west-2 with default health check settings.
Register your EC2 instances as endpoints and verify traffic routes through the accelerator's static IP.

Create the accelerator and configure the listener

The Global Accelerator console always opens in us-west-2 (Oregon), regardless of which region you were in previously. This is because Global Accelerator is a global service that uses us-west-2 for management operations.

In the AWS console search bar at the top, type Global Accelerator.
Click Global Accelerator in the search results.
Click Create accelerator.
In the Accelerator name field, enter multi-region-accelerator.
For Accelerator type, select Standard.
For IP address type, select IPv4.
Click Next.

You are now on the Add listener page. A listener defines which port and protocol the accelerator accepts incoming traffic on.

In the Ports field, enter 80.
For Protocol, select TCP.
Leave Client affinity set to None.
Click Next.

What is a listener?

A listener processes inbound connections based on the protocol and port you configure. By setting TCP on port 80, you're telling the accelerator to accept HTTP traffic and forward it to your endpoint groups.

Client affinity set to None means the accelerator distributes traffic across endpoints without sticking a client to one server. You'll experiment with changing this in the Secret Mission.

Add endpoint groups for both regions

You are now on the Add endpoint groups page. Each endpoint group maps to one AWS Region and controls how much traffic that region receives.

In the first endpoint group section, choose us-east-1 from the Region dropdown.
Leave the Traffic dial at 100.
Leave the health check settings at their defaults (TCP protocol, port 80, 30-second interval, threshold of 3).
Click Add endpoint group to add a second group.
In the second endpoint group, choose us-west-2 from the Region dropdown.
Leave the traffic dial at 100 and health check settings at defaults.
Click Next.

What is a traffic dial?

The traffic dial is a percentage (0 to 100) that controls how much traffic an endpoint group accepts. At 100, the group accepts all traffic directed to it. At 0, it accepts none under normal conditions.

You'll use this dial in the next step to steer traffic between regions and observe how Global Accelerator responds.

Add your EC2 instances as endpoints

You are now on the Create endpoints page. This is where you register the actual servers that will receive traffic from the accelerator.

In the us-east-1 endpoint group section, click the Endpoint dropdown.
Select your EC2 instance running in us-east-1.
Leave the Weight at 128.
In the us-west-2 endpoint group section, click the Endpoint dropdown.
Select your EC2 instance running in us-west-2.
Leave the weight at 128.
Click Create accelerator.

What does the weight do?

Endpoint weights range from 0 to 255 and control how traffic is distributed between endpoints within the same group. With both endpoints at 128, they each receive an equal share.

If you had two endpoints in the same group with weights 128 and 64, the first would receive roughly twice the traffic of the second.

The Global Accelerator dashboard now shows your accelerator with a status of In progress. Wait for the status to change to Deployed (this typically takes 1-2 minutes).

Click on your accelerator name to view its details.
Find the two static IP addresses listed under Static IP addresses.
Copy one of the two IP addresses.

Why two static IPs?

Global Accelerator assigns one IP from each of two independent network zones. If one network zone experiences an issue, the other IP remains reachable. This gives your accelerator built-in high availability at the network layer.

Before you test, what do you expect to see when you visit this IP address in your browser?

Open a new browser tab and paste the static IP address into the address bar.
Press Enter.

You should see either "Hello from us-east-1 (N. Virginia)" or "Hello from us-west-2 (Oregon)" depending on which region Global Accelerator considers closest to you.

Not seeing a response?

If the page doesn't load, confirm the accelerator status shows Deployed in the console. If it still shows In progress, wait another minute and refresh the console page.

If the status is Deployed but the page times out, verify that your EC2 instances are still running and that their security groups allow inbound TCP on port 80 from all sources (0.0.0.0/0).

help me troubleshoot why my Global Accelerator static IP is not returning a response from my EC2 instances

Your accelerator is live. One static IP now reaches both regions automatically. Next up, you'll manipulate traffic dials and endpoint weights to control exactly which region serves your requests.

Shape Traffic with Dials and Weights

Your accelerator is live and routing traffic to the nearest healthy region. Right now, both endpoint groups sit at 100% traffic dial with equal weight 128, so Global Accelerator simply sends you to whichever region is closest. You have no proof that you can actually control where traffic goes.

Traffic dials and endpoint weights are the two levers Global Accelerator gives you for shaping request distribution. In this step, you'll turn each lever and watch routing behavior change in real time. This is a core SAA-C03 exam objective.

In this step, get ready to:

Set the us-east-1 traffic dial to 0% and confirm all traffic shifts to us-west-2.
Adjust endpoint weights to bias traffic distribution between regions.
Set the us-west-2 traffic dial to 0% to prepare for the failover experiment.

Set the us-east-1 traffic dial to 0%

A traffic dial controls what percentage of already-directed traffic actually reaches an endpoint group. Setting a dial to 0% means no new connections route to that region. This is how teams take a region offline for maintenance without touching the instances themselves.

Return to the Global Accelerator console.
On the Accelerators page, choose your accelerator.
In the Listeners section, click the Listener ID for your port 80 listener.
Find the us-east-1 endpoint group and choose Edit endpoint group.
Change the Traffic dial from 100 to 0.
Choose Save.

What does this change do?

The traffic dial applies only to traffic that Global Accelerator has already directed to this endpoint group based on proximity. Setting it to 0 cuts off the group entirely for new connections.

Existing connections are not terminated. The updated setting applies to only new connections. Health checks are not affected by traffic dial settings.

Wait approximately 30 seconds for new connections to reflect the change.

Before you refresh your browser, what do you expect to see? Think about which region can still accept traffic now that us-east-1's dial is at 0%.

Refresh your browser tab pointing at the accelerator's static IP address.

You should see "Hello from us-west-2 (Oregon)" exclusively. Every refresh confirms that all traffic now routes to us-west-2 because us-east-1's endpoint group is dialed down to zero.

Still seeing us-east-1 responses?

Traffic dial changes only apply to new connections. Close all browser tabs pointing at the accelerator IP, wait 30 seconds, then open a fresh tab. Do not reuse a cached connection.

If you still see us-east-1 after a fresh tab, double-check that you saved the traffic dial change and that it reads 0 in the console.

help me troubleshoot why my traffic dial change isn't taking effect

Bias traffic with endpoint weights

Traffic dials control traffic at the endpoint group level. Endpoint weights work differently. They control the proportion of traffic routed to individual endpoints within a single endpoint group. Both your endpoints currently have weight 128.

First, restore the us-east-1 traffic dial to its original value. Select the us-east-1 endpoint group, choose Edit endpoint group, change the Traffic dial back to 100, and choose Save.
Now navigate to the us-east-1 endpoint group's detail page. In the Endpoint groups section, click the Endpoint group ID for us-east-1.
Choose Edit.
In the Endpoints section, find your EC2 instance. Change its Weight from 128 to 1.
Choose Save changes.

How do endpoint weights affect routing?

Global Accelerator calculates the sum of all endpoint weights in a group, then routes traffic proportionally. Your us-east-1 endpoint now has weight 1, while us-west-2 has weight 128. That means us-west-2 receives 128/129 of the traffic directed to it. The ratio is 1:128.

Weights range from 0 to 255, with 128 as the default. Setting weight to 0 stops all traffic to that endpoint entirely.

Wait 30 seconds, then refresh your browser pointing at the accelerator's static IP multiple times in a row.

You should see responses heavily favoring us-west-2 due to the 1:128 weight ratio. You may occasionally see a us-east-1 response, but the vast majority will come from us-west-2.

Seeing an even split between regions?

Make sure you changed the weight on the us-east-1 endpoint specifically, not the traffic dial. Weights are set on individual endpoints within the endpoint group detail page, not on the endpoint group edit page.

Also confirm the us-east-1 traffic dial is restored to 100 from the previous experiment. If it is still at 0, traffic can't reach the group regardless of weight.

help me figure out why my endpoint weight change isn't affecting traffic distribution

Prepare for the failover experiment

You've proven that traffic dials cut off entire regions and weights bias distribution within a region. Now you'll set up a specific configuration that will become critical in the next step: us-west-2 dialed to 0%, simulating a maintenance window where that region should receive no traffic under normal conditions.

First, reset the us-east-1 endpoint weight back to its default. Navigate to the us-east-1 endpoint group detail, choose Edit, change the Weight back to 128, and choose Save changes.
Now select the us-west-2 endpoint group. Choose Edit endpoint group.
Change the Traffic dial from 100 to 0.
Choose Save.

Before you refresh, predict: with us-west-2 dialed to 0% and us-east-1 at 100%, which region should serve your requests?

Wait 30 seconds, then refresh your browser pointing at the accelerator's static IP.

You should see "Hello from us-east-1 (N. Virginia)" exclusively. All traffic now routes to us-east-1 because us-west-2's dial is set to 0%.

Why leave us-west-2 at 0%?

This configuration sets up the key SAA-C03 exam question for the next step: what happens to us-west-2 during failover if its traffic dial is 0%? The answer will surprise you.

Still seeing us-west-2 responses?

Close all browser tabs and open a fresh one. Traffic dial changes apply only to new connections. If your browser is reusing a keep-alive connection, you'll continue seeing the old routing.

help me verify my traffic dial configuration is correct

You've now proven you can control exactly where Global Accelerator sends traffic. Next up, you'll break a region on purpose and discover what Global Accelerator does when the only healthy endpoint lives behind a traffic dial set to 0%.

Trigger Cross-Region Failover

In the previous step, you proved you can shape traffic using dials and weights. You left the us-west-2 traffic dial at 0%, meaning under normal conditions it receives zero traffic.

But what happens when us-east-1 goes down entirely? The SAA-C03 exam tests a critical behavior: whether Global Accelerator respects or ignores traffic dial settings during failover. In this step, you'll break a region on purpose and find out.

In this step, get ready to:

Stop the us-east-1 EC2 instance and watch its health state change to Unhealthy.
Confirm that failover routes traffic to us-west-2 despite its 0% traffic dial.
Restart the instance and restore normal operation across both regions.

Stop the us-east-1 instance to simulate a regional failure

To trigger failover, you need a real failure. Stopping the EC2 instance shuts down Apache, which causes the health checks on port 80 to fail.

In the AWS console, make sure you are in the us-east-1 (N. Virginia) region.
Open the EC2 service and click Instances in the left sidebar.
Select your us-east-1 instance.
Click Instance state, then Stop instance.
Confirm by clicking Stop.

Why stop and not terminate?

Stopping an instance shuts it down but keeps it available to restart later. Terminating permanently deletes it. You'll need this instance again in a few minutes to confirm recovery.

Return to the Global Accelerator console.
Select your accelerator and expand the us-east-1 endpoint group.
Watch the endpoint's health status. It takes approximately 90 seconds to change from Healthy to Unhealthy (3 consecutive failed health checks at 30-second intervals).

You should see the us-east-1 endpoint's status change to Unhealthy after about 90 seconds. Refresh the console page if the status does not update automatically.

Still showing Healthy after 2 minutes?

Confirm the instance state shows Stopped in the EC2 console (not just "Stopping"). If it is still shutting down, wait another 30 seconds.

Also verify you are looking at the correct endpoint group (us-east-1, not us-west-2).

Why isn't my Global Accelerator endpoint showing Unhealthy after stopping my EC2 instance?

Observe failover to us-west-2 despite its 0% traffic dial

The us-east-1 endpoint is now Unhealthy. The us-west-2 endpoint group still has its traffic dial set to 0%. Under normal routing rules, a 0% dial means that endpoint group receives no traffic at all.

Before you refresh your browser, think about this: do you expect the accelerator's static IP to return a response, or do you expect it to time out? Why?

Open a new browser tab and navigate to your accelerator's static IP address (the same one you used in previous steps).
Refresh the page a few times.

You should see "Hello from us-west-2 (Oregon)" in your browser. Traffic is flowing to us-west-2 even though its traffic dial is set to 0%.

Why does failover ignore the traffic dial?

This is a key SAA-C03 exam concept. When no healthy endpoints exist in the nearest endpoint group, Global Accelerator ignores the traffic dial setting and tries the three closest endpoint groups to find a healthy endpoint.

The logic prioritizes availability over your manual routing preferences. A 0% dial is meant for routine traffic shaping, not as a mechanism to permanently exclude a region from serving requests during a failure event.

Getting a timeout or no response?

Make sure you waited long enough for the us-east-1 endpoint to flip to Unhealthy. If Global Accelerator still thinks us-east-1 is healthy, it will try to route there and time out.

Confirm you are using the accelerator's static IP address, not the EC2 instance's public IP.

Why is my Global Accelerator static IP timing out during failover?

Restart the instance and restore normal routing

You have confirmed the failover behavior. Now bring us-east-1 back online and verify that Global Accelerator detects the recovery and resumes normal routing.

Switch back to the EC2 console in us-east-1.
Select your stopped instance.
Click Instance state, then Start instance.

The instance needs about 90 seconds to pass 3 consecutive health checks at 30-second intervals before Global Accelerator marks it Healthy again.

Return to the Global Accelerator console and watch the us-east-1 endpoint status.
Wait until the status returns to Healthy (refresh the console page if needed).

Once the endpoint is Healthy, refresh your browser at the accelerator's static IP. You should see responses from us-east-1 again (since it is your nearest region).

Now reset the us-west-2 traffic dial to restore normal operation. In the Global Accelerator console, select your accelerator.
Choose the us-west-2 endpoint group and click Edit endpoint group.
Change the traffic dial from 0 to 100.
Click Save.

Both endpoint groups are now at 100% traffic dial with endpoints at weight 128. Both instances are running and Healthy. Your accelerator is fully restored to normal operation.

What did you just prove?

You demonstrated the complete failover lifecycle: failure detection (3 failed health checks), automatic rerouting (ignoring the 0% traffic dial), and recovery (3 successful health checks restore routing). This is the core Global Accelerator failover behavior tested on the SAA-C03 exam.

Traffic not returning to us-east-1 after restart?

Confirm the instance shows Running in the EC2 console. The Apache web server starts automatically on boot thanks to the user data script, but it can take a minute after the instance enters the Running state.

Try visiting the instance's public IPv4 address directly. If that works but the accelerator still routes to us-west-2, wait another 30 seconds for the health checks to pass.

Why is my Global Accelerator still routing to us-west-2 after I restarted the us-east-1 instance?

Secret mission

Fine-Tune Health Checks and Client Affinity

The default health check settings mean failover takes about 90 seconds to detect. Can you cut that detection time down and add session stickiness for stateful applications?

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project has no free tier coverage for Global Accelerator, so charges accumulate every hour the accelerator exists.

Cost warning

Your Global Accelerator costs $0.025/hour just for the accelerator, plus $0.005/hour per static IPv4 address ($0.01/hour for both). Combined with EC2 instances and their public IPs, the total is approximately $0.066/hour or ~$1.58/day.

The accelerator charges even when disabled. The only way to stop all charges is to delete it entirely. We recommend deleting all resources immediately after completing this project.

Resources you used:

1 Global Accelerator with 2 static anycast IPv4 addresses ($0.035/hour combined).
1 EC2 t3.micro instance in us-east-1 with a public IPv4 address (~$0.015/hour).
1 EC2 t3.micro instance in us-west-2 with a public IPv4 address (~$0.015/hour).
1 security group in us-east-1 (no cost).
1 security group in us-west-2 (no cost).

Keep everything running

No action needed. Choose this only if you plan to continue experimenting with Global Accelerator traffic management in the next few minutes.

Your accelerator charges $0.035/hour (accelerator fee + two IPv4 addresses) whether you send traffic or not.
Your two EC2 instances add approximately $0.031/hour (compute + public IPs).
Total running cost is approximately $0.066/hour or $1.58/day.

Pause - I'll come back to this later

Stop your EC2 instances to save compute costs, but be aware the accelerator still charges even when disabled.

In the EC2 console in us-east-1, select your instance, choose Instance state, then Stop instance.
Switch to us-west-2 and stop that instance the same way.
Your accelerator continues to charge $0.035/hour even with no healthy endpoints. Disabling it does not stop charges. Only deletion stops charges.
When you return, start both instances and wait for health checks to mark them Healthy again (approximately 60-90 seconds depending on your health check settings).

Delete - I don't want to use this again

Remove all project resources to stop all charges. This is the recommended option.

Delete the Global Accelerator

Open the Global Accelerator console at https://us-west-2.console.aws.amazon.com/globalaccelerator/home.
Select your accelerator.
Choose Edit.
Select Disable accelerator, then click Save.
Wait for the accelerator status to show as disabled. The Delete button is unavailable until the accelerator is fully disabled.
Select the accelerator again and choose Delete. Confirm deletion.
You do not need to remove listeners and endpoint groups first. Deleting the accelerator removes them automatically.

What happens to the static IPs?

When you delete an accelerator, you lose the static IP addresses assigned to it permanently. You cannot recover or reuse them.

Terminate EC2 instances

In the AWS console, switch to the us-east-1 region.
Open the EC2 console, select your instance, choose Instance state, then Terminate instance.
Switch to the us-west-2 region and terminate that instance the same way.

Delete security groups

Wait until both instances show a Terminated state. You cannot delete a security group while an active instance uses it.
In us-east-1, go to EC2, then Security Groups in the left sidebar.
Select the security group you created for this project (the one allowing inbound TCP port 80 from 0.0.0.0/0).
Choose Actions, then Delete security groups. Confirm deletion.
Switch to us-west-2 and delete that region's security group the same way.

Nice Work!

Nice work! You just built a fault-tolerant, multi-region architecture fronted by AWS Global Accelerator and proved key SAA-C03 exam concepts with your own hands.

You've learned how to:

Build a multi-region architecture with two EC2 web servers in us-east-1 and us-west-2, fronted by a single Global Accelerator entry point with static anycast IPv4 addresses.
Shape traffic using traffic dials (0-100%) to cut off a region and endpoint weights (0-255) to bias traffic distribution, observing real routing changes in your browser.
Trigger and observe automatic cross-region failover, proving the exam-critical concept that Global Accelerator ignores traffic dial settings during failover and routes to the nearest healthy endpoint.
Secret Mission: Reduced failover detection time with custom health check settings (10-second interval, threshold 2) and configured client affinity (Source IP) for stateful session routing.

Ready to quiz yourself?