Uptime, Availability Zones and What Redundancy Really Costs

Every extra nine costs more than the last. Deciding how many you need is a business decision that engineering keeps making by accident.

11 August 2026 3 min read

Availability targets are usually inherited rather than chosen. Someone builds for high availability because it seems responsible, or builds a single server because it is quick, and nobody states the target the design is meant to hit.

What the nines mean

Availability	Downtime per year	Downtime per month	Typical design
99%	3.65 days	7.2 hours	Single server, manual recovery
99.9%	8.8 hours	43 minutes	Single server, good monitoring, fast restore
99.95%	4.4 hours	22 minutes	Two servers, one zone
99.99%	53 minutes	4.3 minutes	Multi-zone, automatic failover
99.999%	5.3 minutes	26 seconds	Multi-region, no manual steps

Note the last column. 99.99 per cent leaves no room for a human to notice, log in and act. Everything must be automatic, which is where the cost lives.

Regions, zones and what fails together

Availability zone — an isolated data centre within a region, with independent power and cooling, connected to its siblings by low-latency links.
Region — a group of zones in one geography. Independent of other regions.
Multi-zone — replicas in two or more zones in one region. Survives a data centre failure with negligible latency cost.
Multi-region — replicas in different geographies. Survives a regional failure, and introduces real latency and complexity.

Multi-zone is the sweet spot for most systems: a meaningful reliability gain for modest cost. Multi-region roughly doubles the operational burden and should follow a specific requirement, not a general aspiration.

Not every provider has zones. Several VPS providers offer independent locations rather than linked zones, which changes how failover is built — see choosing a cloud region.

What each step actually costs

One server, restore from backup. Cheapest. Recovery measured in hours, and dependent on someone being awake.
One server plus a warm standby. Roughly 1.5 times the cost. Recovery in minutes with a manual switch.
Two servers, load balanced, one zone. About twice the cost plus the balancer. Survives instance failure automatically.
Two zones, replicated database. Two to three times. Survives a data centre failure.
Multi-region active-active. Three times or more, plus substantial engineering. Survives regional failure.

Each step is roughly a doubling of cost for a diminishing reduction in expected downtime. Stopping at step three or four is a reasonable, defensible decision for most businesses.

What an SLA actually promises

A provider SLA is a billing commitment, not a guarantee of uptime. If they miss the target you receive service credits, usually a percentage of that month’s spend for the affected service.

Two things follow. First, credits will not compensate for what an outage costs your business. Second, the SLA usually applies only if you followed the architecture it requires — a single instance is typically excluded from the highest tier, which requires multiple zones.

The failures redundancy does not cover

A bad deployment, replicated instantly to every server.
A schema migration that corrupts data everywhere at once.
An expired certificate, which fails in all zones simultaneously.
A DNS misconfiguration, upstream of all your redundancy.
Account suspension or a billing failure.
A dependency outage — payment provider, identity provider, third-party API.

These are, in practice, more common causes of downtime than hardware failure. Deployment safety, staged rollouts and dependency timeouts often buy more availability than another zone.

Decide the number first

Estimate what an hour of downtime costs — revenue, contractual penalties, support load, reputation.
Pick a target availability that the business would defend in writing.
Design to that target and no further.
Write down what happens during a failure, and test it at least once.
Revisit annually, as the cost of downtime changes with the business.

Common questions

Is multi-region worth it?

For most businesses, no. Regional failures are rare, and the complexity is permanent. It becomes worth it with a contractual requirement, or genuinely global users where latency alone justifies it.

Do I need redundancy for a staging environment?

No. Staging exists to be broken. Spend the redundancy budget on production, and consider shutting staging down overnight.

Does a managed database give me high availability?

Only if you enabled the multi-zone option, which usually costs extra. A single-instance managed database is still a single point of failure with better backups.

How do I test failover?

Deliberately, on a schedule, during working hours. Stop the primary and watch what happens. A failover mechanism that has never run is a hypothesis, not a capability.

Where to go next

See backup strategy and scaling up versus scaling out.

AWS Microsoft Azure UpCloud