Add a lifecycle configuration to the two CloudTrail log buckets

The work is in terraform/cloudtrail.tf. Start by reading the existing bucket resources and the linked issue #191. Add an aws_s3_bucket_lifecycle_configuration resource for each bucket, following the detailed instructions for the filter, status, and count condition. After applying, verify with aws s3api get-bucket-lifecycle-configuration.

Overview

We need to give the two CloudTrail log buckets a lifecycle configuration, because neither has one and so audit logs accumulate forever with no stated retention period. The management-events bucket already holds objects going back to October 2022. This is a governance decision more than a cost one — see the sizing below, which is deliberately honest that the money at stake is small.

Action Items

• Apply the agreed retention period: expire objects after 365 days in both buckets. Settled 2026-09-23 (Alex) with the cost figures below already known, so this is not a number to re-litigate when the assignee notices the saving is small. No compliance regime requiring a longer period has been recorded for Hack for LA; if someone identifies one, raise it here before applying rather than changing the number quietly.
• Do not add a storage-class transition. This is the counter-intuitive part and it is why the rule should be expiration-only. Glacier tiers bill a 128 KB minimum per object, and these objects are far smaller — averaging 946 bytes in the backend-logs bucket and 13 KB in the management-events bucket. Transitioning would bill 55 GB and 230 GB respectively instead of the real 0.4 GB and 21.3 GB, taking the pair from $0.53/month to $1.14/month, plus a one-off ~$43 in transition requests for 2.17 million objects. The obvious lifecycle rule makes this cost more than twice as much as doing nothing.
• Add an aws_s3_bucket_lifecycle_configuration resource for each bucket in terraform/cloudtrail.tf, alongside the existing per-bucket resources. Both must carry count = var.iam_only ? 0 : 1 like every other resource in that file, and reference aws_s3_bucket.tf_backend_logs[0].id and aws_s3_bucket.management_events[0].id.
• Include an abort_incomplete_multipart_upload rule in both, at 7 days. CloudTrail does not generally leave incomplete uploads, but they are invisible in the console and billed as storage, so this is the cheap standard guard.
• Give each rule an explicit filter {} and an explicit status. A lifecycle rule with no filter is an error in AWS provider v6, and the failure message is not obvious.
• Update the file-header comment near the top of terraform/cloudtrail.tf, which lists a bucket lifecycle configuration as one of four things deliberately left out by #191. Remove that one from the list; leave the other three as they are.
• Confirm the plan shows 2 to add, 0 to change, 0 to destroy. Both buckets carry prevent_destroy, so anything touching the bucket resources themselves is wrong.
• After the PR merges and the apply runs, confirm both configurations exist: aws s3api get-bucket-lifecycle-configuration --bucket <name> on each should return the rules rather than NoSuchLifecycleConfiguration.
• After the PR merges, be aware the first expiration sweep is not immediate — S3 evaluates lifecycle rules asynchronously, usually within 24–48 hours, and deletions are then visible as a falling object count. Do not read an unchanged count an hour after apply as a failure. Re-check the day after.
• Sanity-check the blast radius before merging, not after. At 365 days, the management-events bucket loses roughly three of its four years of history on the first sweep, and that deletion is permanent. Confirm that is genuinely intended, and that nobody is relying on 2022–2023 CloudTrail history, before this applies.

Resources/Instructions

• terraform/cloudtrail.tf — the only file this touches. It already declares, per bucket, the bucket, its policy, its public access block and its encryption configuration, so the lifecycle resource slots in beside those.
• devops-security#191 — imported both buckets as-is and names the missing lifecycle configuration as deferred work.
• aws_s3_bucket_lifecycle_configuration
• S3 lifecycle transition constraints — the source for the 128 KB minimum billable object size that makes a transition rule counter-productive here.

Current state, measured 2026-09-23 (from CloudWatch AWS/S3 daily metrics, not a full listing):

The cost case is small and that is understood. The two buckets together cost about $6.41 a year, and the management-events bucket has grown at roughly 0.45 GB/month over nearly four years. Expiring at 365 days saves a few dollars annually and no more. The reason this was ticketed is to have a deliberate, written retention period for audit logs and to stop unbounded growth — not to save money. That trade was made with these figures in hand, so an assignee who rediscovers the small saving has not found a reason to close the ticket.