Amazon Route 53 shows up on the SAA-C03 exam far more than its “it’s just DNS” reputation suggests. The exam rarely asks what DNS is — it asks you to pick the one routing policy, out of seven, that satisfies a scenario about global users, blue/green rollouts, disaster recovery, or data-sovereignty rules. Two of the answer choices are almost always technically workable, and only one matches the intent buried in the question. Getting fast at that mapping is worth several marks.
This guide walks through every Route 53 routing policy, the health-check mechanics that make failover work, and the alias-versus-CNAME distinction the exam tests constantly. It builds on the DNS-resilience section of the resilient architectures guide for SAA-C03 and pairs with the VPC concepts guide for the networking picture around it. If you are still assembling your prep, start with the AWS Solutions Architect Associate guide for 2026.
What Route 53 Actually Does
Route 53 is AWS’s managed, highly available DNS service. It translates names like www.example.com into the address of whatever should answer — an ELB, a CloudFront distribution, an S3 static site, an EC2 IP, or an on-premises endpoint. On the exam it plays three roles: authoritative DNS, domain registrar, and — the part that earns marks — a traffic router that can make routing decisions based on latency, geography, health, and weight.
The routing decision happens at resolution time. When a client asks “what is the address for this name?”, Route 53 evaluates the record’s routing policy and returns the answer that fits. That is the mental model for every question below: which answer does Route 53 hand back, and why?
Alias vs CNAME: The Record-Type Trap
Before policies, settle the record-type question, because the exam loves it. Both CNAME and Route 53’s alias records point one name at another target — but they are not interchangeable.
| Alias record | CNAME record | |
|---|---|---|
| Points to AWS resources (ELB, CloudFront, S3, API GW) | Yes, natively | Yes, but only via the resource’s DNS name |
Works at the zone apex (example.com) | Yes | No — CNAMEs are illegal at the apex |
| Cost per query | Free (for AWS targets) | Charged as standard DNS queries |
| Resolves to | AWS resource, evaluated by Route 53 | Another domain name |
The decisive fact: you cannot use a CNAME at the zone apex. If a scenario needs example.com (not www.example.com) to point at a load balancer or CloudFront distribution, the answer is an alias record — a CNAME is simply invalid there. This single rule resolves a surprising number of questions.
The Seven Routing Policies
Route 53 offers seven policies. Learn each one by the signal word in the scenario that points to it.
1. Simple Routing
One record, one or more values, no logic. If you give it multiple IPs, Route 53 returns all of them in random order and the client picks one — but there is no health checking. Use it for a single resource with no failover or steering needs.
Signal: “a single web server,” “no health checks required,” basic mapping.
2. Weighted Routing
Splits traffic across multiple resources in proportions you set with numeric weights. Weights are relative: two records with weights 90 and 10 send 90% and 10% of traffic. Set a weight to 0 to stop sending traffic to a record without deleting it.
Signal: “send 10% of traffic to the new version,” “gradually shift traffic,” “canary,” “A/B test,” “blue/green.” Weighted routing is the exam’s default answer for controlled percentage-based rollouts.
example.com (weighted)
├─ record → v1 weight 90 → ~90% of traffic
└─ record → v2 weight 10 → ~10% of traffic (canary)3. Latency-Based Routing
Routes each user to the AWS Region that gives them the lowest network latency, based on Route 53’s latency measurements. Note this is latency, not geographic distance — the nearest Region is usually but not always the fastest.
Signal: “best performance,” “lowest latency,” “fastest response for global users,” resources deployed in multiple Regions. If the question optimises for speed, think latency-based.
4. Failover Routing (Active-Passive)
Sends traffic to a primary resource while it is healthy and fails over to a secondary (standby) when a health check marks the primary unhealthy. This is the classic active-passive disaster-recovery pattern — a common secondary is an S3 static “site is down” page or a standby stack in another Region.
Signal: “active-passive,” “disaster recovery,” “standby,” “if the primary fails, route to a backup.” Failover routing requires a health check on the primary to work.
5. Geolocation Routing
Routes based on the physical location of the user (continent, country, or US state). Use it for content localisation, regional licensing, or compliance — “European users must be served from EU infrastructure.” Always configure a default record to catch locations you did not explicitly map, or those users get no answer.
Signal: “based on where the user is located,” “serve content in the local language,” “data must stay in-region,” “restrict content by country,” “compliance/sovereignty.” The intent is who the user is, not how fast.
6. Geoproximity Routing
Routes based on the geographic distance between users and resources, with a bias value that lets you expand or shrink a resource’s effective service area — shifting more or less traffic toward it. It requires Route 53 Traffic Flow. Because it looks similar to geolocation, the exam uses the bias detail to distinguish them.
Signal: “shift more traffic toward a region,” “expand the service area,” “bias.” If you see the word bias, it is geoproximity, not geolocation.
7. Multivalue Answer Routing
Returns up to eight healthy records at random, each optionally attached to a health check. It is not a substitute for a load balancer — there is no session affinity or real load distribution — but it adds health-aware, DNS-level randomisation for multiple resources.
Signal: “return multiple healthy IPs,” “simple client-side load spreading with health checks,” “no load balancer.” Contrast with simple routing, which has no health checks.
Geolocation vs Latency: The Most-Confused Pair
These two trip up more candidates than any other Route 53 topic, because both involve “location.” The distinction is about why:
| Latency-based | Geolocation | |
|---|---|---|
| Decides on | Measured network latency | User’s physical location |
| Optimises for | Speed | Compliance / localisation |
| Typical driver | ”fastest experience" | "serve from a specific country,” “data sovereignty” |
| Nearest Region always wins? | No — fastest, not closest | Yes — by mapped location |
Rule of thumb: if the requirement is about performance, choose latency-based. If it is about rules, borders, language, or legal residency, choose geolocation. Read the objective in the question, not the geography.
Health Checks: What Makes Failover Real
Failover, multivalue, and any health-aware routing depend on Route 53 health checks. There are three kinds:
- Endpoint health checks — monitor an IP or domain over HTTP, HTTPS, or TCP and mark it healthy/unhealthy based on responses.
- Calculated health checks — combine the results of other health checks with
AND/OR/threshold logic (a parent that is healthy only if N children are healthy). - CloudWatch alarm health checks — treat a CloudWatch alarm state as the health signal, useful for metrics an HTTP probe cannot see (like private resources).
Health checkers probe from multiple global locations; an endpoint is considered unhealthy only when enough of them agree, which avoids flapping from a single-region blip. In a failover setup, you attach the health check to the primary record — when it goes unhealthy, Route 53 stops handing out the primary and returns the secondary instead.
example.com (failover)
├─ PRIMARY → ALB in us-east-1 [health check ✓]
└─ SECONDARY → S3 "down" page (served only when primary fails)Matching Policies to Scenarios
The exam is a mapping exercise. Internalise this table and most Route 53 questions become fast:
| Requirement in the scenario | Routing policy |
|---|---|
| Single resource, nothing fancy | Simple |
| Canary / blue-green / % traffic split | Weighted |
| Lowest latency for global users | Latency-based |
| Active-passive DR / automatic backup | Failover (+ health check) |
| Serve by country / compliance / language | Geolocation |
| Shift traffic with a tunable bias | Geoproximity |
| Return several healthy IPs, no ELB | Multivalue answer |
Point example.com (apex) at an ELB/CloudFront | Alias record (not CNAME) |
Common Mistakes on This Topic
| Mistake | Why it’s wrong |
|---|---|
| Using a CNAME at the zone apex | Illegal — the apex requires an alias record |
| Confusing latency with geolocation | Latency = speed; geolocation = user’s location/compliance |
| Expecting failover to work without a health check | Failover needs a health check to detect the primary is down |
| Treating multivalue as a load balancer | It randomises DNS answers; it is not real load balancing |
| Forgetting a default record in geolocation | Unmapped locations get no answer at all |
| Choosing geoproximity when there is no bias | Bias is the tell for geoproximity vs geolocation |
A Worked Exam Scenario
“A company runs its application in
us-east-1andeu-west-1. Users worldwide must be served from whichever deployment gives them the fastest response. If a Region’s endpoint fails, users should be routed to the healthy Region.”
Two requirements are stacked here. “Fastest response” → latency-based routing. “If an endpoint fails, route elsewhere” → health checks attached to each latency record so Route 53 only returns healthy Regions. The answer is latency-based routing with health checks — not failover (which is active-passive, not performance-optimised) and not geolocation (which optimises for location, not speed). Watching for the speed keyword is what breaks the tie.
Practising the Distinctions
Route 53 questions are pure pattern recognition — the facts are simple, but under a 130-minute clock with 65 questions and two plausible options per item, the bottleneck is reading the intent fast enough. The skill is spotting the signal word (bias, canary, compliance, lowest latency, active-passive) and mapping it to a policy without second-guessing.
That timed discrimination is exactly what the AWS Solutions Architect Associate (SAA-C03) Mock Exam Bundle drills. Its questions mirror the exam’s layered wording — where latency and geolocation, or weighted and simple, sit side by side as answer choices — with detailed explanations for why each option is right or wrong. Pair it with the resilient architectures guide for the DR context around failover, and the high-performing architectures guide for how latency-based routing fits the performance pillar.
Frequently Asked Questions
What is the difference between latency-based and geolocation routing in Route 53?
Latency-based routing sends users to the Region with the lowest measured network latency, optimising for speed — the nearest Region usually wins but not always. Geolocation routing sends users to a resource based on their physical location (continent, country, or US state), optimising for compliance, licensing, or localisation. Choose latency-based when the requirement is about performance; choose geolocation when it is about where users are, legal residency, or serving region-specific content.
Can I use a CNAME record at the zone apex in Route 53?
No. The DNS standard forbids CNAME records at the zone apex (the root domain like example.com). Route 53 solves this with alias records, which can point the apex directly at AWS resources such as an ELB, CloudFront distribution, S3 website endpoint, or API Gateway. Alias records also resolve for free when pointing at AWS targets, whereas CNAME lookups are billed as standard queries. If a question needs the apex to point at an AWS resource, the answer is an alias record.
How does Route 53 failover routing work?
Failover routing implements an active-passive pattern with two records: a primary and a secondary. You attach a health check to the primary; while it is healthy, Route 53 returns the primary. When the health check marks the primary unhealthy, Route 53 automatically returns the secondary instead — commonly a standby stack in another Region or an S3 static maintenance page. Failover requires a working health check on the primary; without one there is nothing to trigger the switch.
What is the difference between multivalue answer and simple routing?
Both can return multiple values, but multivalue answer routing supports health checks and only returns records that are healthy (up to eight, chosen at random), while simple routing returns all configured values with no health awareness at all. Neither is a true load balancer — there is no session stickiness or real load distribution — but multivalue answer adds health-aware DNS-level randomisation, which is why the exam favours it when the scenario mentions returning multiple healthy endpoints without an ELB.
When should I use weighted routing on the SAA-C03 exam?
Use weighted routing whenever the scenario describes shifting a controlled percentage of traffic between resources — canary releases, blue/green deployments, A/B testing, or gradually migrating users to a new version. You assign relative numeric weights to records, and Route 53 distributes traffic in those proportions; a weight of zero stops traffic to a record without removing it. Any wording about “10% of traffic,” “gradual rollout,” or “test the new version with some users” points to weighted routing.
What is geoproximity routing and how is it different from geolocation?
Geoproximity routing sends traffic to resources based on the geographic distance between users and those resources, and it adds a bias value that expands or shrinks a resource’s effective service area to shift more or less traffic toward it. Geolocation routing, by contrast, routes strictly by the user’s mapped location with no distance calculation or bias. The presence of a bias — “send more traffic to this region” — is the exam’s signal that the answer is geoproximity rather than geolocation. Geoproximity requires Route 53 Traffic Flow.