AWS S3 Lifecycle Policies Explained: Rules, Examples & Costs

Simple explanation

S3 lifecycle policies work the same way. You write a rule that says: after 30 days, move this object to Standard-IA; after 90 days, move it to Glacier; after 365 days, delete it. S3 checks object ages daily and moves things along the chain automatically.

How it works

Lifecycle rules operate on a simple age-based trigger:

1. Object lands in the bucket. S3 records its creation date.
2. Rule matching. Each lifecycle rule has a filter: a prefix, a tag, or no filter at all. S3 checks whether the object key and tags match the rule.
3. Age threshold reached. Once the object is old enough (measured in days since creation, or days since it became a noncurrent version), the rule becomes eligible to fire.
4. S3 performs the action asynchronously. Transitions and expirations are not instant. AWS runs lifecycle processing in the background, typically within 24 hours of the configured day. An object with a 30-day transition rule will not move at midnight on day 30 exactly. It may take until day 31 depending on when the job runs.

Rules never fire early. An object will not be transitioned or deleted before the configured day count is reached.

You can have multiple rules on the same bucket, and they run independently. One rule can transition logs/ objects while another expires temp-exports/ objects. They do not interfere with each other unless their filters overlap.

When to use this

Lifecycle policies work best when object access patterns are predictable and time-based. Common situations:

• Application logs. Logs from the last week are queried actively. Logs from last month are checked during incident reviews. Logs older than 90 days are kept for compliance but rarely opened. A three-stage lifecycle rule covers this exactly and significantly cuts the cost of long-term log retention.
• Database or VM backups. Daily backups older than 30 days rarely need to be retrieved quickly. Moving them to Standard-IA or Glacier after a set period keeps them available without paying Standard pricing for cold data.
• Exported reports. A finance team generates monthly CSVs that are reviewed for 30 days and then archived. A lifecycle rule can automatically move these to a cold tier once that window closes.
• Compliance archives. Some industries require objects to be retained for 7 years. Lifecycle rules can automate the transition to Glacier Deep Archive (the cheapest tier) after the active period ends, and trigger expiration at the end of the retention window.
• Versioned buckets with growing old versions. If S3 versioning is enabled and you never clean up noncurrent versions, storage costs accumulate silently. Lifecycle rules can automatically move old versions to cheaper classes and delete them after a defined period.

When not to use this

Lifecycle policies are not the right tool in every case.

Access patterns are unpredictable. If you cannot reliably predict when objects will go cold (for example, a media library where some assets are re-requested months later without warning), a lifecycle rule risks moving frequently-needed objects to a slow or expensive-to-retrieve tier. S3 Intelligent-Tiering is a better fit here, since it monitors access automatically and adjusts without a fixed schedule.

Data is accessed frequently. Objects that are read often should stay in Standard or Standard-IA. Transitioning frequently accessed objects to Glacier will slow your application down and generate unexpected retrieval costs.

Objects are small and short-lived. Lifecycle transitions have per-request overhead. If you have millions of tiny objects kept for only a few days, the overhead of managing transitions may not be worth the marginal cost saving. Minimum storage duration charges (covered below) can actually increase your bill.

Lifecycle actions

There are six action types you can include in a lifecycle rule. A single rule can combine multiple types.

Transition#

Moves an object to a different S3 storage class after a set number of days. Common targets:

Minimum storage duration charges apply. Standard-IA and One Zone-IA carry a 30-day minimum; Glacier Flexible Retrieval carries a 90-day minimum; Deep Archive carries a 180-day minimum. Transitioning before those thresholds does not block the transition, but you will be billed as if the object stayed for the full minimum period. See S3 cost optimisation for how these charges work in practice.

Expiration#

Deletes the current version of an object after a set number of days.

In a non-versioned bucket, expiration permanently removes the object.

In a versioned bucket, expiration adds a delete marker. The object still exists as a noncurrent version: it is hidden in normal listings but still stored and billed. To truly remove versioned objects, you need the two noncurrent-version rules below.

AbortIncompleteMultipartUpload#

S3’s multipart upload feature splits large files into parts uploaded individually. If an upload is interrupted by a network failure, a crashed process, or an abandoned script, the uploaded parts remain in storage and accumulate charges indefinitely. This action automatically cancels any multipart upload that has not completed within a specified number of days after initiation.

NoncurrentVersionTransition#

