The Architecture Review
Field Notes
Cloud Architecture · 2026-07-23

You Don't Choose Five Nines. You Buy Them.

Three nines is 43 minutes of downtime a month; five nines is 5 minutes a year. You don't close that gap by trying harder — you choose a deployment archetype that can deliver it, and pay what it costs. A working guide to the six cloud archetypes as a ladder, from Zonal to Global (with Hybrid and Multi-cloud as compositions, not rungs), drawn from Berenberg and Calder's Open-Access ACM Computing Surveys paper.

By Tom Ward, Enterprise Architect — Cloud & Infrastructure

Download the deep-dive PDF6 pages — the full model in detail, a checklist, and curated references. Free, no signup.
You Don't Choose Five Nines. You Buy Them. — architecture infographic
The six cloud deployment archetypes — and what each rung actually costs

The ladder: six deployment archetypes

Availability is a purchase, not an aspiration. Each rung buys more availability and lower latency — and costs more. Not every application needs the top of the ladder: the paper separates business-critical applications from line-of-business and internal ones, and only the first group is usually worth the climb.

01

Zonal

“One fault domain”

Every component runs inside a single zone. If the zone goes down, the workload restarts elsewhere from its last checkpoint or fails over to a standby — so a zone is a single failure domain, and this is not a high-availability posture. It stays the right answer for a real set of cases: HPC and TPU pods needing supercomputer-like bandwidth in one zone, developer test workloads, and license-bound COTS whose per-instance costs make redundant copies prohibitive. Buys: lowest cost and no cross-zone egress. Costs: a zone outage is an application outage.

02

Regional

“Survives a zone failure”

The application is replicated across three or more zones inside one region, all actively serving — the active-everywhere posture is what separates it from zonal. Best practice is to replicate across every zone and size each roughly equally, so capacity genuinely exists when a zone is lost; data is typically replicated synchronously within the region. Buys: survives a zone failure with no user impact, and keeps data in one jurisdiction. Costs: cross-zone traffic and replication, and a region-wide outage still takes you down.

03

Multi-regional

“Survives a region failure”

The serving stack is stitched across several regions — via isolated regional stacks with data sharding (the paper's example is banking: us.hsbc.com for US customers, hsbc.co.uk for UK ones), DNS load balancing across isolated stacks, or DNS with a custom multi-region load balancer. Buys: survives a whole region failure and cuts latency by geography, with data residency per jurisdiction. Costs: three zones in every region for redundancy (3×N), replication, and DNS TTL delays that cap achievable availability.

04

Global

“Five-nines territory”

One stack spread worldwide behind global anycast load balancing — a single virtual IP mapped everywhere — with a globally available database. The stronger Global Services Stack model load-balances each microservice globally so it can fail over independently, and it's the cheapest multi-region option because it needs only one zone per region and expands incrementally. Buys: instantaneous recovery (the requirement for five nines) and per-microservice failover. Costs: the anycast VIP and global database become global failure domains with no regional isolation to fall back on.

05

Hybrid & Multi-cloud

“Compositions, not rungs”

Read these sideways rather than upward. Hybrid connects on-premises to public cloud, so on-prem becomes another connected zone or region — a bridge and a home for what can't move. Multi-cloud runs across two or more public clouds so one provider's failure is survivable, the highest theoretical availability because the failure domains are genuinely independent; the paper calls it “in its infancy.” Neither is a higher rung: each is assembled from the four archetypes above, one per cloud or premises. The honest question isn't “should we be multi-cloud?” but “which archetype are we running, in each place we run?”

Four things that surprise people

Most of the ladder is intuitive: more redundancy, more availability, more cost. These four findings are not — and each one changes a decision.

  1. Surprise 1

    Global can cost less than multi-regional

    3×N versus N

    A multi-regional deployment needs three zones in every region for zonal redundancy, so it runs at 3×N. A global deployment needs only one zone per region (N), and each added region is incremental rather than multiplied. The cheaper option is also the more reliable one — which inverts how availability is usually budgeted, where “global” is assumed to be the expensive end of the menu.

  2. Surprise 2

    DNS failover cannot deliver five nines

    the protocol won't allow it

    Five nines leaves roughly five minutes of unavailability a year, which rules out any manual mitigation — recovery has to be instantaneous. DNS can't provide that: TTL delays are built into the protocol, and clients like browsers routinely disobey TTLs anyway. If your failover story is “we'll repoint DNS,” you've already chosen a lower tier. Five nines needs anycast load balancing with integrated health checking.

  3. Surprise 3

    One sick microservice takes down a whole region

    the real case for global

    With a regional application stack, if any single service in the region is unhealthy the entire region is pronounced unhealthy and pulled from serving — even though the rest of the stack is fine. A global services stack doesn't work that way: each microservice is independently load-balanced, so only the affected service moves. This, more than geography, is the real architectural argument for the global model.

  4. Surprise 4

    Failover you never test isn't failover

    an untested standby is an assumption

    Standby stacks sit unused, and there's always a risk the standby isn't ready when it's needed. Worse, the act of failing over exercises code paths that are rarely stressed — and those paths can themselves cause the outage. Load-balancing-based models sidestep the whole problem, because every zone and region is always taking traffic. If you keep a standby, you must routinely promote it in production.

The Archetype Selection Test

Ten checks before you commit an application to a deployment archetype. Score one point per honest “yes.” Below seven, you have a preference rather than a decision — and you'll discover the gap during an incident.

  1. The availability target is stated in minutes, not nines, and the business has agreed to that number.
  2. You know which application type this is — business-critical, line-of-business, or internal — and only the first is climbing the ladder.
  3. RPO and RTO are defined per application, and the archetype was chosen to meet them rather than justified after the fact.
  4. Data residency and regulatory constraints were mapped before the archetype was picked, not discovered after.
  5. You can name which fault domain each rung protects against — zone, region, cloud — and which ones you remain exposed to.
  6. If you need five nines, recovery is instantaneous via load balancing — no manual step fits inside a five-minute annual budget.
  7. If you rely on DNS for failover, you have consciously accepted that five nines is out of reach.
  8. Failover paths are exercised on a schedule — a standby you never promote is a standby you cannot trust.
  9. Your global dependencies — anycast VIP, global database, global control plane — are themselves counted as failure domains.
  10. The cost is understood all-in: instances per zone, zones per region, cross-zone and cross-region egress, replication, redundant storage, and the skills to operate it.

Going deeper

Sources worth your time, roughly in the order a team should read them.

More field notes ship as they're written.

Get the next note by email