This chapter covers Route 53 routing policies, a core topic for the CLF-C02 exam under Cloud Technology Services (Objective 3.4). Understanding routing policies is essential because they control how user traffic reaches your applications, directly impacting availability, performance, and cost. This objective is weighted approximately 5-10% of the exam, and you can expect 2-3 questions on routing policies specifically.
Jump to a section
Imagine you are a delivery driver for a busy courier company. Your GPS navigation system is like Amazon Route 53. When you start your shift, you have a list of delivery addresses (domain names). Your GPS decides which route to take to each destination. But this GPS is smarter than a basic one: it can choose different routes based on the time of day, traffic conditions, or even which customer pays for faster delivery.
Simple routing is like always taking the same fastest route, even if there's a road closure. That's the default 'simple' policy.
Weighted routing lets you send 70% of your deliveries via the highway and 30% via side streets, to test which is more efficient.
Latency routing picks the route that historically has the least traffic, so you arrive fastest.
Failover routing sends you to your primary route, but if that road is blocked, it automatically reroutes you to a backup route.
Geolocation routing delivers to the nearest warehouse based on the package's origin.
Geoproximity routing shifts traffic between warehouses based on how close the driver is, and you can 'bias' traffic toward one warehouse even if it's slightly farther.
Multi-value answer routing returns multiple warehouse addresses so you can choose the best one, but you still have to pick one.
Each policy is a different algorithm the GPS uses to decide which route to show you. Route 53 does the same for DNS queries: it decides which IP address to return based on the policy you configure.
What is Route 53 and the Problem It Solves
Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service. Its primary job is to translate human-readable domain names (like www.example.com) into IP addresses (like 192.0.2.1) that computers use to connect to each other. But Route 53 goes beyond simple DNS resolution: it offers several routing policies that allow you to control how traffic is routed to your endpoints based on various criteria. The core problem these policies solve is directing user requests to the most appropriate resource, whether that's for performance, cost, health, or geographic compliance.
Without a smart routing policy, all traffic would go to a single server, which is a single point of failure and cannot scale. Routing policies enable load balancing, fault tolerance, and performance optimization directly at the DNS level, before traffic even reaches your infrastructure.
How Routing Policies Work – The Mechanism
When a user types a domain name into their browser, their device sends a DNS query to a DNS resolver (often provided by their ISP). The resolver recursively queries the DNS hierarchy until it reaches Route 53, which is the authoritative name server for that domain. Route 53 then responds with one or more IP addresses based on the routing policy configured for that record.
Each routing policy is essentially a set of rules that Route 53 evaluates when answering a query. For example, with a latency-based policy, Route 53 maintains a database of latencies between AWS regions and the user's location. When a query arrives, it calculates which endpoint would provide the lowest latency and returns that IP address. The key mechanism is that Route 53 does not redirect traffic; it only returns DNS responses. The user's application then connects to the IP address it receives.
Key Routing Policies and Their Configurations
Simple Routing Policy – The default policy. You can only have one record with multiple values (e.g., multiple IP addresses). Route 53 returns all values in a random order to the client. This is the simplest but provides no health checking or load balancing.
Weighted Routing Policy – You create multiple records with the same name and type, each assigned a weight. Route 53 returns one of the records proportionally to its weight. For example, if you have two records with weights 70 and 30, 70% of queries will get the first record's IP, and 30% the second. This is useful for A/B testing or gradually shifting traffic.
Latency-Based Routing Policy – You create records in multiple AWS regions. Route 53 measures the latency between the user's location and each region. When a query arrives, it returns the record from the region with the lowest latency. This improves performance for global users.
Failover Routing Policy – You configure a primary and a secondary record. Route 53 uses health checks to monitor the primary. If the primary fails, it returns the secondary record. This provides active-passive failover.
Geolocation Routing Policy – You specify which DNS queries should come from which geographic location (continent, country, or US state). Route 53 returns the record that matches the user's location. This is used for content localization or legal restrictions.
Geoproximity Routing Policy – Similar to geolocation, but you can also shift traffic by specifying a bias value. This policy uses Route 53 traffic flow, which allows you to define rules based on the user's location and the location of your resources. Bias can increase or decrease the size of the geographic region from which traffic is routed to a resource.
Multi-Value Answer Routing Policy – You can configure up to eight healthy records with the same name and type. Route 53 returns up to eight values in response to a query, but only those that are healthy. This is not a substitute for a load balancer but provides simple DNS-level load balancing with health checking.
Pricing Considerations
Route 53 pricing is based on the number of hosted zones and the number of queries. Basic features like simple and multi-value answer routing are included. However, advanced features like latency-based, geolocation, geoproximity, and failover routing incur additional costs per query. Weighted routing is also charged per query. Health checks have separate pricing. For the CLF-C02 exam, you should know that routing policies affect cost, but exact pricing numbers are not tested.
Comparison to On-Premises DNS
On-premises DNS servers typically offer only simple A/AAAA record resolution or round-robin. They lack health checking, latency optimization, and geographic awareness. To achieve similar functionality on-premises, you would need dedicated load balancers, global traffic managers, and complex scripting. Route 53 provides these capabilities as a managed service, saving operational overhead. The exam may ask why a company would migrate from on-premises DNS to Route 53 – the answer is usually high availability, global performance, and ease of management.
When to Use Each Policy
Simple: When you have a single endpoint and don't need health checks.
Weighted: When you want to test new features or gradually migrate traffic.
Latency: When you have applications in multiple regions and want the best performance for global users.
Failover: When you need disaster recovery with automatic failover.
Geolocation: When you need to restrict content based on user location or serve localized content.
Geoproximity: When you want to shift traffic between regions based on proximity and bias.
Multi-Value Answer: When you want simple DNS-based load balancing with health checks, but you don't need a full load balancer.
Important Limits and Defaults
Maximum number of records per hosted zone: 10,000 by default (can be increased).
Maximum number of health checks: 200 by default.
For multi-value answer routing, you can configure up to 8 healthy records per query.
Weighted routing supports up to 255 records per name.
Geolocation records require at least one default record (without a location) to handle unmatched queries.
Failover routing requires health checks on the primary record.
CLI and SDK Example
To create a weighted record using AWS CLI:
aws route53 change-resource-record-sets --hosted-zone-id Z1234567890 --change-batch '{
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.example.com.",
"Type": "A",
"SetIdentifier": "Prod",
"Weight": 70,
"TTL": 60,
"ResourceRecords": [{"Value": "192.0.2.1"}]
}
},
{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "www.example.com.",
"Type": "A",
"SetIdentifier": "Test",
"Weight": 30,
"TTL": 60,
"ResourceRecords": [{"Value": "192.0.2.2"}]
}
}
]
}'Create a hosted zone
First, you create a hosted zone for your domain (e.g., example.com). A hosted zone is a container for DNS records. In the AWS Management Console, navigate to Route 53, click 'Create hosted zone', enter your domain name, and choose 'Public hosted zone'. Route 53 automatically generates four name server (NS) records. You must update your domain registrar's NS records to point to these Route 53 name servers to delegate authority. Behind the scenes, Route 53 provisions a set of highly available DNS servers across the globe.
Create a record with routing policy
Inside the hosted zone, you create a record set. For example, to create a latency-based record for www.example.com, choose 'Create record', enter the name, select 'A' type, and under 'Routing policy', choose 'Latency'. Then you specify the region (e.g., us-east-1) and the value (IP address of your EC2 instance). You can create multiple records for the same name in different regions. Route 53 will evaluate the latency between the user and each region to return the best one.
Configure health checks (optional)
For failover, multi-value answer, and weighted routing policies, you can associate a health check with each record. A health check monitors the endpoint (e.g., HTTP/HTTPS endpoint) and marks it healthy or unhealthy. Route 53 only returns healthy records. To set up, create a health check in Route 53 specifying the endpoint, protocol, and interval (default 30 seconds). Then, when creating or editing a record, you can link the health check. This prevents traffic from being sent to unhealthy resources.
Test the routing policy
After records are created, you can test by using tools like 'dig' or 'nslookup' from different locations. For example, to test latency routing, query your domain from a client in Europe and another in Asia. The responses should show different IP addresses corresponding to the closest region. Route 53's latency data is based on actual measurements between the resolver and AWS regions. Note that DNS caching by resolvers can affect results, so you may need to wait for TTL to expire.
Monitor and adjust routing
Use Amazon CloudWatch metrics to monitor query volumes and health check status. You can also use Route 53 traffic flow to visualize and edit routing policies with a visual editor. If you need to shift traffic gradually, adjust weights in a weighted policy. For geoproximity, you can modify bias values. Remember that DNS changes propagate based on TTL, so updates are not instant. The exam may ask about the impact of TTL on failover time – shorter TTLs allow faster failover but increase query costs.
Scenario 1: Global E-commerce Platform with Latency-Based Routing
A global e-commerce company wants to provide the fastest possible experience to customers worldwide. They deploy their application on EC2 instances in three AWS regions: us-east-1 (N. Virginia), eu-west-1 (Ireland), and ap-southeast-1 (Singapore). They create a latency-based routing policy for their main domain (www.shopglobal.com). When a user in Japan queries the domain, Route 53 determines that ap-southeast-1 has the lowest latency and returns that IP address. The user connects to the Singapore server, experiencing lower page load times. The business benefits from improved user engagement and higher conversion rates. Cost considerations: latency-based queries incur a small per-query charge, but the performance improvement justifies the cost. Misconfiguration could happen if the company forgets to create records in all regions or if health checks are not used – a region going down would still receive traffic until the latency data updates, causing errors.
Scenario 2: Disaster Recovery with Failover Routing
A financial services company has a primary application in us-east-1 and a standby in us-west-2. They use failover routing with a health check on the primary. The health check monitors an HTTP endpoint (e.g., https://app.primary.com/health). If the primary becomes unhealthy (e.g., due to an AWS outage), Route 53 automatically returns the secondary record's IP address. This provides automatic failover within seconds, depending on the health check interval (default 30 seconds). The business avoids extended downtime. However, if the health check is misconfigured (e.g., checking the wrong path), it might falsely mark the primary as unhealthy, causing unnecessary failover. Also, if the secondary is not scaled to handle the full load, it could become overwhelmed. Cost includes health check charges and the secondary region infrastructure.
Scenario 3: A/B Testing with Weighted Routing
A SaaS company wants to test a new user interface. They deploy two versions of their application: v1 (stable) and v2 (experimental). They create weighted records for www.saasapp.com: v1 with weight 90, v2 with weight 10. This means 10% of users are directed to v2. They monitor metrics like error rates and user engagement. If v2 performs well, they gradually increase its weight. This approach allows safe rollout without impact on most users. A common mistake is not using health checks – if v2 becomes unhealthy, it still receives 10% of traffic, causing errors. Also, DNS caching by clients can skew the distribution, so TTL should be set low (e.g., 60 seconds). The exam might ask about the difference between weighted routing and using an Application Load Balancer (ALB) – weighted routing works at DNS level and is stateless, while ALB provides more sophisticated routing (e.g., path-based) and integrates with health checks at the application layer.
What CLF-C02 Tests on This Objective
The CLF-C02 exam under Objective 3.4 (Cloud Technology Services) expects you to:
Identify the appropriate Route 53 routing policy for a given scenario.
Understand the purpose of each policy (simple, weighted, latency, failover, geolocation, geoproximity, multi-value answer).
Know that routing policies are configured on DNS records.
Recognize that health checks can be associated with records for failover and multi-value answer policies.
Understand that weighted routing distributes traffic based on relative weights.
Know that latency routing uses actual latency data to direct users to the region with the lowest latency.
Understand that geolocation routing uses the user's IP address to determine location, not latency.
Know that geoproximity routing uses a bias value to shift traffic.
Understand that simple routing does not support health checks.
Know that multi-value answer routing returns up to eight healthy records.
Common Wrong Answers and Why Candidates Choose Them
Choosing 'latency' when scenario describes geographic restriction. Many candidates confuse geolocation (based on user location) with latency (based on performance). If the scenario says 'serve content based on user's country', the answer is geolocation, not latency. Candidates pick latency because they think 'fastest' equals 'closest geographically', but latency is about measured network performance, not political boundaries.
Choosing 'simple' when health checks are needed. Simple routing does not support health checks. If the scenario requires automatic removal of unhealthy endpoints, the answer should be multi-value answer (if you need multiple values) or failover (if active-passive). Candidates see 'simple' and think it's fine for small setups, but the exam tests that simple has no health check capability.
Choosing 'weighted' when scenario mentions A/B testing. Weighted is actually correct for A/B testing, but candidates sometimes pick 'simple' with multiple values (which returns all IPs randomly, not proportionally). The exam expects you to know that weighted allows precise percentage control.
Thinking 'failover' requires a load balancer. Failover routing works at DNS level and does not require an AWS load balancer. It simply returns different IP addresses based on health check status. Candidates may think they need ELB, but failover is purely DNS.
Specific Terms and Values on the Exam
'Routing policy' is the term used.
'Set identifier' is a required field when creating multiple records for the same name.
'Weight' is a number between 0 and 255.
'Health check' is a separate resource that can be associated.
'Traffic flow' is a visual editor for geoproximity and other advanced policies.
'Alias record' is a special type that points to AWS resources, but it also uses routing policies.
'TTL' (time to live) is critical for failover speed.
Tricky Distinctions
Geolocation vs. Geoproximity: Geolocation routes based on the user's location (country/state). Geoproximity routes based on the user's location relative to your resources and allows a bias to shift traffic. The exam may present a scenario where you need to shift traffic away from a region even if users are close – that's geoproximity with bias.
Multi-value answer vs. simple with multiple values: Simple returns all values in random order; multi-value returns only healthy values (up to 8). The exam tests that multi-value supports health checks.
Failover vs. latency with health checks: Failover is active-passive (primary takes all traffic until failure). Latency with health checks can also route around failures, but it distributes traffic across multiple regions based on performance, not a single standby.
Decision Rule for Multiple-Choice Questions
When you see a scenario asking which routing policy to use, ask yourself: 1. Does the scenario mention health checks or automatic failover? If yes, eliminate simple. 2. Does it mention distributing traffic by percentage? → Weighted. 3. Does it mention reducing latency for global users? → Latency. 4. Does it mention restricting content by country? → Geolocation. 5. Does it mention shifting traffic based on proximity with a bias? → Geoproximity. 6. Does it mention returning multiple healthy IPs? → Multi-value answer. 7. Does it mention a primary and secondary for disaster recovery? → Failover.
Route 53 offers seven routing policies: simple, weighted, latency, failover, geolocation, geoproximity, and multi-value answer.
Simple routing does not support health checks; all other policies can optionally or require health checks.
Weighted routing distributes traffic based on weights (0-255) and is used for A/B testing or gradual rollouts.
Latency routing uses actual latency measurements to direct users to the region with the best performance.
Failover routing provides active-passive failover using health checks; primary record must have a health check.
Geolocation routing uses the user's IP to determine location; geoproximity uses location plus bias.
Multi-value answer routing returns up to eight healthy records; it is not a substitute for a load balancer.
Routing policies are configured on DNS records and affect how Route 53 responds to queries.
Health checks are separate resources that can be associated with records to monitor endpoint health.
TTL (time to live) affects how quickly changes propagate; shorter TTL allows faster failover but increases query costs.
Alias records can point to AWS resources (e.g., CloudFront, ELB) and can also use routing policies.
The CLF-C02 exam tests the ability to select the correct routing policy for a given scenario, not configuration details.
These come up on the exam all the time. Here's how to tell them apart.
Simple Routing Policy
Supports multiple values but returns all of them in random order
No health check support
Cannot filter out unhealthy endpoints
Simple to configure
Useful for single endpoint or when health checks are not needed
Multi-Value Answer Routing Policy
Supports up to 8 healthy records per query
Supports health checks – only returns healthy records
Provides DNS-level load balancing with health awareness
More complex due to health check setup
Useful when you want simple load balancing with health checks
Geolocation Routing Policy
Routes based on user's geographic location (country/state)
No bias or traffic shifting
Requires a default record for unmatched locations
Good for content localization and legal compliance
Static routing based on location
Geoproximity Routing Policy
Routes based on user's location relative to resources
Allows bias to shift traffic toward or away from a region
Does not require a default record if all locations are covered
Good for regional traffic distribution with flexibility
Dynamic routing with bias adjustment
Mistake
Route 53 routing policies load balance traffic across endpoints.
Correct
Routing policies are DNS-level and do not load balance in real time. They only respond to DNS queries with IP addresses. Actual load balancing is done by AWS Elastic Load Balancers. Weighted routing distributes query responses proportionally, but client caching can skew actual traffic distribution.
Mistake
Latency-based routing always routes to the geographically closest region.
Correct
Latency routing routes to the region with the lowest network latency, which is often but not always the closest geographically. Network conditions, peering, and internet congestion can make a farther region faster. Geolocation routing, not latency, routes based on geographic location.
Mistake
Simple routing policy supports health checks.
Correct
Simple routing does not support health checks. If you need health checks, you must use failover, multi-value answer, or weighted routing with health checks.
Mistake
Failover routing requires an Elastic Load Balancer.
Correct
Failover routing is purely DNS-based. It does not require any load balancer. The primary and secondary records point directly to IP addresses or other endpoints. Health checks monitor the endpoints, and Route 53 returns the secondary if the primary is unhealthy.
Mistake
Geolocation routing uses latency data.
Correct
Geolocation routing uses the source IP address of the DNS resolver to determine the user's geographic location (country or state). It does not consider latency. Latency routing uses actual measured latency data.
Simple routing policy returns all values in a record in random order and does not support health checks. Multi-value answer routing policy returns up to eight values, but only those that are healthy (if health checks are configured). The key difference is health check support: simple has none, multi-value can filter out unhealthy endpoints. For the exam, remember that multi-value provides DNS-level load balancing with health checks, while simple is just a basic response.
Yes, weighted routing does not require health checks. However, it is a best practice to associate health checks with each weighted record so that Route 53 can automatically remove unhealthy endpoints from the rotation. Without health checks, all records are considered healthy, and traffic is distributed according to weights regardless of endpoint status. The exam may test that health checks are optional for weighted routing.
Route 53 maintains a database of latencies between AWS regions and the user's DNS resolver. When a query arrives, Route 53 looks up the latency from the resolver's approximate location to each region where you have a record. It returns the record from the region with the lowest latency. This data is updated continuously based on actual measurements. Note that latency is not static and can change due to network conditions.
A set identifier is a unique string you assign to each record when you have multiple records with the same name and type (e.g., for weighted, latency, geolocation, failover, or multi-value answer). It distinguishes one record from another. For example, you might have two weighted records for www.example.com with set identifiers 'Prod' and 'Test'. The set identifier is required for all routing policies except simple.
No, failover routing supports exactly one primary and one secondary record. If you need multiple standby endpoints, you can use a different architecture, such as using a Network Load Balancer with multiple targets, or using weighted routing with health checks. The exam expects you to know that failover is active-passive with a single failover target.
If no geolocation record matches the user's location, Route 53 returns a 'NoAnswer' response unless you have a default record. A default record is a geolocation record without a specified location (e.g., location: 'Default'). It is strongly recommended to create a default record to handle queries from locations you haven't explicitly configured. The exam may test that a default record is needed to avoid DNS resolution failures.
Geolocation routing routes based on the user's geographic location (e.g., country or state). Geoproximity routing routes based on the user's location relative to your resources and allows you to specify a bias to shift traffic toward or away from a region. For example, you can increase the bias for us-east-1 to send more traffic there even if users are closer to eu-west-1. Geolocation is static; geoproximity is dynamic with bias.
You've just covered Route 53 Routing Policies — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?