Locking Down Log Storage Buckets

CloudTrail, Config, and Flow Logs ultimately store data in S3 buckets. That bucket is the crown jewel of your audit trail, so it deserves the strongest protections. If the bucket is secure, an attacker who compromises a workload still cannot reach the evidence of what they did.

The first control is S3 Block Public Access, ensuring the log bucket is never exposed to the internet. A publicly readable log bucket leaks sensitive operational detail to anyone. Enabling Block Public Access at the account and bucket level closes this risk decisively.

A tight bucket policy should allow only the logging service to write and only specific security roles to read, denying everyone else. You can also deny s3:DeleteObject for all principals so logs cannot be removed through normal API calls, a strong baseline against casual tampering.

S3 Object Lock enforces write-once-read-many (WORM) storage, making objects truly immutable for a set period. Even an account administrator cannot delete or overwrite a locked object before its retention expires. This is the strongest defense against an attacker, or insider, deleting logs.

Object Lock has two modes. In Governance mode, users with special permission can override the lock. In Compliance mode, no one, not even the root user, can delete or shorten retention until it expires. For regulated audit logs, Compliance mode provides the strongest guarantee.

Object Lock requires versioning, which keeps every version of an object. Versioning alone also helps: if an attacker overwrites an object, the previous version remains. Combined with a deny on DeleteObjectVersion, versioning makes destroying history far harder than deleting a single current object.

MFA Delete requires multi-factor authentication to permanently delete object versions or change versioning state. It adds a human, hardware-backed gate in front of destructive actions on the log bucket, so even a compromised credential cannot quietly purge versions without the MFA device.

Encrypt log data at rest with KMS, ideally a customer managed key whose policy limits who can decrypt. This protects confidentiality, since logs often contain sensitive details like usernames and IPs. KMS also produces an audit record of every decrypt, adding visibility into who reads the logs.

Enable S3 server access logging or use CloudTrail data events on the log bucket so you can see who accessed it. Alarm on unexpected reads or any delete attempt. Monitoring the log bucket itself ensures that an attack on your evidence is, ironically, also recorded.

No single setting is enough. Block Public Access, a deny-delete bucket policy, Object Lock in Compliance mode, versioning, MFA Delete, and KMS encryption together make the bucket resistant to deletion, modification, and exposure. Defense in depth is the goal: each layer covers another's gaps.

A properly locked-down log bucket is immutable, private, encrypted, and monitored. Combined with CloudTrail log file validation for tamper detection, it ensures your evidence both survives and stays provably intact. This bucket-level hardening is exactly what exam scenarios about protecting logs expect.

Test your bucket-hardening knowledge.

Harden log buckets with layered controls: Block Public Access, a deny-delete bucket policy, S3 Object Lock (Compliance mode is unbreakable, Governance is overridable), versioning, MFA Delete, and KMS encryption for confidentiality. Monitor access with S3 access logging or CloudTrail data events. Together they make logs immutable, private, and monitored.