🌐 AWS Route 53 Complete Guide

Table of Contents

1. Route 53 Overview

AWS Route 53 is a highly scalable Domain Name System (DNS) web service that connects user requests to infrastructure running on AWS and also on-premises. It provides three main functions: domain registration, DNS routing, and health checking.

graph TB subgraph "Route 53 Core Services" A[Domain Registration] --> B[DNS Resolution] B --> C[Health Checking] C --> D[Traffic Routing] end subgraph "External Components" E[User/Client] --> F[Internet] F --> G[Route 53 Resolver] end subgraph "AWS Infrastructure" H[EC2 Instances] I[Load Balancers] J[CloudFront] K[S3 Buckets] end G --> B D --> H D --> I D --> J D --> K
Diagram Explanation: This diagram shows the high-level architecture of Route 53. Users make DNS requests through the internet to Route 53 resolvers, which then use the DNS resolution service to determine where to route traffic. The health checking service monitors endpoint health, and traffic routing directs requests to healthy AWS resources like EC2 instances, load balancers, CloudFront distributions, or S3 buckets.

2. Architecture & Components

graph LR subgraph "Route 53 Components" A[Hosted Zone] --> B[Record Sets] B --> C[A Records] B --> D[CNAME Records] B --> E[MX Records] B --> F[TXT Records] B --> G[ALIAS Records] H[Health Checks] --> I[HTTP/HTTPS Checks] H --> J[TCP Checks] H --> K[Calculated Checks] L[Routing Policies] --> M[Simple] L --> N[Weighted] L --> O[Latency-based] L --> P[Failover] L --> Q[Geolocation] L --> R[Geoproximity] L --> S[Multivalue] end
Component Architecture: Route 53 consists of hosted zones containing various record types, health checks for monitoring endpoint availability, and routing policies that determine how traffic is distributed. Each component serves a specific purpose in the DNS resolution and traffic management process.

3. Traffic Flow Diagrams

3.1 Basic DNS Resolution Flow

sequenceDiagram participant Client participant ISP_DNS as ISP DNS Resolver participant Route53 as Route 53 participant WebServer as Web Server Client->>ISP_DNS: DNS Query for example.com ISP_DNS->>Route53: Forward DNS Query Route53->>Route53: Check Hosted Zone Route53->>Route53: Apply Routing Policy Route53->>Route53: Check Health Status Route53->>ISP_DNS: Return IP Address ISP_DNS->>Client: Return IP Address Client->>WebServer: HTTP Request to IP WebServer->>Client: HTTP Response
DNS Resolution Flow: This sequence shows how a client's DNS request travels through the ISP's DNS resolver to Route 53, where the hosted zone is checked, routing policies are applied, health checks are verified, and the appropriate IP address is returned to route the client to the healthy endpoint.

3.2 Multi-Region Failover Traffic Flow

graph TB subgraph "Client Request" A[User Request] --> B[Route 53 DNS] end subgraph "Route 53 Decision Logic" B --> C{Health Check Status} C -->|Primary Healthy| D[Route to Primary] C -->|Primary Unhealthy| E[Route to Secondary] end subgraph "Primary Region - us-east-1" D --> F[Primary ALB] F --> G[Primary EC2 Instances] H[Primary Health Check] --> G end subgraph "Secondary Region - us-west-2" E --> I[Secondary ALB] I --> J[Secondary EC2 Instances] K[Secondary Health Check] --> J end H --> C K --> C
Multi-Region Failover: This diagram illustrates how Route 53 implements disaster recovery by routing traffic to a primary region when healthy, and automatically failing over to a secondary region when health checks detect issues with the primary infrastructure.

3.3 Weighted Routing Distribution

graph TB A[User Requests] --> B[Route 53 Weighted Routing] B --> C{Weight Distribution} C -->|70% Weight| D[Production Environment] C -->|20% Weight| E[Staging Environment] C -->|10% Weight| F[Canary Environment] D --> G[Prod Load Balancer] E --> H[Staging Load Balancer] F --> I[Canary Load Balancer] G --> J[Production Fleet] H --> K[Staging Fleet] I --> L[Canary Fleet]
Weighted Routing: This shows how Route 53 can distribute traffic across multiple endpoints based on assigned weights, enabling blue-green deployments, canary releases, and load distribution scenarios.

