AWS Edge Networking and Multi-Region Resilience

Route 53, CloudFront, Global Accelerator, and the DR topology across SAP and DOP.

§ IFrame

Today's Ops lesson kept a pool of chain query nodes caught up to the chain head and routed public traffic only to the healthy ones. Today's Dev lesson built that router in Go. Both stayed inside one region, one data center's worth of nodes, one load balancer. This cert lesson asks the question that begins where those two stopped: what keeps the public endpoint reachable when the failure is not a single node falling behind but an entire availability zone going dark, or an entire region becoming unreachable.

That question is the spine of the AWS Solutions Architect Professional exam and a recurring theme of the AWS DevOps Professional exam. The two exams approach it from different angles. SAP asks the architect to design the topology: how many regions, what stands ready in each, what the recovery time and recovery point targets demand. DOP asks the engineer to automate the topology: how failover triggers without a human, how the standby region stays current, how the deployment pipeline reaches every region at once. One exam draws the diagram; the other wires it to fire on its own.

This lesson treats the shared foundation once and pivots to each exam's flavor. The shared foundation is the AWS edge: Route 53 for health-checked DNS, CloudFront for cached delivery, and Global Accelerator for the anycast network path. On top of that foundation sits the disaster-recovery topology, and the four named DR strategies the SAP exam expects an architect to choose between by cost and recovery target.

§ IIDomain Foundations — The AWS Edge

Three services form the edge layer that sits in front of a multi-region application. Each does a distinct job, and the exams test whether the candidate knows which job belongs to which service.

Route 53 is AWS's managed DNS. Its relevant power for resilience is the health check coupled to the routing policy. A health check polls an endpoint on an interval and marks it healthy or unhealthy. A routing policy decides which record to return, and several consult health: failover routing returns the primary while healthy and the secondary when not, latency routing returns the lowest-latency healthy region, and weighted routing splits traffic among healthy records. The health check is the trigger; the routing policy is the response.

CloudFront is the content delivery network. It caches responses at edge locations close to users and serves cached content without reaching the origin. For a read-heavy endpoint, CloudFront absorbs the bulk of traffic at the edge, lowering latency and shielding the origin from load. Its resilience contribution is origin failover: an origin group names a primary and a secondary origin, and CloudFront fails to the secondary on configured error responses.

Global Accelerator moves the failover decision off DNS and onto the network. It gives the application two static anycast IP addresses advertised from AWS edge locations worldwide. User traffic enters the AWS backbone at the nearest edge and routes to the healthiest endpoint over AWS's own network rather than the public internet. Because the client-facing IPs are static and routing happens inside the network, failover does not wait for DNS time-to-live to expire. This is the foundational distinction the exams test: Route 53 failover is bounded below by DNS caching, Global Accelerator failover is not.

§ IIISAP Flavor — Designing the DR Topology

The Solutions Architect Professional exam frames multi-region resilience as a choice among four disaster-recovery strategies, ordered by cost and by how fast they recover. The architect picks by the recovery time objective, the maximum acceptable downtime, and the recovery point objective, the maximum acceptable data loss.

Backup and restore keeps backups in a second region and rebuilds there after a disaster. Cheapest, slowest to recover, recovery time in hours. Pilot light keeps a minimal core running in the second region: the database replicating continuously, application servers defined but switched off. Recovery scales the dormant servers up; recovery time drops to tens of minutes. Warm standby runs a scaled-down but fully functional copy taking no production traffic until failover; recovery only scales up, faster than pilot light, at the cost of an always-running fleet. Multi-site active-active runs full production in both regions at once; there is no recovery step because the survivor absorbs the failed region's load. Most expensive, lowest recovery time and point, hardest design because writes happen in two regions at once.

The architect's exam skill is mapping a stated recovery target onto the cheapest strategy that meets it. A scenario naming a four-hour recovery time and a one-hour recovery point points at pilot light. A scenario naming near-zero downtime for a global user base points at active-active with latency-based Route 53 routing. The exam rewards meeting the target without over-paying for resilience the application did not ask for.

§ IVDOP Flavor — Automating the Failover

The DevOps Professional exam takes the topology the architect designed and asks how it runs without a human standing by. Three automation surfaces define the DOP flavor.

The first is health-driven failover. A CloudWatch alarm watches a metric on the primary region, the alarm state feeds a Route 53 health check, and the health check flips the failover routing policy to the secondary. The DOP exam tests whether the candidate knows a Route 53 health check can be driven by a CloudWatch alarm, which lets failover trigger on any metric CloudWatch can see rather than only on a simple endpoint poll.

The second is keeping the standby current. A warm-standby or pilot-light region is only useful if its version and configuration match production. The DOP discipline is a deployment pipeline that targets every region in the same release: CodePipeline with per-region stages, or a single pipeline that fans out to multiple regions, so the standby never drifts behind the primary. A standby running last month's build fails over into an incident of its own.