In versioned buckets, this moves older (noncurrent) versions to a cheaper storage class after they have been noncurrent for a set number of days. Useful for keeping old versions around for recovery without paying Standard prices for all of them.

NoncurrentVersionExpiration#

Permanently deletes noncurrent versions after they have been noncurrent for a set number of days. This is how you stop a versioned bucket from growing indefinitely. Without this rule, every overwrite generates a noncurrent version that sits in storage forever.

ExpiredObjectDeleteMarker#

When a delete marker has no remaining noncurrent versions beneath it, it is considered expired. Without this setting, expired delete markers accumulate and inflate your object count (and therefore your LIST request costs). Setting ExpiredObjectDeleteMarker: true in the expiration block tells S3 to clean these up automatically.

Practical examples

Example 1: Log retention with tiered transitions#

A standard pattern for application logs: active for 30 days, reference tier for 90 days, compliance archive until 365 days:

{
  "Rules": [
    {
      "ID": "log-retention-tiered",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "logs/"
      },
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        }
      ],
      "Expiration": {
        "Days": 365
      }
    }
  ]
}

Why this rule exists: logs are queried heavily in the first few days and occasionally over the following months. Past 90 days they are almost never accessed but must be retained for audits. Glacier Flexible Retrieval at day 90 keeps them accessible (with a restore step) at a fraction of Standard pricing. The day 365 expiration prevents indefinite accumulation.

The GLACIER storage class here refers to S3 Glacier Flexible Retrieval. Objects transitioned here cannot be read directly. They must be restored first, which takes 1–12 hours depending on the retrieval tier you request.

Example 2: Versioned bucket cleanup#

For a versioned bucket that receives frequent overwrites, this rule moves noncurrent versions to cheaper storage and eventually deletes them:

{
  "Rules": [
    {
      "ID": "versioned-bucket-cleanup",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionTransitions": [
        {
          "NoncurrentDays": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "NoncurrentDays": 90,
          "StorageClass": "GLACIER"
        }
      ],
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 365
      },
      "Expiration": {
        "ExpiredObjectDeleteMarker": true
      }
    }
  ]
}

Why this rule exists: without noncurrent-version management, every overwrite creates a new version that accumulates indefinitely. After 365 days as a noncurrent version, the old copy is permanently deleted. ExpiredObjectDeleteMarker: true prevents leftover delete markers from inflating object counts after the underlying versions are gone.

An empty Filter: {} means this rule applies to every object in the bucket.

Example 3: Incomplete multipart upload cleanup#

Add this to any bucket that receives large file uploads:

{
  "Rules": [
    {
      "ID": "abort-incomplete-multipart",
      "Status": "Enabled",
      "Filter": {},
      "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7
      }
    }
  ]
}

Why this rule exists: if a large upload fails halfway through, the parts uploaded so far are stored and billed even though the object is never completed. Without this rule, interrupted uploads silently accumulate over time. Seven days is long enough to cover retries; shorter is fine depending on your upload patterns.

You can combine this rule with the others above by adding multiple objects to the Rules array in a single lifecycle configuration.

S3 Lifecycle Policies vs S3 Intelligent-Tiering

Both tools reduce storage costs, but they approach the problem differently.

Many teams use both: lifecycle rules for objects with a known retention period, Intelligent-Tiering for long-lived assets with irregular access.

How to create a lifecycle rule

AWS Console#

1. Open the S3 console and select your bucket.
2. Go to the Management tab.
3. Click Create lifecycle rule.
4. Enter a rule name and choose the scope: all objects, or a specific prefix/tag filter.
5. Select the lifecycle rule actions you want: transitions, expiration, noncurrent-version actions, or incomplete multipart upload cleanup.
6. Configure the day thresholds for each action.
7. Review the summary and click Create rule.

The console shows a visual timeline as you configure thresholds, which helps verify the rule logic before saving.

AWS CLI#

Save your lifecycle configuration JSON to a file (for example, lifecycle.json), then apply it:

aws s3api put-bucket-lifecycle-configuration \
  --bucket your-bucket-name \
  --lifecycle-configuration file://lifecycle.json

To view the current lifecycle configuration on a bucket:

aws s3api get-bucket-lifecycle-configuration --bucket your-bucket-name

To delete all lifecycle rules from a bucket:

aws s3api delete-bucket-lifecycle --bucket your-bucket-name

For large file uploads that use multipart upload, see uploading files with the AWS CLI for how the multipart process works and when the AbortIncompleteMultipartUpload rule becomes important.