I’ve seen daily disk snapshots proposed as a log retention control more than once. The reasoning goes like this: the logs are on the disk, the snapshots are kept for the required period, so the logs are retained. Check the box.
It’s an understandable shortcut, and it fails almost every test that retention is supposed to pass. The point of keeping logs isn’t to own old bytes. It’s to be able to answer questions later, usually under pressure: did this IP address ever reach that host? What ran as root on this box last March? Which systems did this account touch? Snapshots are bad at all of it.
Why snapshots fail the job
They preserve tampering faithfully. The first thing a competent intruder does with root on a host is edit or clear the local logs. A snapshot taken after that point preserves the edited version, and the snapshot taken before it may not exist anymore once retention rolls. Logs that live only on the host they describe can be changed by anyone who compromises that host, which is exactly the person you’re investigating.
They aren’t searchable. To answer “did this IP ever connect” across six months of daily snapshots, you’d restore hundreds of volumes, mount them, and grep them one at a time. In practice nobody does that, which means the logs are retained in the sense that a filing cabinet in a flooded basement is retained.
They miss what happens between snapshots. Local logs rotate and get deleted on their own schedule. An event written and rotated away between two snapshots was never captured.
They don’t follow ephemeral infrastructure. Autoscaled instances, CI runners, and containers terminate. If their logs only ever existed on their own disks, they died with them, and no snapshot schedule fixes that.
They don’t correlate. An investigation is rarely about one host. It’s about reconstructing a sequence across many, which needs every event in one place with timestamps you can trust.
Snapshots are a fine backup and recovery tool. They’re a poor logging tool.
What the requirements actually ask for
In NIST SP 800-53, the audit family spells out the expectations, and snapshots run into several of them at once:
- AU-6, review and analysis. Logs have to be reviewable, which means searchable.
- AU-9, protection of audit information. Logs have to be protected from unauthorized modification and deletion, including by the systems that generate them.
- AU-11, audit record retention. Logs have to be kept long enough to support after-the-fact investigations.
- AU-5, response to logging failures. Someone has to notice when logging stops.
The retention period itself changed recently for federal systems. OMB memo M-21-31 set the old bar at 12 months of active storage plus 18 months of cold storage, 30 months in total. On May 22, 2026, OMB rescinded it and replaced it with M-26-14, which requires logs to stay actively searchable for at least six months and retrievable for one year from creation.
That’s a big change, and it’s worth being careful with. A lot of system security plans and control implementations were written against the old 30-month number. The federal minimum dropping doesn’t automatically change what your authorization package, contract, or authorizing official expects. If you want to shorten retention, update the package and get that decision made explicitly, rather than quietly turning down a lifecycle rule. Notice also what M-26-14 kept: “actively searchable.” A pile of snapshots doesn’t meet that word.
What good looks like
The pattern that holds up is simple to describe:
- Ship logs off the host in near real time. An agent forwards system, authentication, and application logs as they’re written, to a central store such as CloudWatch Logs or a SIEM like Splunk. Once an event has left the host, compromising the host can’t erase it.
- Store them where the source can’t touch them. The hosts get permission to write logs and nothing else: no read, no delete. In AWS, a dedicated log archive account is the clean version of this, so even an administrator of the workload account can’t remove the evidence.
- Make the archive immutable. For long-term storage in S3, Object Lock in compliance mode prevents anyone, including the root user, from deleting or overwriting objects until the retention date passes. That’s what integrity actually looks like.
- Tier by how the data gets used. Recent logs stay in a hot, searchable tier for monitoring and alerting. Older logs move to cheaper storage that can still be queried or restored. In AWS, that’s typically CloudWatch Logs with a retention setting, a subscription to Firehose, and S3 with lifecycle rules, queried with Athena when needed. The tiers map directly onto “searchable” and “retrievable.”
- Synchronize time. Every host syncs to the same time source. Correlating events across systems falls apart when clocks drift, and so does the timeline you’ll eventually have to defend.
- Alert on silence. A host that stops sending logs is either broken or being tampered with. Both deserve an alert. That’s AU-5 in practice, and it’s the control most often missing.
Decide what to collect
Retention doesn’t help if the important events were never captured. At a minimum, for servers and CI runners: authentication successes and failures, privilege escalation (sudo and its equivalents), process execution where you can get it, changes to users and groups, service starts and stops, and for CI specifically, job metadata: who triggered what, on which commit, on which runner. Cloud control plane activity, such as CloudTrail, belongs in the same archive.
The short version
If someone proposes snapshots as a log retention control, ask three questions. Can we search six months of these in an afternoon? Can someone with root on the host change them before they’re captured? What happens to the logs from an instance that was terminated yesterday? The answers make the case for a real pipeline faster than any control citation will. Logs earn their keep in an investigation, and an investigation needs them searchable, complete, and out of the attacker’s reach.