Route 53 Traffic Routing Policies

Configure weighted, latency, and multivalue DNS routing across AWS regions.

Introduction

30 Second Summary

When you visit a global website, you get connected to a server near you without thinking about it. Behind the scenes, DNS routing policies decide which server responds to each user based on location, traffic load, or server health.

In this project, you will configure multiple Route 53 routing policies in a hosted zone and use the console's Test Record tool to watch DNS resolve to different endpoints depending on weights, latency, and health check status. No domain purchase required.

What You'll Build

You will use Route 53's built-in Test Record tool to simulate queries from different locations, see Route 53 pick different servers based on the routing policy you configured, and deliberately break a health check to watch an unhealthy IP vanish from DNS responses in real time.

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

A weighted routing configuration that splits traffic 70/20/10 across three endpoints, verified by running the Test Record tool repeatedly and watching the IP distribution match your weights.
A latency-based routing setup where Route 53 picks the closest AWS region automatically, proven by simulating queries from different global locations using the console's Test Record tool.
A multivalue answer routing record set paired with health checks, where you stop a server and confirm Route 53 removes the unhealthy IP from DNS responses within minutes.
A complete SAA-C03 routing policy decision framework so you know exactly when to choose weighted, latency, geolocation, geoproximity, multivalue, or IP-based routing on exam day.
Secret Mission: Configure geolocation routing with continent-level records and a Default catch-all, then prove what happens when the Default record is missing.

Do I need to buy a domain?

No. You will create a hosted zone for a practice domain name you do not own. Route 53 lets you create records in any hosted zone regardless of domain ownership. You will verify all routing behaviour using the console's Test Record tool, which works without public DNS resolution.

This project assumes you have an AWS account and are familiar with Route 53 health checks and record types from the earlier projects in this series.

Before We Start

Before any hands-on work, let's lock in what you're about to build and why it matters.

Launch Regional Web Servers

Route 53 routing policies need real endpoints to route traffic to. Without servers running in different AWS regions, there is nothing meaningful for Route 53 to choose between when making routing decisions.

In this step, you will launch two simple web servers in separate regions. Each server displays which region it lives in, so you can visually confirm which endpoint Route 53 selected later in the project.

In this step, get ready to:

Launch an EC2 instance in us-east-1 serving a region identifier page.
Launch a second EC2 instance in us-west-2 serving a different region identifier.
Verify both servers are reachable via browser.

Launch the us-east-1 web server

Your first EC2 instance will run in US East (N. Virginia) and serve a page that identifies its region.

In the AWS Management Console, check the region selector in the top-right navigation bar.
Select US East (N. Virginia) us-east-1 if it is not already selected.
Type EC2 in the search bar at the top and select the EC2 service.
Click Launch instance on the EC2 Dashboard.

The launch wizard opens as a single page where you configure all the instance settings.

Under Name and tags, enter route53-east in the Name field.
Under Application and OS Images (Amazon Machine Image), choose Quick Start and select Amazon Linux.
Confirm the selected AMI is Amazon Linux 2023 (this is the default).
Under Instance type, select t2.micro.
Under Key pair (login), choose Proceed without a key pair (Not recommended). You will not need SSH access for this project.
Under Network settings, check the box labelled Allow HTTP traffic from the internet. This creates a security group rule allowing inbound traffic on port 80.

What is a security group?

A security group acts as a virtual firewall for your EC2 instance. By allowing HTTP on port 80, you are telling AWS to let web browsers reach the server. Without this rule, the instance would silently drop all incoming HTTP requests.

Now you need to add a startup script that installs a web server automatically when the instance boots.

Scroll down and expand the Advanced details section at the bottom of the page.
Scroll to the User data field at the very bottom of this section.
Paste the following script into the User data field:

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Region: us-east-1</h1>" > /var/www/html/index.html

What does this script do?

yum update -y updates the operating system packages.
yum install -y httpd installs the Apache web server.
systemctl start httpd starts the web server immediately.
systemctl enable httpd ensures it starts automatically on reboot.
The final line creates a simple HTML page displaying Region: us-east-1 so you can identify this server by visiting its IP.

