AWS Services
Route 53 Routing Policies
Compare Amazon Route 53 simple, weighted, latency, failover, geolocation, geoproximity, IP-based, and multivalue answer routing policies for SAA-C03 architecture decisions.
After this, you will understand
Route 53 routing policies become simple once learners stop memorizing names and map each policy to the decision it automates.
Simple routes to one answer, weighted splits traffic by percentages, latency chooses lower-latency Regions, failover supports active-passive, and location policies use geography or source IP.
Learners choose latency when the requirement is legal geography, choose weighted when the requirement is health-based DR, or treat DNS routing as a load balancer.
Read the requirement as a routing question: one target, percentage split, active-passive failover, best latency, user geography, resource geography, source IP, or multiple healthy answers.
Think before readingWhich Route 53 policy fits blue-green traffic shifting by percentage?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Simple routing
- Weighted routing
- Latency routing
- Failover routing
- Geolocation routing
- Geoproximity routing
- IP-based routing
- Multivalue answer routing
- Health checks
- DNS exam traps
1. Plain-English Mental Model
Route 53 routing policies decide which DNS answer Route 53 returns.
They do not replace load balancers. They do not inspect every application request after DNS resolution. They influence which endpoint a client receives when it asks DNS for a name.
The useful mental model is:
Route 53 policy = how DNS chooses an answer
The exam usually gives you the desired decision rule:
split 10 percent of users -> weighted
send users to lowest-latency Region -> latency
send traffic to standby only when primary fails -> failover
route European users to Europe -> geolocation
shift traffic around resource locations -> geoproximity
choose based on source CIDR -> IP-based
return several healthy records -> multivalue
2. Why This Service Exists
DNS starts many application journeys. A user types a domain name. A service calls an endpoint. A browser needs an IP address or alias target before it can connect.
At small scale, one DNS record is enough:
www.example.com -> one load balancer
At larger scale, the question becomes more subtle. You may have multiple Regions, blue-green releases, active-passive disaster recovery, users in different countries, or several healthy endpoints.
Route 53 routing policies exist because not every DNS decision is the same.
3. The Naive Approach And Where It Breaks
The naive approach is to use one record for everything.
That breaks when the application needs controlled rollout, regional routing, failover, or geographic compliance.
Another naive approach is to pick "latency" for every multi-Region setup. Latency routing chooses the Region that gives the user the best Route 53 latency measurement. It does not mean the user must stay inside a legal jurisdiction, and it does not mean weighted release control.
A third mistake is expecting DNS to behave like per-request load balancing. DNS results can be cached by resolvers and clients. TTLs matter. Existing connections do not instantly move because a DNS answer changes.
4. Core Primitives
Simple routing returns one or more values for a record without special routing logic.
Weighted routing returns records according to weights you specify. It is useful for blue-green deployments, canary releases, A/B experiments, and gradual migration.
Latency routing uses latency measurements between users and AWS Regions to return the endpoint expected to provide the best latency.
Failover routing uses health checks to support active-passive DNS failover.
Geolocation routing uses the user's geographic location, such as continent, country, or subdivision.
Geoproximity routing routes based on the geographic location of resources and can bias traffic toward or away from a location.
IP-based routing uses source IP ranges that you define.
Multivalue answer routing can return up to eight healthy records selected at random.
5. Architecture Use Cases
Use weighted routing when the requirement says "send 5 percent of traffic to the new version" or "gradually migrate users."
Use latency routing when an application runs in multiple AWS Regions and users should reach the lower-latency regional endpoint.
Use failover routing when one endpoint is primary and another should receive traffic only when the primary is unhealthy.
Use geolocation routing when location is policy-driven, such as serving users from a required geography or customizing content by country.
Use geoproximity routing when the resources themselves have locations and the design needs traffic bias. This is common in more advanced global-routing scenarios.
Use IP-based routing when the decision should be based on source CIDR ranges, such as corporate networks or ISP-specific routing.
Use multivalue answer routing for simple DNS-level distribution across several healthy endpoints when a load balancer is not the requirement.
7. Security Model
Routing policies do not authenticate users. They decide DNS answers.
If a user receives an endpoint, the endpoint still needs security controls: TLS, WAF, IAM, application auth, security groups, private networking, and least privilege.
Geolocation routing is not a hard security boundary. It is DNS routing based on observed location and resolver behavior, not identity verification.
Failover routing requires health checks that accurately represent application health. A weak health check can send users to an unhealthy endpoint or keep users on a broken primary.
Protect hosted zones and record changes with IAM, change review, and CloudTrail monitoring. DNS changes can become production outages quickly.
8. Reliability And Resilience
Failover routing is the policy most directly tied to disaster recovery. It helps active-passive designs by returning the secondary answer when the primary is unhealthy.
Weighted routing can support safer releases because you can shift traffic gradually instead of changing all users at once.
Latency routing can improve regional user experience, but it does not guarantee the whole application path is healthy unless combined with health checks.
Multivalue answer routing can return multiple healthy answers, but it is not a replacement for Elastic Load Balancing.
TTL affects how quickly DNS changes are observed. Low TTLs can improve responsiveness but increase query volume. High TTLs reduce queries but slow changes.
9. Performance And Scaling
Latency routing is the main Route 53 policy chosen for performance-sensitive global applications.
CloudFront and Global Accelerator may be better choices when the application needs edge caching, static anycast IPs, TCP/UDP acceleration, or fast health-based traffic movement.
Route 53 chooses DNS answers. After the answer is cached, the client connects to the endpoint it has. Application performance still depends on the endpoint, network path, caches, load balancers, databases, and service design.
Do not use DNS policy as a substitute for autoscaling targets behind load balancers.
10. Cost Model
Route 53 cost includes hosted zones, DNS queries, health checks, and some advanced routing features.
Weighted and latency policies can reduce migration risk and performance problems, which may be worth more than their direct cost.
Health checks add cost but are required for many failover designs.
Low TTLs can increase DNS query volume. Tune TTL based on change frequency and recovery expectations.
12. SAA-C03 Exam Signals
"Active-passive disaster recovery" points to failover routing.
"Gradually shift 10 percent of traffic" points to weighted routing.
"Route users to the Region with the lowest latency" points to latency routing.
"Route based on country or continent" points to geolocation routing.
"Route based on resource location and bias" points to geoproximity routing.
"Route based on source CIDR blocks" points to IP-based routing.
"Return several healthy IPs selected at random" points to multivalue answer routing.
13. Common Exam Traps
Do not choose latency routing for compliance-based geographic routing.
Do not choose weighted routing when the requirement is automatic active-passive failover.
Do not treat geolocation routing as authentication.
Do not forget DNS caching and TTLs.
Do not use multivalue answer routing as a full load balancer replacement.
Do not assume Route 53 health checks understand deep application correctness unless you design them to.
15. Related Topics
Review Amazon Route 53, CloudFront vs Global Accelerator, and Multi-Region Disaster Recovery On AWS.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.