Cloud incident response

Detecting is not enough: when the alert fires, it is the speed and quality of containment that decide whether it becomes a scare or a headline.

AWS Security HubAmazon GuardDutyAWS Systems ManagerPagerDutyVelociraptor

What it is

Incident response is the process that begins when a detection signal (a GuardDuty alert, a CloudTrail anomaly, a warning) is confirmed as a real event and ends when the environment is contained, restored and has learned something from what happened.

In the cloud the game changes in two ways. First, everything is an API: you can isolate an instance, revoke a credential or swap a key in seconds and by script. Second, the environment is ephemeral: if you do not preserve the evidence before tearing down the resource, it disappears along with it.

The phases of the cycle

The NIST model (SP 800-61) remains the best backbone, even for the cloud:

Preparation: written runbooks, on-call contacts, response accounts with ready and tested access, centralized logs.
Detection and analysis: confirm the alert is real, estimate the scope (which identities, resources and data) and classify severity.
Containment, eradication and recovery: stop the damage, remove the attacker's access and restore the service from a trusted state.
Lessons learned: , adjustments to controls and inventory, and runbook updates.

Identity containment first

The most common vector in the cloud is a leaked credential, so the first move is usually to neutralize the identity, not the machine. Deactivating the access key and attaching a deny-all policy cuts off the attacker without taking down the legitimate workload, and preserves the state for analysis.

contain-key.sh - deactivate compromised keybash

USER=svc-deploy
KEY=AKIAIOSFODNN7EXAMPLE

# 1. deactivates the key (does not delete: preserves for forensics)
aws iam update-access-key --user-name "$USER" \
  --access-key-id "$KEY" --status Inactive

# 2. denies everything for sessions already issued before now
aws iam put-user-policy --user-name "$USER" \
  --policy-name quarantine \
  --policy-document file://deny-all.json

Preserve the evidence before destroying

For a suspicious workload, the reflex of "terminate the instance" erases memory, processes and open connections. The correct path is to isolate first (swap the for one that allows no traffic), snapshot the volumes, capture whatever is volatile and only then decide whether to discard or investigate.

Separate forensic accounts, with snapshots copied to an immutable bucket (Object Lock) and a documented , prevent the evidence from being altered by whoever compromised the original account.

Automate what is repeatable

A good part of containment is repetitive and urgent, the perfect environment for automation: a high-confidence alert triggers a function that isolates the resource, opens the ticket and notifies the on-call. Ambiguous decisions remain human.

The metric that matters is MTTR (). Runbooks tested in exercises (game days) and automations with approval for destructive actions bring MTTR down without creating the risk of the automation itself causing the incident.

CWPPcloud workload protection platformMonitored protection for running workloads: VMs, containers, serverless functions. It combines visibility into what runs (processes, syscalls, network) with prevention (blocking execution, isolating anomalies). It is endpoint security reworked for the ephemeral reality of the cloud.see in glossary →Postmortemblameless reviewA written review of an incident that asks how the system allowed it, not who erred, and ends with owned actions.see in glossary →Security groupsecurity groupA stateful list of rules attached to an instance or network interface in the cloud: who can come in on which port, from which source. It works as a host firewall at the cloud level, and it fails open by default: if you forget to close a port, it stays open to 0.0.0.0/0.see in glossary →Chain of custodychain of custodyA record of who collected, stored and handled each piece of digital evidence, and when. Without it, the evidence loses value for audits and for any legal dispute.see in glossary →MTTRmean time to respondThe average time between confirming an incident and containing it. It is the metric that shows whether runbooks and automation really work, and the one that drops the most when response is practiced in exercises.see in glossary →

connections on the map

Logging & detection - signals and alertstriggers the responseCloud incident response
CWPP - workload protectionruntime alertCloud incident response
Cloud incident responserevokes credentialsIAM - identity and access

updated on 14/10/2026 · sources to go deeper · report an error

in other domains

Triage, scoping and containmentresponsethe same containment, applied to accounts and cloud resources
Regression evals - fixed suite on the PRai-agentsevery incident becomes a test case
Runbooks, response and post-incident hardeningsecopsthe L7 runbook is a specific case of the general response

Study before

test what you learned

Loading questions…