TCP# 56: Route 53 Routing Strategies

Mastering DNS for Resilient and High-Performance AWS Architectures

You can also read my newsletters from the Substack mobile app and be notified when a new issue is available.

---

I offer a ton of free resources. Check out my store at Gumroad if you haven’t already.

---

Most teams use Route 53 like a basic phonebook: simple A records, nothing more.

But if you know how to use the right routing strategy, you can turn it into a global traffic manager, disaster recovery router, and canary deployment switchboard.

Today’s issue includes 7 Route 53 routing types with real-world use cases, edge case insights, and tactical implementation advice.

Let’s make DNS do more.

---

1. Simple Routing – Use it only when simple is enough

This is the default. Route 53 returns a single value for a DNS name: no logic, no health checks.

Use Case:

• Routing to a static website on S3

• A single ALB fronting an app in one region

Avoid:

• Any form of failover

• High-availability or global traffic management use cases

Tip: Stick to this when there’s no redundancy or conditional logic. If you’re doing anything dynamic, skip this and use something more robust.

2. Failover Routing – Route 53 as a lightweight disaster recovery switch

This lets you configure active-passive DNS failover based on health checks.

Use Case:

• Multi-region DR setup

• App in us-east-1 (Primary) with standby in us-west-2 (Secondary)

Setup Steps:

1. Create a health check on the primary endpoint

2. Mark the record as PRIMARY and attach health check

3. Set the secondary record to SECONDARY (no health check required)

4. TTL should be low (30–60s) for fast failover

Gotchas:

• Health checks only work on public endpoints unless you use CloudWatch alarms or Lambda.

• Failover doesn’t support geolocation or weighted routing natively.

3. Geolocation Routing – Location-aware routing by user origin

These routes are based on the origin country or continent of the user, not proximity to AWS regions.

Use Case:

• Localized content (e.g., send Indian users to Mumbai region)

• Country-specific legal restrictions or performance considerations

Setup Steps:

1. Define rules for each region you want to serve

2. Use ISO country codes (e.g., IN, US, DE)

3. Always define a default record for unmatched locations

Gotchas:

• Doesn’t adapt to network performance

• No way to override location logic dynamically (e.g., VPN users may get misrouted)

4. Geoproximity Routing – Shift traffic based on where your AWS resources are

Different from geolocation. This uses AWS region location + optional bias values to shift traffic weight.

Use Case:

• Multi-region apps where you want to push more traffic to a specific region

• Dynamic traffic steering during maintenance or scaling events

Setup Steps:

1. Use Traffic Flow in Route 53 (console or API)

2. Define a Geoproximity rule for each resource (ALB, EC2, etc.)

3. Adjust bias to increase/decrease traffic to a location (positive = more traffic)

Gotchas:

• Requires using Route 53 Traffic Flow policies

• No health check logic built-in, add that manually or combine with failover

5. Latency-Based Routing – Smart global performance optimization

Routes users to the AWS region with the lowest latency from location to the resource.

Use Case:

• Active-active multi-region apps

• Serving real-time traffic globally (video, gaming, analytics)

Setup Steps:

1. Deploy identical app stacks in multiple regions

2. Attach alias records (ALBs, NLBs, CloudFront) with latency routing policy

3. Add health checks to each region

Best Practices:

• Combine with health checks: If the “lowest latency” region is unhealthy, failover happens automatically.

• Use CloudWatch latency metrics to validate effectiveness.

6. Weighted Routing – Control traffic flow with precision

This lets you split traffic by percentage between multiple endpoints.

Use Case:

• Blue/green deployments

• Canary rollouts (e.g., 90% stable, 10% new version)

• Controlled A/B testing

Setup Steps:

1. Create multiple records for the same domain

2. Assign weight values (total doesn’t have to be 100)

3. TTL should be low to allow for fast shift

Tips:

• Automate weight changes via CI/CD or Terraform

• Add health checks to each target. Route 53 only serves healthy ones

7. Multi-Value Answer Routing – Basic load balancing, DNS-style

This returns multiple healthy IP addresses in a single DNS response.

Use Case:

• Cost-sensitive apps that need minimal load balancing

• Legacy apps are not behind ALB/NLB

Setup Steps:

1. Add multiple IP-based records

2. Enable health checks for each

3. Route 53 returns up to 8 healthy values per request

Gotchas:

• No stickiness

• No intelligent load distribution, just round-robin from DNS resolver’s perspective

---

Power Combinations

Why pick one when you can combine?

• Failover + Latency
  Deploy active-passive multi-region infra and route to the lowest-latency region only if healthy.

• Weighted + Health Checks
  Run phased deployments with instant fallback if the new version fails health checks.

• Geolocation + Multi-Value
  Route Indian users to Mumbai and serve 3 app servers via round-robin at DNS level.

Route 53’s real power is in stacking strategies to match real-world needs.

Troubleshooting Pitfalls (and how to avoid them)

• TTL is too high → Slow failover. Keep it under 60s for anything dynamic

• Health checks on the wrong target → Failover won't trigger

• Forgetting to set a default geolocation → Some users get NXDOMAIN errors

• Latency-based routing without health checks → Users may be routed to downed regions

Log everything in CloudWatch. Test using dig, nslookup, and real-world traffic.

---

Final Thoughts

Route 53 is not just DNS. It’s a traffic routing engine hiding in plain sight.

When you stack its routing strategies smartly, you get:

• Smarter traffic flows

• Resilient multi-region architecture

• Safer deployments

Most engineers never go beyond Simple Routing. But you now have the roadmap to go all the way.

---

SPONSOR US

The Cloud Playbook is now offering sponsorship slots in each issue. If you want to feature your product or service in my newsletter, explore my sponsor page

Become a Proud Sponsor!

---

That’s it for today!

Did you enjoy this newsletter issue?

Share with your friends, colleagues, and your favorite social media platform.

Until next week — Amrut

---

Get in touch

You can find me on LinkedIn or X.

If you wish to request a topic you would like to read, you can contact me directly via LinkedIn or X.