Click Launch instance in the Summary panel on the right.
Wait for the success message, then click View all instances.
Wait until the Instance state column shows Running and both Status checks show green (this takes 1-2 minutes).
Select your route53-east instance and find the Public IPv4 address in the instance details panel below.
Copy this IP address and save it somewhere you can reference later.

Open a new browser tab, paste the public IP, and press Enter. You should see a page displaying Region: us-east-1.

Not seeing the page?

Make sure you are using http:// (not https://) in the browser address bar. The server only listens on HTTP port 80.
Confirm both status checks are green. The User Data script needs a minute or two to install and start Apache after the instance reaches Running state.
Verify the security group allows HTTP inbound. Select your instance, click the Security tab, and confirm an inbound rule exists for port 80 with source 0.0.0.0/0.

Still stuck? Help me troubleshoot why my EC2 instance is not serving the web page on port 80.

Launch the us-west-2 web server

Your second instance will run in US West (Oregon) with nearly identical configuration. The only difference is the HTML content that identifies this server as us-west-2.

Click the region selector in the top-right of the console navigation bar.
Select US West (Oregon) us-west-2.
Navigate to the EC2 service and click Launch instance.
Under Name and tags, enter route53-west.
Under Application and OS Images, choose Quick Start and select Amazon Linux (Amazon Linux 2023).
Under Instance type, select t2.micro.
Under Key pair (login), choose Proceed without a key pair (Not recommended).
Under Network settings, check Allow HTTP traffic from the internet.

Expand Advanced details and scroll to the User data field.
Paste the following script (note the region identifier is different):

#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Region: us-west-2</h1>" > /var/www/html/index.html

Click Launch instance in the Summary panel.
Click View all instances and wait for the instance state to show Running with green status checks.
Select your route53-west instance and copy the Public IPv4 address.
Save this IP address alongside your us-east-1 IP.

Verify both servers are reachable

Before you configure any Route 53 routing policies, you need to confirm both web servers respond correctly. What do you expect to see when you visit each IP in your browser?

Open a browser tab and navigate to http:// followed by your us-east-1 public IP.
Confirm you see Region: us-east-1 displayed on the page.
Open another tab and navigate to http:// followed by your us-west-2 public IP.
Confirm you see Region: us-west-2 displayed on the page.

Both pages load with their correct region identifier. You now have two distinct endpoints that Route 53 can route traffic between.

Keep these IPs handy

You will reference these two public IPv4 addresses throughout the rest of this project when creating Route 53 records. Consider keeping them in a text file or sticky note on your desktop.

Your regional web servers are live and ready. Next up, you will create weighted routing records in Route 53 and watch it distribute DNS queries across your endpoints in specific proportions.

Configure Weighted Routing

Your two servers are live. If you create a standard A record in a hosted zone, it can only point to one of them.

Weighted routing solves this by letting you assign a proportion to each endpoint. Route 53 then distributes DNS responses according to those proportions. This is exactly how blue/green deployments and A/B testing work in production.

In this step, get ready to:

Create a practice hosted zone for a domain you do not own.
Create three weighted A records that split traffic 70/20/10 across your endpoints.
Verify the traffic distribution by running repeated queries using the Route 53 Test Record tool.

Create a practice hosted zone

You do not need to own a domain to create a hosted zone in Route 53. You can create a hosted zone for any domain name and configure records inside it. The console's Test Record tool queries the hosted zone directly, so you can verify all routing behaviour without public DNS resolution.

Type Route 53 in the AWS console search bar and select the Route 53 service.
Click Hosted zones in the left navigation pane.
Click Create hosted zone.
In the Domain name field, enter routing-lab.com.
Leave Type set to Public hosted zone.
Click Create hosted zone.

Route 53 creates the hosted zone and opens it. You should see the default NS and SOA records already listed.

Why does this work without owning the domain?

