Route 53 Routing Policies

Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service. DNS's primary function is to translate human-readable domain names (e.g., www.example.com) into IP addresses (e.g., 192.0.2.1). However, when you have multiple resources serving the same domain—such as multiple web servers, load balancers, or AWS regions—you need a way to decide which IP address to return to each DNS query. Routing policies are the set of rules that Route 53 uses to select a record from a record set when a query arrives.

Route 53 supports eight routing policies:

Each policy addresses a different operational requirement, such as load distribution, performance optimization, geographic restriction, or high availability.

When a DNS resolver queries Route 53 for a domain name, the following steps occur: 1. The resolver sends a DNS query to a Route 53 name server. 2. Route 53 receives the query and examines the requested record name and type (e.g., A record for www.example.com). 3. Route 53 checks the routing policy configured on that record set. 4. Based on the policy, Route 53 selects one or more records from the record set. 5. Route 53 returns the selected record(s) in a DNS response, which may include a TTL (time-to-live) value.

The routing policy logic is executed on the Route 53 server side at the time of the query. The DNS resolver caches the response according to the TTL, so subsequent queries within the TTL period will receive the cached answer without contacting Route 53 again.

Record Name and Type: Each record set has a name (e.g., www.example.com) and a type (A, AAAA, CNAME, MX, etc.). The routing policy is configured on the record set, not on individual records.

Set Identifier: For weighted, latency, geolocation, geoproximity, failover, multi-value, and IP-based policies, you must assign a unique set identifier to each record within the record set. This differentiates records when the policy selects one.

TTL (Time-to-Live): Default is 300 seconds (5 minutes) for most policies, but you can set it from 0 to 2,147,483,647 seconds (about 68 years). Lower TTLs allow faster propagation of changes but increase DNS query load. For failover routing, a low TTL (e.g., 10 seconds) is common to enable quick failover.

Health Checks: Route 53 can associate health checks with records. If a health check fails, Route 53 may exclude that record from responses (depending on the policy). For failover routing, health checks are mandatory for primary and secondary records.

Weighted Routing Policy: Each record is assigned a weight (integer between 0 and 255). The probability of selecting a record is its weight divided by the sum of all weights in the record set. A weight of 0 means the record is never returned unless all records have weight 0, in which case all are returned. Default weight is 1 if not specified.

Latency Routing Policy: Route 53 measures network latency between the user's DNS resolver and the AWS region where the resource is located. It maintains a latency table updated periodically. When a query arrives, Route 53 returns the record with the lowest latency for the user's resolver region. If multiple records have similar latency, one is chosen arbitrarily.

Geolocation Routing Policy: Route 53 uses the source IP address of the DNS resolver to determine the user's geographic location (country or US state). It then returns the record that matches that location. If no record matches the exact location, Route 53 returns the record for the default location (if configured) or returns no answer (NXDOMAIN). You can also create a record for "Other Continent" or "Other Country" to catch unmatched locations.

Geoproximity Routing Policy: Available only through Route 53 Traffic Flow (not simple record sets). You specify a location (latitude and longitude) for each resource and a bias value (+/- 99). The bias shifts traffic toward or away from the resource. Route 53 calculates a "proximity score" based on the user's location and the resource's location, adjusted by bias, and selects the resource with the best score.

Failover Routing Policy: You configure a primary and a secondary record (or more with Traffic Flow). Route 53 returns the primary record if its associated health check is healthy. If the primary health check fails, Route 53 returns the secondary record. Only one record is returned per query. You can have multiple secondary records for disaster recovery.

Multi-value Answer Routing Policy: Similar to simple routing but allows up to 8 healthy records to be returned in a single response. If fewer than 8 records are healthy, only those are returned. If no records are healthy, all are returned. Health checks are optional but recommended.

IP-based Routing Policy: You define CIDR blocks (e.g., 203.0.113.0/24) and associate them with records. Route 53 matches the querying resolver's IP address against the CIDR blocks and returns the corresponding record. This is useful for routing traffic from specific ISPs or corporate networks.

You configure routing policies using the AWS Management Console, AWS CLI, SDKs, or CloudFormation. For example, using the AWS CLI to create a weighted A record:

aws route53 change-resource-record-sets --hosted-zone-id Z3A1B2C3D4E5F6 --change-batch '{
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "www.example.com",
        "Type": "A",
        "SetIdentifier": "WebServer1",
        "Weight": 70,
        "TTL": 300,
        "ResourceRecords": [{"Value": "192.0.2.1"}]
      }
    }
  ]
}'

To verify, use dig or nslookup to query the Route 53 name servers directly:

dig www.example.com @ns-123.awsdns-45.net

Check the response to see which IP address is returned. Repeat multiple times to confirm weight distribution.

AWS Global Accelerator: Use Global Accelerator to route traffic to optimal endpoints using Anycast IPs, then use Route 53 to point your domain to the Global Accelerator DNS name. This combines low-latency routing with DNS-level policies.

Elastic Load Balancing (ELB): You can create an alias record that points to an ELB DNS name. Route 53 automatically resolves the ELB's IP addresses. Routing policies like weighted or latency can be applied to alias records pointing to different ELBs.

CloudFront: Similar to ELB, you can create alias records pointing to CloudFront distributions. Route 53 routing policies can distribute traffic across multiple CloudFront distributions or between CloudFront and other origins.

Health Checks: Route 53 health checks can monitor endpoints (IP/port), CloudWatch alarms, or other health checks (calculated health checks). They are essential for failover and multi-value routing to ensure traffic is sent only to healthy resources.

#### Simple Routing Policy - Use case: Single resource (e.g., one web server). - Behavior: Returns all values in the record set in a random order. If multiple values are present, the resolver may cache one or all. - Limitations: No health checks, no load balancing. If the single resource fails, DNS still returns its IP. - Configuration: No set identifier required. Just create a record with one or more values.

#### Weighted Routing Policy - Use case: Load balancing across multiple resources with controlled proportions (e.g., 70% traffic to region A, 30% to region B). - Behavior: Route 53 selects a record based on weight distribution. The selection is deterministic based on a hash of the query source IP and other factors, so the same user tends to hit the same resource (sticky). - Configuration: Each record must have a unique set identifier and a weight. The sum of weights can be any number; weights are normalized. - Exam tip: If you set all weights to 0, all records are returned (like simple). If you set some to 0, those are never returned unless all are 0.

#### Latency Routing Policy - Use case: Direct users to the AWS region with the lowest latency for better performance. - Behavior: Route 53 maintains a latency database based on traffic between resolvers and AWS regions. It returns the record with the lowest latency for the user's resolver. - Configuration: Each record must have a set identifier and a region (the AWS region where the resource is located). Route 53 uses the region to estimate latency. - Exam tip: Latency routing does not consider actual endpoint health; use health checks to exclude unhealthy records.

#### Geolocation Routing Policy - Use case: Restrict content based on user location (e.g., serve EU users from EU region for GDPR compliance). - Behavior: Route 53 maps the resolver's IP to a geographic location (country, continent, or US state). It returns the record that matches that location. If no match, it returns the default record (if configured) or no answer. - Configuration: Each record must have a set identifier and a location (country code, continent code, or US state). You can also create a record for "Other Continent" or "Other Country" to catch unspecified locations. - Exam tip: If you have overlapping geolocations (e.g., a record for the US and a record for North America), Route 53 uses the most specific match (US over North America).

#### Geoproximity Routing Policy (Traffic Flow only) - Use case: Route traffic based on geographic distance with optional bias to shift traffic. - Behavior: Route 53 calculates a proximity score for each resource based on user location and resource location, adjusted by bias. The resource with the best score is selected. - Configuration: Requires Traffic Flow policy record. You specify latitude, longitude, and bias for each resource. Bias can be positive (attract traffic) or negative (repel traffic). - Exam tip: Geoproximity is not available in simple record sets; you must use Traffic Flow.

#### Failover Routing Policy - Use case: Active-passive failover between two resources. - Behavior: Route 53 returns the primary record if its health check is healthy; otherwise, it returns the secondary record. Only one record is returned per query. - Configuration: You need a primary and secondary record, each with a set identifier and a failover role (PRIMARY or SECONDARY). Health checks are required for primary and recommended for secondary. - Exam tip: You can have multiple secondary records (e.g., multiple regions) but only one primary. If the primary fails, Route 53 selects one secondary based on routing policy (e.g., weighted among secondaries).

