High availability and disaster recovery in the cloud
In short: High availability keeps a service running through common failures, usually by spreading it across availability zones. Disaster recovery restores service after a major event, often in another region. You pick a strategy from your recovery time and recovery point objectives, and you must test it.
Two related goals
Both start with business requirements, expressed as two numbers:
- Recovery time objective (RTO): how long the service may be down. "We must be back within 4 hours."
- Recovery point objective (RPO): how much data you may lose, measured in time. "We can lose at most 15 minutes of orders."
Lower numbers cost more. Agree them with the business owner per workload, not one value for everything. For availability targets such as 99.9 percent and what they mean in minutes, see nines and SLAs.
High availability in practice
Within a region, use at least two availability zones:
- Run instances or containers in an auto scaling group or scale set across zones, behind a load balancer with health checks.
- Use managed databases with a synchronous standby in another zone, such as Amazon RDS Multi-AZ or Azure SQL zone-redundant configuration.
- Choose zone-redundant storage and gateways; one NAT gateway in one zone is a hidden single point of failure.
- Make application servers stateless so any instance can take any request.
Disaster recovery strategies
| Strategy | What runs in the DR region | Typical RTO / RPO |
|---|---|---|
| Backup and restore | Only backups | Hours or more / last backup |
| Pilot light | Replicated data, core services off or minimal | Tens of minutes to hours / minutes |
| Warm standby | A scaled-down working copy | Minutes / seconds to minutes |
| Multi-site active-active | Full capacity serving users | Near zero / near zero |
Infrastructure as code helps every strategy, because you can rebuild networks and servers in a new region from templates instead of from memory.
Backups and testing
Replication is not a backup: if data is deleted or encrypted by ransomware, the damage replicates too. Follow the 3-2-1 idea (three copies, two media types, one off-site), and in cloud terms add:
- Use a backup service (AWS Backup, Azure Backup) with policies, not ad-hoc snapshots.
- Copy backups to another region and, ideally, another account with separate credentials.
- Make backups immutable with vault lock or Object Lock features.
- Encrypt backups and control who can restore or delete them.
- Test restores regularly and run full failover drills at least yearly; measure the real RTO and RPO.
Tip: a DR plan that has never been tested is a guess. Start with a tabletop walk-through, then a restore test, then a planned failover.
Practice
A shop can lose at most 5 minutes of orders and must be back within 30 minutes. Which DR strategy fits best?
Why is database replication not enough on its own?
What is the difference between RTO and RPO?
Key takeaways
- HA survives common failures; DR recovers from major disasters.
- Set RTO and RPO per workload with the business.
- Use multiple zones, health checks and stateless servers for HA.
- DR strategies range from backup and restore to active-active.
- Keep immutable, cross-account backups and test restores.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.