On 7 May 2026 a room full of machines in Northern Virginia got too hot. Several cooling units failed inside a single Availability Zone, use1-az4, racks lost power as temperatures went past safe limits, and AWS confirmed elevated error rates and impaired EC2 instances in us-east-1 at 17:25 PDT (Network World). Cooling was back to pre-event capacity around 13:50 PDT the next day, and independent trackers put total recovery somewhere between 19 and roughly 28 hours (IT Pro).
That incident is the strongest argument for multi-AZ anyone has published in years, because it is precisely the failure multi-AZ exists for. One zone went down physically while the rest of the region kept serving. It is also why the more famous outage seven months earlier is the strongest argument against treating multi-AZ as your resilience plan. On 20 October 2025 a race condition in the internal DNS automation behind DynamoDB took out a regional endpoint in that same region, and the damage crossed every zone inside it (AWS post-event summary). Multi-AZ did not help.
This is written for the founding engineer or CTO of a 10 to 50 person company running one production environment on one cloud, who has just been asked by an investor, an enterprise buyer, or their own 03:00 brain whether they should be multi-AZ, multi-region or multi-cloud. Most articles answer with an availability calculation. The calculation is the least useful thing in the room. What decides the answer is which boundary your failure lives inside, and whether your redundancy sits inside the same one.
Where this sits in 2026
Forrester's 2026 predictions call for at least two major multi-day hyperscaler outages this year, and attribute the risk to investment shifting toward GPU capacity while older estates carry rising complexity (Forrester). Whether or not the count lands at two, the direction is the useful part: more moving parts, inside shared infrastructure you do not operate and cannot inspect.
Meanwhile the thing lean teams actually buy has not changed in a decade: two of everything in a second zone, a standby database, and a networking line item that grows quietly. The last twelve months handed us unusually clean evidence about what that purchase really covers.
1. The last twelve months contained three different failure shapes
Treat the recent incidents as a taxonomy rather than a list. The May 2026 thermal event was zone scoped: one zone impaired, the region intact, which is the textbook case for spreading capacity. The October 2025 DynamoDB event was region scoped: a regional service endpoint failed and the failure was visible from every zone, plus a second wave of Network Load Balancer connection errors caused by health check failures across the fleet (AWS). The Cloudflare R2 incidents in February and August 2026 were provider scoped: availability problems in object storage and related products, sitting outside the compute region entirely (Cloudflare status history).
Three shapes, three different answers. Zone redundancy addresses the first. Only degradation design or a second region addresses the second. Only a second provider path, or the ability to serve without that provider, addresses the third. Teams get this wrong because "went down" is one phrase for three unrelated events, and the architecture diagram treats them as one risk.
Takeaway: before costing any redundancy, classify the failure you are buying against by its boundary. Zone, region, or provider. Buying at the wrong level is the most common way lean teams spend real money on no protection.
2. What an Availability Zone actually promises
An AWS Availability Zone is one or more discrete data centres with redundant power, networking and connectivity, meaningfully separated from other zones in the same region, and connected by high bandwidth low latency links (AWS global infrastructure). Azure describes its availability zones the same way, as physically separate locations within a region with independent power, cooling and networking (Microsoft Learn). Google Cloud zones sit inside regions with the same intent (Google Cloud).
Read what that sentence guarantees and what it does not. It guarantees physical independence: a fire, a flood, a power feed, a cooling plant. Three zones, one region, is the shape. The guarantee says nothing about logical independence, and almost every regional service you consume, a managed database endpoint, a queue, an identity service, is one logical system spread across those zones. When the logical system fails, physical separation is irrelevant to you.
Takeaway: multi-AZ is insurance against a building, not against software. Write that sentence on the architecture diagram, because it is the single distinction that makes the rest of the budget conversation rational.
3. Availability maths is the least reliable part of the plan
The classic pitch multiplies component availabilities and shows three nines becoming four. That arithmetic assumes failures are independent, and the incidents above are mostly correlated failures: one DNS automation bug, one cooling plant, one deployment. Correlated failures are exactly the ones that break the model, and they are the ones that make the news.
The contractual side is worth reading too. The AWS compute service level agreement targets a monthly uptime percentage and pays in service credits on a sliding scale, which is a discount on your own bill, not compensation for your downtime (AWS Compute SLA). Your enterprise customer's contract with you is unlikely to be written on the same terms.
The replacement is boring and it works: per user-visible function, write down the recovery time objective and recovery point objective you will commit to, then check which failure shapes your current design meets them under. AWS's own disaster recovery guidance is organised the same way, RTO and RPO first, topology second (AWS DR whitepaper).
Takeaway: replace the nines slide with a one page table of functions, RTO, RPO, and the largest failure each survives. It takes an afternoon and it ends the debate.
4. The control planes that live in one place
Some AWS services are global, and their control planes run only in us-east-1. IAM, Route 53 and CloudFront are the ones most teams touch (AWS fault isolation boundaries). Data planes are designed to keep serving when a control plane is impaired: existing DNS answers still resolve, existing roles still authorise. What you lose is the ability to change things, which is a problem when your recovery plan is a list of changes.
This is the trap inside most written failover runbooks. Step one updates a DNS weight, step two attaches a role, step three launches instances in the surviving zone. Every one of those is a control plane call, and during a large regional event those are the calls that queue, throttle or fail. AWS's own guidance for customers is to pre-provision resources and avoid control plane dependencies in the recovery path (AWS re:Post).
Takeaway: read your runbook and mark every step that requires an API write during the incident. Each mark is a step that may not run when you need it. Convert as many as you can into things that already exist, and see the next section for how.
5. Static stability, or the failover that needs the broken thing
Amazon's own pattern for this has a name. In the Builders' Library article on static stability, the design goal is that a system keeps doing what it was already doing when a dependency becomes impaired, without needing that dependency to recover or a new resource to be created (Amazon Builders' Library). The concrete version is capacity: instead of relying on the EC2 control plane to launch replacements when a zone fails, the capacity is already running. Across three zones that means overprovisioning by roughly 50 percent so the survivors can carry the whole load.
For a lean team the honest translation is that two instances in two zones is not a multi-AZ design, it is a design that halves under failure. Either each zone can carry the full load, or you have accepted degraded service as the plan, which is a legitimate choice as long as it is written down and the customer-facing behaviour is decided in advance rather than discovered live.
Takeaway: pick one: overprovision so any single zone can go and nothing changes, or define in advance exactly which features degrade first. Both are professional. Only "we will scale up when it happens" is not.
6. What multi-AZ costs, line by line
Four line items move. Inter-zone traffic is charged at 0.01 USD per GB in each direction, so a chatty service mesh split across zones is billed on both legs (AWS EC2 on-demand pricing). NAT gateways are zonal, so a properly zone-isolated design runs one per zone and pays the hourly charge plus processing on each. A managed relational database in a Multi-AZ instance configuration provisions a standby, so the instance cost roughly doubles, and the three node cluster option adds a second readable instance (AWS RDS documentation). Fourth, the overprovisioning from the previous section.
None of that is a reason to stay in one zone. It is a reason to be deliberate about which traffic crosses a zone boundary. Keep high volume chatty paths, caches and their clients, sidecar to service calls, and analytics fan-out inside a zone where correctness allows, and let the replicated state be the thing that crosses. That single rule is usually the difference between multi-AZ being a rounding error on the bill and being a visible line item.
Takeaway: measure inter-AZ bytes for a week before you change topology. The number tells you whether this decision is an architecture question or a finance one.
7. The database decides the whole question
The stateless tier is easy and everybody gets it right. State is where the money and the risk live. Amazon RDS documents typical failover for a Multi-AZ DB instance at 60 to 120 seconds, with long transactions or recovery extending it (AWS), and typical failover for a Multi-AZ DB cluster at under 35 seconds (AWS). Those numbers are the real recovery time objective for anything that writes, whatever your application tier does.
Two things matter more than the topology choice. First, whether your application survives the failover window: connection pools that never reconnect, retries without backoff, and a health check that flaps will turn a 90 second event into a 20 minute one. Second, whether you have ever performed a failover. Providers expose a forced failover for exactly this reason, and it is the one drill a lean team can afford to run quarterly in a maintenance window.
Takeaway: if you do one thing from this post, put the primary database in a managed multi-zone configuration and trigger a forced failover on purpose, with the application running and someone watching the error rate.
8. The edge is a dependency nobody designed
Your CDN, your DNS provider and your object storage are a separate boundary from your compute region, and they usually arrived by default rather than by decision. Cloudflare published detailed public write-ups of its November and December 2025 outages (Cloudflare), and its status history records R2 availability incidents through 2026 (Cloudflare status history). A perfectly multi-AZ application behind a single edge path still has a single point of failure, and it is the one your users hit first.
The fix here is cheap and mostly paperwork. Know whether your origin can serve traffic directly if the edge is bypassed, keep the TLS certificate and origin hostname able to answer on their own, know your DNS time to live and therefore how long a cutover really takes, and keep a second copy of anything user-facing that lives only in one provider's object storage. Practitioner opinion: for most seed stage products, a documented and rehearsed 20 minute manual edge cutover beats an automated one nobody has tested.
Takeaway: write the edge bypass procedure on one page, then test it once against staging. Most teams discover a hard dependency they did not know about in the first 10 minutes.
9. Concentration risk is now a contract question, not only an engineering one
Your enterprise and financial-sector customers are being pushed on this from their side. Under the EU Digital Operational Resilience Act, financial entities must assess concentration risk when a critical or important function depends on a provider that is not easily substitutable, and must hold exit strategies for those arrangements (DORA Article 29). Indian regulated entities carry comparable outsourcing expectations, which is why the questions arrive in vendor questionnaires rather than in architecture reviews, as covered in our post on the RBI outsourcing direction and what flows down to vendors.
The practical consequence for a small vendor is that the question you will be asked is not "how many zones". It is "what happens to our service if your provider or your region is unavailable, how long does it last, and who decides". That is answerable today with a written recovery plan, a tested restore, and named decision ownership, none of which requires a second region.
Takeaway: get the answer written before it is asked. The same page serves the security questionnaire, the board update, and the incident itself.
10. The honest case for one region, and the four things that must be true
Running in a single region is a defensible engineering decision for most pre-seed and seed products, and it stays defensible exactly as long as these four hold. One, a written RTO and RPO per function that your customers have seen and accepted. Two, backups in a different region or a different provider, immutable where possible, with a restore you have actually performed and timed, which we cover in the immutable backup post. Three, infrastructure as code complete enough to rebuild the environment somewhere else, verified by building it somewhere else at least once. Four, a status page and a comms plan that does not depend on the infrastructure that is down.
If any of the four is missing, that is the next thing to build, and each is measured in days of work rather than a permanent cost line. Multi-region active-active is the right answer later, when a customer contract or a revenue-per-minute number makes the ongoing cost obvious. Until then, put the money into the four items above, because they are what actually shorten a bad day.
Takeaway: single region plus a proven restore beats multi-region that nobody has exercised. Choose the one you can prove this quarter.
Summary
| Failure shape | Does multi-AZ help | What actually helps |
|---|
| One zone loses power or cooling (7 May 2026, us-east-1) | Yes, this is the design case | Capacity already running in the other zones |
| Regional service or DNS automation failure (20 October 2025) | No | Static stability, planned degradation, second region for the critical path |
| Global control plane impaired (IAM, Route 53, CloudFront changes) | No | Pre-provisioned resources, no API writes in the recovery path |
| CDN or object storage provider incident (Cloudflare R2, 2026) | No | Tested edge bypass, second copy of user-facing assets |
| Your own bad deploy | No | Progressive rollout and a rollback measured in minutes |
| Region unavailable for a day or more | No | Cross-region backups with a timed restore drill |
What to do at your stage
Pre-seed, first paying users. One region, one zone for the application tier is fine. Spend the effort on cross-region backups with one real restore, infrastructure as code, and the written RTO and RPO. Put the database in a managed multi-zone configuration because it is the cheapest risk reduction available and it needs no architecture change.
Seed, enterprise pilots in flight. Make the whole application tier zone independent, size it so one zone can carry the load, and run a forced database failover in a maintenance window every quarter. Write the edge bypass page. This is also the stage where the questionnaire arrives, so the written plan starts paying for itself in sales cycles.
Series A, revenue per minute is measurable. Now the maths changes. Put the critical read path in a second region with pre-provisioned capacity and no control plane dependency in the failover, keep the rest single region, and rehearse the cutover twice a year. Partial multi-region on the path that earns money beats a full copy of everything.
Where to start this week
Open your failover runbook and count the steps that need an API write during an incident. If the count is above zero, you have this week's work, and it is design time rather than spend. If there is no runbook, that page is the work, and one page is enough to start.
The cloud and security checklist on this site walks the same ground for a lean team, including the backup, restore and recovery items above. You can open it here: the MatrixGard cloud and security checklist. It is free, it takes about twenty minutes, and it will tell you which of the ten items above you already have.
About the author
Avinash S is the founder of MatrixGard, a fractional DevSecOps practice for early-stage startups, funded or bootstrapped. MatrixGard acts as the cloud, infrastructure and security team for companies that are not yet ready to hire one, covering cloud architecture, cost control, and the security posture that enterprise customers ask about before they sign.
Methodology
Every incident detail in this post comes from the provider's own post-event summary or status history where one exists, and otherwise from contemporaneous reporting, all linked inline. Every architectural claim is sourced to provider documentation, the Amazon Builders' Library, or the regulation text itself. Pricing and failover timings are the published figures at the time of writing, so re-check them before building a budget. Nothing here is drawn from client work, no figures are estimated, and judgement calls that are not documented anywhere are labelled practitioner opinion.
