Remediate Compute Incidents With Controlled Actions
Understand how to respond to EC2 instance failures through controlled remediation actions such as reboot, stop-start, terminate, and replace. This lesson guides you in selecting the safest recovery method, executing it with auditability, and confirming successful service restoration. You will learn to use monitoring alarms, automation tools, and evidence collection to manage incidents effectively while preserving critical data for post-incident analysis.
A page fires for a high error rate, and in the same minute, a CloudWatch alarm called StatusCheckFailed flips to ALARM for one EC2 instance in a fleet. Requests are still arriving, the load balancer is routing, but one target is unhealthy, and error rates are rising. The fastest safe recovery starts by tracing the alarm into a controlled action that changes instance state on purpose, then verifying the specific state change actually happened.
Controlled actions matter because remediation can destroy evidence and data. A reboot can clear a stuck kernel without losing the instance disk, while a stop and start can move the instance to new hardware and change its public IP. Terminate and replace can restore capacity quickly in an immutable fleet, but it discards everything on the instance that was never persisted off the host.
Since evidence needs to be forced at each step, the incident is sequenced into detect, decide, execute, confirm state change, and confirm service recovery. In an Auto Scaling group behind a load balancer, replace is meaningful because the group can terminate an unhealthy instance, launch a new one, and then register the new instance as healthy before traffic fully returns. Each hop in that sequence maps to an artifact that later serves as proof, including alarm history, Auto Scaling activity, and EC2 instance state.
Use the step through to connect each hop to the artifact you will later use as proof, including alarm history, Auto Scaling activity, and EC2 ...
The pipeline ...