AWSNetworkingintermediate

Route 53 DNS Patterns

DNS routing policies, failover patterns, and multi-region strategies with Route 53.

CloudToolStack Team24 min readPublished Feb 22, 2026

Prerequisites

Understanding of DNS concepts (records, zones, resolution)
AWS account with Route 53 access
Familiarity with AWS networking

Route 53 Fundamentals

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service. It provides three main functions: domain registration, DNS routing, and health checking. Route 53 has a 100% availability SLA, the only AWS service with this guarantee, making it one of the most reliable DNS services available. Its name references TCP/UDP port 53, the standard port for DNS traffic.

Route 53 hosts your DNS records in hosted zones. A public hosted zone handles internet DNS traffic for a domain (e.g., example.com), while a private hosted zone resolves DNS queries within one or more VPCs. You can have both public and private hosted zones for the same domain to return different answers for internal and external queries, a pattern called split-horizon DNS that is common in enterprise architectures.

This guide covers Route 53 record types, all seven routing policies with real-world use cases, health check configuration for DNS failover, private DNS and hybrid DNS architectures, and advanced patterns like blue-green deployments and multi-region active-active routing.

Route 53 Pricing

Public hosted zones cost $0.50/month each. Standard DNS queries cost $0.40 per million. Latency-based and geolocation queries cost $0.60 per million. Alias records to AWS resources (CloudFront, ALB, S3, API Gateway) are free of query charges, which is a significant cost benefit over using CNAME records. Health checks cost $0.50/month for standard or $1.00/month for fast (10-second interval) checks.

Record Types and Alias Records

Understanding when to use each record type is essential for correct DNS configuration. Route 53 supports all standard DNS record types plus the AWS-specific Alias record, which provides unique advantages over CNAME records.

Record Type	Purpose	Example Value	Zone Apex
A	Maps domain to IPv4 address	192.0.2.1	Yes
AAAA	Maps domain to IPv6 address	2001:db8::1	Yes
CNAME	Maps domain to another domain name	app.example.com	No, cannot be used at zone apex
MX	Mail server routing with priority	10 mail.example.com	Yes
TXT	Text records (SPF, DKIM, verification)	v=spf1 include:_spf.google.com ~all	Yes
NS	Nameserver delegation	ns-123.awsdns-45.com	Yes
SOA	Start of Authority (zone metadata)	Auto-created by Route 53	Yes
Alias	AWS-specific: maps to AWS resources	d123.cloudfront.net	Yes, key advantage over CNAME

Always Use Alias Over CNAME for AWS Resources

Alias records are a Route 53 extension that works like a CNAME but has three key advantages: (1) they can be used at the zone apex (e.g., example.com, not just www.example.com), (2) they do not incur DNS query charges for AWS resource targets, and (3) they respond with the target's IP addresses directly, eliminating an extra DNS resolution step. Use Alias records whenever pointing to CloudFront, ALB, NLB, S3 static websites, API Gateway, Elastic Beanstalk, VPC endpoints, or another Route 53 record in the same hosted zone.

Routing Policies

Route 53 supports seven routing policies, each serving different use cases. The routing policy determines how Route 53 responds to DNS queries and is the foundation for advanced traffic management patterns.

Policy	Use Case	How It Works	Health Check
Simple	Single resource, no special routing	Returns one or all values randomly	No
Weighted	Canary deployments, A/B testing	Distributes traffic by assigned weights (0-255)	Optional
Latency-based	Multi-region applications	Routes to the region with lowest latency to user	Recommended
Failover	Active-passive disaster recovery	Routes to secondary when primary fails health check	Required on primary
Geolocation	Content localization, data sovereignty	Routes based on user's geographic location	Recommended
Geoproximity	Fine-grained geographic routing	Routes based on proximity with adjustable bias	Recommended
Multivalue Answer	Simple DNS-level load balancing	Returns up to 8 healthy IPs randomly	Recommended

Weighted Routing for Canary Deployments

Weighted routing distributes traffic across multiple resources based on assigned weights. This is the primary mechanism for DNS-based canary deployments and blue-green deployments. By setting a weight of 90 on the current deployment and 10 on the new deployment, you can gradually shift traffic while monitoring for errors.

