← All cloud projects
CASE STUDY us-east-1 + us-west-2 2026
CLOUD PROJECT · 2026

Three ways to survive a region failure — measured

DNS failover, anycast withdrawal and a blue/green listener swap, all built and timed against real traffic. Anycast moved regions in 25 seconds against DNS's 60–80, but a third of requests still failed while it noticed. The finding is that neither mechanism prevents the outage — both are bounded below by how fast they can detect one, and any RTO claim that ignores that window is wrong.

Global AcceleratorRoute 53ALBDynamoDB Global TablesLambdaEC2

Built, measured and torn down on 12 August 2026 across us-east-1 and us-west-2. Total cost $0.36. The infrastructure no longer exists — the code, the teardown scripts and the raw samples behind every number here are in the repo.

The question

“We fail over to another region” is a claim people make without a number attached. I wanted the number, and I wanted it for more than one mechanism, so I built three and pointed a request loop at each while breaking them.

What was measured

MechanismFailoverRequests lostDataCost floor
Blue/greenlistener rule swap, one region~40 s to propagate0 of 62sharedone ALB
DNS failoverRoute 53 stops answering with the primary60–80 syes, the whole windowreplicated~$1/mo
AnycastGlobal Accelerator withdraws the endpoint25 s79 of 233none — stateless~$18/mo fixed
AWS CloudGlobal Acceleratoranycastus-east-1 · primaryALBEC2 t3.microus-west-2 · secondaryALBEC2 t3.microRequest loop~5 req/s2 static IPsprimaryfailoveronly target

The anycast build. Normal path: request loop → Global Accelerator → ALB → EC2 in us-east-1. Failover (red): the accelerator withdraws us-east-1 and routes the same two IPs to us-west-2.

requestfailure / failover Hover, tap or Tab to a component to see what it does and why. Swipe sideways for the whole diagram.

The anycast run, one bar per request. Blue is us-east-1, green is us-west-2, red is HTTP 503:

Global Accelerator failover and failback233 requests. Blue is us-east-1, green is us-west-2, red is HTTP 503. 79 of 233 failed. Failover completed 25 seconds after the break was issued; errors ran from +4s to +30s.503s begin +4sus-west-2 +25sfailed back
233 requests at ~5/s. The primary was broken by deregistering its only target, so the load balancer had no healthy backend. Recomputable from data/s9-failover.log.

The finding

Anycast is two to three times faster than DNS, and neither prevents the outage.

They fail for different parts of the same total, and both are bounded below by detection:

So anycast removes the caching penalty entirely and permits a tighter interval. What it cannot do is notice a failure faster than it looks. You cannot get below detection time with either, which is why 34% of requests still failed on the fastest of the three.

If you need genuinely zero errors, failover is the wrong tool — you need both regions serving simultaneously, which is a different and more expensive architecture.

The detail the summary hides

The raw samples show something the test script’s own timing missed: the last 503 arrives at +30 s, five seconds after the secondary starts serving at +25 s. A short tail of requests keeps reaching the withdrawn endpoint after the switch has effectively happened.

That also corrected a number. The script reported 28 s because it polled on a five-second sleep and carried that granularity into its own measurement. Recomputing from the samples gives 25 s. The log is committed so anyone can check.

What each one is actually for

What it cost to find out

$0.36 across two regions for an afternoon — Global Accelerator at $0.025/hr fixed, two ALBs, two t3.micro. The same stack left running is about $70/month, and the accelerator’s share of that accrues in a console view nobody opens: its control plane lives in us-west-2 regardless of where the endpoints are, so a per-region sweep never finds it.

That combination — highest hourly cost of the nine projects, easiest to leave running by accident — is why the teardown script was written before the failover test was run.