Amazon S3 Lifecycle lets you define rules that transition or expire objects in a bucket. A rule can cover a bucket or a filtered set of objects, and can manage current versions, noncurrent versions, expired delete markers, or incomplete multipart uploads.

Lifecycle rules follow object age and configured filters; they do not detect whether an object has actually been accessed. A transition set for 90 days means 90 days since the object was created or last modified, not 90 days of inactivity. For changing or unknown access patterns, compare S3 Intelligent-Tiering with age-based rules. Storage-class tradeoffs are covered in our Amazon S3 storage class guide.

How S3 Lifecycle rules work

A lifecycle rule combines a filter with one or more actions. You can filter by key prefix, object tags, object size, or combinations of those fields. For transition and expiration actions, Days is measured from object creation (the last-modified time). For actions on noncurrent versions, NoncurrentDays is measured from when a version became noncurrent.

Rules apply to existing objects as well as future objects. If an existing object already meets a rule's age and filter conditions, S3 can begin processing it after you save the configuration. Transitions and deletions are asynchronous, so an eligible action may complete later than the rule's day threshold.

  • Transition: move current or noncurrent versions to a supported storage class.
  • Expiration: expire current versions, permanently delete selected noncurrent versions, or remove eligible expired object delete markers. The effect depends on bucket versioning.
  • Abort incomplete multipart uploads: stop unfinished uploads after a chosen number of days and remove their stored parts.

A lifecycle policy is a schedule based on age and filters, not a record of actual reads. Use observed access data when deciding which objects belong in a colder class.

Check transition and storage costs

S3 supports specific transition paths between storage classes. For example, objects in S3 Standard can move to Standard-IA, Intelligent-Tiering, One Zone-IA, Glacier Instant Retrieval, Glacier Flexible Retrieval, or Glacier Deep Archive. Later transitions are more limited: Glacier Flexible Retrieval can transition to Deep Archive, while Deep Archive cannot transition to another class through Lifecycle. Check AWS's supported transition paths before building a sequence of rules.

The lowest storage rate does not always produce the lowest bill. Compare expected retention, object sizes, reads, restores, and transitions for the bucket's Region. Common cost conditions include:

Storage class Conditions to include in an estimate
S3 Standard-IA and S3 One Zone-IA 30-day minimum storage duration; objects smaller than 128 KB are billed as 128 KB; retrieval charges apply. One Zone-IA stores data in one Availability Zone.
S3 Glacier Instant Retrieval 90-day minimum storage duration; 128 KB minimum billable object size; retrieval charges apply.
S3 Glacier Flexible Retrieval 90-day minimum storage duration; a restore is required before reading; retrieval and restore charges can apply. Each archived object also has 40 KB of metadata overhead, billed partly at S3 Standard rates and partly at the Glacier rate.
S3 Glacier Deep Archive 180-day minimum storage duration; a restore is required before reading; retrieval and restore charges can apply. Each archived object also has 40 KB of metadata overhead.

Since July 2026, new S3 Lifecycle rules can transition current object versions from S3 Standard to Standard-IA or One Zone-IA on day 0; the previous 30-day wait in Standard has been removed. The destination classes still have a 30-day minimum billable duration: deleting, overwriting, or transitioning an object out before 30 days in either class incurs a prorated charge. See AWS's announcement of the transition change.

Deleting, overwriting, or transitioning an object before its class's minimum storage duration ends can leave a prorated minimum-duration charge. In a transition chain, schedule the next step after the current class's minimum duration; a single rule cannot transition out earlier, and separate rules can still incur the remaining charge. For Glacier Flexible Retrieval and Deep Archive, destination-class billing and the minimum-duration clock start when the rule is satisfied, even if the physical transition is delayed. Restores create a temporary copy that is billed while the archive remains stored. Transition requests also have a per-object cost, so moving many small files can offset storage savings. Review the current Amazon S3 pricing and storage class details for your Region.

Since September 2024, the default behavior for new and modified lifecycle configurations prevents objects smaller than 128 KB from transitioning to any storage class. Configurations created before that change keep their previous behavior until modified; modifying one applies the newer default. Explicit object-size filters can override the default, but include small objects only after estimating transition and storage charges.

Create a scoped lifecycle rule