The third is recovery verification. The DOP exam expects automated proof that failover works, not faith that it will. This is the game-day rehearsal automated: a scheduled exercise that fails traffic to the secondary region, confirms the application serves correctly there, and fails back. The rehearsal turns the recovery target from a number on a design document into a measured property of the running system. The Ops node-fleet lesson made the same point about chain upgrades: the rehearsal must include the recovery path, not only the happy path.

The two exams meet at the same topology from opposite sides. SAP certifies that the engineer chose the right number of regions and the right strategy for the recovery target. DOP certifies that the chosen strategy fires automatically, stays current, and is proven by rehearsal. An architecture correctly designed but manually operated passes neither exam's full intent.

§ VWorked Example — A Global Read API Across Two Regions

Consider a read-heavy API serving a global user base, with a recovery time objective of two minutes and a recovery point objective near zero. The architecture places full production in two regions, us-east-1 and eu-west-1, each running the application behind a regional load balancer, with the database replicating cross-region.

Global Accelerator fronts both regions with two static anycast IPs. User traffic enters the AWS backbone at the nearest edge and routes to the healthier regional endpoint. Because failover happens on the network path rather than through DNS, the two-minute target is reachable; a DNS-based design would risk missing it on resolver caching alone. CloudFront sits in front for the cacheable read traffic, absorbing the bulk of requests at the edge and shielding both origins. A CloudFront origin group names each region's load balancer as primary and secondary so an origin-level failure also fails over at the cache tier.

The DOP automation wires the rest. A CloudWatch composite alarm in each region watches load-balancer health and application error rate; an unhealthy alarm drives the Global Accelerator endpoint health so traffic drains from the failing region automatically. The deployment pipeline releases to both regions in one run, with a manual approval gate only before production, so the eu-west-1 standby never drifts from us-east-1. A weekly automated game-day drains us-east-1 to eu-west-1, confirms the API serves from the survivor, and restores, recording the measured recovery time against the two-minute target.

The result satisfies both exams. The SAP architect chose active-active because the recovery target demanded it and chose Global Accelerator because the target was below the DNS-caching floor. The DOP engineer made failover fire on a composite alarm, kept the standby current through a multi-region pipeline, and proved the recovery time with a recurring rehearsal. The two static IPs the user connects to never change through any of it.

§ VIConnection to Today's Ops and Dev Lessons

The trio shares one problem at three scales. The Ops lesson kept a pool of chain nodes caught up to the head and routed only to healthy nodes inside one region. The Dev lesson built that intra-region router in Go, with a health check that pulls a stale node from rotation. This cert lesson lifts the identical health-route-failover pattern to the inter-region scale, where the unhealthy unit is a whole region and the router is Route 53 or Global Accelerator rather than a Go reverse proxy.

The health gate recurs at every scale. The Go balancer gated a backend on height lag and shed load with a 503 when no node was at the head. The AWS edge gates a region on a CloudWatch alarm and drains it through Global Accelerator when it degrades. Same shape: a health signal, a routing decision conditioned on it, a defined behavior when nothing healthy remains. The chain-node fleet is the within-region instance; the multi-region AWS topology is the across-region instance. An engineer who built the Go balancer this morning already holds the pattern the SAP and DOP exams test at the larger scale.

§ VIIPractice Questions

§ VIIIClosing

Multi-region resilience on AWS is one problem seen by two exams. The SAP architect chooses among backup-restore, pilot light, warm standby, and active-active by mapping the recovery time and recovery point targets onto the cheapest strategy that meets them, and chooses Route 53 or Global Accelerator at the edge by how fast failover must be. The DOP engineer makes the chosen topology fire on a CloudWatch-driven health check, keeps the standby current through a multi-region pipeline, and proves the recovery target with a recurring automated game-day. The edge foundation under both is the same three services: Route 53 for health-checked DNS, CloudFront for cached delivery, Global Accelerator for the network-path failover that DNS caching cannot match.

The trio's lesson is that the health-route-failover pattern is scale-free. The Go reverse proxy gated a chain node on height lag this morning; the AWS edge gates a region on a composite alarm; the shape is one shape. The Friday Terraform synthesis will provision this multi-region topology as code, tying this week's AWS resilience surface to the IaC seam.

For now: take the worked example above and name, for your own systems, the unhealthy unit at each scale — the process, the node, the zone, the region. For each, name the health signal, the router, and the behavior when nothing healthy remains. Where any of the three is unnamed, the failover is a hope rather than a mechanism.

Paired Ops → δ-Chain/Synthesis-Lessons/2026-06-09-rpc-and-full-node-infrastructure-operations-for-sovereign-chains
Paired Dev → Polyglot-Dev/Go/2026-06-09-gos-httputil-reverseproxy-and-health-aware-load-balancing-for-chain-rpc-endpoints