Incident response and forensics in the cloud: snapshots, isolation, logs and provider support

How cloud incidents differ

The incident response lifecycle still applies, but the cloud changes the details. The most common starting points are leaked access keys, phished admin accounts, exposed storage and vulnerable internet-facing workloads. Attackers act through the same APIs you do, can spin up resources in any region in seconds and may try to delete logs and backups.

Under the shared responsibility model you investigate your own identities, configurations and workloads. You usually cannot inspect the provider's hypervisors or physical hosts, and you rarely need to.

Prepare before anything happens

• Enable organisation-wide audit logging, flow logs and DNS logs, stored in a protected log account (see logging strategy).
• Create a forensic account or subscription with tools and storage, to which snapshots can be copied for analysis.
• Pre-create an incident response role with read access everywhere and the specific permissions needed to isolate resources, protected by break-glass procedures.
• Write cloud-specific runbooks for leaked keys, compromised users, exposed buckets and compromised instances or pods.
• Know how to contact your provider's support and security teams, and what your support plan covers.
• Practise with tabletop exercises based on realistic cloud scenarios.

Contain and preserve

Avoid simply terminating a compromised instance: that destroys volatile evidence and possibly the disk. Isolate first, tag the resource as under investigation, then snapshot.

aws ec2 create-snapshot --volume-id <volume-id> --description "IR case 2026-014" --tag-specifications 'ResourceType=snapshot,Tags=[{Key=case,Value=2026-014}]'
aws ec2 modify-instance-attribute --instance-id <instance-id> --groups <quarantine-sg-id>
aws iam update-access-key --user-name <user> --access-key-id <key-id> --status Inactive

Note that changing a security group may not cut connections that are already established and tracked, so combine it with network ACLs or host-level isolation if needed. Record every action with a timestamp and keep hashes of exported evidence to maintain chain of custody.

Investigate, eradicate and recover

Use audit logs to build a timeline: the first malicious API call, which identities were used, what was created, read or changed, and in which regions. Look for persistence such as new users, new access keys, new roles with trust to external accounts, OAuth app grants, Lambda functions or scheduled tasks. Then eradicate by removing everything the attacker created and rotating all credentials they could have seen. Rebuild workloads from known-good images and infrastructure-as-code rather than cleaning them.

Tip: if personal data may have been accessed, involve legal and data protection colleagues early; regulations such as the UK GDPR set tight notification deadlines.