Route 53 Routing and Application Recovery Controller
Key Takeaways
- Amazon Route 53 failover routing is active-passive (primary/secondary). Latency, geolocation, geoproximity, weighted, and multivalue answer policies can implement active-active behavior when health checks remove unhealthy targets.
- Geolocation maps client IPs to continents, countries, or U.S. states and needs a default record for unmapped addresses. Geoproximity routes by distance to resources and uses a bias from -99 to +99.
- Multivalue answer routing returns up to eight healthy records and is not a load balancer. Alias records to AWS resources should use Evaluate Target Health instead of a duplicate health check when AWS documents that option.
- Amazon Application Recovery Controller (ARC) currently names these capabilities in AWS Docs: zonal shift and zonal autoshift for in-Region AZ recovery; routing control, Region switch, and readiness check for multi-Region recovery.
- Routing-control state changes should use the ARC data-plane API against a five-Region cluster (retry endpoints). Readiness check watches quotas and capacity and is explicitly not the failover critical path.
DNS is a recovery lever, not a load balancer
Quick Answer: Use Amazon Route 53 failover records for active-passive Regional cutover. Use latency, geolocation, geoproximity, weighted, or multivalue answer policies when more than one endpoint should be eligible. Attach health checks (or Evaluate Target Health on aliases) so unhealthy targets drop out. For operator-driven Regional failover, Amazon Application Recovery Controller (ARC) routing control is the highly available on/off switch. For a single impaired Availability Zone (AZ), use zonal shift or zonal autoshift, not a Regional evacuation.
SAP-C02 expects you to pick the routing policy that matches the business rule, then pick the recovery controller that matches the failure domain. An AZ power event on an Application Load Balancer (ALB) is not a reason to fail a healthy Region. A full Regional impairment is not a reason to start a 60-minute zonal shift. Independent OpenExamPrep material for SAP-C02 walks those boundaries using current AWS Docs names.
Routing policies you must be able to contrast
| Policy | What Route 53 optimizes | Active-active or passive | Health-check notes | Exam-style use |
|---|---|---|---|---|
| Failover | Primary until unhealthy, then secondary | Active-passive | Health check or Evaluate Target Health on aliases | Warm standby / pilot light cutover |
| Latency | Lowest-latency AWS Region for the client | Active-active among healthy Regions | Latency can change over time; EDNS0 client subnet may refine location | Global API without hard residency rules |
| Geolocation | Continent, country, or U.S. state of the client | Sticky to geography | Create a default record; unmapped IPs otherwise get no answer | Licensing, language, data-residency |
| Geoproximity | Distance from users to your resources, optional bias | Active-active with steering | Bias +1 to +99 expands a resource’s catchment; -1 to -99 shrinks it | Shift traffic toward a new Region without hard country lists |
| Weighted | Share of traffic = weight / sum of weights | Active-active (or drain with weight 0) | If all nonzero weights are unhealthy, Route 53 can consider zero-weight records | Canary, blue/green, slow migration |
| Multivalue answer | Up to eight healthy records per response | Roughly random among healthy IPs | Unhealthy records omitted; if all are unhealthy, Route 53 still returns up to eight | Small DNS-based spreading, not a substitute for Elastic Load Balancing |
Simple routing (one record, optional multiple values without health-aware selection) is the baseline. The policies above are what professional scenarios actually hinge on.
Failover routing is the active-passive primitive: one primary, one secondary, same name and type. Primary and secondary can themselves be alias trees (for example a weighted group of healthy ALBs behind the primary). If you alias to an AWS resource that supports it, set Evaluate Target Health to yes and do not duplicate a health check on that alias. Route 53 docs call that out specifically for ALB, AWS Elastic Beanstalk, Amazon S3 website endpoints, and similar alias targets.
Latency-based routing is not residency. A user in Dublin might land in eu-west-1 this week and eu-central-1 next week if paths change. If a regulator says “EU persons must be served in Frankfurt,” that is geolocation, not latency.
Geolocation uses IP-to-location maps. Overlapping records prefer the smallest region (Canada wins over North America for Canadian IPs). Always define a default for addresses Route 53 cannot map; otherwise those clients receive a no-answer response.
Geoproximity uses the location of resources (AWS Region or latitude/longitude) and a bias. A positive bias makes a resource look closer than it is, pulling more traffic. A negative bias pushes traffic away. That is how you drain a Region that is still healthy but expensive, without rewriting country lists.
Weighted routing is the canary tool. Weight 0 stops sending traffic unless every nonzero-weighted sibling is unhealthy—then zero-weight records can receive queries. That caveat is a reliability trap: a tiny standby that cannot absorb full load should not be the hidden overflow path without capacity planning.
Multivalue answer returns up to eight healthy IP records and varies answers across resolvers. Clients that cache one response can still try another address in the same answer. It does not session-stick, does not understand application health beyond the health check, and does not replace an ALB target group.
Health checks
Route 53 health checks can watch:
- An endpoint (IP or domain, HTTP/HTTPS/TCP).
- A calculated check (the status of other checks), for “at least two of three cells healthy.”
- An Amazon CloudWatch alarm, when the signal is a metric rather than an HTTP probe.
- An ARC routing control, which does not probe the application. It is an on/off bit that you change on purpose.
Health checks live on the Route 53 data plane. Changing a weighted record’s weight in the console during an outage is a control-plane change. The Disaster Recovery whitepaper warns that some operators used weight flips as “manual failover” and that ARC routing control is the more resilient data-plane alternative.
DNS TTL still bounds how fast clients notice. A 300-second TTL means some users remain on the old endpoint for minutes after a healthy-record change. Design TTLs with that delay inside the RTO, or use AWS Global Accelerator anycast when DNS cache behavior is unacceptable. Global Accelerator health checks can fail away from an unhealthy Regional endpoint; adjusting traffic dials is still a control-plane action.
Amazon Application Recovery Controller — current feature names
AWS Docs (“What is ARC?”) split ARC into multi-AZ recovery and multi-Region recovery. Use these names on the exam; do not substitute retired marketing labels.
Zonal shift (multi-AZ, manual). You opt in a supported resource (commonly ALB, Network Load Balancer (NLB), and other listed resources). You shift traffic away from one AZ to the other AZs in the same Region. You must prescale so remaining AZs can carry the load—this is static stability. Shifts are temporary: you set an expiration from one minute up to three days (72 hours) and can extend it. Zonal shift does not move traffic to another Region. Cancel anytime to restore the AZ.
Zonal autoshift (multi-AZ, AWS-initiated). You authorize AWS to shift supported resources when internal telemetry (network, EC2, Elastic Load Balancing signals) indicates AZ impairment that could affect customers. AWS ends the autoshift when telemetry recovers. Practice runs are required: ARC starts regular (documented as weekly) practice zonal shifts, typically about 30 minutes, and reports SUCCEEDED or FAILED. You configure blocked windows and blocking alarms so practice runs skip deploys and peak; those blocks apply to practice runs, not to a real AWS-initiated autoshift during an actual impairment.
Routing control (multi-Region). Routing controls are highly available on/off switches stored on an ARC cluster with endpoints in five AWS Regions. AWS states that at least three of the five endpoints remain accessible. You associate routing controls with a special Route 53 health check, then with DNS records (often failover records) in front of each Regional replica. To fail over, you change routing-control state with the ARC API or CLI, rotating through cluster endpoints if one is down. AWS recommends the API over the console for this path. Safety rules live on a control panel:
- Assertion rule — refuse a state change that would violate a criterion (classic: at least one routing control in a set remains
On, preventing fail-open to nowhere). - Gating rule — a master switch that must be
Onbefore target routing controls can change, stopping runaway automation.
Region switch (multi-Region). AWS describes Region switch as a centralized, automated, observable way to plan and coordinate recovery across Regions and accounts. When a Region is impaired, plans you define can fail over or switch resources so the application continues in a healthy Region. Treat it as orchestration sitting above routing controls and resource-level recovery, not as a replacement for zonal shift.
Readiness check (multi-Region monitoring). It continually inspects quotas, capacity, and network routing policies that would block failover. AWS states it is useful while you configure ARC and during normal operations, and that it is not intended for the critical path of failover during an event. If a scenario says “the failover API is readiness check,” that answer is wrong.
Organization versus new versus existing
Task 1.3 (organization). Central platform teams own the ARC cluster, control panels, and assertion rules so application teams cannot turn every cell off. They standardize which ALBs must enable zonal autoshift. They do not give every product line a different DNS naming scheme that bypasses safety rules.
Tasks 2.2 and 2.4 (new solutions). Pick geolocation versus latency when you first publish the domain. Build two Regional stacks with routing controls from day one if RTO cannot tolerate control-plane weight edits. Prescale (or use zonal shift-aware capacity) if you will opt into autoshift.
Task 3.4 (existing). An ALB that has never opted into zonal shift cannot be shifted. The reliability improvement is the opt-in, the prescale, and a game day—not rewriting the app into active-active across continents. For existing weighted records used as a poor-man’s failover, replace the runbook’s “change weights in the console” step with routing-control API calls.
AZ impairment scenario
Payments API ALBs in us-east-1a/b/c. Telemetry shows us-east-1a impaired. Remaining AZs were prescaled to 100% of peak divided by two (static stability for losing one of three). The architect starts a zonal shift away from us-east-1a (or autoshift already did). Route 53 latency records that still point at us-east-1 stay valid; you did not flip failover to us-west-2. Flipping Region would double RPO risk on asynchronously replicated ledgers and would burn the organizational DR drill on the wrong failure domain.
An Application Load Balancer in us-east-1 is opted into Amazon Application Recovery Controller. One Availability Zone is impaired. You must move client traffic off that AZ while keeping the other AZs in us-east-1 in service. Which ARC capability matches current AWS documentation?
A media publisher must serve European Union users only from eu-central-1 and United States users only from us-east-1 because of licensing. Lowest-latency routing would sometimes send EU users to us-east-1. Which Route 53 policy enforces the residency rule and still handles addresses Route 53 cannot map?
A platform team needs operator-initiated failover between two active/passive Regional replicas. The runbook must not depend on editing weighted records in the Route 53 console during a Regional event. Which design matches AWS disaster-recovery guidance?