Route 53 routing policy questions on the SAA-C03 exam require you to match a business requirement to the correct policy. Each policy has a specific purpose and a specific set of scenarios where it is the right answer.
The Seven Routing Policies
Simple — Returns a single resource. No health checks. Used for single-resource setups.
Weighted — Distributes traffic across multiple resources based on percentage weights. Used for A/B testing, canary deployments, or gradually shifting traffic.
Latency-based — Routes users to the region with the lowest latency. AWS measures latency from the user's location to each region and routes to the fastest one.
Failover — Routes to a primary resource when healthy; automatically switches to a secondary when the primary fails health checks. Used for active-passive disaster recovery.
Geolocation — Routes based on the user's geographic location (continent, country, or state). Used for compliance, language-specific content, or restricting access by region.
Geoproximity — Routes based on geographic location with a configurable bias. You can skew traffic toward or away from a resource by adjusting the bias value. Only available via Traffic Flow.
Multivalue Answer — Returns up to 8 healthy records selected at random. Provides basic load balancing with health checking — different from Simple, which returns all records without checking health.
Failover Routing
Failover routing uses health checks to determine which record to serve:
- Primary record — Served when healthy
- Secondary record — Served when the primary fails health checks
Active-passive — This is the classic failover pattern. The primary handles all traffic; the secondary is idle until needed. Use when you have one main site and one DR site.
Health checks — Required for failover routing. Route 53 monitors the primary endpoint and fails over automatically when the endpoint does not respond correctly.
Exam scenario: "A company has a primary website in us-east-1 and a static S3 website in us-west-2 as a backup. Traffic should automatically route to S3 if the primary is unavailable."
Answer: Route 53 Failover routing with a health check on the primary endpoint.
Latency vs Geolocation vs Geoproximity
These three are commonly confused:
Latency: user in Brazil routes to São Paulo region if that has the lowest latency, even though the user is in South America. The decision is purely based on network latency measurement.
Geolocation: user in Brazil routes to a record specifically configured for South America or Brazil, regardless of latency. Used when the routing must follow geographic rules (compliance, language).
Exam trap: "Route all European users to a server in Frankfurt, regardless of performance." — Geolocation (it is a rule, not a performance decision).
"Route users to the fastest AWS region." — Latency-based.
Weighted Routing
Weighted routing allows percentage-based traffic splitting:
- Two records, weights 90 and 10: 90% to the first, 10% to the second
- Used for gradual rollouts: start with 5% of traffic to the new version, increase over time
- If one record has weight 0, it receives no traffic (but the record still exists)
Exam scenario: "A company wants to test a new version of their application with 10% of users." — Weighted routing.
Health Checks
Route 53 health checks monitor:
- An endpoint (HTTP/HTTPS/TCP)
- Another CloudWatch alarm
- A calculated health check (combination of other health checks)
Health checks are required for Failover routing to work. Without health checks, Route 53 has no way to know the primary is down.
Exam trap: Simple routing does not support health checks — Route 53 always returns the record regardless of endpoint health. Multivalue Answer does support health checks and will not return unhealthy records.
Practice SAA-C03 Route 53 questions to build quick recognition of which routing policy each scenario requires.
Routing Policy Decision Table — The Exam's Trick
The exam gives you a scenario and asks which Route 53 routing policy to use. Match the scenario keyword to the policy:
| Scenario Keyword | Routing Policy |
|---|---|
| "Route 50% of traffic to v1, 50% to v2" | Weighted |
| "Minimize latency for users in different regions" | Latency-based |
| "Users in Germany must be routed to EU servers (regulation)" | Geolocation |
| "Route users to the physically closest endpoint" | Geoproximity |
| "Route to primary, failover to secondary if primary fails" | Failover |
| "Distribute across multiple IPs, return all healthy ones" | Multivalue answer |
| "Return a single IP with no health check logic" | Simple |
Geolocation vs Geoproximity is the trap pair. Geolocation routes based on the user's country or continent — it's deterministic and used for regulatory compliance or content licensing where traffic from Germany must go to a German server, regardless of where servers are physically. Geoproximity routes based on physical geographic distance and can be biased with a "bias" value to shift the routing boundary. Geoproximity is used for performance and regional load balancing. If the exam says "regulatory" or "compliance," pick Geolocation. If it says "closest" or "minimize distance" without regulatory constraints, Geoproximity.
Health Check Types — HTTP vs HTTPS vs TCP vs Calculated
Route 53 health checks come in three endpoint types and one aggregation type.
HTTP/HTTPS health checks: Route 53 sends an HTTP GET request to your endpoint. The check passes if the endpoint returns a 2xx or 3xx HTTP status code within 4 seconds. You can optionally specify a string that must appear in the response body (first 5,120 bytes). Use this for web servers, APIs, and load balancers.
TCP health checks: Route 53 establishes a TCP connection to the specified port within 10 seconds. No HTTP exchange is required. Use this for non-HTTP services like SMTP, database ports (checking if the port is open, not whether the database is healthy), or any TCP-based service.
Calculated health checks: aggregate the status of up to 256 child health checks. You define the threshold — the check passes if at least N of the child checks are healthy. Use this when you want a health check to represent the overall health of a multi-component system. For example: a calculated check that passes when at least 2 of 3 AZ endpoint checks are healthy.
CloudWatch alarm-based health checks: Route 53 monitors a CloudWatch alarm state. If the alarm is in ALARM state, the health check fails. This is the mechanism for checking resources that don't have public endpoints (like an RDS instance in a private subnet) — you create a CloudWatch metric alarm on the RDS instance, then a Route 53 health check that monitors that alarm's state.
The exam scenario that points to CloudWatch alarm-based health checks: "The company wants Route 53 failover for an RDS database that is not publicly accessible." The database has no public IP to health-check directly. The answer is a CloudWatch alarm on RDS metrics (like DatabaseConnections or the Multi-AZ replication lag) and a Route 53 health check that monitors that alarm.
Failover vs Simple Routing — The Difference
Simple routing is the baseline. You create a record with one or more values (IP addresses). Route 53 returns all values (in random order if multiple values). There is no health checking — if the IP is dead, Route 53 still returns it. Simple routing is for basic DNS resolution when you have a single resource and no need for failover or traffic distribution.
Failover routing requires a primary record and a secondary record, both with the same DNS name, both with associated health checks. When the primary health check passes, Route 53 returns only the primary record. When the primary fails, Route 53 returns the secondary. This is automatic DNS-level failover without any manual intervention.
The exam distinguishes them clearly: "No single point of failure" and "automatic recovery if primary goes down" both point to Failover routing policy with health checks. "Single static endpoint with no availability concern" points to Simple.
Private Hosted Zones — The Limitations the Exam Tests
Public hosted zones resolve for anyone on the internet. Private hosted zones resolve only from within associated VPCs.
Configuration requirement: the VPC must have two attributes enabled: enableDnsHostnames (allows EC2 instances to get DNS names) and enableDnsSupport (enables DNS resolution in the VPC). Without both, private hosted zone resolution doesn't work even if the zone is associated.
Split-horizon DNS (also called split-view DNS): you can have the same domain name (e.g., api.example.com) resolve to different IPs depending on whether the query comes from inside or outside the VPC. Create a public hosted zone with the external IP and a private hosted zone with the internal IP. Instances inside the VPC get the private IP; external users get the public IP. This is a common exam pattern for internal load balancers — external traffic goes through the public ALB, internal service-to-service traffic goes through the private NLB endpoint.
Multi-VPC association: a private hosted zone can be associated with multiple VPCs, even across accounts (with cross-account association setup). Instances in any associated VPC can resolve the private zone's records.
The exam trap: "A company creates a private hosted zone for internal.example.com and associates it with their VPC. External Route 53 resolvers cannot resolve records in this zone." This is TRUE and is the expected behavior — private hosted zones are not visible externally. The question might ask what configuration change would make a record resolvable externally — the answer is to create a corresponding public hosted zone.
Alias Records vs CNAME — Why Alias for AWS Resources
CNAME records point a name to another name (e.g., www.example.com CNAME app-1234.us-east-1.elb.amazonaws.com). They work for subdomains but have one critical limitation: a CNAME cannot be created at the zone apex (the root domain, like example.com). This is an RFC restriction.
Alias records are a Route 53 extension to DNS that function like CNAMEs but work at the zone apex. An alias record for example.com can point directly to an ELB, CloudFront distribution, S3 website endpoint, or other Route 53 record. No CNAME restriction at the apex.
Additional benefits of Alias records:
- Free queries: Route 53 doesn't charge for queries to Alias records that resolve to AWS resources (ELB, CloudFront, API Gateway, S3, etc.)
- Automatic IP tracking: for load balancers that have dynamic IPs, the Alias record automatically resolves to the current IPs without you managing them
- Health check integration: Alias records can inherit the health check status of the resource they point to
The exam question: "A company wants to route example.com (naked domain) to their Application Load Balancer. What type of Route 53 record should they create?" CNAME cannot be used at the apex — the answer is an Alias record.
Route 53 as a Global Service
Route 53 is not a regional service. There is no us-east-1 Route 53 and no eu-west-1 Route 53 — there's just Route 53, and your hosted zones are globally distributed across Route 53's name servers.
This has operational implications the exam tests:
TTL management for failover: when failover occurs (primary health check fails), Route 53 stops returning the primary record. But DNS resolvers cache responses for the record's TTL. A 300-second TTL means resolvers might continue sending traffic to the failed primary for up to 5 minutes after Route 53 has switched. Lower TTL = faster failover propagation but more Route 53 query charges and more load on resolvers.
The TTL tradeoff: there's no free lunch. A 60-second TTL gets you faster failover but costs more in Route 53 query fees (small amount) and causes more DNS lookups from clients. A 60-second TTL is typical for failover-sensitive records. A 300-second TTL is typical for stable records.
The exam scenario: "A company uses Route 53 failover routing. After a primary region failure, users still reach the failed endpoint for several minutes. What would reduce this delay?" Lower the TTL on the DNS records. Set it to 60 seconds or less for records involved in failover.
Practice Question Sets
Working through real SAA-C03 questions is the fastest way to lock in how the exam phrases these scenarios. Pick a session that fits your time: