AWS Route 53 Routing Policies – SAP-C02 Study Guide

Purpose of This Lesson

Amazon Route 53 routing policies determine how DNS responses direct clients to application endpoints. The correct policy depends on the architecture objective: distributing traffic, minimizing latency, routing by geography or client network, or directing users to a healthy failover endpoint.

Route 53 returns DNS answers; it does not proxy application traffic. After receiving an answer, the client connects directly to the returned endpoint, such as an Elastic Load Balancing load balancer, Amazon CloudFront distribution, Amazon S3 endpoint, or IP address.

Key Concepts

DNS records and TTL

A Route 53 record maps a DNS name to a value such as an IPv4 address, load balancer name, or CloudFront distribution. The record’s time to live (TTL) controls how long DNS resolvers and clients may cache the answer.

• A longer TTL can reduce DNS query volume and improve cache efficiency.
• A shorter TTL allows routing changes to be observed sooner, but increases DNS query volume.
• TTL does not guarantee immediate failover because recursive resolvers may continue using a cached answer until the TTL expires.

Many advanced routing policies use multiple records with the same record name and type. Route 53 selects or combines those records according to the policy.

Simple routing

Simple routing is the basic Route 53 policy. It is suitable when no specialized routing decision is required.

• A record can contain a single value or multiple values.
• Route 53 does not perform sophisticated traffic distribution across multiple values.
• Health checks are not the defining feature of this policy.
• Use it for straightforward DNS mapping where the application or endpoint handles availability and load distribution.

Weighted routing

Weighted routing distributes DNS responses according to weights assigned to records with the same name and type.

For example, records with relative weights of 60, 20, and 20 receive approximately 60%, 20%, and 20% of eligible DNS responses. The weights are relative values, so they do not need to add up to a specific total. AWS supports integer weights from 0 through 255.

Common uses include:

• Blue/green or canary deployments
• Gradual migration to a new application version
• Splitting traffic between regions or environments
• Testing a new endpoint with a small percentage of traffic

Health checks are optional. When health checks are associated with weighted records, Route 53 excludes unhealthy endpoints from responses. A record with a weight of zero can be used as a standby target when health checks are configured appropriately.

Weighted routing distributes DNS answers, not individual HTTP requests. DNS caching means the actual request distribution may not precisely match the configured percentages.

Latency-based routing

Latency-based routing returns the endpoint that Route 53 determines will provide the lowest network latency for the requesting client. Each record is associated with an AWS Region, and the same DNS name can have records for multiple Regions.

Typical use cases include:

• Active-active multi-Region applications
• Directing users to a nearby application deployment
• Improving user-perceived response time

The selected Region is based on measured network latency, not necessarily geographic distance. A client geographically close to one Region may still receive an endpoint in another Region if network measurements indicate lower latency there.

Health checks are optional but valuable. If an endpoint is unhealthy, Route 53 can exclude it and select another eligible endpoint.

Failover routing

Failover routing provides an active-passive design with two records for the same name:

• Primary: The normal production endpoint
• Secondary: The standby or disaster recovery endpoint

A health check is required for the primary record. Route 53 returns the primary endpoint while it is healthy. If the health check fails, Route 53 returns the secondary endpoint.

Failover routing is appropriate for:

• Regional disaster recovery
• Active-passive application deployments
• A primary service with a backup endpoint

DNS failover is not instantaneous. Cached DNS responses can continue directing clients to the primary until their cached TTL expires. The health check also detects the configured failure condition; it does not automatically validate every dependency in the application stack unless those dependencies are represented by the health-check target or a suitable endpoint.

Geolocation routing

Geolocation routing selects a response based on the geographic location associated with the DNS query source. Records can be configured for locations such as countries, continents, or the default location.

Use cases include:

• Country-specific content or compliance requirements
• Directing users to an endpoint intended for a particular market
• Regional application customization

A default geolocation record is important as a fallback for clients whose locations do not match a more specific configured location. Geolocation routing is based on location classification, not measured network performance.

Health checks are optional. If a matching endpoint is unhealthy, Route 53 may use an applicable healthy record according to the routing configuration.

Geoproximity routing

Geoproximity routing directs traffic based on the geographic location of resources and, where applicable, the requesting users. Traffic Flow is required to create and manage geoproximity routing policies.

Geoproximity routing supports geographic bias. A positive or negative bias can expand or shrink the geographic area served by a particular endpoint, allowing traffic to be shifted between endpoints without changing their physical locations.

Supported endpoint types can include resources such as:

• Amazon CloudFront distributions
• Elastic Load Balancing load balancers
• Amazon Elastic Beanstalk environments
• Amazon S3 resources
• IP addresses

Do not confuse geoproximity routing with latency-based routing:

• Geoproximity: Routes according to geographic boundaries and configurable bias.
• Latency-based: Routes according to measured network latency.

Multivalue answer routing

