3.4 Reliability Improvement
Official task mapping
SAP-C02 task 3.4: Replication and quotas knowledge; single-point removal and self-healing design. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.
Prerequisites
Review load balancing, Auto Scaling and recovery design. Be able to explain the relevant failure boundary and access/cost model before choosing a service.
Find actual failure boundaries
Inventory single points in compute, data, DNS, identity, connectivity and operational ownership. Two instances are not independent if they share one AZ, one fragile dependency or insufficient surviving capacity. Estimate failover load and quotas before declaring redundancy.
ALB provides application-layer routing; NLB serves appropriate transport-layer needs and static-address patterns; GWLB integrates network appliances. If an application needs ALB features plus fixed ingress addresses, supported NLB-to-ALB or Global Accelerator designs may work with additional cost, health and operational constraints. WAF support is broader than only ALB/CloudFront.
Auto Scaling health replacement, predictive scaling and warm pools serve different purposes. Warm pools can reduce startup latency under supported configurations but still need readiness checks and incur associated costs. Self-healing should not repeatedly replace healthy instances during a shared downstream outage.
Single-point remediation and load balancing
| Weak point | Candidate remediation | Validate |
|---|---|---|
| One application instance | Multi-AZ ASG and suitable LB | Statelessness, health and surviving capacity |
| Single-AZ database | Supported Multi-AZ/recovery design | Connection retry, failover time and backup |
| One hybrid circuit | Diverse circuits/locations or VPN backup | Routes, failover throughput and provider independence |
| One egress/identity dependency | Redundant supported architecture | Reachability and regional failure behavior |
ALB offers HTTP host/path routing; NLB offers supported transport protocols and address patterns; GWLB steers traffic through compatible appliances using GENEVE. Their health checks, cross-zone behavior and charges differ. Static ingress with ALB features is a composed design, not a claim that an ALB’s own resolved IPs become fixed.
Predictive scaling anticipates eligible recurring load; reactive policies handle measured demand. Warm pools can retain supported stopped/running/hibernated capacity depending on configuration. Readiness still requires configuration, application health and permissions.
With six workers each serving 100 requests/second across three AZs, losing one AZ leaves only 400 requests/second. If demand is 500, two AZs are not enough without scale-out/headroom. Check launch latency and quota/capacity availability instead of labeling the initial six workers “highly available.”
Scenario and rationale
A service survives instance loss but fails during an AZ outage because its NAT path and database are single-AZ. Add appropriate multi-AZ data/egress paths and test surviving capacity. Preserve ALB HTTP routing while evaluating a supported static-ingress fronting design for a partner allowlist.
Reject only increasing the ASG minimum: it cannot repair the shared NAT/database dependency. Reject “static IP means ALB is impossible”: fronting is an option, although complexity and charges must be justified.
Practice drill
Draw the dependency graph and remove each node/AZ in turn. Calculate whether remaining workers meet demand, including database connections and network limits. Specify failure alarms, recovery ownership, health-check semantics and a bounded game-day plan. Document stop conditions before any fault injection.
References
Return to Domain 3. The drill is proposed study work, not a claim of a completed deployment.