4. Setup Sequence & Command Flow

graph TD A[1Create Hosted Zone] --> B[2Create Health Checks] B --> C[3Create Record Sets] C --> D[4Configure Routing Policy] D --> E[5Associate Health Checks] E --> F[6Test DNS Resolution] F --> G[7Monitor & Optimize] subgraph "Command Details" A1[aws route53 create-hosted-zone] B1[aws route53 create-health-check] C1[aws route53 change-resource-record-sets] D1[Set routing policy in record] E1[Reference health-check-id] F1[nslookup / dig commands] G1[aws route53 get-health-check] end A --> A1 B --> B1 C --> C1 D --> D1 E --> E1 F --> F1 G --> G1
Setup Sequence: This diagram shows the logical order for setting up Route 53 components. You start with creating a hosted zone, then health checks, followed by record sets with routing policies, and finally testing and monitoring.

5. Detailed Configurations

5.1 Creating a Hosted Zone

aws route53 create-hosted-zone \ --name example.com \ --caller-reference $(date +%s) \ --hosted-zone-config Comment="Production hosted zone for example.com"
Parameter Explanation:
  • --name: The domain name for the hosted zone
  • --caller-reference: A unique string that identifies the request (prevents duplicate creation)
  • --hosted-zone-config: Optional configuration with comment for documentation
What this does: Creates a hosted zone that will contain all DNS records for your domain. This is the foundational step that must be completed before creating any DNS records.

5.2 Creating Health Checks

aws route53 create-health-check \ --caller-reference health-check-$(date +%s) \ --health-check-config '{ "Type": "HTTPS", "ResourcePath": "/health", "FullyQualifiedDomainName": "api.example.com", "Port": 443, "RequestInterval": 30, "FailureThreshold": 3, "EnableSNI": true, "Regions": ["us-east-1", "us-west-2", "eu-west-1"] }'
Health Check Parameters:
  • Type: HTTP, HTTPS, or TCP
  • ResourcePath: The path to check (for HTTP/HTTPS)
  • FullyQualifiedDomainName: The domain or IP to check
  • Port: Port number to check
  • RequestInterval: 10 or 30 seconds between checks
  • FailureThreshold: Number of consecutive failures before marking unhealthy
  • EnableSNI: Enable Server Name Indication for HTTPS
  • Regions: AWS regions to perform health checks from
Purpose: Health checks monitor the availability of your endpoints. They run from multiple AWS regions and can check HTTP/HTTPS endpoints or TCP ports.

5.3 Creating Failover Records

aws route53 change-resource-record-sets \ --hosted-zone-id Z1234567890ABC \ --change-batch '{ "Changes": [ { "Action": "CREATE", "ResourceRecordSet": { "Name": "api.example.com", "Type": "A", "SetIdentifier": "primary", "Failover": "PRIMARY", "TTL": 60, "ResourceRecords": [ {"Value": "203.0.113.10"} ], "HealthCheckId": "12345678-1234-1234-1234-123456789012" } } ] }'
Failover Record Parameters:
  • SetIdentifier: Unique identifier for this record set
  • Failover: PRIMARY or SECONDARY
  • TTL: Time to Live in seconds (how long DNS resolvers cache the record)
  • ResourceRecords: Array of IP addresses or values
  • HealthCheckId: ID of the health check to associate with this record
Configuration Order: Create the primary record first, then create the secondary record with "Failover": "SECONDARY". The health check determines which record is returned.
aws route53 change-resource-record-sets \ --hosted-zone-id Z1234567890ABC \ --change-batch '{ "Changes": [ { "Action": "CREATE", "ResourceRecordSet": { "Name": "api.example.com", "Type": "A", "SetIdentifier": "secondary", "Failover": "SECONDARY", "TTL": 60, "ResourceRecords": [ {"Value": "203.0.113.20"} ], "HealthCheckId": "87654321-4321-4321-4321-210987654321" } } ] }'
Secondary Record: This creates the failover target. Route 53 will only return this record when the primary record's health check fails. Both primary and secondary records should have health checks for optimal reliability.

