Availability, Resilience, and Disaster Recovery Promises
Goal
Separate related reliability promises so teams can specify, design, and test them without using the terms interchangeably.
The Short Version
Availability describes whether a service is usable when needed. Resilience describes how it withstands and adapts to faults. Disaster recovery describes how it restores acceptable service after an event exceeds normal resilience. These ideas reinforce one another, but each requires different evidence.
An availability percentage alone is incomplete. It needs a measurement boundary, time window, excluded conditions, and definition of "usable." A monthly uptime number can hide a severe outage during the busiest hour or repeated failures of one critical customer journey.
Three Different Questions
| Concern | Question | Typical evidence |
|---|---|---|
| Availability | Can users complete the promised flow now? | Flow success, latency, and error objectives |
| Resilience | What happens when a dependency or component fails? | Fault tests, isolation, degradation, and self-healing |
| Disaster recovery | How is service restored after a major disruption? | Recovery targets, runbooks, drills, and reconciliation |
Scope each promise to a business flow. "The platform is highly available" is vague; "authorized customers can submit an order within the stated latency target" is measurable. Also state what happens under overload and partial failure. A fast error may be available from an infrastructure perspective but not useful to a customer.
Architecture Meaning
Redundancy can improve availability only when replicas do not share the same failure mode and traffic can reach a healthy instance. Resilience also needs application behavior: timeouts, workload shedding, idempotency, bounded queues, and graceful degradation. Disaster recovery adds another operating mode, usually involving restored data, alternate capacity, decision authority, communications, and validation.
Provider regions and availability zones are implementation lenses, not complete promises. AWS and Azure both offer fault-isolation constructs and managed failover features, but workload teams still own dependency analysis, configuration, application behavior, and recovery rehearsal.
Example: Available Front End, Failed Checkout
A retailer runs web servers across fault-isolated locations. The website loads, so an infrastructure uptime check remains green. Its single payment integration fails, however, and customers cannot place orders. The honest reliability model measures checkout, isolates the payment call, and defines a degraded state. A separate regional recovery plan covers a broader event, including data recovery and traffic switching.
Common Mistakes
Calling redundancy resilience without proving independent failure behavior.
Publishing an availability target without a user flow or measurement rule.
Treating ordinary component failover and disaster recovery as the same procedure.
Assuming a provider service commitment becomes the workload's end-to-end promise.
If Someone Asks You
Availability is the user-facing service level, resilience is the system's behavior during faults, and disaster recovery restores service after normal protections are exceeded. Define and test all three at the workload-flow boundary.
What You Should Remember
Reliability promises are credible only when their scope, measurement, failure behavior, and recovery evidence are explicit.
Questions to Check Your Understanding
Why does component availability not determine workload availability?
What evidence distinguishes resilience from redundancy?
Which conditions must an availability objective define?
Further Study
AWS Well-Architected Reliability Pillar - Review official guidance for designing and operating reliable AWS workloads.