Design Resilient Architectures
High Availability and Failure Isolation
CoreDesign for instance, Availability Zone, dependency, and quota failures with automation and visibility.
Aligned to the current SAA-C03 exam guide, verified August 16, 2026.
Why this matters
Availability is meaningful only relative to a failure boundary. The architect must identify what may fail, distribute independent capacity beyond that boundary, automate replacement or failover, and monitor signals that reveal whether the design is actually meeting the business requirement.
Must Know
- An instance replacement design survives instance failure; a Multi-AZ design survives an AZ failure; a multi-Region design addresses a Region boundary. Do not pay for a broader boundary unless required.
- Place redundant application capacity in multiple AZs behind health-aware traffic distribution and allow Auto Scaling to replace unhealthy capacity.
- Remove single points in state, networking, and dependencies—not only in compute. Each tier needs a failure and recovery story.
- Health checks must measure useful service health. Shallow reachability can route users to a target whose critical dependency is broken.
- CloudWatch metrics, alarms, and logs reveal workload behavior; X-Ray traces distributed requests. Choose a signal tied to the business requirement.
- Immutable infrastructure replaces known-good units instead of repairing drifting servers in place; CloudFormation makes infrastructure repeatable.
- Standby environments need quotas, capacity, dependencies, secrets, and routes ready for the intended recovery plan. A template alone does not reserve capacity.
- Throttling and dependency failures require bounded retries, backoff, jitter, queues, and load shedding to avoid retry storms.
Compare and Distinguish
- Multi-AZ vs multi-Region: Multi-AZ wins for AZ resilience with lower latency/complexity; multi-Region wins only when Region failure, geography, or residency requires it.
- High availability vs fault tolerance: HA restores or reroutes quickly; fault-tolerant designs continue through specified failures with little interruption and usually more cost.
- Load balancing vs Route 53 failover: a load balancer handles target health within its scope; Route 53 can steer DNS among endpoints, including across Regions.
- CloudWatch vs X-Ray vs CloudTrail: operational telemetry, distributed request traces, and AWS API activity answer different questions.
- Mutable repair vs immutable replacement: repair may preserve legacy state; replacement reduces drift and improves repeatability.
Scenario examples
- Scenario: A production web tier must survive one AZ. Think: deploy healthy capacity in multiple AZs behind a load balancer and ensure state is not local.
- Scenario: One dependency is throttling and retries amplify traffic. Think: bound exponential backoff with jitter, buffer where possible, and scale from the real constraint.
- Scenario: A standby Region exists only as a template. Think: verify quotas, data copies, dependencies, routing, and capacity activation against RTO.
- Scenario: Health checks pass while checkout fails. Think: use a dependency-aware health signal or business metric, not only port reachability.
Exam traps
- Multiple instances in one AZ do not provide AZ resilience.
- A backup does not keep an application available during failure.
- Route 53 health checks do not repair an unhealthy endpoint.
- Auto Scaling cannot replace a hidden single point in a database, NAT path, or dependency.
- A CloudFormation template does not guarantee capacity or current data in a standby Region.
- More retries without backoff can worsen an outage.
Key takeaways
- Name the failure boundary before choosing redundancy.
- Spread independent capacity beyond that boundary and automate health-based recovery.
- Use business-relevant signals and test failure behavior.
- Prepare quotas and dependencies before they are needed.
- Prefer replaceable infrastructure when legacy constraints do not require in-place state.
How it works
- Health checks remove unhealthy targets or change traffic routing according to the service scope.
- Auto Scaling reconciles desired capacity and replaces failed instances.
- Infrastructure templates reproduce known configuration; deployment automation creates new units consistently.
- Metrics and traces connect resource behavior to request paths and business outcomes.
When to use it
- Use multi-AZ redundancy for common production AZ-failure requirements.
- Use multi-Region only for Region-level continuity, geographic, or residency requirements.
- Use queues and rate control when downstream dependencies need backpressure.
- Use immutable replacement to reduce configuration drift and speed repeatable recovery.
Security and governance implications
- Grant monitoring and automation roles only required permissions.
- Protect templates, images, and deployment pipelines because they define recovered infrastructure.
- Avoid health endpoints that disclose sensitive dependency detail.
- Include security services and key access in standby recovery dependencies.
Operational and diagnostic signals
- If failover does not occur, inspect the health signal, threshold, routing scope, and whether healthy capacity exists.
- If failover occurs but service remains broken, trace shared dependencies and data readiness.
- If recovery automation is throttled, inspect quotas and retry/concurrency behavior before adding more retries.
- If targets repeatedly replace, separate startup delay, bad image, health-check mismatch, and real application failure.
More detail
- Availability design is end-to-end: DNS, edge, networking, compute, data, and dependencies must all survive or recover from the stated event.
- Managed services can reduce component administration, but architects still choose topology, capacity mode, client retry behavior, and recovery targets.
- Distributed systems should degrade safely under overload instead of allowing unbounded concurrency to collapse a dependency.
Ready for the quiz?
- What must change when the failure boundary moves from instance to AZ to Region?
- Why can a multi-AZ web tier still have one point of failure?
- When does Route 53 complement a load balancer?
- Which metric proves user-facing availability?
- Why must standby quotas be checked in advance?
Related objectives
- D2.2.K1
- D2.2.K2
- D2.2.K3
- D2.2.K5
- D2.2.K6
- D2.2.K7
- D2.2.K8
- D2.2.K10
- D2.2.K12
- D2.2.S1
- D2.2.S2
- D2.2.S3
- D2.2.S4
- D2.2.S8