S3 Lifecycle Policy Generator
Build a valid AWS S3 Lifecycle Configuration — storage class transitions, expiration, incomplete multipart cleanup and noncurrent version rules — and get back the exact JSON the S3 API expects.
Rule & filter
Leave both blank to apply the rule to every object in the bucket. Setting both prefix and tag filters an object on both matching — S3 ANDs them together, it does not OR them.
Storage class transitions
Check a storage class and set the object age (in days since upload) at which objects move there. Standard-IA and One Zone-IA cannot be set below 30 days — that is S3’s own minimum storage duration for those classes.
Expiration
Incomplete multipart uploads
Noncurrent versions (only relevant if bucket versioning is enabled)
Lifecycle Configuration JSON
Save as policy.json and apply with: aws s3api put-bucket-lifecycle-configuration --bucket YOUR-BUCKET --lifecycle-configuration file://policy.json
How to use this tool
- Set a prefix and/or tag filter, or leave both blank to apply the rule bucket-wide.
- Check the storage classes you want objects to move through and set the age, in days, at which each transition fires. S3 requires these in increasing order of both age and “coldness” — the tool warns you if they are not.
- Turn on expiration if objects should eventually be deleted outright, and set incomplete-multipart-upload cleanup so abandoned uploads do not sit there generating storage cost forever.
- If the bucket has versioning enabled, configure noncurrent-version transitions and expiration separately — these govern old versions, not the current one.
- Copy the JSON and apply it with
aws s3api put-bucket-lifecycle-configuration, or paste it straight into a Terraformaws_s3_bucket_lifecycle_configurationresource.
An S3 Lifecycle Configuration is a set of rules, and each rule is really three independent things sharing one filter: a list of transitions that move an object between storage classes as it ages, an optional expiration that deletes it outright, and separate handling for noncurrent versions if the bucket has versioning turned on. All of it is evaluated relative to the object's creation date (or, for noncurrent versions, the date it became noncurrent) — there is no way to schedule a transition for a fixed calendar date.
The storage classes exist on a strict ladder, and S3 enforces the ordering: Standard, then Standard-IA or One Zone-IA, then Intelligent-Tiering or Glacier Instant Retrieval, then Glacier Flexible Retrieval, then Glacier Deep Archive. A rule that tries to transition to Glacier on day 30 and Standard-IA on day 90 will be rejected by the API, because that asks an object to get warmer as it ages. This tool checks that ordering before you ever submit it.
The 30-day figure for Standard-IA and One Zone-IA is not a UI limitation, it is S3's minimum storage duration for those classes, and it cuts both ways: if you delete or transition an object out of Standard-IA before 30 days have passed, you are still billed as if it stayed the full 30 days. Glacier Flexible Retrieval and Glacier Instant Retrieval carry a 90-day minimum, and Deep Archive carries 180 days, both billed the same way on early deletion. Setting expiration shorter than these minimums after a transition is a common way to accidentally pay for storage you no longer have.
AbortIncompleteMultipartUpload is easy to skip and expensive to skip. Every multipart upload that never completes — a crashed client, a broken retry, a browser tab closed mid-upload — leaves its parts sitting in the bucket, fully billed, invisible in a normal object listing. A rule that aborts anything incomplete after 7 days is close to a strict improvement for almost every bucket; there is rarely a reason to keep failed upload parts around longer than that.
Noncurrent version rules only do anything on a versioned bucket, and they are independent from the rules governing the current version. Without them, every overwrite or delete on a versioned bucket keeps the prior version around forever at full Standard pricing. A typical pattern is to transition noncurrent versions to a cheaper class quickly (they are, by definition, not the object anyone is actively serving) and expire them entirely after a retention window, optionally keeping a small number of the most recent noncurrent versions with NewerNoncurrentVersions as a safety margin against accidental overwrites.
Frequently asked questions
What happens if I leave both the prefix and tag filter empty?
The rule applies to every object in the bucket. An empty Filter: {} is valid and common — it is how you write a bucket-wide expiration or transition rule.
If I set both a prefix and a tag, does either one matching apply the rule?
No. S3 combines them with AND, not OR — an object must match the prefix and carry the tag to be affected. This is exactly why the API wraps both inside a single Filter.And block rather than listing them separately.
Why can't I transition to Standard-IA before 30 days?
That is S3's minimum storage duration for Standard-IA and One Zone-IA, enforced by the API itself — a request with a shorter transition is rejected outright. It also has a billing consequence: deleting or moving an object out of Standard-IA early still bills the full 30 days.
Do noncurrent version settings do anything if versioning is off?
No, they are simply ignored. There is no noncurrent version without versioning enabled, so it is safe to leave them configured for a bucket that later has versioning turned on.
Why bother with AbortIncompleteMultipartUpload?
Failed or abandoned multipart uploads leave billed, invisible parts in the bucket indefinitely — they will not show up in a normal ListObjects call. Aborting anything incomplete after a week or two is safe for nearly every workload and stops that cost from accumulating silently.