S3 lifecycle policy workflow

Start with object behavior, not bucket size

A large bucket is not automatically wasteful. Before proposing a lifecycle policy, a team needs to understand object age, access patterns, versioning, replication, retention obligations, restore-time requirements, and whether applications depend on current storage-class behavior.

S3 Storage Lens and inventory reports can provide aggregated usage and object metadata. AWS documents the available S3 Lifecycle transitions and constraints, including minimum storage durations and transition charges.

Proposed evidence and policy

The workflow would model storage-class transition or expiration separately. It would exclude buckets with legal holds, Object Lock, unknown owners, or explicit protection tags. A proposed Terraform diff would identify the exact prefix or tag filter and show minimum-duration tradeoffs.

The approval preview should include:

• Current bytes and object counts by age band.
• Expected request, transition, retrieval, and minimum-duration charges.
• Replication, versioning, and noncurrent-version behavior.
• The owning repository and module, plus rollback limitations.

Limitations and risks

Lifecycle expiration is destructive and is not undone by removing a policy. Transitioning small or frequently accessed objects can cost more, and incomplete multipart uploads require separate handling. Estimates based on historical access do not guarantee future behavior.

OpsTiller would initially favor reversible transitions over expiration and require additional safeguards for destructive policies. Explore why Terraform changes need a remediation workflow.