Cargando...
Cargando...
Master every routing policy — know exactly which to pick and why on any AWS exam
Choose the right policy by use case: availability, performance, compliance, or traffic distribution
| Feature | Simple One record, one destination | Failover Active-passive disaster recovery | Geolocation Route by user's geographic location | Geoproximity Route by distance with bias tuning | Latency Route to lowest-latency AWS region | Weighted Split traffic by percentage | Multivalue Return multiple healthy IPs | IPBased Route by client IP/CIDR range |
|---|---|---|---|---|---|---|---|---|
Primary Use Case | Single resource, no special routing logic needed | Active-passive HA — primary fails, traffic shifts to standby | Serve localized content, data residency, compliance requirements | Shift traffic between resources based on geographic distance + bias | Minimize end-user latency across multiple AWS regions | Blue/green deployments, A/B testing, gradual traffic migration | Simple load balancing with health-check filtering (not a replacement for ELB) | Route based on known client IP ranges (ISP, corporate network, etc.) |
Health Check Support Simple routing does NOT support health checks — a classic exam trap | NO — cannot associate health checks (single value). With multiple values, returns all; client picks randomly. | YES — REQUIRED. Health check on primary is mandatory; failover triggers automatically. | YES — optional but strongly recommended | YES — optional but strongly recommended | YES — optional but strongly recommended | YES — records with weight 0 are excluded; unhealthy records skipped | YES — only healthy records (up to 8) are returned to clients | YES — optional |
Routing Decision Factor | None — returns the configured value(s) always | Health status of primary endpoint | Geographic location of the DNS query origin (continent, country, or US state) | Geographic distance between user and resource, adjusted by bias (-99 to +99) | Measured network latency from user to AWS region (based on historical latency data) | Proportional weight assigned to each record (0–255) | Returns up to 8 healthy records; client selects one | Client's IP address matched against user-defined CIDR blocks in CIDR collections |
Multiple Records Allowed (Same Name + Type)? | YES — one record can have multiple IP values (returned all at once, random selection by client) | YES — exactly 2: one PRIMARY, one SECONDARY | YES — one per location granularity level | YES — one per resource/location | YES — one per region | YES — up to the Route 53 record limit per hosted zone | YES — up to 8 healthy values returned | YES — one per CIDR collection mapping |
Requires Traffic Flow (Visual Editor)? Geoproximity routing REQUIRES Traffic Flow — this is a critical exam differentiator vs. Geolocation | NO | NO | NO | YES — Geoproximity is ONLY available through Route 53 Traffic Flow | NO | NO | NO | NO |
Bias / Fine-Tuning Control Bias in Geoproximity is the ONLY policy that lets you manually expand/shrink a resource's geographic reach | None | None | None — hard geographic boundaries, no overlap adjustment | YES — bias value from -99 (shrink) to +99 (expand) shifts traffic boundaries | None — AWS measures latency automatically | YES — weight 0–255 per record; weight 0 means no traffic sent | None | None — binary: IP matches CIDR or falls through |
Supports Alias Records? Multivalue Answer does NOT support Alias records — commonly tested | YES | YES | YES | YES | YES | YES | NO — Multivalue does NOT support Alias records | YES |
Best For Compliance / Data Sovereignty | NO | NO | YES — ensures users in EU always hit EU servers (GDPR use case) | Partially — proximity-based, not strict boundary enforcement | NO — routes to fastest, not compliant region | NO | NO | YES — if you know the CIDR ranges of regulated users |
Traffic Split / Canary Deployments | NO | NO | NO | Partially — via bias adjustment | NO | YES — the canonical choice for canary, blue/green, A/B testing | NO | NO |
Acts as Basic Load Balancer? Multivalue is NOT a substitute for ELB. It has no session persistence, no TLS termination, and is DNS-only. | Rudimentary — returns all IPs, client picks | NO | NO | NO | Partially — distributes across regions | Partially — distributes by weight | YES — closest to DNS-level load balancing (up to 8 healthy records) | NO |
Pricing Consideration Geoproximity incurs Traffic Flow charges. Health checks are billed separately per endpoint monitored. | Standard DNS query charges apply | Standard DNS query charges + health check fees | Standard DNS query charges | Traffic Flow policy record charges + DNS query charges (Traffic Flow required) | Standard DNS query charges | Standard DNS query charges | Standard DNS query charges | Standard DNS query charges + CIDR collection charges |
Default / Catch-All Record Support For Geolocation, if no default record exists and the user's location doesn't match, Route 53 returns NODATA response — a common trap | N/A — always returns value | Secondary acts as fallback | YES — configure a '*' (default) record for unmatched locations | N/A — distance-based, always matches nearest | N/A — always matches lowest latency region | N/A | N/A | YES — configure a default record for IPs not in any CIDR collection |
AWS Resource vs. Non-AWS Endpoint Support Geoproximity supports non-AWS resources by specifying custom latitude/longitude coordinates | Both | Both (health checks required for non-AWS) | Both | Both (AWS regions OR custom latitude/longitude for non-AWS) | AWS regions only for latency measurement (endpoint can be external but latency is to the region) | Both | Both | Both |
Granularity of Control | None | Binary (primary/secondary) | Continent → Country → US State | Continuous — adjustable via bias | Per AWS region | Precise — integer weights 0–255 | Binary — healthy or not | Per CIDR block |
Exam Scenario Keywords | 'Single endpoint', 'no routing logic', 'basic DNS' | 'disaster recovery', 'active-passive', 'primary goes down', 'standby' | 'users in Germany see German content', 'GDPR', 'data residency', 'localization' | 'shift more traffic to US-East', 'expand reach', 'bias', 'Traffic Flow' | 'lowest latency', 'best performance', 'multi-region performance' | 'blue/green', 'canary', 'A/B test', '10% to new version', 'gradual migration' | 'multiple healthy IPs', 'simple load balancing', 'up to 8 records' | 'ISP routing', 'corporate network', 'known IP ranges', 'CIDR-based routing' |
Summary
Route 53 offers 8 routing policies each optimized for a distinct scenario. Latency routes for performance, Geolocation for compliance, Weighted for traffic splitting, Failover for DR, Geoproximity (via Traffic Flow) for bias-adjusted geographic routing, Multivalue for basic DNS load balancing, IP-Based for CIDR-aware routing, and Simple for single-destination needs. Understanding the decision axis — availability vs. performance vs. compliance vs. control — is the key to answering any exam question correctly.
🎯 Decision Tree
If single endpoint with no special logic → Simple | If active-passive DR → Failover | If route by user country/continent for compliance → Geolocation | If route by distance AND need to manually shift traffic boundaries → Geoproximity (requires Traffic Flow) | If minimize latency across AWS regions → Latency | If split traffic by percentage / canary deploy → Weighted | If return multiple healthy IPs for basic DNS LB → Multivalue | If route based on known client IP ranges → IP-Based
Simple routing does NOT support health checks. If the question mentions health checks + single record, the answer is NOT Simple routing — pivot to Failover or Multivalue.
Geoproximity routing is ONLY available through Route 53 Traffic Flow. If a question asks how to 'shift more traffic toward a region' or 'expand geographic reach,' the answer is Geoproximity with bias — not Geolocation.
Weighted routing with weight=0 does NOT stop the record from existing — it stops traffic to it. If ALL records have weight=0, Route 53 returns them ALL equally. This is the #1 Weighted policy trap.
Geolocation requires a default '*' record. Without it, users from unmatched locations receive a NODATA DNS response and cannot resolve the hostname. Always add a default record in production.
Multivalue Answer is NOT a load balancer replacement. It returns up to 8 healthy DNS records and the client picks one — there is no session persistence, health monitoring of active connections, or TLS termination. Use ELB for true load balancing.
Latency-based routing uses AWS historical latency data, not real-time measurements. A user geographically close to eu-west-1 might still be routed to us-east-1 if historical latency data shows it's faster.
For blue/green or canary deployments using DNS, Weighted routing is the canonical answer. Use weight=10 for new version, weight=90 for old version to send 10% of traffic to new.
IP-Based routing is the newest policy (GA 2023) and is tested on SAA-C03 and ANS-C01. Scenario: 'Route users from a specific ISP or corporate network to a dedicated endpoint' → IP-Based routing.
Confusing Geolocation with Geoproximity: Geolocation routes based on the USER'S LOCATION (country/continent) with hard boundaries and is ideal for compliance. Geoproximity routes based on DISTANCE between user and resource and allows BIAS ADJUSTMENT to shift traffic — it requires Traffic Flow. Exam questions that mention 'shift traffic', 'expand reach', or 'bias' → Geoproximity. Questions that mention 'users in France must use French servers' or 'GDPR' → Geolocation.
CertAI Tutor · · 2026-02-22
Services
Comparisons
Guides & Patterns