AWS 164: Route 53 routing policies
Why this lesson matters
Choose simple, weighted, latency, failover, geolocation, geoproximity, multivalue, or IP-based routing from a precise traffic requirement.
Route 53 routing policies select DNS answers, not packets and not individual HTTP requests. Recursive resolvers cache answers and represent many users, so observed traffic percentages and geographic/latency outcomes are approximate and delayed by TTL and persistent connections.
What you will be able to do
By the end, you can:
- explain route 53 routing policies in plain language;
- locate the current service controls in the AWS Management Console;
- run the matching CloudShell or AWS CLI queries and explain every important field;
- draw the identity, network, data, failure, and monitoring path;
- choose the service from requirements and reject it when those requirements are absent;
- diagnose a failed or misleading result from evidence;
- state the cost owner and prove cleanup or a no-create result.
Before you start
- Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
- CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
- The course example Region is
ap-south-1. Global services and services with a required control Region are called out in their commands. - Run
aws sts get-caller-identityprivately. Redact the account number before sharing evidence. - Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
- This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
- Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.
The core model
| Question | What it means in this lesson |
|---|---|
| Purpose | Choose simple, weighted, latency, failover, geolocation, geoproximity, multivalue, or IP-based routing from a precise traffic requirement. |
| Scope and boundary | The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Route 53 routing policies. |
| Evidence of success | Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Route 53 routing policies. |
| Cost model | Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design. |
| Safe rejection rule | Avoid calling weighted routing exact traffic splitting or expecting DNS to drain existing connections immediately. |
How the request flows
+-------------------------------+
| DNS query and client source |
+-------------------------------+
|
v
+---------------------------------------+
| Policy evaluates records and health |
+---------------------------------------+
|
v
+----------------------+
| Selected answer |
+----------------------+
|
v
+-------------------------------+
| Client connects to endpoint |
+-------------------------------+For Route 53 routing policies, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Route 53 routing policies. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Route 53 routing policies. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.
Architecture decision table
| Situation | Direction | Reason |
|---|---|---|
| Requirement matches | Use a routing policy when DNS-level answer selection fits the requirement and cache behavior is accepted. | Select only after scope, behavior, security, recovery, operations, and price evidence agree. |
| Requirement does not match | Avoid calling weighted routing exact traffic splitting or expecting DNS to drain existing connections immediately. | Rejecting an attractive service is a valid architecture result. |
| No create permission or cost approval | Use supplied evidence and local design work | Learning does not depend on creating an hourly resource. |
| Existing resource is unknown or unowned | Inspect only, then stop | Never change or delete a resource merely because it resembles a course example. |
Policy behavior and selection
| Policy | Selects by | Correct use and trap |
|---|---|---|
| Simple | one ordinary answer/set | one endpoint or multiple unordered values; no policy-level health selection |
| Weighted | configured relative record weights, then health | canary/gradual distribution; resolver caching and small samples prevent exact request percentages; weight zero has special fallback behavior |
| Latency | AWS-measured latency between resolver location and Regions | lowest-latency Regional endpoint, not continuous per-user probe and not data residency |
| Failover | primary/secondary plus health | active-passive DNS; secondary must be independently viable and cached primary answers persist until TTL/connection renewal |
| Geolocation | resolver/client location mapping with default | localization/compliance approximations; unknown location needs default and is not a legal residency guarantee |
| Geoproximity | resource/customer coordinates, distance and optional bias | shift geographic boundaries, often through Traffic Flow; bias is not a fixed percentage |
| Multivalue answer | up to a subset of healthy records | simple DNS-level health distribution, not an ELB substitute or sticky/connection-aware balancer |
| IP-based | source resolver/client CIDR collection mapping | known network-specific answers; EDNS Client Subnet behavior and unmatched default matter |
Records in one policy group need the exact same name/type and unique set identifiers where required. Alias evaluate-target-health inherits supported target health; explicit health checks on aliases can create misleading combinations. Nested Traffic Flow policies can combine decisions, but every layer increases failure reasoning and cost.
For weighted changes, pre-lower TTL, define sample size/time, version-specific application metrics and abort threshold. A 1% DNS weight can produce zero or many requests from a large resolver cache. For latency/geolocation, test from distributed probes and record which recursive resolver/ECS prefix Route 53 saw. For failover, understand current all-unhealthy behavior: DNS systems often return an answer to avoid total unavailability; do not assume fail closed.
AWS Management Console, step by step
Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.
- Use the Console service search and open Route 53, Hosted zones, Record details and Traffic flow; confirm the account and Region before reading the page.
- Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
- Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
- Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.
CloudShell and AWS CLI, step by step
Start with a known caller and Region:
export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure listRedact the account part of the ARN in shared evidence. Now run the topic queries:
aws route53 list-resource-record-sets --hosted-zone-id replace-with-zone-id --query 'ResourceRecordSets[].{Name:Name,Type:Type,Set:SetIdentifier,Weight:Weight,Region:Region,Failover:Failover,Geo:GeoLocation,Health:HealthCheckId}' --output tableExpected interpretation
Routing policy controls which healthy records Route 53 may answer; it is not a load balancer connection, content cache, or guarantee of client location.
Practical work
For blue/green, lowest-latency global access, active-passive recovery, and country-specific content, select policies and define record identifiers, TTL, health evaluation, rollback, and test locations.
Add multivalue, geoproximity and IP-based cases. Simulate 100 resolvers with uneven client counts to show weighted DNS differs from request weighting. Test missing geolocation default, unknown IP range, all endpoints unhealthy, weight-zero fallback, stale resolver cache, one AAAA endpoint unhealthy and nested-policy rollback. State when ALB, Global Accelerator or CloudFront is required instead.
Diagnose this topic from its own evidence
Capture answer, TTL, resolver IP/ECS, query location, record set ID, policy and health state. Wrong Region under latency may reflect resolver location or current measurements; wrong country may reflect IP geolocation; unexpected weighted ratio needs resolver/sample analysis; no failover needs health status plus cached TTL. Do not repeatedly change weights before one old TTL and observation window complete.
Cost and cleanup
Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Knowledge check
- What operational purpose is this lesson solving?
Expected direction: Choose simple, weighted, latency, failover, geolocation, geoproximity, multivalue, or IP-based routing from a precise traffic requirement.
- Which scope or ownership boundary must be proved first?
Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Route 53 routing policies.
- What evidence is strong enough to accept the result?
Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Route 53 routing policies.
- Which tempting design or shortcut must be rejected?
Expected direction: Avoid calling weighted routing exact traffic splitting or expecting DNS to drain existing connections immediately.
- Which cost dimensions and retained resources need an owner?
Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.
Lesson acceptance
Pass when all eight policies are explained from their actual selection input, health and fallback; DNS caching effects are quantified; and tests include defaults/all-unhealthy/rollback. Fail if weighted means exact requests, latency means nearest geography, geolocation guarantees residency, or multivalue is described as a load balancer.