Cloud Incident Response: A Playbook for AWS, Azure, and Google Cloud
Cloud incidents move faster and leave different evidence. On-premise playbooks do not transfer.
The first cloud incident tends to expose an uncomfortable truth: the incident response plan was written for servers. It assumes disks can be imaged, that network containment is meaningful, and that the evidence will still be there tomorrow. In cloud environments, none of those assumptions hold reliably.
What is structurally different
- Identity is the perimeter. Most incidents start with a leaked key or over-permissioned role, not a network intrusion.
- Evidence is ephemeral. Autoscaling destroys the instance you needed to examine, often before you know it existed.
- Blast radius is instantaneous. A compromised control plane credential can affect every region at once.
- Forensics is API-driven. You collect snapshots and logs through provider interfaces, and only what you configured beforehand exists.
That last point is decisive. Cloud investigation capability is determined by logging decisions made months earlier.
Prepare before you need it
| Preparation | Why |
|---|---|
| Control plane audit logging in every account and region | Primary record of attacker actions |
| Central log archive in an isolated account | Prevents attacker deletion of evidence |
| Break-glass administrative identity | Access when normal identity paths are compromised |
| Pre-authorised forensic account and role | Removes approval delay during an incident |
| Asset and ownership inventory | Answers whose workload this is at 2am |
| Tested snapshot and memory capture procedure | Preserves evidence under time pressure |
Investigate identity first
Start with the control plane log and reconstruct what the compromised principal did: which API calls, from which addresses, creating or modifying what, and whether new identities, keys, or roles were created. Attackers routinely establish a second identity within minutes, so revoking only the original credential leaves them present.
Then check for the standard persistence set: new access keys, new IAM users or service principals, modified trust policies, added federation providers, and changes to logging configuration. Any attempt to disable or reconfigure audit logging is a strong indicator of a capable adversary and should escalate the incident severity immediately.
Contain without destroying the evidence
Sequence matters. Snapshot volumes and capture memory before terminating anything. Isolate compute by stripping network access and detaching instance roles rather than deleting resources. Revoke sessions and rotate credentials rather than deleting identities, which erases the audit trail linkage. Copy relevant logs to the forensic account at once, because retention windows and attacker tampering both work against you.
Also disable autoscaling for affected groups early — otherwise your evidence is recycled while you are still deciding what to collect.
Scope data exposure honestly
Determining what data was accessed drives every regulatory decision, and it depends on storage access logging that many organisations leave disabled for cost reasons. Enable it for sensitive data stores now; the cost is trivially small compared with being unable to establish exposure scope during a notifiable incident.
Recover into a clean state
Cloud gives you a genuine advantage here: rebuild rather than clean. Redeploy from known-good infrastructure as code into fresh accounts or subscriptions, restore data from validated backups, rotate every credential the compromised environment could reach, and only then decommission the isolated originals once the investigation closes.
Close with the control change that would have prevented it — usually removing long-lived access keys in favour of short-lived federated credentials, or narrowing a role that had far more permission than its workload required.
Frequently asked questions
How is cloud IR different?
It is identity-driven, evidence is ephemeral, control plane actions have estate-wide blast radius, and collection depends on provider APIs and pre-configured logging.
Which logs are essential?
Control plane audit logs, identity sign-in events, network flow logs, storage access logs, and workload runtime logs — archived centrally where the compromised environment cannot alter them.
How do we contain without losing forensics?
Snapshot and capture memory first, isolate rather than delete, revoke sessions and credentials rather than removing identities, and copy logs to a forensic account immediately.
Should we rebuild or remediate?
Rebuild from infrastructure as code into clean accounts. It is faster and gives higher confidence than cleaning a compromised environment.