Route 53 lets anyone create a hosted zone for any domain name. The zone only receives real internet traffic if the domain's registrar points its name servers at this hosted zone. Since you are not doing that, no public traffic will reach these records. The Test Record tool queries the zone's configuration directly, bypassing public DNS entirely.

Create three weighted A records in your hosted zone

Weighted routing works by creating multiple records with the same name and type, each assigned a numeric weight. Route 53 responds to queries based on the ratio of each record's weight to the total weight of the group.

In your routing-lab.com hosted zone, click Create record.
In the Record name field, enter weighted as the subdomain.
Set Record type to A.
For Routing policy, select Weighted.

You now need to add three weighted records inside this record set. Each record gets its own IP, weight, and unique ID.

For the first record, enter your us-east-1 instance's public IP in the Value field.
Set TTL (seconds) to 60.
Set Weight to 70.
In the Record ID field, enter east-primary.
Click Add another record to add the second weighted record.

For the second record, enter your us-west-2 instance's public IP in the Value field.
Set TTL (seconds) to 60.
Set Weight to 20.
In the Record ID field, enter west-secondary.
Click Add another record to add the third weighted record.

For the third record, enter 198.51.100.1 in the Value field.
Set TTL (seconds) to 60.
Set Weight to 10.
In the Record ID field, enter canary.
Click Create records to save all three.

What does this configuration do?

You created three A records that all share the same name (weighted.routing-lab.com). Route 53 calculates each record's share by dividing its weight by the total (70 + 20 + 10 = 100).

Approximately 70% of DNS queries return the us-east-1 IP, 20% return the us-west-2 IP, and 10% return the canary IP. The 60-second TTL means resolvers cache each answer briefly, allowing you to observe the rotation quickly.

Your hosted zone should now show three new A records under weighted.routing-lab.com.

Test routing and simulate weight changes in the console

The Route 53 console has a built-in test tool that lets you check how Route 53 responds to queries without relying on external resolvers or caching behaviour.

Return to your hosted zone in the Route 53 console.
Click Test record.
In the Record name field, enter weighted.
Set the record type to A.
Click Get Response.

Run Get Response several times. Each time, note which IP is returned in the Response returned by Route 53 section. You should see the responses rotate across your three IPs, with the weight-70 IP appearing most often.

Now simulate disabling an endpoint by removing its traffic share.

Close the test tool and return to your record list.
Select the east-primary record and click Edit record.
Change the Weight from 70 to 0.
Click Save.

Click Test record again and run Get Response several times.

What do you expect to see now that the east-primary weight is 0?

Route 53 should return only the us-west-2 IP or the canary IP. The us-east-1 IP no longer appears because its weight is 0. This demonstrates how weighted routing enables zero-downtime deployments. You can drain traffic from one endpoint completely before taking it offline.

What happens when all weights are zero?

If you set the weight to 0 for all records in the group, Route 53 routes traffic to all resources with equal probability. Setting a single record to 0 removes it from rotation, but setting ALL to 0 does not disable routing entirely.

Before continuing, change the east-primary weight back to 70 and click Save.

Test Record still showing the east IP after setting weight to 0?

The Test Record tool reads directly from the hosted zone configuration. If you still see the old IP, confirm you clicked Save after editing the weight. Refresh the hosted zone records list to verify the weight shows as 0.

help me troubleshoot why Route 53 Test Record still returns my east IP after I set its weight to 0

You have seen how weighted routing distributes DNS queries across multiple endpoints by proportion. Next, you will configure latency-based routing so Route 53 automatically sends users to the closest region for the best performance.

Configure Latency-Based Routing

Your weighted routing configuration splits traffic by fixed percentages. That works well for A/B testing, but it ignores where your users are located.

For a global application, you want users automatically routed to the nearest region for the best performance. Latency-based routing solves this by using AWS's own latency measurements between users and regions to pick the fastest endpoint.

In this step, get ready to:

Create latency-based A records pointing to your two regional EC2 instances.
Use the Route 53 Test Record tool to simulate queries from different geographic locations.
Understand how EDNS0 client subnet improves Route 53's location accuracy.

