The instincts that serve you well in on-premises response — pull the cable, image the disk, work the timeline — will actively mislead you in a cloud intrusion. Cloud incident response is identity-centric, API-driven, and races against infrastructure that deletes itself. The attacker rarely gets on a box at all: they get a credential, and from that moment the control plane is the crime scene.
This changes tooling, evidence sources, and containment logic all at once. Teams that bolt a cloud annex onto an on-prem playbook consistently discover the mismatch mid-incident, which is the most expensive possible time to learn it.
The Control Plane Is the Crime Scene
In AWS the primary evidence is CloudTrail; in Azure, the Activity Log and Entra ID sign-in logs; in GCP, Cloud Audit Logs. Verify three things about that telemetry today, not during an incident:
- ▸Coverage: an organization-wide trail capturing all regions and all accounts, including data events for sensitive S3 buckets — management events alone will not show you which objects were actually read.
- ▸Integrity: logs delivered to a dedicated, locked-down account that workload accounts cannot write to or delete from. Attackers who gain admin routinely attempt to stop trails.
- ▸Retention: ninety days of hot searchability at minimum; identity-driven intrusions are often discovered months after initial access.
GuardDuty, Microsoft Defender for Cloud, and equivalent native detectors are worth enabling everywhere, but treat them as tripwires, not investigation tools — the investigation happens in the raw audit logs.
Containment Without a Cable to Pull
Cloud containment is a sequence of API calls, and ordering matters more than raw speed. Deactivating a leaked access key does not terminate sessions already established with temporary credentials; you must also revoke active sessions or attach an explicit deny that invalidates tokens issued before a timestamp. The common moves, roughly in order of use:
- ▸Identity first: disable the principal, revoke refresh and session tokens, and audit for attacker-registered MFA devices and OAuth application grants.
- ▸Scope from the logs: enumerate every API call the credential made — sorted into reads, writes, and privilege-relevant actions — before deciding what else you can trust.
- ▸Isolate compute without destroying it: swap the instance's security group for a pre-built no-ingress, no-egress quarantine group instead of terminating it. Termination destroys memory and, with it, most of your answers.
- ▸Snapshot before you change anything: EBS snapshots and disk exports are your forensic images, and they can be shared into a dedicated forensics account for analysis away from production.
Watch for persistence unique to the platform: new IAM users and access keys, backdoored role trust policies, functions wired to event triggers, and cross-account access grants. Terminating an instance evicts nobody if the attacker still holds a valid role.
The First Hour, Concretely
1. Confirm the finding against raw audit logs and establish which principal, keys, and sessions are involved. 2. Contain the identity: disable keys, revoke sessions, and force reauthentication with MFA re-registration where warranted. 3. Snapshot affected compute and quarantine it with the deny-all security group; capture instance metadata and, where feasible, memory. 4. Enumerate everything the principal touched — especially IAM writes, newly created credentials, and data-plane reads on sensitive stores. 5. Check for organization-level damage: trail tampering, new accounts joined to the org, and service control policy modifications. 6. Start the incident timeline document immediately, in UTC, recording responder actions alongside attacker activity.
Prepare the Environment, Not Just the Team
Cloud IR readiness is mostly infrastructure-as-code work done in peacetime: a forensics account with tooling pre-deployed, quarantine security groups pre-created in every VPC, snapshot-sharing permissions rehearsed, and break-glass responder roles that still work when the SSO provider is the thing that is compromised. Ephemerality raises the stakes — autoscaling will happily terminate your evidence — so hook scale-in events to snapshot critical instances during declared incidents, and ship container and function logs off-host by default, because there is no host to go back to.
The payoff is not only faster response. Organizations that can produce a precise, log-backed account of what an attacker did in their cloud can scope customer notifications narrowly, satisfy regulators with evidence instead of assumptions, and avoid the panicked full-environment rebuilds that follow uninvestigated incidents. In an estate that is entirely programmable, response capability is programmable too — and building it in advance is one of the highest-leverage security investments a cloud-first company can make.