Stop 07 · Identity & SecurityTopics · 10/10

Incident Response in the Cloud

In short

At 2 a.m. your bill alert fires: 40 GPU servers you never launched. What you do in the next hour depends on whether you planned it on a calm day.

A structured process for detecting, containing, and recovering from a security incident in cloud infrastructure — including the added step of preserving evidence (logs, snapshots) for investigation.

The blob character sprays an extinguisher at a small dustbin fire while an alarm bell rings.

Think of it like this

The school fire drill

In a fire drill nobody debates who carries the register or which staircase to use. It was decided and practised months ago. When the real alarm rings, everyone just follows the plan. Incident response is that drill for your cloud.

Watch it happen

Leaked key: the response plan

Detect

Contain

Preserve

Eradicate

Recover

Learn

1/6GuardDuty or a billing alarm flags strange activity: new instances in a region you never use.

The big ideas

What you need to know

Logs first

Without CloudTrail turned on and kept safe, you can't answer what the attacker did. Enable it before you need it.

Runbooks

Write step-by-step playbooks for common cases: leaked key, public bucket, compromised instance.

Who to call

Know your contacts in advance: team lead, security, and the cloud provider's support. Save the numbers somewhere offline.

Isolate, don't destroy

Move a compromised instance to a quarantine security group instead of terminating it straight away.

See it in code

Walk through the code

bash

1# 1. Contain: disable the leaked key2aws iam update-access-key --user-name ci-bot \3  --access-key-id AKIAEXAMPLEKEY --status Inactive4 5# 2. Preserve: snapshot the suspicious instance's disk6aws ec2 create-snapshot --volume-id vol-0abc123 \7  --description "IR-2026-10-27 evidence"8 9# 3. Isolate: swap to a no-traffic security group10aws ec2 modify-instance-attribute --instance-id i-0def456 \11  --groups sg-quarantine

1/3Inactive, not deleted, so you can still see the key ID in logs.

Practise these on your own test account. Real incidents also need your company's process and, often, provider support.

Save yourself the pain

Common mistakes

Oops

Terminating everything suspicious immediately to "make it stop".

Do this instead

Contain first, preserve evidence, then clean up. Deleted instances can't tell you how they got in.

Oops

Writing the response plan during the incident.

Do this instead

Write and rehearse it on a quiet day, even as a 30-minute tabletop exercise with the team.

Your mission

Tabletop drill, solo edition

~35 min

Quick check

You find an instance mining crypto. What should you do first?

Go deeper

1Learn the standard incident response phases: identify, contain, eradicate, recover, review.
2Understand why isolating a compromised resource (e.g. removing it from a security group) often comes before full investigation.
3Read a public post-mortem of a real cloud security incident to see this process applied.