13.2 Route 53 Advanced Routing Policies & Query Logging

13.2 Route 53 Advanced Routing Policies & Query Logging

CloudOps Blueprint Focus: The AWS Certified CloudOps Engineer – Associate (SOA-C03) exam tests your expertise in architecting resilient, multi-region traffic steering and auditing DNS activity. CloudOps engineers must select the exact Route 53 routing policy to satisfy operational requirements—ranging from canary deployments and latency optimization to active-passive disaster recovery and geoproximity biasing—while leveraging Route 53 query logs to identify security anomalies, volumetric attacks, and DNS tunneling.

---

Route 53 Routing Policies Deep-Dive

When creating DNS records in Route 53, the Routing Policy determines how Route 53 responds to DNS queries from client resolvers. Route 53 provides eight distinct routing policies, each engineered for specific architectural patterns:

1. Simple Routing

• Mechanics: Responds with a single resource or multiple static values (e.g., three IP addresses) returned in a randomized order for basic client-side load distribution.
• Operational Constraints: Does not support health checks. If an IP address in a simple routing record becomes unreachable, Route 53 continues returning it in DNS responses. It is intended for single-resource workloads or static configurations.

2. Weighted Routing

• Mechanics: Assigns integer weights (ranging from 0 to 255) to individual records sharing the same domain name. Route 53 calculates traffic distribution proportionally: $\text{Traffic Share} = \frac{\text{Record Weight}}{\sum \text{All Weights}}$
• Operational Use Cases: Ideal for canary deployments, blue/green releases, and progressive rollouts. For example, assigning a weight of 20 to a new application release and 80 to the stable baseline routes exactly 20% of traffic to the new version. Setting a record's weight to 0 stops routing traffic to that resource immediately, provided other records have non-zero weights.

3. Latency-Based Routing (LBR)

• Mechanics: Directs client queries to the AWS Region that provides the lowest network latency for that specific user. AWS continuously gathers global network latency telemetry across worldwide internet networks and AWS Regions, updating dynamic latency tables.
• Operational Use Cases: Multi-region active-active deployments where optimizing user experience and response time is paramount. LBR records can be associated with Route 53 health checks; if the lowest-latency Region becomes unhealthy, Route 53 automatically fails over to the Region offering the next lowest latency.

4. Failover Routing

• Mechanics: Implements active-passive disaster recovery. CloudOps engineers configure two records: a Primary record pointing to the active production resource and a Secondary record pointing to the standby/disaster recovery resource (or a static maintenance page in S3).
• Health Check Requirement: The Primary record must be associated with a Route 53 health check. Under normal operations, Route 53 responds exclusively with the Primary record. When the health check marks the primary resource unhealthy, Route 53 automatically begins serving the Secondary record.

5. Geolocation Routing

• Mechanics: Routes queries based on the geographic location of the querying DNS resolver. Locations can be scoped by Continent (e.g., Europe, North America), Country (two-letter ISO country code), or US State (subdivision code).
• Operational Use Cases: Enforcing regulatory compliance (e.g., ensuring European user data queries resolve strictly to EU endpoints under GDPR), delivering localized language interfaces, and managing digital copyright/licensing restrictions. A Default record must be defined to handle queries originating from IP addresses that do not map to any specific configured geographic rule.

6. Geoproximity Routing (Traffic Flow)

• Mechanics: Routes queries based on the physical geographic distance between the client resolver and the serving resource. CloudOps engineers define resources by AWS Region (e.g., us-east-1, eu-central-1) or by explicit latitude and longitude coordinates for external, on-premises datacenters.
• The Bias Mechanism: Geoproximity routing allows operators to shift traffic boundaries dynamically using Bias values ranging from -99 to +99:
  • Positive Bias (e.g., +20): Expands the geographic serving area of a region, drawing more traffic from neighboring regions.
  • Negative Bias (e.g., -20): Shrinks the geographic serving area of a region, shedding traffic to neighboring regions.
• Configuration: Geoproximity routing cannot be configured via standard record creation; it requires Route 53 Traffic Flow visual policies and Traffic Policy Records.

+-----------------------------------------------------------------------------------+
|                        GEOPROXIMITY BIAS TRAFFIC SHIFT                            |
|                                                                                   |
|       US-WEST REGION                                  US-EAST REGION              |
|       (Normal Boundary)                               (Normal Boundary)           |
|   [ Seattle ]   [ Denver ]                    [ Chicago ]   [ New York ]          |
|   <------------------------>                  <------------------------>          |
|                                                                                   |
|       AFTER APPLYING BIAS: US-East (+30) / US-West (-30)                          |
|   [ Seattle ]               |   [ Denver ]    [ Chicago ]   [ New York ]          |
|   <----------->             |   <-------------------------------------->          |
|   US-West serving area      |   US-East expanded serving area                     |
|   contracts significantly   |   now services Denver and Central US workloads       |
+-----------------------------------------------------------------------------------+

7. Multivalue Answer Routing

• Mechanics: Responds to DNS queries with up to 8 healthy DNS records selected randomly from a larger pool of healthy resources.
• Operational Distinctions: Unlike Simple routing, Multivalue Answer routing natively integrates with Route 53 health checks. If an underlying web server fails, Route 53 filters out the unhealthy IP address and stops returning it to clients. While it does not replace a dedicated Application Load Balancer (ALB) for session affinity or Layer 7 routing, it provides robust, zero-cost DNS-level load balancing across multiple public IP addresses.