weighted-routing.json

[
  {
    "Name": "api.example.com",
    "Type": "A",
    "SetIdentifier": "blue-deployment",
    "Weight": 90,
    "AliasTarget": {
      "HostedZoneId": "Z2FDTNDATAQYW2",
      "DNSName": "blue-alb-123456.us-east-1.elb.amazonaws.com",
      "EvaluateTargetHealth": true
    }
  },
  {
    "Name": "api.example.com",
    "Type": "A",
    "SetIdentifier": "green-deployment",
    "Weight": 10,
    "AliasTarget": {
      "HostedZoneId": "Z2FDTNDATAQYW2",
      "DNSName": "green-alb-789012.us-east-1.elb.amazonaws.com",
      "EvaluateTargetHealth": true
    }
  }
]

Latency-Based Routing for Multi-Region

Latency-based routing automatically directs users to the AWS region that provides the lowest latency. Route 53 maintains a database of latency measurements between network prefixes and AWS regions, updated regularly. This is the recommended routing policy for multi-region applications where you want to minimize response time for global users.

latency-routing.sh

# Create latency-based records for multi-region API
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "api.example.com",
          "Type": "A",
          "SetIdentifier": "us-east-1",
          "Region": "us-east-1",
          "AliasTarget": {
            "HostedZoneId": "Z35SXDOTRQ7X7K",
            "DNSName": "us-east-alb.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      },
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "api.example.com",
          "Type": "A",
          "SetIdentifier": "eu-west-1",
          "Region": "eu-west-1",
          "AliasTarget": {
            "HostedZoneId": "Z32O12XQLNTSW2",
            "DNSName": "eu-west-alb.eu-west-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      },
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "api.example.com",
          "Type": "A",
          "SetIdentifier": "ap-southeast-1",
          "Region": "ap-southeast-1",
          "AliasTarget": {
            "HostedZoneId": "Z1LMS91P8CMLE5",
            "DNSName": "ap-se-alb.ap-southeast-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      }
    ]
  }'

Combining Routing Policies

Route 53 supports combining routing policies by creating alias records that point to other Route 53 records. For example, you can use latency-based routing to select the closest region, then weighted routing within each region to split traffic between blue and green deployments. This creates a tree of routing decisions that gives you fine-grained control over traffic distribution.

VPC Architecture Patterns: Multi-Region Architecture

Health Checks and DNS Failover

Route 53 health checks monitor the health of your endpoints and automatically route traffic away from unhealthy resources. Health checks are the foundation of DNS-based failover and are essential for any production routing configuration that involves multiple endpoints.

Health Check Types

Type	What It Monitors	Use Case
Endpoint	HTTP/HTTPS/TCP response from a URL or IP	Direct monitoring of web servers, APIs
Calculated	Status of other health checks (AND/OR logic)	Complex health determination from multiple signals
CloudWatch Alarm	State of a CloudWatch alarm	Health based on custom metrics (latency, error rate)

Failover Configuration

failover-pattern.yaml

# Health check for primary region
PrimaryHealthCheck:
  Type: AWS::Route53::HealthCheck
  Properties:
    HealthCheckConfig:
      FullyQualifiedDomainName: api-primary.internal.example.com
      Port: 443
      Type: HTTPS
      ResourcePath: /health
      RequestInterval: 10
      FailureThreshold: 3
      EnableSNI: true
      Regions:
        - us-east-1
        - us-west-2
        - eu-west-1
    HealthCheckTags:
      - Key: Name
        Value: primary-api-health

# Primary record with failover routing
PrimaryRecord:
  Type: AWS::Route53::RecordSet
  Properties:
    HostedZoneId: !Ref HostedZone
    Name: api.example.com
    Type: A
    SetIdentifier: primary
    Failover: PRIMARY
    HealthCheckId: !Ref PrimaryHealthCheck
    AliasTarget:
      HostedZoneId: !GetAtt PrimaryALB.CanonicalHostedZoneID
      DNSName: !GetAtt PrimaryALB.DNSName
      EvaluateTargetHealth: true

# Secondary record (active when primary fails)
SecondaryRecord:
  Type: AWS::Route53::RecordSet
  Properties:
    HostedZoneId: !Ref HostedZone
    Name: api.example.com
    Type: A
    SetIdentifier: secondary
    Failover: SECONDARY
    AliasTarget:
      HostedZoneId: !GetAtt SecondaryALB.CanonicalHostedZoneID
      DNSName: !GetAtt SecondaryALB.DNSName
      EvaluateTargetHealth: true

# Calculated health check combining multiple signals
CalculatedHealthCheck:
  Type: AWS::Route53::HealthCheck
  Properties:
    HealthCheckConfig:
      Type: CALCULATED
      ChildHealthChecks:
        - !Ref PrimaryHealthCheck
        - !Ref DatabaseHealthCheck
        - !Ref CacheHealthCheck
      HealthThreshold: 2  # Healthy if 2 of 3 children are healthy

TTL and Failover Timing

DNS failover is not instantaneous. Total failover time equals the health check detection time (RequestInterval x FailureThreshold) plus the DNS TTL. With a 10-second interval, 3-failure threshold, and 60-second TTL, failover takes up to 90 seconds. For critical applications, set TTLs low (60 seconds) and health check intervals to 10 seconds (fast health checks cost $1/month instead of $0.50). Note that DNS clients cache records for the TTL duration, so some clients will continue to use the old record until their cache expires.

Failover to S3 Static Site

A common DR pattern is failing over to a static “sorry” page hosted on S3 when your primary application is unavailable. This ensures users see a branded maintenance page instead of a browser error.

s3-failover.sh

# Create S3 bucket for failover page
aws s3 mb s3://api-failover.example.com

# Enable static website hosting
aws s3 website s3://api-failover.example.com \
  --index-document index.html \
  --error-document error.html

# Upload the maintenance page
aws s3 cp maintenance.html s3://api-failover.example.com/index.html \
  --content-type "text/html"

# Create Route 53 failover record pointing to S3
# Use an Alias record to the S3 website endpoint
# Primary: your ALB with health check
# Secondary: S3 website bucket (no health check needed)

Private DNS and Split-Horizon DNS

Private hosted zones enable DNS resolution within your VPCs without exposing internal service names to the internet. When you create a private hosted zone and associate it with a VPC, the Amazon-provided DNS resolver in that VPC resolves queries for that domain using the private hosted zone records.

Split-Horizon DNS

Split-horizon DNS uses the same domain name (e.g., api.example.com) with different records for internal and external queries. Internal users resolve to private IP addresses, while external users resolve to public IP addresses. This simplifies configuration by allowing the same DNS name to work in both contexts.

split-horizon.sh

# Create private hosted zone for internal resolution
aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference "private-$(date +%s)" \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0123456789abcdef0 \
  --hosted-zone-config PrivateZone=true

# Add internal record (private IP via ALB)
aws route53 change-resource-record-sets \
  --hosted-zone-id Z_PRIVATE_ZONE_ID \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z_INTERNAL_ALB_ZONE",
          "DNSName": "internal-alb-123.us-east-1.elb.amazonaws.com",
          "EvaluateTargetHealth": true
        }
      }
    }]
  }'

