A regional logistics firm runs 40 EC2 route-optimization workers in an Auto Scaling group behind a Network Load Balancer. Hung processes serve stale routes, impaired instances linger for 30 minutes, and in-flight jobs are killed during scale-in. It needs OS and app failure detection with replacement in under 3 minutes plus graceful draining. Which automated failure recovery design using health checks and replacement best meets these recovery requirements?

The correct design succeeds because it unites both signal planes: EC2 status checks catch OS/hardware impairment, ELB checks via the Network Load Balancer target group catch hung processes serving stale routes, the Auto Scaling health-check type using both triggers termination and replacement, a short grace period avoids boot churn yet allows replacement in under three minutes, and deregistration delay preserves targets for draining so in-flight jobs finish before termination. The EC2-status-checks-only design fails on application awareness because status checks pass while the worker is hung, so stale routes persist and impaired nodes linger despite proper draining. The terminate-connections-immediately design fails on graceful scale-in because instant removal on deregistration abandons in-flight jobs, violating draining despite correct detection. The lifecycle-hook-holding design fails on time-bound recovery because holding impaired nodes for inspection keeps bad capacity in service past the three-minute objective despite correct detection and draining. An exam caveat is to separate grace period, delaying health evaluation after launch, from deregistration delay, delaying connection removal after deregistration, from interval-times-threshold, setting detection speed. As a practical check, confirm in staging that threshold times interval plus deregistration delay stays under the objective, NLB checks hit the real app port and calculation path, and CloudTrail plus load balancer logs show completed requests on scale-in.