8. IP-Based Routing

• Mechanics: Routes queries based on the source IP address of the client resolver, matched against operator-defined CIDR collections. Each CIDR block in the collection is tagged with a location name, and DNS records are then associated with those location names.
• Operational Distinction: Geolocation routing infers a user's position from a geographic IP database, and Latency-Based Routing uses measured AWS network telemetry. IP-based routing is the only policy where the operator supplies the mapping explicitly, which makes routing deterministic and auditable for known networks.
• Operational Use Cases: Pinning a specific internet service provider's announced address ranges to a Region with favorable peering to reduce transit cost and latency; steering known branch-office or corporate egress CIDR blocks to a dedicated endpoint; and overriding geolocation misclassification for VPN or satellite carriers.
• Configuration: Create a CIDR collection, add CIDR blocks grouped under location names, then create records with the IP-based routing policy that reference the collection and location. Define a record for the default location (*) to answer queries from any IP address that does not fall inside a configured CIDR block; without it, unmatched queries receive no answer.

---

Route 53 Health Checks

Route 53 health checks continuously monitor the availability and performance of application endpoints. When associated with routing policies, health checks drive automated DNS failover.

Health Check Types

1. Endpoint Monitors (HTTP, HTTPS, TCP): Route 53 edge checkers located globally send requests to an IP address or domain name. Configurable parameters include:
   • Request Interval: Standard interval (30 seconds) or Accelerated/Fast interval (10 seconds, incurring additional cost).
   • Failure Threshold: Number of consecutive failed checks (1 to 10; default: 3) required before marking the endpoint unhealthy.
   • String Matching: Checks can inspect the first 5,120 bytes of the HTTP/HTTPS response body for a specific expected string.
   • Invert Health Check Status: Inverts the result (considers 200 OK unhealthy and 500 error healthy), useful for testing failover logic.
2. Calculated Health Checks: Monitors the status of up to 256 other health checks using boolean logic (AND, OR, or N of M). For example, an application is deemed healthy only if at least 3 out of 5 internal microservices report healthy.
3. CloudWatch Alarm Monitors: Evaluates a CloudWatch metric alarm (e.g., ALB target response time, RDS CPU utilization, or custom synthetic canary metrics) to determine health state.

---

Route 53 Query Logging & Forensic Analysis

DNS queries contain critical telemetry for operational troubleshooting and security investigations. Route 53 provides comprehensive logging across both public hosted zones and VPC resolvers.

Public Hosted Zone Logging

Public hosted zones can export DNS query logs to Amazon CloudWatch Logs, Amazon S3, or Amazon Kinesis Data Firehose. Logs capture queries submitted to Route 53 authoritative name servers, providing visibility into query volume, request origins, and response codes.

Route 53 Resolver Query Logging for VPCs

For internal VPC workloads, Route 53 Resolver Query Logging captures all DNS queries originating from within specified VPCs, including:

• Queries for Route 53 Private Hosted Zones.
• Queries forwarded to on-premises DNS servers via Outbound Endpoints.
• Public recursive internet queries executed by EC2 instances.
• Queries originating from on-premises through Inbound Endpoints.

Log Record Schema & Key Fields

Route 53 Resolver query logs are emitted as structured JSON records containing the following essential fields:

{
  "version": "1.100000",
  "account_id": "111122223333",
  "region": "us-east-1",
  "vpc_id": "vpc-0123456789abcdef0",
  "query_timestamp": "2026-09-04T18:30:00Z",
  "query_name": "api.internal.example.com.",
  "query_type": "A",
  "query_class": "IN",
  "rcode": "NOERROR",
  "answers": [
    {
      "Rdata": "10.0.15.22",
      "Type": "A",
      "Class": "IN"
    }
  ],
  "srcaddr": "10.0.1.45",
  "srcport": "52341",
  "transport": "UDP",
  "srcids": {
    "instance": "i-0a1b2c3d4e5f67890"
  }
}

Operational Security Scenarios & Attack Detection

Analyzing Route 53 Resolver query logs in Amazon Athena or CloudWatch Logs Insights allows CloudOps engineers to identify and remediate critical security threats:

• DNS Tunneling & Data Exfiltration: Compromised EC2 instances exfiltrate sensitive data by encoding payloads into DNS query prefixes (e.g., aXR5LWNvbmZpZy1kYXRh.attacker-domain.com). Security analysts detect tunneling by querying logs for abnormally long domain names (exceeding 50 characters) or high frequencies of unique subdomains queried by a single private IP address (srcaddr).
• Command and Control (C2) Beaconing: Malware communicates with external botnet infrastructure using Domain Generation Algorithms (DGA). Query logs reveal periodic, automated lookups to suspicious, newly registered domains at strict mathematical intervals.
• NXDOMAIN Flood Attacks: Adversaries or malfunctioning microservices generate millions of queries for non-existent domains. A sudden spike in the rcode: "NXDOMAIN" metric indicates either an active cache poisoning attempt, a DNS amplification attack, or a broken internal service configuration.