Create latency-based A records

Unlike weighted routing where you manually set percentages, latency-based routing lets Route 53 decide which endpoint to return based on which AWS Region gives the user the lowest latency.

Return to your Route 53 hosted zone in the AWS Management Console.
Click Create record.
In the Record name field, enter latency (this creates latency.routing-lab.com).
Set Record type to A.
In the Value field, enter your us-east-1 instance's public IPv4 address.
Set TTL to 60 seconds.
Under Routing policy, select Latency.
For Region, select US East (N. Virginia).
In the Record ID field, enter east-latency.
Click Create records.

You should see the new latency record appear in your hosted zone's record list.

Now create the second latency record for your us-west-2 instance.

Click Create record again.
In the Record name field, enter latency (same name as the first record).
Set Record type to A.
In the Value field, enter your us-west-2 instance's public IPv4 address.
Set TTL to 60 seconds.
Under Routing policy, select Latency.
For Region, select US West (Oregon).
In the Record ID field, enter west-latency.
Click Create records.

Your hosted zone now has two latency-based A records under latency.routing-lab.com. Both should appear in the record list.

Why use the same record name for both?

Just like weighted routing, latency-based routing groups records by name. Route 53 sees both records under latency.routing-lab.com and picks the one in the region with the lowest latency to the user.

The Region you set on each record tells Route 53 where that endpoint lives. Route 53 then uses its own latency data between users and AWS data centers to make the routing decision.

Test latency routing with the Route 53 Test Record tool

The Route 53 console includes a Test Record tool that lets you simulate DNS queries from different locations. This is how you verify latency routing without physically being in another region.

In your hosted zone, click Test record (at the top of the records list).
In the Record name field, enter latency.
Set Type to A.
In the Resolver IP address field, enter 72.21.210.29 (a resolver in the eastern United States).
Click Get response.

Route 53 should return your us-east-1 instance's IP address. The eastern resolver is closest to the N. Virginia region, so Route 53 picks that endpoint.

Now simulate a query from the western United States.

Change the Resolver IP address to 54.240.193.1 (a resolver in the western US/Asia Pacific region).
Click Get response.

This time, Route 53 should return your us-west-2 instance's IP address. The western resolver has lower latency to Oregon, so Route 53 routes accordingly.

What is the Resolver IP address field?

