Cargando...
Cargando...
Scalable, highly available DNS + health checking + traffic routing — the backbone of every resilient AWS architecture
Amazon Route 53 is a highly available, scalable, and fully managed Domain Name System (DNS) web service that translates human-readable domain names into IP addresses, routes end-user requests to AWS or on-premises infrastructure, and monitors the health of your resources. It integrates natively with virtually every AWS service and supports sophisticated traffic management policies including latency-based, geolocation, geoproximity, weighted, failover, and multivalue answer routing. Route 53 is the only AWS service with a 100% uptime SLA, making it the authoritative choice for mission-critical DNS and global traffic management.
To provide globally distributed, authoritative DNS resolution combined with health-based traffic routing and failover, ensuring end users are always directed to the fastest, healthiest endpoint available.
Use When
Avoid When
Alias Records (Route 53-native)
Free DNS queries; map to AWS resources (ELB, CloudFront, S3, API GW, etc.) at the zone apex; auto-update when resource IP changes
CNAME Records
Standard DNS CNAME — cannot be used at zone apex (root domain); charged per query unlike Alias
Latency-Based Routing
Routes to the AWS Region with lowest network latency for the end user — based on AWS latency data, not geographic proximity
Geolocation Routing
Routes based on user's geographic location (continent, country, US state); requires a default record for unmatched locations
Geoproximity Routing (Traffic Flow only)
Routes based on geographic distance with configurable bias (+/-); only available via Traffic Flow/Traffic Policies
Weighted Routing
Distributes traffic by percentage weight (0–255); weight 0 = no traffic sent; useful for blue/green and canary deployments
Failover Routing (Active-Passive)
Primary record served when healthy; secondary (failover) served when primary health check fails
Multivalue Answer Routing
Returns up to 8 healthy records randomly; NOT a substitute for a load balancer but adds basic client-side load distribution
IP-Based Routing
Routes traffic based on the CIDR block of the originating IP address; useful for ISP-based or on-premises routing
Health Checks
HTTP, HTTPS, TCP checks on public endpoints; CloudWatch alarm-based checks for private/VPC resources; calculated health checks aggregate multiple checks
Private Hosted Zones
DNS resolution within one or more VPCs; requires enableDnsHostnames and enableDnsSupport on the VPC
Route 53 Resolver
Inbound endpoints (on-premises → AWS) and outbound endpoints (AWS → on-premises) for hybrid DNS; Resolver Rules forward specific domains
Route 53 Resolver DNS Firewall
Filters and blocks DNS queries to malicious or unwanted domains at the VPC level; managed domain lists available
DNSSEC Signing
Supported for public hosted zones; Route 53 acts as the signing authority; protects against DNS spoofing/cache poisoning
Domain Registration
Register domains directly through Route 53; supports many TLDs; auto-renew available; WHOIS privacy included for supported TLDs
Traffic Flow (Visual Policy Editor)
GUI-based complex routing policy builder; required for geoproximity routing; supports versioned policies
100% Availability SLA
The only AWS service with a 100% uptime SLA — Route 53 is globally distributed across 100+ edge locations (Points of Presence)
Query Logging
Logs DNS queries to CloudWatch Logs (public hosted zones) or S3 (via Kinesis Data Firehose); useful for security auditing and debugging
Split-Horizon DNS
Same domain name resolves differently inside VPC (private hosted zone) vs. public internet (public hosted zone)
Alias Record for Global Content Delivery
high freqCreate an Alias A/AAAA record pointing to a CloudFront distribution for the zone apex (e.g., example.com). Route 53 resolves to CloudFront edge locations automatically. Combine with Route 53 health checks and failover routing for origin resilience. Note: Route 53 routes to CloudFront; CloudFront handles caching and content delivery — these are complementary, not competing services.
Static Anycast IP Routing for Non-HTTP Workloads
high freqUse Global Accelerator when you need fixed static IP addresses (for whitelisting), TCP/UDP protocol support, or consistent performance via AWS backbone. Route 53 can point to Global Accelerator's static IPs or DNS name, but Global Accelerator is NOT a DNS service — it intercepts traffic at the network layer. Use Route 53 for DNS; use Global Accelerator for network-layer acceleration and IP stability.
Alias Record for Load Balancer DNS
high freqAlways use Alias records (not CNAME) to point Route 53 to ELB/ALB/NLB DNS names. Alias records work at zone apex, are free for queries, and automatically follow IP changes. Route 53 health checks can monitor ELB endpoints and trigger failover to a secondary region's ELB when the primary becomes unhealthy.
Static Website Hosting with Custom Domain
high freqCreate an S3 bucket named exactly as your domain (e.g., example.com), enable static website hosting, then create a Route 53 Alias A record pointing to the S3 website endpoint. The bucket name MUST match the domain name exactly. Use CloudFront in front of S3 for HTTPS support, as S3 static website endpoints do not support HTTPS natively.
Hybrid DNS Resolution via Resolver Endpoints
high freqDeploy Route 53 Resolver inbound endpoints so on-premises systems can resolve AWS private hosted zone records over Direct Connect or VPN. Deploy outbound endpoints with Resolver Rules to forward on-premises domain queries from AWS workloads to on-premises DNS servers. This is the canonical hybrid DNS architecture tested on SAP-C02 and SAA-C03.
DNS Validation for TLS Certificates
high freqACM can validate domain ownership via DNS by adding a CNAME record to your Route 53 hosted zone. Route 53 and ACM integrate to add this validation record automatically when both are in the same account. DNS validation is preferred over email validation because it auto-renews as long as the CNAME record remains in place.
Serverless DNS Failover with Lambda
medium freqRoute 53 health checks can trigger CloudWatch alarms, which invoke Lambda functions via SNS for custom remediation during failover events. Additionally, Lambda@Edge can be used with CloudFront (which Route 53 routes to) for dynamic request manipulation at edge locations.
Custom Domain for API Gateway
medium freqCreate a custom domain name in API GW, then create a Route 53 Alias record pointing to the API GW regional or edge-optimized endpoint. For edge-optimized endpoints, use us-east-1 for ACM certificates. Route 53 weighted routing can split traffic between API GW stages for canary deployments.
Alias records are ALWAYS preferred over CNAME for AWS resources: they work at the zone apex (root domain), DNS queries are FREE, and they automatically track IP changes. CNAME cannot be used at the zone apex — this is a hard DNS protocol limitation, not an AWS limitation.
DNS failover speed is controlled primarily by TTL, NOT by health check interval. Even with a 10-second health check interval and 1-failure threshold, if your TTL is 300 seconds, clients will continue hitting the failed endpoint for up to 5 minutes. Always lower TTL BEFORE a planned failover event or maintenance window.
Route 53 health checks CANNOT directly monitor private VPC resources (e.g., RDS endpoints, internal EC2 instances) because health checkers are external to your VPC. For private resources, use a CloudWatch metric alarm as the health check target (calculated health check via CloudWatch alarm), which Route 53 can then monitor.
Latency-based routing ≠ geolocation routing. Latency-based routes to the AWS Region with the LOWEST NETWORK LATENCY (measured empirically by AWS). Geolocation routes based on WHERE THE USER IS GEOGRAPHICALLY. A user in Europe might get routed to us-east-1 with latency routing if that has lower latency than eu-west-1 at that moment.
Route 53 vs Global Accelerator: Route 53 is a DNS service (Layer 7 DNS resolution, subject to TTL caching). Global Accelerator is a network service (Layer 3/4, static anycast IPs, no DNS caching issue, uses AWS backbone). For scenarios requiring fixed IPs for whitelisting or faster failover without DNS propagation delay, choose Global Accelerator.
Health checks CANNOT directly monitor private VPC resources (RDS, internal EC2). Use CloudWatch alarm-based health checks as a proxy for private endpoints.
Alias records = FREE queries + zone apex support + auto IP tracking. CNAME = charged queries + cannot be used at zone apex. ALWAYS use Alias for AWS resource endpoints.
DNS failover speed = TTL (dominant factor) + health check interval + failure threshold. Lowering TTL before a change is the most impactful action to minimize failover delay — not adjusting health check settings.
Geoproximity routing requires Traffic Flow (Traffic Policies). You CANNOT configure geoproximity routing directly through the standard hosted zone record interface — it must be done through the visual Traffic Flow editor. This is a common exam trap.
Multivalue Answer routing is NOT a load balancer replacement. It returns up to 8 healthy IP addresses and the client picks one — there is no session persistence, connection draining, or algorithm-based distribution. Use ELB for true load balancing.
For private hosted zones, the associated VPC must have both 'DNS resolution' (enableDnsSupport) and 'DNS hostnames' (enableDnsHostnames) enabled. If either is disabled, private hosted zone resolution will fail silently — a common debugging trap.
Weighted routing with weight=0 sends NO traffic to that record but the record is still returned if ALL records in the set have weight=0 (traffic is distributed equally among all). This is different from disabling a record — use health checks with failover routing to truly remove an unhealthy endpoint.
Route 53 Resolver inbound endpoints allow on-premises DNS servers to resolve AWS private hosted zone records. Outbound endpoints + Resolver Rules allow AWS resources to forward DNS queries for on-premises domains to on-premises DNS servers. You need BOTH endpoint types for full bidirectional hybrid DNS — a key SAP-C02 architecture pattern.
For S3 static website hosting with a custom domain via Route 53, the S3 bucket name MUST exactly match the domain name (e.g., bucket 'www.example.com' for domain 'www.example.com'). This is a hard requirement — mismatched names will fail.
Cross-account private hosted zone association: you CAN associate a private hosted zone from Account A with a VPC in Account B, but it requires CLI/SDK steps (authorize-vpc-association + associate-vpc-with-hosted-zone). The console does NOT support cross-account association.
Common Mistake
Route 53 health checks can directly monitor internal VPC resources like RDS endpoints or internal application servers on private IPs.
Correct
Route 53 health checkers are external AWS infrastructure and cannot reach resources inside a VPC's private network. For private resources, you must use a CloudWatch metric alarm as a proxy health check — Route 53 monitors the CloudWatch alarm state, and CloudWatch monitors your private resource via the CloudWatch agent or service metrics.
This is one of the most tested misconceptions on SAA-C03 and SAP-C02. The exam will present a scenario with an RDS failover requirement and expect you to know the CloudWatch alarm workaround. Remember: Route 53 health checkers live OUTSIDE your VPC — they can only reach public endpoints.
Common Mistake
Switching from CNAME to Alias records (or vice versa) will speed up or slow down DNS propagation.
Correct
DNS propagation speed is determined entirely by TTL (Time to Live) — the value set on the DNS record. The record TYPE (CNAME vs. Alias) has zero effect on propagation speed. Alias records are preferred for AWS resources because they are free, work at zone apex, and auto-update IPs, but they do not change how fast DNS changes propagate.
Candidates conflate 'Alias = AWS magic = faster' with propagation speed. The TTL is what resolvers cache. Lower TTL = faster propagation. This is tested directly in questions about minimizing DNS failover time.
Common Mistake
Latency-based routing sends users to the geographically closest AWS Region.
Correct
Latency-based routing sends users to the AWS Region with the LOWEST MEASURED NETWORK LATENCY, which is based on empirical latency data AWS maintains between regions and ISPs/geographic areas. This is usually (but not always) the closest region. A user in eastern Canada might be routed to us-east-1 rather than ca-central-1 if latency measurements favor it.
The exam loves to test the distinction between latency (network performance metric) and geography (physical distance). Geolocation routing is the policy for geography-based routing. Mixing these up leads to wrong architecture recommendations.
Common Mistake
Global Accelerator is just a faster version of Route 53, and both serve the same DNS-based traffic routing purpose.
Correct
Route 53 is a DNS service — it resolves domain names to IPs, and clients cache those IPs per TTL. Global Accelerator is a network-layer service that provides static anycast IP addresses and routes traffic over the AWS global backbone, bypassing the public internet. Global Accelerator failover is near-instantaneous (seconds) because it does not rely on DNS TTL propagation. Use Route 53 for DNS; use Global Accelerator when you need fixed IPs, non-HTTP protocols, or sub-minute failover without DNS propagation delays.
This is the #1 confusion on certification exams involving both services. The key differentiators: (1) Global Accelerator = static IPs + no TTL caching issue + AWS backbone; (2) Route 53 = DNS resolution + TTL-based caching + flexible routing policies. Questions about 'whitelisting IPs' or 'gaming/IoT with TCP/UDP' almost always want Global Accelerator.
Common Mistake
Failover routing and latency-based routing are interchangeable for high availability across regions.
Correct
Failover routing is an ACTIVE-PASSIVE pattern — traffic always goes to the primary unless it fails a health check, then it routes to the secondary. Latency-based routing is an ACTIVE-ACTIVE pattern — traffic is continuously distributed to the lowest-latency healthy endpoint. For HA with cost optimization (secondary only used in failure), use failover. For performance optimization with all endpoints active, use latency-based.
Exam scenarios will describe a requirement and expect you to choose the right routing policy. 'Primary site with DR backup' = failover. 'Best performance for global users with multiple active regions' = latency-based. Mixing these up results in over-engineered or incorrect architectures.
Common Mistake
You can use a CNAME record for the root/apex domain (e.g., example.com without www).
Correct
The DNS protocol specification (RFC 1912) prohibits CNAME records at the zone apex. Route 53 enforces this — you cannot create a CNAME for 'example.com' itself. Use an Alias record instead, which is a Route 53 extension to DNS that behaves like a CNAME but is allowed at the zone apex and maps directly to AWS resource DNS names.
This is a fundamental DNS concept that appears on every level of AWS certification. The answer to 'how do I point example.com to my ELB/CloudFront/S3?' is ALWAYS an Alias A record, never a CNAME.
Common Mistake
Route 53 Resolver is only needed for DNS within AWS VPCs and has no relevance to on-premises connectivity.
Correct
Route 53 Resolver is the service that enables HYBRID DNS — bidirectional DNS resolution between AWS VPCs and on-premises networks. Inbound Resolver endpoints allow on-premises systems to resolve AWS private hosted zone records. Outbound Resolver endpoints with forwarding rules allow AWS resources to resolve on-premises domain names. This is a critical architecture component for any Direct Connect or VPN-connected hybrid environment.
SAP-C02 and SAA-C03 heavily test hybrid DNS architectures. Candidates who think Route 53 Resolver is only for VPC-internal DNS will miss questions about on-premises DNS integration patterns.
ALIAS = Always Linked Into AWS Services (free, zone-apex capable, auto-updating) — CNAME = Can't Name At apex (zone apex forbidden)
TTL = 'Time To Linger' — DNS changes linger in resolver caches for exactly TTL seconds; health check speed is irrelevant if TTL is high
Routing policy cheat: FLWGM = Failover (active-passive), Latency (lowest ms), Weighted (%), Geolocation (country/continent), Multivalue (up to 8 IPs) — plus Geoproximity (Traffic Flow only) and IP-based
Global Accelerator vs Route 53: 'GA = Fixed IPs + No TTL wait + Backbone speed' | 'R53 = DNS names + TTL cache + Routing policies'
Private Hosted Zone checklist: 'DNS Support ON + DNS Hostnames ON' — both VPC settings must be enabled or private DNS silently breaks
CertAI Tutor · SAP-C02, CLF-C02, SAA-C03, DEA-C01, DOP-C02, DVA-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns