Reliability and Business Continuity
Health Checks, Multi-AZ Capacity, and Fault-Tolerant Operation
CoreBuild and troubleshoot layered availability using healthy capacity, load-balancer target checks, Route 53 endpoint health, replacement, and managed Multi-AZ failover.
Aligned to AWS Certified CloudOps Engineer - Associate (SOA-C03) Version 1.1, verified August 24, 2026.
Why this matters
A load balancer, health check, Auto Scaling group, or DNS record cannot create healthy capacity by itself. Availability depends on correctly connected layers and independent failure zones.
Must Know
- ELB target health depends on the configured protocol, port, path, expected response, thresholds, target listener, and allowed network path.
- Place healthy service capacity across Availability Zones and preserve enough per-zone capacity; an ELB cannot distribute to capacity that was never deployed.
- Route 53 health checks produce endpoint health evidence. Failover records must associate and evaluate the appropriate health state.
- Stateless compute resilience combines multi-AZ placement, health-based routing, and replacement of failed capacity.
- RDS Multi-AZ maintains a managed availability topology and failover path; a read replica primarily serves read scaling and has a different promotion model.
- Elasticity handles demand variation; fault tolerance handles component or zone failure. Some workloads require both.
Compare and Distinguish
- ELB target health governs targets behind the load balancer; Route 53 health and routing govern DNS answers.
- Multi-AZ addresses an Availability Zone or host failure; Multi-Region DR addresses a wider recovery boundary.
- Auto Scaling replaces capacity; load balancing distributes requests; neither alone proves the application is healthy.
- RDS Multi-AZ availability and read-replica scaling solve different operational needs.
Scenario examples
- Scenario: A target answers on the application URL but fails the configured health path. Correct the health path or target response rather than lowering DNS TTL.
- Scenario: An AZ fails and all registered targets disappear. Restore multi-AZ capacity and health before changing outer DNS routing.
- Scenario: A database must fail over after primary host loss. Use the appropriate RDS Multi-AZ deployment and test client reconnection.
Exam traps
- Do not infer target health from one manual request to a different path.
- Do not expect a routing policy to generate health evidence automatically.
- Do not call one-AZ Auto Scaling fault tolerant.
- Do not treat a read replica as identical to a synchronous standby.
Key takeaways
- Healthy capacity is the foundation of availability.
- Measure health at the layer that routes traffic.
- Distribute capacity before relying on failover.
- Test client and dependency behavior during failover.
How it works
- Confirm that sufficient service capacity exists in each intended Availability Zone.
- Test the configured health endpoint and trace its response through target networking and load-balancer evaluation.
- Validate DNS or database failover from a client, including reconnection, cached names, and dependency health.
When to use it
- Use Elastic Load Balancing target health to control which registered targets receive traffic; use Route 53 health evaluation and routing to control DNS answers.
- Design Multi-AZ capacity for host or Availability Zone failure; select a Multi-Region disaster recovery pattern when the recovery boundary extends beyond one Region.
- Use Amazon EC2 Auto Scaling to replace or add capacity and load balancing to distribute requests, then verify application health separately.
- Choose Amazon RDS Multi-AZ for managed availability and failover; use read replicas when the requirement is read scaling.
Security and governance implications
- Expose only the minimum health-check path and network access needed for the component performing the check.
- Keep failover and replacement permissions scoped while retaining health and change evidence for review.
Failure signals and diagnosis
- Start at the innermost unhealthy target, then move outward to load balancing and DNS.
- Verify both health-check reachability and the application response.
- During failover testing, inspect connection reuse, DNS caching, replacement capacity, and dependency health.
More detail
- Know how target protocol, port, path, response, thresholds, listener, and network access determine ELB target health.
- Relate deployed capacity in each Availability Zone to load-balancer distribution and Auto Scaling replacement behavior.
- Use Route 53 health for DNS routing decisions and RDS Multi-AZ for the supported managed database failover boundary.
Ready for the quiz?
- Targets are unhealthy behind a load balancer even though the application responds on another URL. Which health-check settings and network evidence should you compare?
- Why does an RDS read replica not satisfy the same requirement as an RDS Multi-AZ deployment?
- What evidence distinguishes an unhealthy ELB target from a healthy target that Route 53 has stopped returning?
Related objectives
- D2.2 — Task 2.2: Implement highly available and resilient environments.
- 2.2.1 — Configure and troubleshoot Elastic Load Balancing (ELB) and Amazon Route 53 health checks.
- 2.2.2 — Configure fault-tolerant systems (for example, Multi-AZ deployments).