TECH **AWS Route 53 Routing Policies: Zero-Fluff, Hands-On Guide**

AWS Route 53 Routing Policies: Zero-Fluff, Hands-On Guide

(For AWS Solutions Architect – Associate & Real-World Deployments)

1. What This Is & Why It Matters

You’re a cloud engineer at a global e-commerce company. Your website (example.com) runs in three AWS regions (us-east-1, eu-west-1, ap-southeast-1) to serve customers worldwide. One day, your boss asks: - "Why are European users complaining about slow load times?" - "If the US region goes down, how do we automatically fail over to Europe?" - "Can we send 10% of traffic to a new version of our app for testing?"

Route 53 routing policies are your answer. They let you control how DNS responds to queries based on: - User location (Geolocation, Geoproximity) - Health of endpoints (Failover) - Performance (Latency) - Traffic distribution (Weighted) - Simplicity (Simple)

Why this matters in production:
- Without routing policies, all users hit the same endpoint—even if it’s slow or down.
- With them, you optimize cost, performance, and reliability. Ignore this, and you’ll either: - Overpay for unused resources (e.g., running all regions 24/7 when only one is needed).
- Lose customers due to slow load times or outages.
- Fail compliance (e.g., GDPR requires EU data to stay in EU regions).

Real-world scenario:
You inherit a legacy app with a single ALB in us-east-1. Users in Asia see 500ms+ latency. Your CTO wants: 1. Asia users → ap-southeast-1 (lowest latency).
2. EU users → eu-west-1 (compliance).
3. US users → us-east-1 (primary), but fail over to eu-west-1 if it crashes.
4. 10% of US traffic → a new beta version (canary testing).

This guide shows you how to implement all of this in under 30 minutes.

2. Core Concepts & Components

3. Step-by-Step Hands-On: Deploy a Multi-Region App with Routing Policies

Prerequisites

1. AWS account with admin IAM permissions.
2. 3 EC2 instances (or ALBs) in:
3. us-east-1 (Primary)
4. eu-west-1 (Secondary)
5. ap-southeast-1 (Asia)
6. A domain (e.g., example.com) registered in Route 53 (or use a subdomain like app.example.com).

Step 1: Set Up Health Checks (Critical for Failover & Latency)

Route 53 needs to know if your endpoints are healthy. Without this, failover won’t work.

CLI Command:

# Create a health check for us-east-1 (HTTP endpoint)
aws route53 create-health-check \
  --caller-reference $(date +%s) \
  --health-check-config '{
    "IPAddress": "54.165.123.45",  # Replace with your EC2/ALB IP
    "Port": 80,
    "Type": "HTTP",
    "ResourcePath": "/health",
    "FullyQualifiedDomainName": "app-us.example.com",
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

Expected Output:

{
  "HealthCheck": {
    "Id": "abc12345-6789-0def-1234-567890abcdef",
    "CallerReference": "1625097600",
    "HealthCheckConfig": { ... },
    "HealthCheckVersion": 1
  }
}

Verify:
- Go to Route 53 → Health Checks in the AWS Console.
- Check the status (should say "Healthy" after a few minutes).

Step 2: Create a Hosted Zone (If You Don’t Have One)

aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference $(date +%s) \
  --hosted-zone-config '{
    "Comment": "Hosted zone for multi-region app",
    "PrivateZone": false
  }'

Note: If you already have a hosted zone, skip this.

Step 3: Configure Routing Policies

A. Latency-Based Routing (Global Users)

Route users to the fastest region.

CLI Command:

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABCDEFGHIJ \
  --change-batch '{
    "Comment": "Latency-based routing for app.example.com",
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "us-east-1-latency",
        "AliasTarget": {
          "HostedZoneId": "Z35SXDOTRQ7X7K",  # ALB/NLB hosted zone ID (varies by region)
          "DNSName": "app-us.example.com",
          "EvaluateTargetHealth": true
        },
        "HealthCheckId": "abc12345-6789-0def-1234-567890abcdef",
        "Region": "us-east-1",
        "TTL": 60,
        "ResourceRecords": []
      }
    }, {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "eu-west-1-latency",
        "AliasTarget": {
          "HostedZoneId": "Z32O12XQLNTSW2",  # eu-west-1 ALB hosted zone ID
          "DNSName": "app-eu.example.com",
          "EvaluateTargetHealth": true
        },
        "HealthCheckId": "def56789-0123-4567-89ab-cdef01234567",
        "Region": "eu-west-1",
        "TTL": 60
      }
    }]
  }'

Key Notes:
- SetIdentifier must be unique per record.
- AliasTarget is used for ALB/NLB/S3/CloudFront (not EC2 IPs).
- EvaluateTargetHealth = true enables Route 53 to check health.

B. Failover Routing (US Primary → EU Secondary)

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABCDEFGHIJ \
  --change-batch '{
    "Comment": "Failover routing for app.example.com",
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "us-east-1-primary",
        "AliasTarget": {
          "HostedZoneId": "Z35SXDOTRQ7X7K",
          "DNSName": "app-us.example.com",
          "EvaluateTargetHealth": true
        },
        "HealthCheckId": "abc12345-6789-0def-1234-567890abcdef",
        "Failover": "PRIMARY",
        "TTL": 60
      }
    }, {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "eu-west-1-secondary",
        "AliasTarget": {
          "HostedZoneId": "Z32O12XQLNTSW2",
          "DNSName": "app-eu.example.com",
          "EvaluateTargetHealth": true
        },
        "HealthCheckId": "def56789-0123-4567-89ab-cdef01234567",
        "Failover": "SECONDARY",
        "TTL": 60
      }
    }]
  }'

