S3 Lifecycle Policy Generator

Introduction:

Amazon S3 lifecycle rules turn storage retention decisions into automatic actions. Instead of keeping every object in the same storage class forever, a bucket can transition older objects to an archive class, delete temporary files after a short period, clean old noncurrent versions, or abort incomplete multipart uploads that would otherwise leave unused parts behind.

The core idea is simple: a rule chooses a set of objects and then applies one or more actions as those objects age. The details matter because lifecycle actions can move data into classes with retrieval costs, minimum storage durations, or delayed access, and expiration can permanently remove current objects or old versions. A rule that is useful for access logs may be dangerous for legal records, backups, active data lake partitions, or files protected by a retention process outside S3.

Filters define scope. A lifecycle rule can apply to a whole bucket, a key prefix such as logs/app/, one or more object tags, and object-size boundaries. Combining filters is powerful, but it also makes review harder. A whole-bucket expiration rule may remove more than intended; a tag-filtered rule may miss objects that were uploaded without the expected tags.

Versioning changes the meaning of deletion. In a nonversioned bucket, current-object expiration removes the object. In a versioned or versioning-suspended bucket, noncurrent version actions can transition or delete older versions while the current object remains. Retaining a number of newer noncurrent versions adds a second threshold: old versions are not affected until both the age and retained-version conditions are met.

Lifecycle policy design should therefore start with ownership and recovery questions, not syntax. Decide who owns the data, how long it must remain recoverable, what storage class tradeoffs are acceptable, and how the rule will be merged with any existing bucket lifecycle configuration.

How to Use This Tool:

Choose a lifecycle posture, tune the filter and age thresholds, then inspect every generated artifact before applying anything to a bucket.

1. Select a Lifecycle preset such as logs archive, temporary expiration, data lake archive, noncurrent version cleanup, multipart cleanup, or directory bucket expiration.
2. Enter Bucket name, Rule ID, Bucket type, and rule status. Directory bucket mode omits unsupported transitions, tag filters, and versioned-object actions.
3. Set the lifecycle filter with Prefix, tag filters, and optional object-size boundaries. Use whole-bucket scope only when that is intentional.
4. Add current-object transitions as CSV rows of days, storage class, and note. Then set current expiration days if the rule should delete current objects.
5. Choose the versioning posture and set noncurrent transition, noncurrent expiration, newer noncurrent versions to retain, and abort-incomplete-multipart days as needed.
6. Use Advanced options for expected bucket owner, region, CloudFormation logical ID, Terraform resource name, visible row limit, and review comments in code artifacts.
7. Review Lifecycle JSON, XML, CloudFormation, Terraform, AWS CLI, Rule Ledger, Review Checks, and Lifecycle Timeline. Blocking input issues should be fixed before copying output.

Interpreting Results:

The Lifecycle JSON tab is the main S3 API shape. Other code tabs translate the same normalized model into XML, CloudFormation, Terraform, and AWS CLI examples. The Rule Ledger is the best place to review scope and timing because it lists each rule, stage, action, day or threshold, storage class, and review note in table form.

• Blocking input issues mean the generated lifecycle configuration should not be used until the input is corrected.
• Review notes flag choices that may be valid but need owner approval, such as destructive expiration or small-object transition behavior.
• Companion multipart rules appear when tag filters would make an abort-incomplete-multipart action invalid in the same rule.
• Lifecycle Timeline visualizes day-based actions, but legal retention, backup ownership, and retrieval needs must be checked outside the chart.

Technical Details:

S3 lifecycle configuration is a list of rules. Each rule has an ID, a status, a filter, and zero or more actions. The filter can be a prefix, a single tag, an And combination of prefix, tags, and size constraints, or a bucket-wide scope. The status value controls whether S3 performs the actions after the configuration is applied.

Current-object actions use creation age. Noncurrent-version actions use the time since an object version became noncurrent, and optional newer-version retention can delay action until enough newer noncurrent versions exist. Multipart cleanup uses days after multipart upload initiation, not object age.

Rule Core:

Object-size filters in S3 are exclusive byte comparisons. The interface accepts inclusive kilobyte boundaries for readability, then converts them to exclusive byte values in the generated filter.

A visible minimum of 128 KB therefore emits an exclusive byte threshold of 131071. Objects larger than 131071 bytes match the filter, which is the inclusive 128 KB intention expressed in S3's exclusive operator.

Artifact Equivalence:

The JSON, XML, CloudFormation, Terraform, and CLI outputs represent the same lifecycle model as closely as each format allows. The CLI example writes the lifecycle JSON to a file and uses put-bucket-lifecycle-configuration, which replaces the bucket lifecycle configuration. Existing bucket rules should be merged deliberately before applying generated output.

Limitations:

Lifecycle output can delete or archive production data. Treat generated policies as review artifacts until they have been checked against account policy, bucket versioning, Object Lock, backup requirements, and workload retrieval expectations.

• The generated AWS CLI command can replace an existing lifecycle configuration unless rules are merged first.
• Storage-class costs, retrieval times, and minimum-duration charges can change after the policy is written.
• Directory bucket support differs from general purpose bucket support, and unsupported actions are intentionally omitted.

Worked Examples:

A logs bucket can use the logs archive preset with prefix logs/app/, tags such as environment=prod, current transitions at 30 and 90 days, and expiration at 365 days. The Rule Ledger should show transition rows followed by current-object expiration, and Review Checks should call out destructive deletion for owner approval.

A versioned documents bucket can set current expiration to 0, keep noncurrent transition at 30 days, noncurrent expiration at 365 days, and retain 5 newer noncurrent versions. The resulting noncurrent version rows should be reviewed with rollback and restore requirements before use.

If tag filters are present and abort-incomplete-multipart cleanup is enabled, a companion rule is generated without tag filters. This is expected because S3 does not allow abort-incomplete-multipart cleanup with tag filters in the same lifecycle rule.

FAQ:

Glossary:

Lifecycle rule

An S3 configuration entry that applies actions to objects matched by a filter.

Prefix filter

A rule scope that matches object keys beginning with a selected string.

Noncurrent version

An older object version that is no longer the current version in a versioned bucket.

Transition

A lifecycle action that moves matching objects or versions to another storage class.

Expiration

A lifecycle action that deletes current objects or old noncurrent versions after a threshold.

References:

• Lifecycle configuration elements, Amazon S3 User Guide.
• put-bucket-lifecycle-configuration, AWS CLI Command Reference.
• Lifecycle transition constraints and considerations, Amazon S3 User Guide.