Multivalue answer routing returns multiple healthy records for the same DNS name. Route 53 can return up to eight healthy records in response to a DNS query.

This policy is useful when clients can select among multiple returned endpoints and a simple DNS-based distribution mechanism is sufficient. Health checks allow Route 53 to return only healthy records.

Multivalue answer routing is not a replacement for a full load balancer:

• DNS responses are cached.
• Clients and resolvers may use returned addresses differently.
• It does not provide application-layer connection management, session handling, or sophisticated load-balancing algorithms.

IP-based routing

IP-based routing selects records based on the source IP address of the DNS query. It uses two related configuration elements:

1. CIDR collections: Groups of IPv4 or IPv6 CIDR blocks representing client networks.
2. Routing rules: Mappings between a CIDR collection and the Route 53 record or endpoint to return.

This is useful when the organization knows client network ranges and needs deterministic routing based on those ranges, such as:

• Directing corporate networks to a private or specialized service
• Routing users from specific ISP or enterprise CIDR blocks
• Supporting network-specific application behavior

The source address observed by Route 53 may not always represent the end user’s original address, especially when clients use recursive DNS resolvers, proxies, or NAT. Design and test IP-based policies with the actual DNS resolution path in mind.

Architecture Decision Guide

Requirement	Recommended policy	Important consideration
One straightforward DNS mapping	Simple	No specialized traffic selection
Send a controlled percentage of traffic to several endpoints	Weighted	Percentages are approximate because of DNS caching
Gradually shift traffic during a deployment	Weighted	Combine with health checks and monitoring
Route users to the lowest-latency Region	Latency-based	Network latency, not physical distance, determines selection
Use a primary endpoint with a disaster recovery standby	Failover	Primary health check is required; DNS caching delays changes
Route based on country or continent	Geolocation	Configure an appropriate default record
Route by geographic proximity and adjust distribution with bias	Geoproximity	Requires Route 53 Traffic Flow
Return several healthy IP addresses	Multivalue answer	Maximum of eight healthy records per response; not a load balancer
Route known client networks by CIDR	IP-based	Depends on the source IP visible to DNS resolution

Exam-Relevant Takeaways

• Route 53 routing policies control DNS answers; they do not forward application requests.
• Weighted routing is the usual choice for percentage-based traffic splitting, canary releases, and blue/green deployments.
• Latency-based routing selects the endpoint with the best measured latency for the client, not simply the nearest Region.
• Failover routing is an active-passive pattern. The primary record requires a health check.
• Geolocation routing uses the geographic location of the query source and should normally include a default record.
• Geoproximity routing uses geographic boundaries and bias and requires Traffic Flow.
• Multivalue answer routing returns multiple healthy records, with a maximum of eight healthy records in a response.
• IP-based routing requires CIDR collections and routing rules.
• Health checks are optional for weighted, latency, geolocation, and multivalue configurations, but are central to failover routing.
• DNS TTL and resolver caching affect how quickly routing changes and failover become visible.
• A healthy DNS target does not necessarily mean the entire application is healthy. Use an endpoint or health-check design that tests the relevant application behavior.

Common Exam Traps

• Confusing latency with geolocation: Latency-based routing optimizes measured network performance. Geolocation routes according to geographic classification.
• Treating weighted routing as exact load balancing: DNS caching and resolver behavior make the resulting request distribution approximate.
• Assuming Route 53 performs instant failover: Cached DNS answers can remain in use until their TTL expires.
• Forgetting the geolocation default: Queries that do not match a configured location need a fallback record.
• Using multivalue routing as an ELB replacement: Multivalue routing only returns DNS answers; it does not manage connections or provide application-aware balancing.
• Assuming a health check is mandatory for every policy: Health checks are optional in many policies, but failover requires a health check on the primary record.
• Confusing geoproximity with geolocation: Geoproximity supports geographic bias and requires Traffic Flow; geolocation maps locations to records.
• Assuming IP-based routing always sees the end user’s IP: Recursive resolvers, NAT, and intermediaries can change the source address visible to Route 53.
• Assuming multiple values in a simple record provide controlled distribution: Use weighted or multivalue answer routing when the routing behavior must be explicit.

Real-World Engineer Notes

• Use low TTLs during planned migrations only when necessary, and restore an operationally sensible TTL afterward. Lower TTLs increase DNS query volume and do not override existing cached responses.
• For multi-Region applications, combine routing with regional health checks, observability, data replication, and a tested recovery process. DNS routing alone does not create application resiliency.
• Weighted routing is effective for deployment progression, but traffic percentages should be validated using real request metrics rather than assumed from DNS record weights.
• Health checks should target a meaningful application endpoint. A TCP check or a basic load balancer response may not detect dependency failures.
• For compliance or data-residency requirements, geolocation routing may help direct users, but it is not a complete enforcement mechanism. Authorization, data placement, and application controls remain necessary.
• When using IP-based routing, document the CIDR ownership and update process. Stale client-network mappings can silently route users to the wrong service.
• If the application requires connection-aware distribution, retries, stickiness, or health-aware request routing, use an appropriate load-balancing layer rather than relying solely on DNS.