# The public hosted zone already has the external record
# Internal VPC queries resolve to private ALB
# External queries resolve to public ALB

Hybrid DNS with Route 53 Resolver

For organizations with on-premises infrastructure, Route 53 Resolver endpoints enable bidirectional DNS resolution between AWS and on-premises networks. This creates a unified DNS architecture where both environments can resolve each other's domain names.

Resolver Endpoint Architecture

Inbound Resolver Endpoints: Allow on-premises DNS servers to resolve Route 53 private hosted zone records. On-premises servers forward queries for AWS domains to the inbound endpoint IPs.
Outbound Resolver Endpoints: Allow VPC resources to resolve on-premises DNS names. Route 53 forwards queries matching specified domains to your on-premises DNS servers via outbound endpoints.
Resolver Rules: Define which domains are forwarded to which DNS servers. Rules can be shared across accounts using AWS Resource Access Manager (RAM).

hybrid-dns-setup.sh

# Create security group for DNS endpoints (port 53)
SG_ID=$(aws ec2 create-security-group \
  --group-name dns-resolver-sg \
  --description "DNS Resolver endpoints" \
  --vpc-id vpc-0123456789abcdef0 \
  --output text --query GroupId)

aws ec2 authorize-security-group-ingress \
  --group-id $SG_ID \
  --protocol udp --port 53 \
  --cidr 10.0.0.0/8