5.4 Weighted Routing Records

aws route53 change-resource-record-sets \ --hosted-zone-id Z1234567890ABC \ --change-batch '{ "Changes": [ { "Action": "CREATE", "ResourceRecordSet": { "Name": "www.example.com", "Type": "A", "SetIdentifier": "production-70", "Weight": 70, "TTL": 300, "ResourceRecords": [ {"Value": "203.0.113.30"} ], "HealthCheckId": "prod-health-check-id" } } ] }'
Weight Configuration:
  • Weight: Relative weight (0-255) for this record
  • SetIdentifier: Must be unique across all weighted records for the same name
Traffic Distribution: If you have weights of 70, 20, and 10, traffic will be distributed proportionally (70%, 20%, 10%). Create multiple weighted records for the same domain name to distribute traffic.

5.5 Latency-Based Routing

aws route53 change-resource-record-sets \ --hosted-zone-id Z1234567890ABC \ --change-batch '{ "Changes": [ { "Action": "CREATE", "ResourceRecordSet": { "Name": "global.example.com", "Type": "A", "SetIdentifier": "us-east-1-endpoint", "Region": "us-east-1", "TTL": 300, "ResourceRecords": [ {"Value": "203.0.113.40"} ], "HealthCheckId": "us-east-health-check" } } ] }'
Latency Routing Parameters:
  • Region: AWS region where this resource is located
  • SetIdentifier: Unique identifier for this latency record
How it works: Route 53 maintains latency data between AWS regions and user locations. It automatically routes users to the region with the lowest latency. Create one latency record per region.

5.6 Geolocation Routing

aws route53 change-resource-record-sets \ --hosted-zone-id Z1234567890ABC \ --change-batch '{ "Changes": [ { "Action": "CREATE", "ResourceRecordSet": { "Name": "geo.example.com", "Type": "A", "SetIdentifier": "north-america", "GeoLocation": { "ContinentCode": "NA" }, "TTL": 300, "ResourceRecords": [ {"Value": "203.0.113.50"} ], "HealthCheckId": "na-health-check" } } ] }'
Geolocation Options:
  • ContinentCode: Two-letter continent code (NA, SA, EU, AS, AF, OC, AN)
  • CountryCode: Two-letter country code (US, CA, DE, etc.)
  • SubdivisionCode: State/province code (requires CountryCode)
Default Record: Always create a default geolocation record (no location specified) to handle requests from unmatched locations.

5.7 ALIAS Records for AWS Resources

aws route53 change-resource-record-sets \ --hosted-zone-id Z1234567890ABC \ --change-batch '{ "Changes": [ { "Action": "CREATE", "ResourceRecordSet": { "Name": "cdn.example.com", "Type": "A", "AliasTarget": { "DNSName": "d123456789.cloudfront.net", "EvaluateTargetHealth": false, "HostedZoneId": "Z2FDTNDATAQYW2" } } } ] }'
ALIAS Record Benefits:
  • DNSName: The AWS resource's DNS name
  • HostedZoneId: The hosted zone ID of the AWS service
  • EvaluateTargetHealth: Whether to check the target's health
Why use ALIAS: ALIAS records are free (no charge for queries), automatically resolve to IP addresses, and can be used for zone apex records (@). They're preferred over CNAME records for AWS resources.

6. Routing Policies Comparison