Quick Reference Summary

• Simple: Basic DNS response.
• Weighted: Relative traffic distribution across same-name records.
• Latency-based: Best measured latency among configured Regions.
• Failover: Primary while healthy; secondary when the primary fails its health check.
• Geolocation: Route according to country, continent, or configured geographic location.
• Geoproximity: Geographic routing with optional bias; requires Traffic Flow.
• Multivalue answer: Returns multiple healthy records, up to eight.
• IP-based: Route according to client source IP and configured CIDR collections.
• TTL: Controls DNS cache duration and affects change propagation.

Flashcards

1. Q: What does a Route 53 routing policy control?

A: It controls which DNS answer Route 53 returns for a query. The client then connects directly to the returned endpoint.

1. Q: Which policy is best for a canary deployment?

A: Weighted routing, because it can distribute an approximate percentage of DNS responses to each version.

1. Q: How does latency-based routing choose an endpoint?

A: It selects the endpoint associated with the lowest measured network latency for the requesting client.

1. Q: What is the relationship between primary and secondary records in failover routing?

A: Route 53 returns the primary while its required health check passes and returns the secondary when the primary is unhealthy.

1. Q: What fallback is generally needed in geolocation routing?

A: A default record for queries that do not match a configured geographic location.

1. Q: Which Route 53 policy requires Traffic Flow?

A: Geoproximity routing.

1. Q: What is the purpose of a geoproximity bias?

A: It expands or shrinks the geographic area served by an endpoint, allowing traffic distribution to be shifted.

1. Q: How many healthy records can multivalue answer routing return in one response?

A: Up to eight healthy records.

1. Q: What two configuration elements are used by IP-based routing?

A: CIDR collections and routing rules.

1. Q: Why might weighted routing not produce exact percentages?

A: DNS resolvers and clients cache answers according to TTL, so individual request distribution is not exact.

1. Q: Are health checks required for every Route 53 routing policy?

A: No. They are optional for many policies, but failover requires a health check on the primary record.

1. Q: What is the key difference between geolocation and latency-based routing?

A: Geolocation uses geographic classification; latency-based routing uses measured network performance.

Practice Questions

Question 1

A company is deploying a new version of an application alongside the existing version. It wants approximately 5% of DNS traffic to reach the new version initially, with the ability to increase that percentage gradually. Which Route 53 routing policy should the architect select?

A. Failover routing
B. Weighted routing
C. Geolocation routing
D. Multivalue answer routing

Correct answer: B. Weighted routing

Explanation: Weighted routing supports relative traffic distribution among records with the same name and type. It is well suited to canary and blue/green deployments. The actual request ratio will be approximate because DNS responses are cached.

Question 2

An application is deployed in North America, Europe, and Asia. The business wants each user to connect to the Region that provides the lowest network latency. Which policy best meets this requirement?

A. Latency-based routing
B. Geolocation routing
C. IP-based routing
D. Simple routing

Correct answer: A. Latency-based routing

Explanation: Latency-based routing selects among Regional endpoints according to measured network latency. Geolocation would route based on geographic classification and may not select the lowest-latency endpoint.

Question 3

A production application runs in us-east-1, and a warm disaster recovery environment runs in ap-southeast-2. Users should normally be directed to the primary environment, but DNS should return the recovery endpoint if the primary becomes unhealthy. Which configuration is appropriate?

A. Weighted records with equal weights
B. Latency-based records without health checks
C. Failover records with a health check on the primary
D. Geoproximity routing with a positive bias toward the primary

Correct answer: C. Failover records with a health check on the primary

Explanation: Failover routing implements an active-passive pattern. Route 53 returns the primary while its health check succeeds and the secondary when the primary fails. DNS caching can delay the visibility of the change.

Question 4

A multinational organization must route clients in Germany and France to a European endpoint, clients in Japan to an Asia-Pacific endpoint, and all other clients to a default endpoint. Which policy should be used?

A. Geolocation routing
B. Latency-based routing
C. Multivalue answer routing
D. Weighted routing

Correct answer: A. Geolocation routing

Explanation: Geolocation routing supports country- and region-based records. A default record handles locations that do not match the explicitly configured geographic records.

Question 5

A company has identified the CIDR ranges of its corporate offices and wants DNS queries from those ranges to resolve to a specialized service. Which Route 53 feature is designed for this requirement?

A. IP-based routing with CIDR collections
B. Geoproximity routing with Traffic Flow
C. Failover routing with a secondary record
D. Simple routing with multiple IP values

Correct answer: A. IP-based routing with CIDR collections

Explanation: IP-based routing maps client source CIDR ranges to routing rules and records. The architect should verify which source IP Route 53 observes because recursive resolvers, NAT, and proxies may affect the apparent client address.