When a user visits your domain, their DNS request goes through a DNS resolver (like their ISP's resolver or a public resolver like Google DNS). Route 53 uses the resolver's IP address to estimate the user's geographic location.

The Test Record tool lets you enter any resolver IP to simulate what Route 53 would return for a query coming from that resolver's location. If you leave the field empty, Route 53 defaults to a resolver in us-east-1.

Understand EDNS0 client subnet

There is a problem with using only the resolver's IP to estimate location. What if a user in New York is using a DNS resolver hosted in California?

Route 53 would see the California resolver IP and route the user to us-west-2. That is the wrong decision for a user who is physically closer to us-east-1.

What is EDNS0 client subnet?

EDNS0 client subnet (ECS) is a DNS extension that solves this problem. When a DNS resolver supports ECS, it sends Route 53 a truncated version of the user's actual IP address (the first 24 bits for IPv4, 64 bits for IPv6).

Route 53 uses this truncated IP to determine the user's location more accurately than the resolver IP alone. Without ECS support, Route 53 falls back to using the resolver's source IP to approximate location.

This applies to latency, geolocation, geoproximity, and IP-based routing. For the SAA-C03 exam, know that EDNS0 client subnet improves routing accuracy when the resolver is geographically distant from the actual user.

Try this in the Test Record tool to see EDNS0 in action.

In the Resolver IP address field, enter 54.240.193.1 (the western resolver).
In the EDNS0 client subnet IP field, enter 72.21.210.29 (simulating a user actually located in the eastern US).
Leave the Subnet mask at its default value of 24.
Click Get response.

Before you check the result, predict which IP Route 53 will return. The resolver is in the west, but the EDNS0 client subnet tells Route 53 the actual user is in the east. Which region will Route 53 pick?

Route 53 returns your us-east-1 IP. Even though the resolver is in the western US, the EDNS0 client subnet override tells Route 53 the user is actually in the east. Route 53 trusts the more specific location data.

Why does this matter for the exam?

The SAA-C03 expects you to know that Route 53 uses EDNS0 to improve routing accuracy. If an exam question asks why latency routing might send a user to the wrong region, the answer is often that the resolver does not support EDNS0 client subnet, forcing Route 53 to rely on the resolver's IP alone.

🙋‍♀️ Test Record returning the same IP regardless of resolver?

Make sure you are entering the resolver IP in the correct field. The Resolver IP address field is separate from the EDNS0 client subnet IP field.

Also verify that you set the correct Region on each latency record. If both records point to the same Region, Route 53 cannot differentiate between them.

Help me troubleshoot why my Route 53 latency-based routing Test Record always returns the same IP regardless of which resolver IP I enter.

Your latency-based routing is verified. Route 53 now automatically directs users to the region with the lowest latency, and you have seen how EDNS0 client subnet provides more accurate location data than the resolver IP alone.

Next up, you will configure multivalue answer routing to return multiple healthy IPs in a single DNS response. You will also see what happens when one of those endpoints goes down.

Configure Multivalue Answer Routing

Latency-based routing always picks one best region per query. That works well for performance, but it means a single DNS response points to a single IP.

What if you want the DNS response itself to return multiple IPs so the client can try another if one fails? Multivalue answer routing solves this by returning up to 8 healthy IPs per query, providing basic fault tolerance at the DNS layer without a load balancer.

In this step, get ready to:

Create Route 53 health checks that monitor each EC2 instance.
Configure multivalue answer records that return both IPs in a single DNS response.
Simulate a failure and watch Route 53 automatically remove the unhealthy IP from responses.

Create health checks for both EC2 instances

Multivalue answer routing only works with health checks attached. Without health checks, Route 53 has no way to know which endpoint is healthy and which to exclude from responses.

In the Route 53 console, click Health checks in the left navigation pane.
Click Create health check.
Enter east-health in the Name field.
For What to monitor, select Endpoint.
Select IP address under Specify endpoint by.
Choose HTTP as the protocol.
Enter your us-east-1 instance's public IPv4 address in the IP address field.
Enter 80 for the Port.
Leave the Path field empty (Route 53 will request the root page).
Click Next.
On the Advanced configuration page, keep the default Request interval of Standard (30 seconds).
Click Next, then click Create health check.

You should see the new east-health health check appear in the list.

Repeat the same process to create a second health check named west-health, using your us-west-2 instance's public IPv4 address.
Wait 1-2 minutes for both health checks to show a Healthy status in the Status column.

Why do health checks take time to show Healthy?

Route 53 has health checkers distributed around the world. When you create a new health check, Route 53 initially marks it as healthy until enough data is collected. After a few check cycles (at your 30-second interval), the status reflects the real endpoint state.

🙋‍♀️ Health check stuck on Unhealthy?

Make sure your EC2 security group allows inbound HTTP traffic on port 80 from all sources (0.0.0.0/0). Route 53 health checkers come from many IP ranges and need to reach your instance directly.

Also confirm the instance is running and httpd is active by visiting the public IP in your browser.

Help me troubleshoot why my Route 53 health check is showing Unhealthy for my EC2 instance.

Create multivalue answer records

Now that Route 53 can monitor each endpoint, you can create records that return multiple healthy IPs in a single DNS response.

In the Route 53 console, click Hosted zones in the left navigation pane.
Click your hosted zone name to open it.
Click Create record.
Enter multi in the Record name field (this creates multi.routing-lab.com).
Set Record type to A.
Enter your us-east-1 instance's public IPv4 address in the Value field.
Set TTL to 60 seconds.
Under Routing policy, select Multivalue answer.
For Health check, select east-health.
Enter multi-east as the Record ID.
Click Create records.

Create a second record with the same Record name (multi), type A, TTL 60, and routing policy Multivalue answer.
This time, enter your us-west-2 instance's public IPv4 address as the Value.
Select west-health for the Health check.
Enter multi-west as the Record ID.
Click Create records.

Both records should now appear in your hosted zone under multi.routing-lab.com.

Before you test, predict: what do you think Route 53 will return when both health checks are Healthy?

Click Test record at the top of the records list.
In the Record name field, enter multi.
Set the record type to A.
Click Get Response.

You should see both IP addresses listed in the Response returned by Route 53 section. Since there are only 2 healthy records (fewer than 8), Route 53 returns all healthy records.

What is multivalue answer routing doing here?

Unlike weighted or latency routing (which pick one IP), multivalue answer returns multiple IPs in a single DNS response. The client can then try the next IP if the first connection fails.

Route 53 returns up to 8 healthy records selected at random from your configured set. This is not a replacement for a load balancer, but it adds a layer of DNS-level fault tolerance.

Simulate a failure and observe automatic removal

The real power of multivalue answer routing appears when an endpoint goes down. Route 53 automatically stops including unhealthy records in DNS responses.

Switch to the EC2 console.
Change your region to US West (Oregon) using the region selector in the top right.
Select your us-west-2 instance.
Click Instance state, then click Stop instance.
Confirm by clicking Stop.

Return to the Route 53 console and click Health checks.
Wait 1-2 minutes and refresh the page until the west-health health check status changes to Unhealthy.

Now predict: what will the Test Record tool return when you query multi.routing-lab.com with one endpoint down?

Return to Test record and click Get Response again.

Route 53 now returns only the us-east-1 IP. The unhealthy us-west-2 record is automatically excluded from the DNS response.

What happens when ALL records are unhealthy?

If every multivalue answer record fails its health check, Route 53 responds with up to 8 unhealthy records as a last resort. This fallback behaviour gives clients at least some IP to try rather than a completely empty response.

Now restart the us-west-2 instance. Switch back to the EC2 console (US West Oregon region).
Select your stopped instance.
Click Instance state, then click Start instance.
Wait 1-2 minutes for the west-health health check to return to Healthy status in the Route 53 console.
Click Test record one more time and run Get Response to confirm both IPs are returned again.

Why is multivalue answer not a replacement for a load balancer?

Multivalue answer distributes IPs at the DNS layer, but it has no awareness of server load, connection counts, or response times. A load balancer actively distributes connections and can perform weighted distribution, session affinity, and health-based connection draining.

Use multivalue answer for simple, stateless fault tolerance. Use Elastic Load Balancing when you need active traffic management.

You have proven that Route 53 multivalue answer routing provides automatic DNS-level fault tolerance. Healthy endpoints get traffic, unhealthy ones are silently removed from responses.

Next up, you will build a complete mental model of the remaining routing policies that the SAA-C03 exam tests, including geoproximity, IP-based routing, and Traffic Flow.

Understand Remaining Routing Policies

You just saw multivalue answer routing return multiple healthy IPs and automatically drop unhealthy ones from DNS responses. That covers three of the eight routing policies you have now configured and verified hands-on.

The SAA-C03 tests your understanding of ALL routing policies, including ones that are expensive to demo or require specific client IP ranges. This step fills those gaps so you have complete exam coverage without unnecessary cost.

In this step, get ready to:

Learn how geoproximity routing uses bias to shift traffic between regions.
Understand IP-based routing use cases and Traffic Flow pricing.
Build your SAA-C03 routing policy decision framework.

Learn how geoproximity routing uses bias

Latency routing picks the fastest region, and geolocation routing picks a region based on the user's country or continent. Geoproximity routing adds a third option: route to the closest resource by geographic distance, but with a tunable bias that lets you expand or shrink each resource's catchment area.

How does geoproximity routing work?

Geoproximity routing determines which endpoint is geographically closest to the user, then applies a bias value you set. The bias modifies the perceived distance using this formula:

Biased distance = actual distance * [1 - (bias/100)]

A positive bias (1 to 99) makes a resource appear closer than it actually is, expanding its catchment area and attracting traffic from a wider region.
A negative bias (-1 to -99) makes a resource appear farther away, shrinking its catchment area and pushing traffic to adjacent resources.
Example: A bias of +50 on your us-east-1 resource makes it appear half as far away (150km becomes 75km), so users further west start routing to it instead of us-west-2.

For AWS resources, you specify the AWS Region or Local Zone Group. For non-AWS resources, you specify latitude and longitude coordinates.

💡 Geoproximity vs. geolocation: what's the difference?

Geolocation routing is binary. You map entire continents, countries, or US states to specific endpoints. A user in France always goes to endpoint A, with no in-between.

Geoproximity routing is gradual. Instead of hard geographic boundaries, you use bias values to smoothly shift traffic between regions over time. This makes geoproximity the better choice when you want to migrate traffic to a new region incrementally rather than flip an entire country at once.

Understand IP-based routing and Traffic Flow

Some organizations need routing decisions based on specific client IP ranges rather than geographic location or latency. IP-based routing routes traffic based on the location of users using the IP addresses that the traffic originates from.

What is IP-based routing?

With IP-based routing, you define CIDR collections in Route 53 that map specific IP address ranges to locations. Then you create routing records that reference those locations.

Use case: An ISP wants to route all traffic from their 203.0.113.0/24 block to a specific endpoint optimized for that network.
Use case: A company wants all traffic from its corporate IP range directed to an internal endpoint rather than the public one.

IP-based routing is more precise than geolocation because you control exactly which IP ranges map to which endpoints. Geolocation relies on Route 53's IP-to-location database, while IP-based lets you define your own mappings.

For complex routing scenarios that combine multiple policies together, AWS offers Traffic Flow. This is a visual editor for building routing trees that chain multiple policies (for example, latency routing into weighted routing into failover).

What is Traffic Flow and how much does it cost?

Traffic Flow lets you design complex multi-policy routing trees visually. Creating traffic policies is free. The charge of $50.00 per policy record per month (prorated for partial months) applies only when you create a policy record that associates a policy with a domain name.

For the SAA-C03: know that Traffic Flow is the tool for building complex routing trees that combine multiple policies. Know the $50/month per policy record pricing. You do not need to demo it to pass the exam.

Build your routing policy decision framework

The SAA-C03 expects you to pick the right routing policy for a given scenario. Here is the complete decision framework covering all eight Route 53 routing policies.

Simple: Single resource, no special routing needed.
Failover: Active-passive disaster recovery. One primary endpoint fails over to a secondary when unhealthy.
Weighted: Blue/green deployments, A/B testing, gradual traffic migration. You control exact percentages.
Latency: Multi-region apps optimizing user experience. Route 53 picks the region with the lowest latency for each user.
Geolocation: Compliance (data must stay in a specific country), content localization, or content restriction by geography. Binary routing by continent, country, or US state.
Geoproximity: Gradual traffic shifting between regions with tunable bias. More flexible than geolocation. Use when you want to move a percentage of traffic to a new region without hard geographic boundaries.
Multivalue answer: Simple DNS load distribution with health checks. Returns up to 8 healthy IPs per query. Not a replacement for a load balancer, but adds DNS-level fault tolerance.
IP-based: Route by known client CIDR blocks. Use for ISP-specific routing or directing corporate network traffic to internal endpoints.

Exam shortcut for geolocation vs. geoproximity

If the exam question mentions compliance, legal requirements, or content localization by country, the answer is geolocation. If the question mentions gradually shifting traffic or expanding/shrinking a region's reach, the answer is geoproximity.

Before you move on, test yourself. Without looking at the list above, can you explain the difference between geolocation and geoproximity routing? Can you articulate when you would choose latency-based routing over weighted routing?

Check your answers

Geolocation is binary by country or continent. Geoproximity is gradual bias-based shifting by distance.
Choose latency when you want Route 53 to automatically pick the fastest region for each user based on network measurements. Choose weighted when you want to control exact traffic percentages regardless of user location (for example, 90% to production and 10% to a canary).

Secret mission

Geolocation Routing with Default Record

Geolocation routing without a Default record is one of the most common Route 53 traps on the SAA-C03 exam. In this mission, you will configure continent-level geolocation records, prove they work, then deliberately break your DNS by removing the Default record to see exactly what happens to users from unmapped locations.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The EC2 instances in this project cost money while running, so review your options below.

Cost warning

Your two t2.micro EC2 instances cost approximately $0.02/hour combined while running. If you leave them running overnight or over a weekend, charges will accumulate.

If you are done experimenting, choose Pause or Delete below to avoid unnecessary costs.

Resources you used:

EC2 instance in us-east-1 (t2.micro, running, costs ~$0.01/hour).
EC2 instance in us-west-2 (t2.micro, running, costs ~$0.01/hour).
Route 53 hosted zone for routing-lab.com ($0.50/month).
Route 53 health checks: east-health and west-health (free within first 50 AWS endpoint health checks).
Route 53 DNS records in your hosted zone: weighted (3 records), latency (2 records), multivalue (2 records), and geolocation (3 records). Query costs are negligible.

Keep everything running

No action needed. Choose this if you are still actively experimenting with Route 53 routing policies and want to try different weight values, latency simulations, or additional routing configurations.

Your two EC2 instances will continue running at approximately $0.02/hour combined.
Health checks remain active and free (within the first 50 AWS endpoint health checks).
DNS records remain in your hosted zone at negligible query cost.
Your hosted zone for routing-lab.com costs $0.50/month (prorated).

Pause - I'll come back to this later

Stop your EC2 instances to eliminate compute charges while preserving your setup. You pay only for EBS storage (approximately $0.10/month per instance) and the hosted zone ($0.50/month).

In the EC2 console for us-east-1, select your instance, click Instance state, then click Stop instance.
Switch to the us-west-2 region in the console and repeat the same steps for your second instance.
Your health checks will flip to Unhealthy since the instances are stopped. This is expected.
Your DNS records and health checks remain configured. When you start the instances again, the health checks will return to Healthy (note that your public IPs may change after stopping and starting).

Delete - I don't want to use this again

Remove all project resources to stop all charges.

Delete DNS records from your hosted zone. In the Route 53 console, click Hosted zones, click routing-lab.com, then select all the weighted records (weighted.routing-lab.com), latency records (latency.routing-lab.com), multivalue records (multi.routing-lab.com), and geolocation records. Click Delete record for each group.
Delete the hosted zone. Once all custom records are deleted (only NS and SOA remain), click Delete hosted zone and confirm.
Delete health checks. In the Route 53 console, click Health checks from the left sidebar. Select east-health and west-health, then click Delete health check.
Terminate the us-east-1 EC2 instance. In the EC2 console for us-east-1, select your instance, click Instance state, then click Terminate instance. Confirm the termination.
Terminate the us-west-2 EC2 instance. Switch to us-west-2 in the region selector, select your instance, click Instance state, then click Terminate instance. Confirm the termination.

Nice Work!

You just built a multi-policy DNS routing configuration across two AWS regions and proved that Route 53 makes intelligent routing decisions in real time.

You've learned how to:

Configure weighted routing with a 70/20/10 traffic split across 3 endpoints, verify the distribution with repeated Test Record queries, and set up latency-based routing that automatically selects the lowest-latency region based on simulated user location.
Build multivalue answer routing with health checks and demonstrate that Route 53 automatically removes unhealthy IPs from DNS responses when an instance goes down.
Explain the full SAA-C03 routing policy decision framework, including how EDNS0 client subnet improves location accuracy, how geoproximity bias shifts traffic gradually between regions, and when to choose IP-based routing or Traffic Flow.
Secret Mission: Configured geolocation routing with continent-level records and a Default catch-all, then proved that missing the Default record causes Route 53 to return "no answer" for unmapped locations.

Ready to quiz yourself?