graph TB subgraph "Simple Routing" A[Single Record] --> B[Single Resource] end subgraph "Weighted Routing" C[Traffic Split] --> D[Resource A - 70%] C --> E[Resource B - 20%] C --> F[Resource C - 10%] end subgraph "Latency Routing" G[User Location] --> H{Lowest Latency} H --> I[US East] H --> J[EU West] H --> K[AP Southeast] end subgraph "Failover Routing" L[Health Check] --> M{Primary Healthy?} M -->|Yes| N[Primary Resource] M -->|No| O[Secondary Resource] end subgraph "Geolocation Routing" P[User IP] --> Q{Geographic Location} Q -->|North America| R[US Server] Q -->|Europe| S[EU Server] Q -->|Asia| T[APAC Server] end
Routing Policy Comparison: This diagram shows how different routing policies make decisions. Simple routing returns one record, weighted splits traffic by percentage, latency routes to the fastest region, failover provides high availability, and geolocation routes based on user location.

7. Health Checks Configuration

7.1 HTTP/HTTPS Health Check

aws route53 create-health-check \ --caller-reference web-health-$(date +%s) \ --health-check-config '{ "Type": "HTTPS", "ResourcePath": "/api/health", "FullyQualifiedDomainName": "api.example.com", "Port": 443, "RequestInterval": 30, "FailureThreshold": 3, "MeasureLatency": true, "EnableSNI": true, "Regions": ["us-east-1", "us-west-2", "eu-west-1"], "AlarmIdentifier": { "Region": "us-east-1", "Name": "api-health-alarm" }, "InsufficientDataHealthStatus": "LastKnownStatus" }'
Advanced Health Check Options:
  • MeasureLatency: Enable latency measurements
  • AlarmIdentifier: CloudWatch alarm to monitor
  • InsufficientDataHealthStatus: Failure, Success, or LastKnownStatus
  • SearchString: String to search for in response body
Best Practice: Use health checks that match your application's actual health endpoint. Set appropriate failure thresholds and request intervals based on your availability requirements.

7.2 Calculated Health Check

aws route53 create-health-check \ --caller-reference calculated-health-$(date +%s) \ --health-check-config '{ "Type": "CALCULATED", "ChildHealthChecks": [ "12345678-1234-1234-1234-123456789012", "87654321-4321-4321-4321-210987654321" ], "HealthThreshold": 1, "CloudWatchAlarmRegion": "us-east-1", "InsufficientDataHealthStatus": "Failure" }'
Calculated Health Check:
  • ChildHealthChecks: Array of health check IDs to monitor
  • HealthThreshold: Minimum number of healthy children required
Use Case: Calculated health checks are useful for complex scenarios where you need to monitor multiple endpoints and define custom logic for what constitutes "healthy."

8. Monitoring & Logging

8.1 Query Logging Configuration

aws route53 create-query-logging-config \ --hosted-zone-id Z1234567890ABC \ --cloud-watch-logs-log-group-arn "arn:aws:logs:us-east-1:123456789012:log-group:/aws/route53/example.com"
Query Logging Setup:
  • Prerequisites: Create CloudWatch Logs group first
  • Log Format: JSON format with timestamp, query name, type, response code
Before enabling: Create the CloudWatch Logs group and set appropriate retention policy to manage costs.

8.2 Health Check Monitoring

aws route53 get-health-check \ --health-check-id 12345678-1234-1234-1234-123456789012 aws route53 get-health-check-status \ --health-check-id 12345678-1234-1234-1234-123456789012
Health Check Monitoring:
  • get-health-check: Returns health check configuration
  • get-health-check-status: Returns current status from all checking regions
Automation: Use these commands in monitoring scripts to track health check status and trigger alerts when endpoints become unhealthy.

8.3 Testing DNS Resolution

# Test DNS resolution dig example.com A +short # Test from specific DNS server nslookup example.com 8.8.8.8 # Test DNS propagation dig @8.8.8.8 example.com A dig @1.1.1.1 example.com A dig @208.67.222.222 example.com A
DNS Testing Commands:
  • dig: Most comprehensive DNS lookup tool
  • nslookup: Basic DNS lookup
  • +short: Returns only the answer section
Testing Strategy: Test from multiple DNS servers to verify propagation. Use different geographic locations to test geolocation routing.
Important Considerations: