Design business continuity solutions
High-Availability Design for Compute and Data
CoreDesign zone, region, replica, and client-routing patterns that remove single points of failure for compute and data workloads.
Aligned to the current AZ-305 study guide, skills measured as of April 17, 2026, verified August 25, 2026.
Why this matters
Availability is an end-to-end property: redundant resources provide little value when state, routing, identity, or capacity remains a single point of failure.
Must Know
- Match zone or multi-region redundancy to the size of failure the workload must withstand.
- Recognize that managed zone redundancy shifts more orchestration to the platform, while zonal resources require explicit placement and recovery logic.
- Choose active-active or active-passive only after evaluating recovery time, utilization, consistency, and conflict-handling trade-offs.
- Remove single points across routing, compute, state, data, identity, detection, and capacity—not merely within one service tier.
Compare and Distinguish
- Availability zones isolate datacenter-scale failures within a region; multi-region designs address regional failure with greater cost and consistency complexity.
- Zone-redundant managed services reduce customer orchestration; zonal resources require explicit placement and failover design.
- Active-active can improve utilization and recovery time but increases data and conflict complexity; active-passive can simplify consistency at the cost of standby and failover behavior.
Scenario examples
- Scenario: A regional web tier must tolerate one zone loss. Think: spread stateless instances across zones behind a zone-resilient ingress.
- Scenario: A write database needs automated regional endpoint failover. Think: choose a database failover feature and design retry behavior.
- Scenario: Object data must survive a zone loss without changing endpoints. Think: select zone-redundant storage in a supported region.
Exam traps
- Autoscale is not a substitute for fault-domain diversity.
- A globally routed front end cannot recover a single-region database by itself.
- Redundant data does not make a stateful application stateless.
Key takeaways
- Trace every dependency through the intended failure.
- Match redundancy scope to the availability target.
- Design detection, routing, state, capacity, and recovery together.
How it works
- A health-aware load balancer probes instances and stops directing new traffic to unhealthy targets, while application retry logic handles requests or connections interrupted during the failure.
- A zonal virtual machine is pinned to one zone, so zone resilience comes from deploying separate instances across zones and arranging customer-managed traffic routing, state replication, failover, and recovery.
- A zone-redundant managed service distributes service components or data across zones and keeps a stable service endpoint while the platform handles supported in-region failover behavior.
Objects and administrative surfaces
- Compute placement, load balancing, health probes, autoscale, state externalization, data replication, capacity reservation, and failure detection all affect availability.
- Relational services expose replicas, zone redundancy, geo-replication, and failover groups with distinct read/write behavior.
- Storage redundancy protects data copies but application recovery still depends on endpoint and failover behavior.
When to use it
- Distribute stateless compute across availability zones when an in-region zone failure is the design target.
- Use zone-redundant managed data services when the platform can keep a stable endpoint through a supported zone failure.
- Build independent regional stacks with health-based global routing when the application must survive total regional loss.
Security and governance implications
- Replicate identities, secrets, keys, certificates, and security policy deliberately so failover does not bypass controls or lose authorization.
- Keep failover endpoints protected and test that emergency capacity preserves the intended segmentation and least privilege.
How to validate and revise the design
- During a zone test, verify health probes, routing, remaining capacity, state access, connection retry, and dependency placement.
- During a region test, trace DNS or global routing, write authority, replication lag, secrets, identity, and client reconnection.
More detail
- Logical zone numbers can map to different physical zones across subscriptions, so cross-subscription component placement must not assume that matching zone labels provide physical colocation or separation.
- Autoscale reacts to demand but does not guarantee spare capacity during a large failure; the design must ensure healthy zones or regions can carry the required load after redundancy is lost.
- Regional data failover can change write authority or endpoint resolution and terminate in-flight work, so clients still need retry, reconnection, and consistency handling even when failover is automatic.
Ready for the quiz?
- Must the workload survive an instance, zone, or entire regional failure?
- Which routing, compute, state, database, identity, and capacity dependency remains a single point of failure?
- Does the active-active or active-passive choice meet consistency, utilization, failover, and conflict-handling constraints?
Related objectives
- D3.2.S1 — Recommend a high availability solution for compute
- D3.2.S2 — Recommend a high availability solution for relational data
- D3.2.S3 — Recommend a high availability solution for semi-structured and unstructured data