The CFO does not buy Object Lock. The staff engineer buys an evidence story that survives a delete. S3 Object Lock CloudTrail log archive is the pattern: an organization trail writes to a dedicated log-archive account, objects are encrypted with a KMS key that account owns, and the bucket uses Object Lock in COMPLIANCE mode for a retention you can defend. This is not a CloudTrail tutorial. It is the archive contract auditors sample when they ask who can alter management events after the fact.
Rutagon builds that contract on AWS cloud infrastructure. We do not claim a FedRAMP authorization or a SOC 2 certification. We produce the bucket settings, the key policy, the trail ARN, and a failed-delete test from the assessment window. The same perimeter thinking shows up in AWS data perimeter architecture for SOC 2. Here the resource is the trail prefix, not the whole data lake.
S3 Object Lock CloudTrail Log Archive in a Log-Archive Account
An organization trail in the management or delegated admin account delivers to a bucket you do not share with application teams. Member accounts cannot change that trail. The log-archive account owns the bucket. Application roles in member accounts do not have s3:DeleteObject on that prefix. That split is the first control. Object Lock is the second. Together they answer “could an admin in the app account erase Friday’s API history?”
Object Lock requires a bucket created with lock enabled. You cannot add COMPLIANCE lock to an existing bucket that was created without the feature. Teams that “will add lock later” are planning a bucket migration. Plan the migration as a project: new bucket, new trail destination, dual-write or a cut date, then freeze the old prefix.
COMPLIANCE mode means even the root user of the log-archive account cannot shorten retention or delete the object until the retain-until date. GOVERNANCE mode allows users with a bypass permission to delete earlier. GOVERNANCE is useful in a lab. For a trail archive that is supposed to be evidence, COMPLIANCE is the mode we put in the design. Retention days are a legal and product choice. We do not invent a number. We implement the number you already owe customers and insurers.
AWS documents Object Lock in the S3 Object Lock guide. CloudTrail delivery needs a bucket policy that allows the CloudTrail service principal to PutObject with the trail’s ACL and encryption expectations. Object Lock default retention on the bucket applies to new objects if you set a default. Confirm CloudTrail puts objects in a way that inherits that default. If it does not, set retention on the write path or use a default configuration CloudTrail honors. We verify with a test object and GetObjectRetention, not with a wiki.
KMS in the Archive Account
SSE-S3 is not the story we hand an auditor who asked about key control. A customer-managed key in the log-archive account, with a key policy that allows CloudTrail to encrypt and allows only a break-glass role plus the SIEM reader to decrypt, is the usual shape. Member-account admins do not get kms:Decrypt on that key. If they can decrypt, they can copy the archive to an account you do not control. That is a data-perimeter miss, not an Object Lock miss.
Key rotation on that CMK is a separate control. Rotation changes the backing key material. Existing objects remain readable. We cover database keys elsewhere. For the trail key, enable rotation and keep the key policy tight. Do not put application workloads on the same key.
Replication to a second region is optional and expensive. If you replicate, the destination bucket needs the same lock and key story or you have built a mutable copy. Many mid-market SaaS teams skip cross-region trail copies and instead treat the archive account plus Object Lock as the integrity control, with AWS Backup restore testing covering other data. Do not pretend trail objects are “backed up” because Backup ran on an app database.
What the Auditor Samples
They sample the trail: organization trail, all management events, and whether data events are on for the buckets that matter. They sample the destination: account id, bucket name, encryption, public access block, Object Lock status, default retention, and a recent object’s retain-until date. They sample access: who can s3:DeleteObject, s3:BypassGovernanceRetention, and kms:ScheduleKeyDeletion. They ask you to attempt a delete on a locked object and show the error.
That failed delete is the artifact. A policy PDF is not.
CloudTrail integrity validation (digest files) is complementary. Object Lock stops delete and overwrite. Digests help you detect tamper if someone could write. Use both if the sample asks. Do not substitute one for the other in the write-up.
We do not turn this article into “how to click Create trail.” If your trail is still per-account and writing into the app account, the archive work starts with moving the destination, not with toggling Object Lock on a bucket developers can still empty.
Delivery Failures Are an Evidence Gap
If CloudTrail cannot write — wrong bucket policy, wrong KMS grant, Object Lock mismatch — you lose hours of management events. That hole is worse than a slightly long retention. We alarm on CloudTrail Failed to deliver metric and on a canary: a known write in a member account must appear in the archive prefix within a bound you pick. Athena or a small Lambda that lists the latest prefix is enough.
Lifecycle rules that expire objects earlier than Object Lock retention will fail or no-op on locked objects. Do not write a lifecycle that fights COMPLIANCE. If finance wants a shorter archive, that is a retention-policy change with legal, not a lifecycle trick.
MFA delete is not Object Lock. MFA delete is a different S3 feature and does not give you COMPLIANCE retain-until dates. We still keep Block Public Access on. Public trail buckets are an incident.
A Bucket Policy Shape, Not a Tutorial
The CloudTrail write statement is the one AWS documents for organization trails (source account and trail ARN conditions). We add explicit denies for s3:DeleteObject and s3:PutObject from any principal except the CloudTrail service and a named archive admin role. Object Lock still blocks the admin role during retention. The deny is defense in depth for GOVERNANCE leftovers and for APIs that are not lock-aware.
{
"Sid": "DenyDeletesExceptBreakGlass",
"Effect": "Deny",
"Principal": "*",
"Action": ["s3:DeleteObject", "s3:DeleteObjectVersion"],
"Resource": "arn:aws:s3:::LOG_ARCHIVE_BUCKET/AWSLogs/*",
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::ARCHIVE:role/trail-archive-admin"
}
}
}
The admin role still loses to COMPLIANCE until retain-until. That is the point.
Config and Access Analyzer stay pointed at this bucket. Detective rules do not replace lock. They tell you when someone opened a public ACL or removed the default retention. That detective layer can live next to AWS Config conformance packs without turning this design into a pack rollout.
Frequently Asked Questions
Can we enable Object Lock on the existing CloudTrail bucket?
Only if that bucket was created with Object Lock enabled. Otherwise you create a new bucket with lock, point the organization trail at it, and treat the old prefix as a historical archive with its own access policy. There is no in-place COMPLIANCE conversion. Budget the dual-destination window so you do not drop events on the cut.
Why COMPLIANCE mode instead of GOVERNANCE for trail objects?
COMPLIANCE prevents privileged principals from shortening retention or deleting early. GOVERNANCE is bypassable with a permission you will eventually grant to someone who is in a hurry. For management-event evidence, the bypass is the control failure. Use GOVERNANCE in accounts where you are still rehearsing the pipeline, then move the archive bucket to COMPLIANCE before you call it the system of record.
Does Object Lock replace CloudTrail log file validation?
No. Object Lock makes objects immutable for a retain-until period, while log file validation writes digest files so you can detect modification of delivered logs. We enable validation on the organization trail and lock on the destination. Neither covers a period when delivery was broken, so alarm the delivery path.
Who should own the KMS key for the log-archive bucket?
The log-archive account should own the key, not the application account and not a shared platform key that app roles can decrypt. CloudTrail needs encrypt permission and a SIEM or security-reader role needs decrypt. If app admins can decrypt trail objects, Object Lock only stopped delete and did not stop copy.
If you want an architecture review tied to audit evidence — trail ARN, lock mode, retention, key policy, and a failed-delete artifact — call 907-841-8407, email contact@rutagon.com, or use rutagon.com/contact.