aws ec2 authorize-security-group-ingress \
  --group-id $SG_ID \
  --protocol tcp --port 53 \
  --cidr 10.0.0.0/8

# Create outbound endpoint for forwarding to on-premises
aws route53resolver create-resolver-endpoint \
  --creator-request-id "outbound-$(date +%s)" \
  --direction OUTBOUND \
  --security-group-ids $SG_ID \
  --ip-addresses SubnetId=subnet-a,Ip=10.0.1.10 SubnetId=subnet-b,Ip=10.0.2.10 \
  --name outbound-to-onprem

# Create forwarding rule for on-premises domain
aws route53resolver create-resolver-rule \
  --creator-request-id "forward-corp-$(date +%s)" \
  --domain-name "corp.internal" \
  --rule-type FORWARD \
  --resolver-endpoint-id rslvr-out-0123456789abcdef0 \
  --target-ips "Ip=172.16.0.53,Port=53" "Ip=172.16.0.54,Port=53" \
  --name forward-corp-internal

# Associate rule with VPC
aws route53resolver associate-resolver-rule \
  --resolver-rule-id rslvr-rr-0123456789abcdef0 \
  --vpc-id vpc-0123456789abcdef0

# Share rule with other accounts via RAM
aws ram create-resource-share \
  --name dns-rules \
  --resource-arns arn:aws:route53resolver:us-east-1:123456789012:resolver-rule/rslvr-rr-0123456789abcdef0 \
  --principals arn:aws:organizations::123456789012:organization/o-abc123

AWS Networking Deep Dive: Hybrid Connectivity and DNS

Advanced DNS Patterns

Blue-Green Deployment with DNS

Use weighted routing to implement zero-downtime deployments. Start with 100% traffic on the blue environment, shift to 10% green for canary testing, then gradually increase to 100% green over minutes or hours. If issues are detected, instantly shift back to blue by updating the weight.

Geolocation for Compliance

Geolocation routing ensures that users in specific countries or continents are always routed to endpoints in their geography. This is essential for data sovereignty compliance (GDPR, data residency laws) where user data must be processed in specific regions.

geolocation-routing.json

[
  {
    "Name": "app.example.com",
    "Type": "A",
    "SetIdentifier": "europe",
    "GeoLocation": { "ContinentCode": "EU" },
    "AliasTarget": {
      "HostedZoneId": "Z_EU_ALB",
      "DNSName": "eu-alb.eu-west-1.elb.amazonaws.com",
      "EvaluateTargetHealth": true
    }
  },
  {
    "Name": "app.example.com",
    "Type": "A",
    "SetIdentifier": "north-america",
    "GeoLocation": { "ContinentCode": "NA" },
    "AliasTarget": {
      "HostedZoneId": "Z_US_ALB",
      "DNSName": "us-alb.us-east-1.elb.amazonaws.com",
      "EvaluateTargetHealth": true
    }
  },
  {
    "Name": "app.example.com",
    "Type": "A",
    "SetIdentifier": "default",
    "GeoLocation": { "CountryCode": "*" },
    "AliasTarget": {
      "HostedZoneId": "Z_US_ALB",
      "DNSName": "us-alb.us-east-1.elb.amazonaws.com",
      "EvaluateTargetHealth": true
    }
  }
]

DNSSEC for DNS Security

Route 53 supports DNSSEC signing for public hosted zones, protecting against DNS spoofing attacks. When enabled, Route 53 signs DNS responses with a cryptographic key, and resolvers that support DNSSEC validation verify the signatures. Enable DNSSEC for any domain handling sensitive traffic (financial services, healthcare, government).

DNSSEC Requires Careful Planning

Enabling DNSSEC is irreversible without potential downtime. Before enabling, ensure your registrar supports DS record delegation, plan key rotation procedures, and test in a non-production domain first. DNSSEC adds KMS costs for the key signing key (KSK). Monitor the DNSSECInternalFailure andDNSSECKeySigningKeysNeedingAction CloudWatch metrics to detect issues before they cause resolution failures.