How it works:
- If us-east-1 health check fails, Route 53 automatically serves eu-west-1.
- Never mix Failover with Latency/Geolocation—it’s one or the other.

C. Weighted Routing (Canary Deployment)

Send 10% of traffic to a new version (v2).

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABCDEFGHIJ \
  --change-batch '{
    "Comment": "Weighted routing for canary deployment",
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "v1-90",
        "AliasTarget": {
          "HostedZoneId": "Z35SXDOTRQ7X7K",
          "DNSName": "app-v1.example.com",
          "EvaluateTargetHealth": true
        },
        "Weight": 90,
        "TTL": 60
      }
    }, {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "v2-10",
        "AliasTarget": {
          "HostedZoneId": "Z35SXDOTRQ7X7K",
          "DNSName": "app-v2.example.com",
          "EvaluateTargetHealth": true
        },
        "Weight": 10,
        "TTL": 60
      }
    }]
  }'

Key Notes:
- Weights are relative (90:10 = 90% to v1, 10% to v2).
- Set weight to 0 to disable an endpoint.

D. Geolocation Routing (EU Users → EU Region)

aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890ABCDEFGHIJ \
  --change-batch '{
    "Comment": "Geolocation routing for EU users",
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "eu-geo",
        "AliasTarget": {
          "HostedZoneId": "Z32O12XQLNTSW2",
          "DNSName": "app-eu.example.com",
          "EvaluateTargetHealth": true
        },
        "GeoLocation": {
          "ContinentCode": "EU"
        },
        "TTL": 60
      }
    }, {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "default-geo",
        "AliasTarget": {
          "HostedZoneId": "Z35SXDOTRQ7X7K",
          "DNSName": "app-us.example.com",
          "EvaluateTargetHealth": true
        },
        "GeoLocation": {
          "CountryCode": "*"  # Default for all other users
        },
        "TTL": 60
      }
    }]
  }'

Key Notes:
- Order matters! Route 53 evaluates geolocation records from most specific to least specific: 1. Country (e.g., US) 2. Continent (e.g., EU) 3. Default (*) - No health checks here—geolocation overrides them.

Step 4: Test Your Setup

1. Latency Test:
   bash
dig app.example.com +short
2. Should return the IP of the closest region.

3. Use a VPN to test from different locations.

4. Failover Test:

5. Stop the us-east-1 EC2 instance.
6. Wait 2–3 minutes (health check interval + DNS TTL).

7. Run dig app.example.com +short → should now return eu-west-1 IP.

8. Weighted Test:

9. Use a tool like DNS Checker to verify traffic distribution.

4. ? Production-Ready Best Practices

Security

• Restrict Route 53 access with IAM policies (e.g., only allow route53:ChangeResourceRecordSets for specific roles).
• Enable DNSSEC for domains handling sensitive data (e.g., banking, healthcare).
• Use private hosted zones for internal services (e.g., app.internal.example.com).

Cost Optimization

• Health checks cost $0.50/month each—delete unused ones.
• Geoproximity with bias can reduce cross-region data transfer costs (e.g., bias traffic toward cheaper regions).
• TTL values:
• Low TTL (60s) for failover/weighted routing (faster updates).
• High TTL (300s+) for static records (reduces Route 53 queries).

Reliability & Maintainability

• Tag all Route 53 resources (e.g., Environment=prod, Purpose=latency-routing).
• Use Infrastructure as Code (IaC) (Terraform/CloudFormation) to manage records.
• Monitor health checks with CloudWatch alarms (e.g., alert if us-east-1 fails).

Observability

• CloudWatch Metrics for Route 53:
• HealthCheckStatus (0 = unhealthy, 1 = healthy).
• DNSQueries (track traffic volume).
• Enable Route 53 Resolver Query Logs to debug DNS issues.

5. ⚠️ Common Mistakes & Traps

6. ? Exam/Certification Focus

Typical Question Patterns

1. "Which routing policy for A/B testing?"

2. Answer: Weighted (not Latency or Geolocation).

3. "How to route EU users to eu-west-1 for GDPR compliance?"

4. Answer: Geolocation (not Latency—users might still hit us-east-1 if it’s faster).

5. "Primary endpoint fails, but failover doesn’t trigger. Why?"

6. Answer: Missing health check or EvaluateTargetHealth=false.

7. "How to reduce latency for global users?"

8. Answer: Latency-based routing (not Simple or Weighted).

Key ⚠️ Trap Distinctions

7. ? Hands-On Challenge (With Solution)

Challenge:
You have a website (app.example.com) with: - A primary ALB in us-east-1.
- A secondary ALB in eu-west-1.
- A new beta version in us-west-2.

Requirements:
1. 90% of US traffic → us-east-1.
2. 10% of US traffic → us-west-2 (beta).
3. All EU traffic → eu-west-1.
4. If us-east-1 fails, fail over to eu-west-1.

Solution:
```bash

1. Create health checks (us-east-1, eu-west-1)

aws route53 create-health-check --caller-reference $(date +%s) --health-check-config '{ "IPAddress": "54.165.123.45", "Port": 80, "Type": "HTTP", "ResourcePath": "/health" }'

2. Weighted routing (US: 90% us-east-1, 10% us-west-2)

aws route53 change-resource-record-sets --hosted-zone-id Z123... --change-batch '{ "Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "app.example.com", "Type": "A", "SetIdentifier": "us-east-1-90",
"AliasTarget": { "HostedZoneId": "Z35SXDOTRQ7X