What Is High Availability and How Do You Design for It?
High availability keeps systems running when parts fail. Here is how redundancy and failover work, what each extra nine of uptime really costs, and how to pick the right target.
High availability means designing a system to keep working when individual parts fail, usually measured as an uptime percentage such as 99.9% or 99.99%. You get there by removing single points of failure with redundant components, spreading them across separate locations and failing over automatically. Each extra "nine" costs noticeably more, so match the target to real business need.
Photo: Unsplash
On this page
Your online store goes down for 2 hours on a Saturday. Was that bad luck, or a design decision you did not know you had made?
Usually it is the second. Somewhere there was a single server, a single database or a single network link that everything depended on, and when it failed, everything failed. High availability (HA) is the practice of designing so that no single failure can take you offline, and of deciding how much that protection is worth paying for.
What high availability means
AWS’s Well-Architected Framework defines availability as the percentage of time a workload is available for use, meaning it performs its agreed function successfully when required. High availability is the design goal of keeping that percentage very high, even when hardware breaks, software crashes or a data center loses power.
NIST’s glossary describes high availability more narrowly, as a failover feature that keeps a service available when a device or component is interrupted. Both views point to the same idea: you assume parts will fail and design so the service survives anyway.
Availability is usually expressed in “nines”:
- 99.9% (“3 nines”)
- 99.99% (“4 nines”)
- 99.999% (“5 nines”)
What each nine allows
The AWS reliability guidance lists common availability goals, the maximum downtime each allows per year, and the kinds of applications typically aimed at each tier:
| Availability | Maximum downtime per year | Example application types (per AWS) |
|---|---|---|
| 99% | 3 days 15 hours | Batch processing, data extraction and load jobs |
| 99.9% | 8 hours 45 minutes | Internal tools such as project tracking |
| 99.95% | 4 hours 22 minutes | Online commerce, point of sale |
| 99.99% | 52 minutes | Video delivery, broadcast workloads |
| 99.999% | 5 minutes | ATM transactions, telecommunications |
Notice the pattern. Moving from 99.9% to 99.99% cuts allowed downtime from almost 9 hours a year to under an hour. That is a 10-times smaller margin for error, and it usually needs a very different design.
AWS also advises against excluding planned maintenance from your availability calculation, because users still want the service during those windows.
The building blocks: redundancy and failover
Remove single points of failure
A single point of failure is any component whose loss takes the whole service down: 1 web server, 1 database, 1 internet connection, 1 DNS provider, or 1 person who knows the password. HA design starts by listing these and removing the ones that matter.
Add redundancy
Redundancy means running more than 1 copy of each critical component. Microsoft’s Azure Well-Architected guidance defines it as implementing multiple identical instances of a workload component, and recommends adding it at different layers, especially for critical flows:
- Compute: several servers or containers behind a load balancer, with no important state stored on any single one.
- Data: database replicas that can take over if the primary fails.
- Network: redundant load balancers, connections and DNS.
Microsoft also warns about spare capacity. If 2 servers each run at 60% and one fails, the survivor would need to run at 120%. Redundancy only works if the remaining parts can carry the full load.
Fail over automatically
Failover is switching traffic from a failed component to a healthy one. Health checks detect the failure, and load balancers, DNS or database tools route around it. Manual failover works, but it adds the time it takes someone to notice, wake up and act.
Microsoft describes 2 broad patterns:
- Active-active: all copies serve traffic at the same time. Failover is nearly instant, but costs and complexity are higher, especially keeping data consistent.
- Active-passive: a primary handles traffic while a standby waits. It is cheaper, but recovery takes longer. A “warm” standby runs at minimum size and scales up; a “cold” standby has its compute stopped until needed.
Separate failure domains
Redundant parts in the same rack, building or power circuit can fail together. Cloud providers address this with isolated locations. AWS describes Availability Zones as multiple isolated locations within each Region and notes that spreading instances across zones protects applications from the failure of a single location. Azure availability zones work in a similar way. For protection against a whole-region event, you add a second region, at a higher cost.
Key takeaway: High availability comes from 3 things working together: redundant copies of every critical component, placement in separate failure domains such as different availability zones, and automatic failover that switches traffic without waiting for a person.
The math: dependencies and redundancy
AWS’s reliability guidance shows 2 calculations every HA design should consider.
Hard dependencies multiply. If your service is designed for 99.99% and depends on 2 other independent systems that are each 99.99%, the theoretical availability of the whole is about 99.97%: 99.99% x 99.99% x 99.99%. Every service you rely on in series pulls your number down.
Redundancy adds nines. If you run 2 independent components that are each 99.9% available, and either one can do the job, the theoretical availability rises to 99.9999%, because both must fail at once for you to go down. The catch is the word “independent.” Copies that share a power supply, a configuration mistake or a bad software release can fail together.
You can also estimate availability from failure history using mean time between failures (MTBF) and mean time to recover (MTTR): availability is roughly MTBF / (MTBF + MTTR). AWS’s example: failures every 150 days with 1 hour to recover gives about 99.97%. This shows why faster recovery is as valuable as fewer failures.
The cost of each additional nine
AWS is direct about this: designing for higher availability typically increases cost, so identify your true needs before you design. The extra cost comes from several places:
| Target | Typical design | Relative cost and effort |
|---|---|---|
| 99% to 99.9% | Single location with backups, managed services, good monitoring, quick manual recovery | Low: mostly good practice |
| 99.9% to 99.95% | Multiple servers behind a load balancer, database replica, automated failover in 1 region | Moderate: roughly doubled infrastructure for critical parts |
| 99.99% | Redundancy across availability zones, automated failover everywhere, tested recovery, careful releases | High: more infrastructure plus serious engineering and testing |
| 99.999% | Multi-region active-active, purpose-built components, extensive automation and testing | Very high: specialist teams, slower change |
AWS notes that very high targets also slow innovation, because every deployment, configuration change and data migration must meet the same bar. You may also have fewer choices of dependencies, since only some services are built and tested to that level.
The practical lesson is to set availability per service, not for the whole company. Checkout might justify 99.95% across zones. An internal reporting tool might be fine at 99.5%.
High availability vs disaster recovery and fault tolerance
These terms overlap but mean different things:
- High availability keeps a service running through common failures, usually with little or no visible interruption.
- Fault tolerance is a stricter goal: the service keeps running with no interruption at all when a component fails, typically through fully duplicated hardware or systems.
- Disaster recovery (DR) restores service after a major event, such as a region outage, ransomware or data corruption, measured by how long recovery takes and how much data you can afford to lose.
HA does not replace backups. If corrupted data or a bad deletion replicates instantly to every copy, redundancy faithfully spreads the damage. You still need tested, separate backups.
Where to start
Use this 7-step plan to design for high availability without overspending:
- Set a target per service based on what downtime actually costs. Express it as an SLO; our guide to SLA vs SLO vs SLI shows how.
- Map dependencies for each critical service, including third-party APIs, DNS, identity and payment providers.
- List single points of failure and rank them by impact.
- Prefer managed services with built-in redundancy, such as managed databases with automatic failover and zone-redundant load balancers. Microsoft’s guidance recommends this to reduce operational burden.
- Spread critical parts across at least 2 availability zones and keep application servers stateless. Containers and orchestrators make this easier.
- Define everything as code so you can rebuild consistently in another zone or region. See our guide to infrastructure as code.
- Test failover regularly. Turn off a server or zone in a controlled exercise. A failover that has never been tested is a hope, not a plan.
Then watch the bill. Redundancy roughly doubles some costs by design, and idle standby capacity adds up. Our guide to FinOps and cloud cost optimization helps keep that in check. For the operating habits that keep HA working over time, see site reliability engineering.
The bottom line
High availability is the discipline of assuming things will break and designing so your service keeps running anyway. Redundant components, separate failure domains and automatic failover are the core tools. Each extra nine buys less downtime at a steeply rising price, so choose targets service by service based on real business impact, test your failover, and keep backups for the failures redundancy cannot fix.
Sources
- AWS Well-Architected Reliability Pillar: Availability — definition, downtime per tier, dependency and redundancy math, MTBF/MTTR, cost of higher availability
- Microsoft Azure Well-Architected Framework: Designing for redundancy — redundancy layers, active-active vs active-passive, spare capacity and cost trade-offs
- AWS EC2 User Guide: Regions and Zones — isolated Availability Zones and multi-zone deployment
- NIST CSRC Glossary: High availability — NIST definition of high availability as a failover capability
Frequently asked questions
What is considered high availability?
There is no single official threshold, but high availability commonly refers to targets of 99.9% or higher, often 99.95% or 99.99%, for critical services. What counts as "high" depends on the business: 99.9% allows almost 9 hours of downtime a year, while 99.99% allows about 52 minutes. Set the target by what downtime actually costs you.
What is the difference between high availability and disaster recovery?
High availability keeps a service running through everyday failures, such as a crashed server or a lost availability zone, usually with little interruption. Disaster recovery restores service after a major event, such as a region outage, ransomware or data corruption. Most businesses need both: redundancy for common failures and tested backups and recovery plans for rare, severe ones.
How much does high availability cost?
Costs depend on the target and architecture, so there is no standard price. As a rule, moving from a single location to redundant components roughly doubles the infrastructure for those components, and each additional nine adds more infrastructure, automation, testing and staff time. AWS's guidance warns that higher availability typically increases cost, so define your real needs first.
Is 99.9% uptime good?
For many business applications, yes. A 99.9% target allows about 8 hours 45 minutes of downtime a year, or roughly 43 minutes a month. AWS lists internal tools such as project tracking at this tier. AWS places online commerce and point of sale at 99.95%, because every hour of downtime for those systems directly costs sales.
What is a single point of failure?
A single point of failure is any component whose failure stops the whole service, such as 1 database server, 1 internet connection or 1 DNS provider. People and processes can be single points too, like the only administrator with access. High availability design starts by finding these and adding redundancy where the impact justifies the cost.
Do I need multiple cloud regions for high availability?
Usually not at first. Spreading resources across multiple availability zones in 1 region protects against the failure of a single data center location and is enough for many workloads. Multiple regions protect against rarer region-wide events but add significant cost, latency and data consistency challenges. Reserve multi-region designs for services where a regional outage would be unacceptable.
What is the difference between active-active and active-passive?
In active-active, all copies of a system serve traffic at the same time, so losing one causes almost no interruption, but it costs more and makes data consistency harder. In active-passive, a primary serves traffic while a standby waits to take over. It is cheaper but recovery takes longer, especially if the standby must start or scale up first.
Was this guide useful
No reviews yet. Share your experience and help other readers.
Write a review
Manishdai
Manishdai writes about the technology that is reshaping every industry — from AI agents and cloud platforms to healthtech, fintech and the IT companies building it all across the United States.
manishdai.com