Snapshotting Volumes for Forensics

Before you touch a compromised instance, capture its disk. An EBS snapshot is a point-in-time copy of an Elastic Block Store volume, stored durably in S3.

It freezes the exact state of the disk at the moment of capture, giving investigators an unchanging baseline to analyze even as the live system is contained or rebuilt.

An EBS snapshot is block-level and incremental: the first captures all used blocks, later ones store only changes. Despite that, each snapshot is a complete, restorable copy of the volume.

It preserves the file system, malware on disk, logs, and configuration exactly as they were — the raw material of a forensic investigation.

The golden rule of forensics is to never modify the original evidence. Work only from copies of the snapshot.

Create a fresh volume from the snapshot, attach it to a forensic instance, and mount it read-only so the act of investigating cannot change a single byte of the captured state.

Disk snapshots miss what lives only in RAM — fileless malware, decryption keys, and active network connections.

If your forensic tooling supports it, dump the instance's memory as well. Together, the disk snapshot and the memory image give the fullest possible picture of the compromise.

Tag every snapshot with the source instance, the incident ID, and the capture time. Clear tags prevent accidental deletion and keep evidence organized.

Document who captured what and when. A defensible chain of custody matters if the findings ever support legal or regulatory action.

Copy the snapshot into your isolated forensic or IR account so the evidence sits beyond the reach of an attacker still active in the compromised account.

Sharing and copying snapshots across accounts is a built-in EBS capability; just ensure KMS key permissions allow the destination account to use encrypted snapshots.

Encrypt forensic snapshots with KMS (Key Management Service) so the sensitive data they contain stays protected at rest.

Control access through the key policy: only authorized investigators should be able to decrypt the evidence. This protects victim data and keeps your handling compliant.

Long-term, export or retain evidence in storage that cannot be altered. An S3 bucket with Object Lock in compliance mode prevents deletion or overwrite for a fixed retention period.

This guards the evidence from both attackers and accidental loss, reinforcing the integrity of your investigation.

In a fast-moving incident, manual snapshots are a bottleneck. A Lambda function triggered by a GuardDuty finding can snapshot all attached volumes automatically the instant a threat is detected.

Automated acquisition captures the freshest possible state and frees responders to focus on analysis.

With a read-only copy mounted on a forensic instance, investigators hunt for indicators of compromise: suspicious files, modified binaries, unexpected cron jobs, and log entries.

Because the work happens on an isolated copy, you can probe aggressively without any risk to production or to the integrity of the original evidence.

When the investigation closes, decide the snapshot's fate by policy. Evidence tied to legal or regulatory matters may need long retention under Object Lock.

Otherwise, delete forensic snapshots on a defined schedule so sensitive captured data does not accumulate. Either way, record the decision so the chain of custody stays intact from capture to disposal.

Protect the evidence correctly.

Capture forensic evidence by taking an EBS snapshot of every volume before changing the instance, and dump memory for what lives only in RAM. Always work from read-only copies, tag everything for chain of custody, and copy the encrypted snapshot into an isolated IR account. Protect it with KMS and S3 Object Lock, automate acquisition from GuardDuty findings, and analyze copies on a hardened forensic instance.