--- title: AWS Route 53: DNS and Traffic Management Patterns description: July 2026: Route 53 hosted zones, latency/geo/failover routing, health checks, and when DNS TTL is not enough, with Route 53 Application Recovery Controller for controlled multi-Region cutover. url: https://www.joinhorizon.co/blog/aws-route-53-dns-traffic-management-patterns/ datePublished: 2026-02-21T00:00:00.000Z dateModified: 2026-10-28T00:00:00.000Z author: palaniappan-p category: Cloud Architecture tags: route-53, dns, aws, networking, high-availability --- # AWS Route 53: DNS and Traffic Management Patterns > July 2026: Route 53 hosted zones, latency/geo/failover routing, health checks, and when DNS TTL is not enough, with Route 53 Application Recovery Controller for controlled multi-Region cutover. Route 53 is more than a DNS host. Health checks, latency/geo/weighted routing, and failover make it a control surface for availability, and a single bad record can take down everything. As of **July 19, 2026**, DNS failover still lives or dies on **health-check fidelity** and **TTL behavior**. When you need operator-controlled multi-Region cutover with a highly available data plane (not “hope the resolver refreshes”), add **[Route 53 Application Recovery Controller](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery-controller.html)** routing controls (on/off switches backed by a multi-Region quorum cluster and safety rules) instead of relying on TTL alone. > **Reproduce this:** Failover checklist: [`examples/architecture-blog-2026/route53/failover-healthcheck-checklist.md`](https://www.joinhorizon.co/examples/architecture-blog-2026/route53/failover-healthcheck-checklist.md) ## Core concepts ### Hosted zones A hosted zone is a container for DNS records for a domain: **Public hosted zone:** Resolves domain names on the internet: ``` example.com (public hosted zone) ├── A example.com → ALB (dualstack.my-alb.us-east-1.elb.amazonaws.com) ├── CNAME www.example.com → example.com ├── MX example.com → 10 mail.example.com └── TXT example.com → "v=spf1 include:amazonses.com ~all" ``` **Private hosted zone:** Resolves domain names within a [VPC](https://www.joinhorizon.co/blog/aws-vpc-networking-best-practices-for-production/) only: ``` internal.example.com (private hosted zone, attached to VPC) ├── A api.internal.example.com → 10.0.11.50 ├── A db.internal.example.com → 10.0.21.30 └── CNAME cache.internal.example.com → my-redis.abc123.use1.cache.amazonaws.com ``` Private hosted zones enable human-readable names for internal services without exposing them to the internet. Attach the hosted zone to each VPC that needs to resolve these names. ### Record types | Type | Purpose | Example | | ----- | ----------------------------------------------- | ---------------------------------------------------- | | A | Maps domain to IPv4 address | `example.com → 192.0.2.1` | | AAAA | Maps domain to IPv6 address | `example.com → 2001:db8::1` | | CNAME | Maps domain to another domain | `www.example.com → example.com` | | Alias | Maps domain to AWS resource (Route 53 specific) | `example.com → ALB DNS name` | | MX | Mail server routing | `example.com → 10 mail.example.com` | | TXT | Text records (SPF, DKIM, verification) | `"v=spf1 include:amazonses.com ~all"` | | NS | Name server delegation | `example.com → ns-123.awsdns-45.com` | | SRV | Service location | `_sip._tcp.example.com → 10 60 5060 sip.example.com` | ### Alias records Alias records are Route 53's most important feature. They map your domain directly to AWS resources without CNAME limitations: ``` CNAME limitation: Cannot be used at the zone apex (example.com) Alias advantage: Works at the zone apex AND is free (no query charges) ``` **Use Alias records for:** - ALB/NLB/CLB endpoints - [CloudFront](https://www.joinhorizon.co/services/aws-cloudfront-consultant/) distributions - S3 website endpoints - API Gateway endpoints - Another Route 53 record in the same hosted zone Alias queries are free and CNAME queries are charged, so use Alias when pointing to an AWS resource. ## Routing policies Routing policies determine how Route 53 responds to DNS queries. Each policy suits a different traffic management pattern. ### Simple routing One record, one or more values. Route 53 returns all values in random order: ``` example.com → [192.0.2.1, 192.0.2.2, 192.0.2.3] Client receives all IPs, connects to one (typically the first) ``` **Best for:** Single resources or simple round-robin distribution. It has no health checks, so if one IP is unhealthy, clients may still receive it. ### Weighted routing Distribute traffic by percentage across multiple resources: ``` example.com: Record 1: ALB-primary weight=90 (90% of traffic) Record 2: ALB-canary weight=10 (10% of traffic) ``` **Use cases:** - **Canary deployments:** Send 5-10% of traffic to the new version, monitor, then shift 100% - **A/B testing:** Split traffic between application variants - **Blue-green migrations:** Gradually shift traffic from old to new infrastructure - **Regional load distribution:** Send traffic to Regions proportionally to capacity ### Latency-based routing Route traffic to the Region with the lowest latency for the user: ``` example.com: Record 1: ALB-us-east-1 (Region: us-east-1) Record 2: ALB-eu-west-1 (Region: eu-west-1) Record 3: ALB-ap-southeast-1 (Region: ap-southeast-1) ``` A user in London gets routed to `eu-west-1`. A user in Tokyo gets routed to `ap-southeast-1`. Route 53 measures latency between the user's DNS resolver location and each AWS Region. **Best for:** Multi-Region applications where user experience depends on latency. Combine with health checks for automatic failover when a Region is unhealthy. ### Geolocation routing Route traffic based on the geographic location of the user: ``` example.com: Record 1: ALB-eu-west-1 (Location: Europe) Record 2: ALB-us-east-1 (Location: North America) Record 3: ALB-ap-northeast-1 (Location: Asia) Record 4: ALB-us-east-1 (Location: Default — catches all others) ``` **Use cases:** - **Compliance:** Keep EU user data in EU Regions (GDPR) - **Content localization:** Serve language-specific content by geography - **License restrictions:** Restrict service availability by country - **Regulatory requirements:** Different processing rules per jurisdiction Always include a default record. Without it, users outside your defined geographies receive no response. ### Failover routing Active-passive failover between primary and secondary resources: ``` example.com: Primary: ALB-us-east-1 (health check: /health → 200 OK) Secondary: ALB-us-west-2 (used only when primary fails health check) ``` Route 53 monitors the primary with health checks. When the primary fails, Route 53 automatically routes all traffic to the secondary. When the primary recovers, traffic routes back. **Best for:** [Disaster recovery](https://www.joinhorizon.co/blog/aws-disaster-recovery-strategies-pilot-light-warm-standby-multi-site/) with active-passive architecture. The secondary can be a full standby, a static S3 error page, or a different Region deployment. ### Multivalue answer routing Return multiple healthy values with health checks: ``` example.com: Record 1: 192.0.2.1 (health check: healthy) ← returned Record 2: 192.0.2.2 (health check: healthy) ← returned Record 3: 192.0.2.3 (health check: unhealthy) ← NOT returned Record 4: 192.0.2.4 (health check: healthy) ← returned ``` This is similar to simple routing but with health checks, so unhealthy resources are removed from responses. Returns up to 8 healthy records. **Best for:** Simple health-checked round-robin without the complexity of an ALB. ## Health checks Health checks make routing policies intelligent. Without them, Route 53 routes to dead endpoints. ### Health check types | Type | Monitors | Best For | | ---------------- | ---------------------------------- | ------------------------------------- | | Endpoint | HTTP/HTTPS/TCP response | ALBs, APIs, web applications | | Calculated | Combination of other health checks | Complex health logic (3 of 5 healthy) | | CloudWatch alarm | CloudWatch metric alarm state | Custom health based on any metric | ### Endpoint health checks ``` Health check configuration: Protocol: HTTPS Endpoint: example.com/health Port: 443 Path: /health Interval: 30 seconds (or 10 seconds for fast detection) Failure threshold: 3 (mark unhealthy after 3 consecutive failures) Regions: Route 53 checks from multiple Regions worldwide ``` **Health check endpoint design:** - Return `200 OK` only when the application is fully operational - Check database connectivity, cache availability, and critical dependencies - Respond within 4 seconds (Route 53's timeout for standard health checks) - Do not cache health check responses ### Calculated health checks Combine multiple health checks with AND/OR logic: ``` Application health = API health check AND Database health check AND Cache health check → All three must be healthy for the application to be considered healthy → If any one fails, failover routing activates OR variant: Application health = API-AZ-a OR API-AZ-b OR API-AZ-c → Application is healthy if at least 1 of 3 AZs is healthy ``` ### Health check and alarm integration Use [CloudWatch alarms](https://www.joinhorizon.co/blog/aws-cloudwatch-observability-metrics-logs-alarms-best-practices/) for health metrics that are not HTTP-based: ``` CloudWatch alarm: SQS queue depth > 10,000 (consumer falling behind) → Alarm state: ALARM → Health check: Unhealthy → Route 53: Failover to secondary Region ``` This allows failover based on any CloudWatch metric, not just HTTP response codes. ## Architecture patterns ### Multi-Region active-active ![Architecture diagram of a user reaching Route 53, which can send them to a load balancer in us-east-1 or eu-west-1](../../assets/images/blog/aws-route-53-dns-traffic-management-patterns-latency.webp) _Figure: the article's active-active example. Latency routing chooses between the regional load balancers. A region that fails its health check stops receiving new traffic. The application tier has to be stateless for this to work. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/aws-route-53-dns-traffic-management-patterns/latency.drawio)._ Serve traffic from multiple Regions simultaneously: ``` example.com (latency-based routing) ├── us-east-1: ALB → ECS Service (health check: /health) ├── eu-west-1: ALB → ECS Service (health check: /health) └── ap-southeast-1: ALB → ECS Service (health check: /health) ``` Users are routed to the nearest healthy Region. If a Region fails its health check, traffic automatically redistributes to the remaining Regions. **Requirements:** - Stateless application tier (no local session state) - [Global database](https://www.joinhorizon.co/blog/aws-disaster-recovery-strategies-pilot-light-warm-standby-multi-site/) (DynamoDB Global Tables or Aurora Global Database) - Cross-Region data replication ### Multi-Region active-passive (DR) Primary Region handles all traffic; secondary activates during failure: ``` example.com (failover routing) ├── Primary: us-east-1 ALB (health check: /health) └── Secondary: us-west-2 ALB (activated on primary failure) ``` **Cost advantage:** The secondary Region can run at reduced capacity (pilot light or warm standby) until failover, significantly reducing DR costs compared to active-active. ### Blue-green deployment ![Architecture diagram of Route 53 weighted routing sending most traffic to a blue stack and a canary share to a green stack](../../assets/images/blog/aws-route-53-dns-traffic-management-patterns-weighted.webp) _Figure: the blue-green pattern in the article. Weighted records send most lookups to blue and a small share to green. Raising green's weight is the cutover. Clients can keep the old answer until the TTL expires. [Open the draw.io source](https://www.joinhorizon.co/examples/architecture-blog-2026/aws-route-53-dns-traffic-management-patterns/weighted.drawio)._ Use weighted routing for zero-downtime deployments: ``` Step 1: example.com → Blue (weight=100), Green (weight=0) Step 2: Deploy new version to Green Step 3: example.com → Blue (weight=90), Green (weight=10) ← canary Step 4: Monitor Green for errors Step 5: example.com → Blue (weight=0), Green (weight=100) ← cutover ``` If Green shows errors at Step 4, revert: set Green weight back to 0. DNS propagation delay (TTL) means some traffic continues to the old weights for the TTL duration. **TTL for blue-green:** Set record TTL to 60 seconds during deployments. Lower TTLs mean faster cutover but more DNS queries (and cost). ### CloudFront and Route 53 For global content delivery: ``` example.com (Alias → CloudFront distribution) → CloudFront edge locations worldwide → Origin: ALB in us-east-1 ``` CloudFront handles geographic distribution at the CDN layer. Route 53 provides the DNS resolution. Combined with [WAF](https://www.joinhorizon.co/blog/aws-waf-web-application-firewall-production-guide/) for security and [S3](https://www.joinhorizon.co/blog/aws-s3-security-best-practices-preventing-data-exposure/) for static assets, this is the standard architecture for global web applications. ## Domain management ### Domain registration Route 53 is also a domain registrar. Registering domains through Route 53 simplifies management because the DNS hosted zone is created automatically. **Domain transfer to Route 53:** 1. Unlock the domain at the current registrar 2. Get the authorization code (EPP code) 3. Initiate transfer in Route 53 console 4. Confirm transfer via email 5. Transfer completes in 5-7 days ### DNSSEC DNSSEC (DNS Security Extensions) protects against DNS spoofing by digitally signing DNS records: ``` Route 53 DNSSEC: 1. Enable DNSSEC signing in the hosted zone 2. Route 53 creates a KMS key for signing 3. Add DS record to the parent zone (registrar) 4. Route 53 signs all records automatically ``` **Enable DNSSEC for:** financial applications, healthcare, any domain where DNS spoofing could redirect users to malicious sites. ## Cost optimization ### Pricing | Component | Cost | | ------------------------------------- | ------------- | | Hosted zone | $0.50/month | | Standard queries | $0.40/million | | Latency-based queries | $0.60/million | | Geo queries | $0.70/million | | Alias queries (to AWS resources) | Free | | Health checks (basic) | $0.50/month | | Health checks (with string matching) | $0.75/month | | Health checks (fast interval, 10 sec) | $1.00/month | ### Cost reduction - **Use Alias records** for AWS resources: Alias queries are free, CNAME queries are not - **Increase TTL** for stable records: higher TTL = fewer queries = lower cost. Production records: 300 seconds (5 min). Stable records: 3600 seconds (1 hour) - **Consolidate hosted zones:** Multiple domains pointing to the same infrastructure can share a hosted zone using subdomains - **Use basic health checks:** Fast interval (10 sec) health checks cost 2x. Use standard interval (30 sec) unless your failover SLA requires faster detection ## Monitoring Set [CloudWatch alarms](https://www.joinhorizon.co/blog/aws-cloudwatch-observability-metrics-logs-alarms-best-practices/) for DNS health: | Metric | Alarm Condition | Indicates | | ------------------------------ | -------------------- | ------------------------------------------- | | `HealthCheckStatus` | 0 (unhealthy) | Endpoint failure, potential failover | | `HealthCheckPercentageHealthy` | < 100% | Partial failure across health check Regions | | `DNSQueries` | Sudden spike or drop | Traffic anomaly or DNS issue | | `ConnectionTime` | > 4 seconds | Endpoint responding slowly | ### Query logging Enable Route 53 query logging to CloudWatch Logs for: - **Traffic analysis:** Understand DNS query patterns and volume - **Security monitoring:** Detect unusual query patterns or domains - **Debugging:** Verify which records are being returned to clients - **Compliance:** Audit trail of DNS resolution ## Common mistakes ### Mistake 1: No health checks on failover records Failover routing without health checks does not fail over: Route 53 always returns the primary record because it does not know the primary is unhealthy. Every failover and latency-based record must have an associated health check. ### Mistake 2: TTL too high during deployments Default TTL of 3600 seconds (1 hour) means DNS changes take up to 1 hour to propagate. Before a deployment or migration, reduce TTL to 60 seconds 24 hours in advance. After the change is stable, increase TTL back. ### Mistake 3: Missing default geolocation record Geolocation routing without a default record means users outside your defined geographies get no DNS response, which is effectively an outage for those users. Include a default record. ### Mistake 4: CNAME at zone apex Using CNAME for the root domain (`example.com`) violates the DNS specification and breaks other records (MX, TXT). Use Alias records instead; they work at the zone apex and are free. ### Mistake 5: No monitoring on health checks Health checks transition to unhealthy and trigger failover, but no one is notified. Set CloudWatch alarms on `HealthCheckStatus` for every health check so the team knows when failover occurs. ## When DNS TTL is not enough: Route 53 ARC **Application Recovery Controller** routing controls flip associated health checks so DNS answers change under operator (or automation) control, with safety rules that can block split-brain (e.g., only one cell ON). Use ARC when GameDays show DNS-only failover is too slow or too accidental; keep readiness checks so standby capacity is real before you flip. Pair with [Global Accelerator](https://www.joinhorizon.co/blog/aws-global-accelerator-when-to-use-multiregion/) when you also need static anycast IPs, since DNS and GA solve different layers. ## What this post doesn't cover - **Private DNS / hybrid Resolver rules** at fleet scale: separate runbook. - **Full ARC cell topology design:** start from the AWS ARC developer guide after the checklist. - **Registrar vs hosted-zone ownership** politics. ## What to do this week 1. Inventory failover/latency records missing health checks. 2. Alarm `HealthCheckStatus` for every production check. 3. Run one GameDay; if TTL-bound recovery misses RTO, evaluate ARC routing controls. [Contact us](https://www.joinhorizon.co/contact-us/) for DNS + multi-Region traffic design. --- *Source: https://www.joinhorizon.co/blog/aws-route-53-dns-traffic-management-patterns/*