Route 53 Monitoring and Troubleshooting

Effective DNS monitoring ensures you detect routing issues before they impact users. Route 53 provides several monitoring capabilities.

CloudWatch metrics: HealthCheckStatus (0 or 1), HealthCheckPercentageHealthy, and DNSQueries per hosted zone
DNS query logging: Log all DNS queries to CloudWatch Logs for troubleshooting and security analysis
Health check alarms: Set CloudWatch alarms on health check status to get notified when failover occurs
Resolver query logging: Log DNS queries from Resolver endpoints for hybrid DNS troubleshooting

dns-monitoring.sh

# Enable DNS query logging for a hosted zone
aws route53 create-query-logging-config \
  --hosted-zone-id Z1234567890 \
  --cloud-watch-logs-log-group-arn \
    "arn:aws:logs:us-east-1:123456789012:log-group:/aws/route53/example.com"

# Create CloudWatch alarm for health check failure
aws cloudwatch put-metric-alarm \
  --alarm-name "API-Primary-Unhealthy" \
  --metric-name HealthCheckStatus \
  --namespace AWS/Route53 \
  --statistic Minimum \
  --period 60 \
  --evaluation-periods 1 \
  --threshold 1 \
  --comparison-operator LessThanThreshold \
  --dimensions Name=HealthCheckId,Value=abc-123-def-456 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:ops-alerts \
  --treat-missing-data breaching

# Test DNS resolution
dig api.example.com @ns-123.awsdns-45.com +short
dig api.example.com @ns-123.awsdns-45.com +trace

Key Takeaways

Use Alias records over CNAMEs for AWS resources to save on query costs and enable zone apex mapping. Choose the routing policy that matches your availability and performance requirements: latency-based for multi-region, weighted for canary deployments, failover for active-passive DR, geolocation for data sovereignty. Implement health checks for any configuration that involves multiple endpoints. Use private hosted zones with Resolver endpoints for hybrid DNS architectures. Keep TTLs low (60 seconds) for records that may need to change quickly during failover. Enable DNSSEC for domains handling sensitive traffic. Monitor health check status with CloudWatch alarms to detect failover events immediately.

AWS Well-Architected Framework: Reliability and Availability AWS Cost Optimization: DNS and Data Transfer Costs Multi-Cloud Networking Glossary: DNS Across Providers

Key Takeaways

1Route 53 supports seven routing policies for different traffic distribution needs.
2Alias records point to AWS resources without CNAME limitations (works at zone apex).
3Health checks enable automatic failover for high-availability architectures.
4Latency-based routing directs users to the nearest AWS region for best performance.
5Private hosted zones provide DNS resolution within VPCs without public exposure.
6Use Route 53 Resolver for hybrid DNS between VPCs and on-premises networks.

Frequently Asked Questions

What is the difference between CNAME and Alias records in Route 53?

CNAME records redirect one domain to another but cannot be used at the zone apex (e.g., example.com). Alias records are a Route 53 extension that work at the zone apex, resolve to AWS resource IPs directly, and incur no query charges for AWS resources.

Which Route 53 routing policy should I use?

Simple for single-resource routing, Weighted for A/B testing, Latency for multi-region performance, Failover for active-passive HA, Geolocation for compliance-based routing, Geoproximity for traffic shifting, and Multivalue for simple load distribution.

How does Route 53 health checking work?

Route 53 health checkers send requests to your endpoints every 10 or 30 seconds from multiple global locations. If an endpoint fails health checks, Route 53 stops including it in DNS responses. You can check HTTP, HTTPS, or TCP endpoints.

How do I set up DNS failover with Route 53?

Create health checks for your primary endpoints. Create failover routing policy records with primary and secondary targets. When health checks fail on the primary, Route 53 automatically returns the secondary record. TTL should be set low (60s) for fast failover.

Can I use Route 53 with resources outside AWS?

Yes. Route 53 is a standard DNS service that can route to any public IP or hostname. You can use it to manage DNS for services hosted on other cloud providers, on-premises, or third-party platforms. Health checks also work with non-AWS endpoints.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.