You can configure S3 Lifecycle in the Amazon S3 console, AWS CLI, an SDK, or the REST API. Before changing a bucket, inspect its current configuration and merge any rules you intend to keep. The put-bucket-lifecycle-configuration operation replaces the bucket's entire lifecycle configuration.

This complete JSON example transitions objects under the application-logs/ prefix to S3 Glacier Flexible Retrieval 90 days after creation. It has no expiration action, and objects smaller than 128 KB are excluded by the current default behavior:

{
  "Rules": [
    {
      "ID": "archive-application-logs",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "application-logs/"
      },
      "Transitions": [
        {
          "Days": 90,
          "StorageClass": "GLACIER"
        }
      ]
    }
  ]
}

Save the JSON as lifecycle.json. For a bucket with no other lifecycle rules, the CLI command to apply it is:

aws s3api put-bucket-lifecycle-configuration --bucket YOUR_BUCKET_NAME --lifecycle-configuration file://lifecycle.json --region YOUR_REGION

For a bucket that already has rules, include every rule you want to retain in the file before applying it. A matching object that already meets the 90-day age condition may become eligible soon after the configuration is saved. Retrieve the configuration again with get-bucket-lifecycle-configuration to confirm which rules are active.

Best practices for S3 Lifecycle rules

  • Define the data's retention and recovery needs before choosing a transition or expiration age.
  • Use a narrow prefix or tags when only part of a bucket shares the same lifecycle.
  • Check representative object ages, sizes, and version counts before enabling a rule on an existing prefix.
  • Model transition requests, retrieval or restore charges, minimum durations, and metadata overhead along with storage rates.
  • Use a small test prefix or disposable data to check the selected scope and actions before applying a rule to production data.

Account for versioning and delete markers

Versioning is not required for S3 Lifecycle. In a bucket without versioning, expiration permanently deletes the current object. In a versioning-enabled bucket, expiring a current version usually adds a delete marker and keeps the prior version as noncurrent data. That retained version continues to use storage.

To permanently remove older versions, configure a separate noncurrent-version expiration action with a retention period that matches your recovery needs. This action permanently deletes those versions. When only a delete marker remains and no object versions remain, Lifecycle can remove the expired object delete marker. Do not assume that current-version expiration alone clears a versioned object or its stored history.

Choose actions for current and noncurrent versions

Current-version transition or expiration rules do not automatically manage every previous version. In a versioned bucket, choose separately whether noncurrent versions should remain in their current class, transition to a colder class, or expire after they become noncurrent. If you configure both an age and a newer-version retention count, AWS requires both conditions to be met before the noncurrent version is transitioned or deleted.

Review the affected objects before enabling a rule

Use an S3 Inventory report or version listings to check which existing objects match a prefix or tag, how old they are, and whether earlier versions will remain stored. Confirm that the target bucket and complete lifecycle configuration are correct before saving. Afterward, verify the stored rules and review object versions or Inventory results as Lifecycle processes them; the configured age is not a promise that an action happens at an exact moment.

Frequently asked questions

Do Lifecycle rules measure inactivity?

No. A rule's Days value is based on an object's creation or last-modified time, and noncurrent-version actions count from when a version became noncurrent. Lifecycle does not reset an object's age when it is read.

Can Lifecycle delete objects in a versioning-enabled bucket?

Current-version expiration normally creates a delete marker, leaving the previous version stored as noncurrent. To permanently delete previous versions, configure noncurrent-version expiration; expired delete markers can be removed when no object versions remain.

Do S3 Lifecycle rules apply to existing objects?

Yes. A new or updated lifecycle configuration applies to existing objects that match its filters. Objects already older than the configured age can become eligible soon after you add the rule, although processing is asynchronous.

Can Lifecycle transition an object to any storage class?

No. S3 permits specific transition paths, and the default transition behavior excludes objects smaller than 128 KB for new or modified configurations. Check both the supported path and the object's size before relying on a transition.

Use lifecycle rules with retention and recovery in mind

S3 Lifecycle can reduce manual storage management and may lower costs when object age, access needs, and retention are well understood. Scope each rule carefully, calculate the full cost of its destination class, and decide explicitly what should happen to noncurrent versions before enabling expiration.