Container Incident Drill
Explore how to manage container incidents by analyzing evidence from AWS ECR, ECS, EKS, and CloudWatch logs and metrics. Learn to identify root causes of service latency, container restarts, and image pull failures, and take least-risk remediation actions. This lesson helps develop a reliable, audit-friendly incident response sequence to maintain service stability under pressure.
This lesson works through a single incident scenario end to end, using the same evidence sources covered in earlier lessons: ECR, ECS, or EKS events, and CloudWatch logs and metrics. The goal is to practice moving through that evidence in the right order, under the same pressure and ambiguity a real incident brings, until the sequence becomes automatic rather than something that has to be worked through from scratch each time.
Here's the scenario. Service latency is climbing, container tasks are restarting on their own, and the error logs show intermittent image pull failures. Three symptoms, all at once, and no clear story yet for which one is the cause.
The win condition here is checking evidence in an order that separates image versus capacity versus networking versus permissions quickly, then taking a least-risk action and proving recovery with signals.
The drill uses three fixed evidence sources so decisions stay auditable under pressure:
Amazon ECR answers whether the image believed to be running can actually be pulled.
ECS or EKS events answer what the scheduler and runtime are doing to tasks or pods.
CloudWatch logs and metrics answer what users and containers are ...