Failures are unavoidable.
Hardware fails, software contains bugs, people make mistakes, networks become unavailable, and entire Azure regions can experience disruption.
So the first question you need to ask as an architect is: what should happen when something breaks?
What are High Availability and Disaster Recovery?
High Availability (HA) keeps a workload running during expected failures. For example, two application instances across availability zones can allow the application to continue running when one zone becomes unavailable.
Disaster Recovery (DR) restores a service after a large disruption.
For example, an application might fail over to another Azure region after the primary region becomes unavailable.
High Availability and Disaster Recovery are related, but they operate at different failure scopes.
If a question describes a single VM, node, or zone failure, the answer involves High Availability. If it describes an entire region going down, the answer involves Disaster Recovery. The key difference is the scope of the failure.
What is Recovery Time Objective (RTO)?
The Recovery Time Objective (RTO) is the maximum acceptable amount of time that a workload can remain unavailable.
If your business sets an RTO of one hour, you need to have the service back online within one hour. No exceptions.
A low RTO normally requires a prepared recovery environment, automation, and current replicated data.
If your recovery plan involves an engineer manually rebuilding every component described in a Word document, you’re probably not going to hit that one-hour target.
A low RTO (a few minutes instead of a few hours) almost always requires a pre-built recovery environment with automated failover. If an answer choice involves a manual process, it cannot satisfy a low RTO.
What is Recovery Point Objective (RPO)?
The Recovery Point Objective (RPO) is the maximum acceptable amount of data loss measured in time.
If the RPO is five minutes, the recovered system must not normally lose more than five minutes of data.
A backup that runs once every 24 hours cannot satisfy a five-minute RPO.
The RPO directly influences several design decisions:
- Backup frequency: If your RPO is 5 minutes, a backup that runs every 24 hours won’t cut it. You need continuous backups or transaction log shipping.
- Replication technology: A tight RPO often requires synchronous data replication, not just backups on a set schedule.
- Database configuration: You may need to enable point-in-time restore, transaction log shipping, or geo-replication at the database level.
- Storage design: The storage layer must support the replication speed and frequency the RPO demands. A storage account that only replicates data to another region based on a schedule may not be frequent enough to meet the RPO.
unknown nodeunknown nodeunknown node
Real World Example
Imagine your company runs an e-commerce application in East US. The business has determined:
- The site can be down for at most 30 minutes during a regional outage.
- The business can tolerate losing at most 5 minutes of order data.
The first requirement gives you an RTO of 30 minutes, while the second one gives you an RPO of 5 minutes.
To satisfy the RTO, you can deploy the application across Availability Zones in East US (to achieve High Availability), and set up geo-replication to West US with an automated failover plan (to achieve Disaster Recovery).
To satisfy the RPO, you can configure the database with geo-replicated transactions that sync every few seconds, rather than relying on a nightly backup.
What to remember for your exam
- High Availability keeps a workload running during expected failures
- Disaster Recovery restores a system after a long disruption
- RTO is the maximum acceptable downtime
- RPO is the maximum acceptable data loss measured in time
- Backup frequency must satisfy the RPO
- Recovery procedures and automation affect the RTO
What’s next?
In the next lesson, you will learn how availability sets, availability zones, scale sets, and platform services provide highly available compute.
