DNS & Traffic Management

TL;DR

• Route 53 hosted zones provide DNS infrastructure; health checks are foundational to failover reliability.
• Latency-based routing only considers Regions with a configured record; missing records silently exclude Regions.
• Geolocation routing requires a default/catch-all record to handle users outside explicitly configured locations.
• Route 53 Resolver bridges hybrid environments via inbound/outbound endpoints for bidirectional name resolution.
• Global Accelerator uses anycast IPs over AWS’s private backbone for sub-second failover, independent of DNS TTL.
• DNS failover speed is constrained by resolver caching and TTL propagation; if failover latency matters more than DNS can deliver, evaluate Global Accelerator.

Core Concepts

Route 53 Hosted Zones and Zone Types

Public Hosted Zones publish DNS records resolvable from the public internet. A public zone answers queries for internet-facing domains and is the foundation for external traffic routing.

Private Hosted Zones are scoped to one or more VPCs and respond to queries only from EC2 instances, Lambda functions, and other VPC resources. Private zone names never appear in public DNS and support internal-only service discovery.

Health Checks: The Failover Foundation

A failover routing policy is only as reliable as its health check. A health check monitors a specific endpoint (HTTP/HTTPS path, TCP port, CloudWatch alarm) and reports failure to Route 53 when that endpoint becomes unavailable. Misconfigured health checks are the root cause of failover failures:

• Wrong endpoint: A health check monitoring a different instance or path than the actual application endpoint.
• Lenient failure threshold: A check that requires 5 consecutive failures before marking unhealthy allows 4 unhealthy responses before failover triggers.
• Wrong path: A health check hitting a generic health endpoint instead of the actual traffic path.

Route 53 uses the health check status to decide whether to return the primary record in a failover policy. If the health check doesn’t accurately reflect the actual failure condition, failover won’t trigger when needed.

Failover Routing

Failover routing specifies a primary record and a secondary record. Route 53 returns the primary record only if its health check passes. When the health check fails, Route 53 returns the secondary record instead.

This is simple and effective — but the entire mechanism depends on the health check being right.

Latency-Based Routing

Latency routing sends traffic to the Region with the lowest measured latency between the resolver and the Region’s Route 53 edge location. However, latency routing only evaluates Regions that have a record configured. A missing latency record for a Region means that Region is never considered, even if it would have the lowest latency in reality.

Example: A design routes latency-based traffic to us-west-1 and us-east-1, but omits eu-west-1. European traffic cannot route to eu-west-1 latency-based because no record exists for it; instead, traffic routes to the lowest-latency configured Region, which may be us-west-1 or us-east-1.

Geolocation Routing

Geolocation routing routes based on the user’s inferred geographic location (derived from the resolver’s IP), not measured latency. This is useful for:

• Data residency compliance: Routing users to a Region matching regulatory jurisdiction.
• Localized content: Serving location-specific language or pricing.

Geolocation routing requires a default record to handle queries from locations not explicitly configured. Without a default, queries from uncovered locations fail to resolve.

Example: A design routes France traffic to eu-west-1 and the UK to eu-west-2, but omits a default record. Queries from Germany (not explicitly configured) fail because no default exists to catch them.

Route 53 Resolver: Hybrid DNS

Inbound endpoints allow on-premises DNS servers to forward queries to Route 53’s private hosted zones inside a VPC. An on-prem system can query a VPC’s private domain (e.g., internal.myapp.local) by forwarding to the inbound endpoint.

Outbound endpoints allow EC2 instances in a VPC to forward queries for on-premises domains back to an on-premises DNS server. A Lambda function in a VPC can resolve an on-prem domain (e.g., db.oncorp.local) if an outbound endpoint is configured to forward those queries.

Hybrid DNS must be designed bidirectionally. Configuring only inbound endpoints leaves on-premises systems unable to resolve private VPC zones; configuring only outbound endpoints leaves VPC resources unable to resolve on-premises names.

Global Accelerator: Network-Layer Failover

Global Accelerator is not DNS-based routing; it’s a network-layer service that provides static anycast IP addresses. Traffic sent to a Global Accelerator IP is routed over AWS’s private backbone to the nearest edge location, which then forwards traffic to one or more endpoints (ALBs, NLBs, Elastic IPs).

Failover behavior: Global Accelerator detects unhealthy endpoints and routes traffic away from them in seconds, independent of DNS TTL or resolver caching. Route 53 failover is constrained by how quickly public resolvers pick up the changed DNS record; Global Accelerator failover happens immediately at the network layer.

When to use: Global Accelerator is preferred when:

• Failover speed matters more than DNS-based routing can deliver.
• Allow-listing requires a static set of entry IPs (DNS-based routing can change edge IPs).
• The application serves global traffic and needs the fastest possible path to the nearest endpoint.

Comparison Table

Command/Configuration Reference

Creating a Failover Record with Health Check

Health check (HTTPS endpoint):

aws route53 create-health-check \
  --type HTTPS \
  --ip-address 203.0.113.1 \
  --port 443 \
  --resource-path /health \
  --failure-threshold 3

Failover record (primary):

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234EXAMPLE \
  --change-batch file://failover-record.json

Example JSON:

{
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "Primary",
        "Failover": "PRIMARY",
        "HealthCheckId": "health-check-id",
        "TTL": 60,
        "ResourceRecords": [{ "Value": "203.0.113.1" }]
      }
    },
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "Secondary",
        "Failover": "SECONDARY",
        "TTL": 60,
        "ResourceRecords": [{ "Value": "198.51.100.2" }]
      }
    }
  ]
}

Setting Up Route 53 Resolver Endpoints

Inbound endpoint (allows on-prem to query VPC):

aws route53resolver create-resolver-endpoint \
  --name on-prem-to-vpc \
  --direction INBOUND \
  --security-group-ids sg-12345678 \
  --ip-address-request SubnetId=subnet-12345678

Outbound endpoint (allows VPC to query on-prem):

aws route53resolver create-resolver-endpoint \
  --name vpc-to-on-prem \
  --direction OUTBOUND \
  --security-group-ids sg-12345678 \
  --ip-address-request SubnetId=subnet-12345678

Common Pitfalls

Interview Questions

• A DNS failover record failed to redirect traffic during a real outage, even though the health check dashboard shows the primary was marked unhealthy. Walk me through your investigation. — Tests operational debugging skill around TTL propagation, resolver caching, and distinguishing between Route 53’s state and public DNS propagation delays.

• When would you choose Global Accelerator over Route 53 latency-based routing for a globally-distributed application? — Tests understanding of the distinction between DNS-layer failover (seconds to minutes) and network-layer failover (sub-second), and cost/complexity trade-offs.

• Design DNS resolution for a hybrid environment where on-premises databases need to be resolvable from a VPC, and VPC-hosted services need to be resolvable from on-premises. — Tests whether both Resolver endpoint directions are included and the security group rules between them are understood.

• A team uses geolocation routing and users in Portugal are being routed to an endpoint in a completely different region. What could be wrong? — Tests knowledge of how geolocation routing works, the importance of default records, and the difference between resolver location and actual user location.