#### Multi-value Answer Routing Policy - Use case: Return multiple healthy IP addresses to a client for client-side load balancing (up to 8). - Behavior: Route 53 returns up to 8 healthy records. If fewer than 8 are healthy, only those are returned. If none are healthy, all are returned. - Configuration: Each record must have a set identifier. Health checks are optional but recommended. - Exam tip: Multi-value is not a replacement for a load balancer; it simply returns multiple A records. The client chooses which to use.

#### IP-based Routing Policy - Use case: Route traffic based on the CIDR block of the user's resolver IP (e.g., send traffic from a corporate VPN to a specific endpoint). - Behavior: Route 53 matches the resolver IP against defined CIDR blocks and returns the corresponding record. - Configuration: You create a CIDR collection (set of CIDR blocks) and associate it with a record set. Each record is mapped to a CIDR location. - Exam tip: IP-based routing is relatively new and may appear in scenario questions about routing traffic from specific ISPs.

Mastering Route 53 routing policies requires understanding the mechanism behind each policy, the configuration options, and how they interact with health checks and other AWS services. For the SOA-C02 exam, focus on scenario-based questions that ask which policy to use given requirements like performance, geographic restrictions, load distribution, or failover. Remember the key differences: simple returns all records, weighted uses probability, latency uses network latency, geolocation uses location, geoproximity uses distance with bias, failover uses health checks, multi-value returns up to 8 healthy records, and IP-based uses CIDR matching.

A multinational e-commerce company deploys web servers in three AWS regions: us-east-1 (N. Virginia), eu-west-1 (Ireland), and ap-southeast-1 (Singapore). Their goal is to minimize page load times for users worldwide. They configure latency-based routing for www.shop.com with three A records, each pointing to an Application Load Balancer (ALB) in its respective region. They associate health checks with each ALB to detect regional outages. When a user in Brazil queries the domain, Route 53 measures latency from the user's resolver to each region and returns the record with the lowest latency, typically us-east-1. If the us-east-1 ALB fails, the health check fails, and Route 53 excludes that record, returning the next best region. The TTL is set to 60 seconds to allow quick adaptation to changes. The company monitors CloudWatch metrics and notices that users in Australia occasionally get routed to us-east-1 due to similar latency to ap-southeast-1; they consider adding a region in Australia or using geoproximity with bias to fine-tune.

A media streaming service must comply with licensing agreements that restrict content to specific countries. They use geolocation routing to serve different content based on the user's country. For example, users in the US get an A record pointing to a CloudFront distribution with US-licensed content; users in the UK get a different CloudFront distribution. They create records for each country and a default record for all other countries that returns a 'content not available' page. They also create a record for 'North America' to catch Canada and Mexico. The routing works by mapping the user's DNS resolver IP to a country. However, they encounter a problem: users using public DNS resolvers (like Google 8.8.8.8) may be mapped to the resolver's location, not the user's actual location. To mitigate this, they encourage users to use EDNS0 client subnet (ECS) if supported, but Route 53 does not currently support ECS for geolocation. They accept the limitation and monitor for discrepancies.

A financial services company requires high availability for its trading platform. They deploy primary infrastructure in us-east-1 and a secondary in us-west-2. They use failover routing with a primary record pointing to the us-east-1 ALB and a secondary record pointing to the us-west-2 ALB. Health checks monitor the primary ALB's /health endpoint. If the primary fails, Route 53 returns the secondary within the TTL period (set to 10 seconds). However, they also want to distribute traffic across multiple secondary regions during a failover to avoid overloading one region. They use Traffic Flow to create a policy that includes a primary and multiple weighted secondary records. This allows them to control the distribution of traffic among secondaries. They also implement a 'gradual failback' by reducing the weight of the secondary records after the primary recovers, to avoid a thundering herd problem. Common pitfalls: forgetting to set a low TTL on the failover records, which delays failover; and not monitoring health check status, leading to false positives or negatives.