Lifecycle Rules & Storage Class Transitions

Q: Why did my Put wipe my other lifecycle rules?

PutBucketLifecycleConfiguration replaces the entire configuration. It is not additive. Read the current rules, add or edit, and send the complete set back every time.

Q: Which storage class should I transition to first?

STANDARD_IA after about 30 days is the common first step for data that is still occasionally read. Move to GLACIER_IR, GLACIER, or DEEP_ARCHIVE as access drops and retrieval latency becomes acceptable.

Q: Why did tiering small files increase my bill?

STANDARD_IA and Glacier classes bill a minimum object size (128 KB for IA) and minimum storage durations. Many tiny or short-lived objects can cost more tiered than left in Standard. Use Intelligent-Tiering or leave them in Standard.

Q: Can I target objects by tag instead of prefix?

Yes. A Filter can match a tag, a prefix, or both. To combine conditions, wrap them in Filter.And with Prefix and Tags.

Q: How do I clean up failed multipart uploads?

Add AbortIncompleteMultipartUpload with DaysAfterInitiation to a rule. S3 will abort and delete orphaned parts that would otherwise bill invisibly.

Q: How do I remove a lifecycle configuration?

Call DeleteBucketLifecycle (boto3 delete_bucket_lifecycle, SDK v3 DeleteBucketLifecycleCommand) to clear all rules on the bucket.

Most data cools off. A log written today is read constantly this week, occasionally next month, and almost never after a year - but if it sits in S3 Standard the whole time, you pay the top rate for storage nobody touches.

Lifecycle rules fix this without any code running on your side. You declare, once, that objects transition to cheaper storage classes as they age and expire when they are no longer needed. S3 enforces the policy continuously. This page shows how to write those rules with the SDK, what the storage classes cost you in trade-offs, and the gotchas that surprise people.

Recipe

Quick-reference recipe card - copy-paste ready.

# --- Python (boto3) ---
import boto3
 
s3 = boto3.client("s3")
s3.put_bucket_lifecycle_configuration(
    Bucket="my-bucket",
    LifecycleConfiguration={"Rules": [{
        "ID": "tier-logs",
        "Filter": {"Prefix": "logs/"},
        "Status": "Enabled",
        "Transitions": [{"Days": 30, "StorageClass": "STANDARD_IA"}],
        "Expiration": {"Days": 365},
    }]},
)

// --- TypeScript (AWS SDK v3) ---
import { S3Client, PutBucketLifecycleConfigurationCommand } from "@aws-sdk/client-s3";
 
const s3 = new S3Client({});
await s3.send(new PutBucketLifecycleConfigurationCommand({
  Bucket: "my-bucket",
  LifecycleConfiguration: { Rules: [{
    ID: "tier-logs",
    Filter: { Prefix: "logs/" },
    Status: "Enabled",
    Transitions: [{ Days: 30, StorageClass: "STANDARD_IA" }],
    Expiration: { Days: 365 },
  }]},
}));

When to reach for this:

Cutting storage cost on data that gets colder as it ages (logs, backups, media archives).
Automatically expiring temporary files, exports, or old versions.
Meeting retention policies that require deleting data after a fixed period.
Cleaning up incomplete multipart uploads that would otherwise bill silently.

Working Example

Apply a multi-stage lifecycle policy, then read it back to confirm.

# --- Python (boto3) ---
import boto3
 
s3 = boto3.client("s3")
bucket = "my-bucket"
 
s3.put_bucket_lifecycle_configuration(
    Bucket=bucket,
    LifecycleConfiguration={"Rules": [
        {
            "ID": "archive-media",
            "Filter": {"Prefix": "media/"},
            "Status": "Enabled",
            "Transitions": [
                {"Days": 30, "StorageClass": "STANDARD_IA"},
                {"Days": 90, "StorageClass": "GLACIER_IR"},
                {"Days": 365, "StorageClass": "DEEP_ARCHIVE"},
            ],
            "NoncurrentVersionExpiration": {"NoncurrentDays": 30},
            "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7},
        },
        {
            "ID": "expire-temp",
            "Filter": {"Prefix": "tmp/"},
            "Status": "Enabled",
            "Expiration": {"Days": 7},
        },
    ]},
)
 
current = s3.get_bucket_lifecycle_configuration(Bucket=bucket)
for rule in current["Rules"]:
    print(rule["ID"], rule["Status"])

// --- TypeScript (AWS SDK v3) ---
import {
  S3Client, PutBucketLifecycleConfigurationCommand, GetBucketLifecycleConfigurationCommand,
} from "@aws-sdk/client-s3";
 
const s3 = new S3Client({});
const Bucket = "my-bucket";
 
await s3.send(new PutBucketLifecycleConfigurationCommand({
  Bucket,
  LifecycleConfiguration: { Rules: [
    {
      ID: "archive-media",
      Filter: { Prefix: "media/" },
      Status: "Enabled",
      Transitions: [
        { Days: 30, StorageClass: "STANDARD_IA" },
        { Days: 90, StorageClass: "GLACIER_IR" },
        { Days: 365, StorageClass: "DEEP_ARCHIVE" },
      ],
      NoncurrentVersionExpiration: { NoncurrentDays: 30 },
      AbortIncompleteMultipartUpload: { DaysAfterInitiation: 7 },
    },
    {
      ID: "expire-temp",
      Filter: { Prefix: "tmp/" },
      Status: "Enabled",
      Expiration: { Days: 7 },
    },
  ]},
}));
 
const current = await s3.send(new GetBucketLifecycleConfigurationCommand({ Bucket }));
for (const rule of current.Rules ?? []) console.log(rule.ID, rule.Status);

What this demonstrates:

A single PutBucketLifecycleConfiguration call replaces the entire rule set - it is not additive.
One rule can chain multiple transitions, moving objects to progressively colder classes over time.
NoncurrentVersionExpiration cleans up old versions, and AbortIncompleteMultipartUpload sweeps orphaned parts.
Each rule is independently scoped by Filter (prefix or tag) and toggled with Status.

The same policy expressed as raw JSON - the shape you would store in version control or apply from IaC - looks like this:

{
  "Rules": [
    {
      "ID": "archive-media",
      "Filter": { "Prefix": "media/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Deep Dive

How It Works

A lifecycle configuration is an array of rules. Each rule has a Filter (prefix, tag, or both via And), a Status, and one or more actions.
Transitions move an object to a cheaper storage class after N days. Expiration deletes it. Both are keyed off the object's age since creation.
The whole configuration is replaced on every Put - there is no partial update, so always send the full desired rule set.
S3 evaluates rules asynchronously, typically once a day. An object crosses its transition or expiration boundary within about a day of the threshold, not to the exact second.

Choosing a Storage Class

Storage class	Best for	Trade-off
STANDARD_IA	Infrequent access, still needs milliseconds	30-day minimum, per-GB retrieval fee
GLACIER_IR (Instant Retrieval)	Archives you occasionally read instantly	90-day minimum, higher retrieval cost
GLACIER (Flexible Retrieval)	Rarely read, minutes-to-hours retrieval OK	90-day minimum, restore step required
DEEP_ARCHIVE	Long-term cold storage, hours to restore	180-day minimum, cheapest storage

The cheaper the class, the longer the minimum storage duration and the more retrieval costs. Transitioning too aggressively can cost more than it saves if objects are deleted or read before the minimum period.

Versioning Interactions

On a versioned bucket, Expiration on a current object just adds a delete marker - it does not free space. To actually reclaim storage, use NoncurrentVersionTransition and NoncurrentVersionExpiration to tier and remove old versions, and ExpiredObjectDeleteMarker to clean up dangling markers.

Gotchas

Put replaces, it does not append - a second PutBucketLifecycleConfiguration wipes the previous rules. Fix: read the current config, modify it, and put the complete set back.
Expiration on a versioned bucket frees nothing - it only adds a delete marker over the current version. Fix: add NoncurrentVersionExpiration (and expire delete markers) to reclaim space.
Transition minimums cost money - moving to STANDARD_IA then deleting at day 20 still bills the 30-day minimum. Fix: transition only objects that will outlive the class's minimum duration.
Small objects and IA - STANDARD_IA bills a 128 KB minimum per object, so tiering many tiny files can raise costs. Fix: keep small, short-lived objects in Standard, or use Intelligent-Tiering.
Transitions are not instant - rules run about once a day, so do not expect a change exactly at the day boundary. Fix: treat thresholds as "within a day," and verify with GetBucketLifecycleConfiguration, not by watching a single object.
Filter shape confusion - combining prefix and tags requires an And wrapper. Fix: use Filter.And with Prefix and Tags when you need multiple conditions.

Alternatives

Alternative	Use When	Don't Use When
Lifecycle rules (this page)	Automatic, age-based tiering and expiration	You need a one-time action on existing objects
S3 Intelligent-Tiering	Access patterns are unknown or unpredictable	Access is predictable and rules are cheaper
Manual CopyObject with StorageClass	A one-off move of specific objects now	Ongoing, age-based policy - use lifecycle instead
S3 Batch Operations	Applying an action across millions of existing objects	Continuous, age-triggered transitions
Deleting in application code	Immediate, event-driven deletion logic	Bulk time-based cleanup lifecycle handles for free

FAQs

Do lifecycle rules cost anything to run?

The evaluation is free; you pay only the per-object transition request fee and the destination class's storage and retrieval costs. For cold data this is almost always a net saving.

Why did my Put wipe my other lifecycle rules?

PutBucketLifecycleConfiguration replaces the entire configuration. It is not additive. Read the current rules, add or edit, and send the complete set back every time.

How quickly does a transition happen?

Asynchronously, usually within a day of the object reaching the threshold age. S3 processes lifecycle actions in a daily batch, so it is never to-the-second.

Which storage class should I transition to first?

STANDARD_IA after about 30 days is the common first step for data that is still occasionally read. Move to GLACIER_IR, GLACIER, or DEEP_ARCHIVE as access drops and retrieval latency becomes acceptable.

Why did tiering small files increase my bill?

STANDARD_IA and Glacier classes bill a minimum object size (128 KB for IA) and minimum storage durations. Many tiny or short-lived objects can cost more tiered than left in Standard. Use Intelligent-Tiering or leave them in Standard.

Does expiration delete objects on a versioned bucket?

Not really. It adds a delete marker over the current version, hiding it but keeping the data. Use NoncurrentVersionExpiration and expire delete markers to actually free storage.

Can I target objects by tag instead of prefix?

Yes. A Filter can match a tag, a prefix, or both. To combine conditions, wrap them in Filter.And with Prefix and Tags.

How do I clean up failed multipart uploads?

Add AbortIncompleteMultipartUpload with DaysAfterInitiation to a rule. S3 will abort and delete orphaned parts that would otherwise bill invisibly.

What is Intelligent-Tiering and when should I use it?

It is a storage class that moves objects between access tiers automatically based on observed usage, for a small monitoring fee. Use it when access patterns are unknown; use explicit lifecycle rules when they are predictable.

How do I remove a lifecycle configuration?

Call DeleteBucketLifecycle (boto3 delete_bucket_lifecycle, SDK v3 DeleteBucketLifecycleCommand) to clear all rules on the bucket.

Multipart Upload & the Transfer Manager - the incomplete uploads lifecycle rules clean up.
S3 Advanced Basics - listing and deleting the objects rules operate on.
S3 via SDK Best Practices - cost-control habits for high-volume buckets.
Amazon S3 via SDK: Buckets & Objects - the object model underneath.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Recipe

Quick-reference recipe card - copy-paste ready.

# --- Python (boto3) ---
import boto3
 
s3 = boto3.client("s3")
s3.put_bucket_lifecycle_configuration(
    Bucket="my-bucket",
    LifecycleConfiguration={"Rules": [{
        "ID": "tier-logs",
        "Filter": {"Prefix": "logs/"},
        "Status": "Enabled",
        "Transitions": [{"Days": 30, "StorageClass": "STANDARD_IA"}],
        "Expiration": {"Days": 365},
    }]},
)

// --- TypeScript (AWS SDK v3) ---
import { S3Client, PutBucketLifecycleConfigurationCommand } from "@aws-sdk/client-s3";
 
const s3 = new S3Client({});
await s3.send(new PutBucketLifecycleConfigurationCommand({
  Bucket: "my-bucket",
  LifecycleConfiguration: { Rules: [{
    ID: "tier-logs",
    Filter: { Prefix: "logs/" },
    Status: "Enabled",
    Transitions: [{ Days: 30, StorageClass: "STANDARD_IA" }],
    Expiration: { Days: 365 },
  }]},
}));

When to reach for this:

Cutting storage cost on data that gets colder as it ages (logs, backups, media archives).
Automatically expiring temporary files, exports, or old versions.
Meeting retention policies that require deleting data after a fixed period.
Cleaning up incomplete multipart uploads that would otherwise bill silently.

Working Example

Apply a multi-stage lifecycle policy, then read it back to confirm.

# --- Python (boto3) ---
import boto3
 
s3 = boto3.client("s3")
bucket = "my-bucket"
 
s3.put_bucket_lifecycle_configuration(
    Bucket=bucket,
    LifecycleConfiguration={"Rules": [
        {
            "ID": "archive-media",
            "Filter": {"Prefix": "media/"},
            "Status": "Enabled",
            "Transitions": [
                {"Days": 30, "StorageClass": "STANDARD_IA"},
                {"Days": 90, "StorageClass": "GLACIER_IR"},
                {"Days": 365, "StorageClass": "DEEP_ARCHIVE"},
            ],
            "NoncurrentVersionExpiration": {"NoncurrentDays": 30},
            "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7},
        },
        {
            "ID": "expire-temp",
            "Filter": {"Prefix": "tmp/"},
            "Status": "Enabled",
            "Expiration": {"Days": 7},
        },
    ]},
)
 
current = s3.get_bucket_lifecycle_configuration(Bucket=bucket)
for rule in current["Rules"]:
    print(rule["ID"], rule["Status"])

// --- TypeScript (AWS SDK v3) ---
import {
  S3Client, PutBucketLifecycleConfigurationCommand, GetBucketLifecycleConfigurationCommand,
} from "@aws-sdk/client-s3";
 
const s3 = new S3Client({});
const Bucket = "my-bucket";
 
await s3.send(new PutBucketLifecycleConfigurationCommand({
  Bucket,
  LifecycleConfiguration: { Rules: [
    {
      ID: "archive-media",
      Filter: { Prefix: "media/" },
      Status: "Enabled",
      Transitions: [
        { Days: 30, StorageClass: "STANDARD_IA" },
        { Days: 90, StorageClass: "GLACIER_IR" },
        { Days: 365, StorageClass: "DEEP_ARCHIVE" },
      ],
      NoncurrentVersionExpiration: { NoncurrentDays: 30 },
      AbortIncompleteMultipartUpload: { DaysAfterInitiation: 7 },
    },
    {
      ID: "expire-temp",
      Filter: { Prefix: "tmp/" },
      Status: "Enabled",
      Expiration: { Days: 7 },
    },
  ]},
}));
 
const current = await s3.send(new GetBucketLifecycleConfigurationCommand({ Bucket }));
for (const rule of current.Rules ?? []) console.log(rule.ID, rule.Status);

What this demonstrates:

A single PutBucketLifecycleConfiguration call replaces the entire rule set - it is not additive.
One rule can chain multiple transitions, moving objects to progressively colder classes over time.
NoncurrentVersionExpiration cleans up old versions, and AbortIncompleteMultipartUpload sweeps orphaned parts.
Each rule is independently scoped by Filter (prefix or tag) and toggled with Status.

The same policy expressed as raw JSON - the shape you would store in version control or apply from IaC - looks like this:

{
  "Rules": [
    {
      "ID": "archive-media",
      "Filter": { "Prefix": "media/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

Deep Dive

How It Works

A lifecycle configuration is an array of rules. Each rule has a Filter (prefix, tag, or both via And), a Status, and one or more actions.
Transitions move an object to a cheaper storage class after N days. Expiration deletes it. Both are keyed off the object's age since creation.
The whole configuration is replaced on every Put - there is no partial update, so always send the full desired rule set.
S3 evaluates rules asynchronously, typically once a day. An object crosses its transition or expiration boundary within about a day of the threshold, not to the exact second.

Choosing a Storage Class

Storage class	Best for	Trade-off
STANDARD_IA	Infrequent access, still needs milliseconds	30-day minimum, per-GB retrieval fee
GLACIER_IR (Instant Retrieval)	Archives you occasionally read instantly	90-day minimum, higher retrieval cost
GLACIER (Flexible Retrieval)	Rarely read, minutes-to-hours retrieval OK	90-day minimum, restore step required
DEEP_ARCHIVE	Long-term cold storage, hours to restore	180-day minimum, cheapest storage

Versioning Interactions

Gotchas

Put replaces, it does not append - a second PutBucketLifecycleConfiguration wipes the previous rules. Fix: read the current config, modify it, and put the complete set back.
Expiration on a versioned bucket frees nothing - it only adds a delete marker over the current version. Fix: add NoncurrentVersionExpiration (and expire delete markers) to reclaim space.
Transition minimums cost money - moving to STANDARD_IA then deleting at day 20 still bills the 30-day minimum. Fix: transition only objects that will outlive the class's minimum duration.
Small objects and IA - STANDARD_IA bills a 128 KB minimum per object, so tiering many tiny files can raise costs. Fix: keep small, short-lived objects in Standard, or use Intelligent-Tiering.
Transitions are not instant - rules run about once a day, so do not expect a change exactly at the day boundary. Fix: treat thresholds as "within a day," and verify with GetBucketLifecycleConfiguration, not by watching a single object.
Filter shape confusion - combining prefix and tags requires an And wrapper. Fix: use Filter.And with Prefix and Tags when you need multiple conditions.

Alternatives

Alternative	Use When	Don't Use When
Lifecycle rules (this page)	Automatic, age-based tiering and expiration	You need a one-time action on existing objects
S3 Intelligent-Tiering	Access patterns are unknown or unpredictable	Access is predictable and rules are cheaper
Manual CopyObject with StorageClass	A one-off move of specific objects now	Ongoing, age-based policy - use lifecycle instead
S3 Batch Operations	Applying an action across millions of existing objects	Continuous, age-triggered transitions
Deleting in application code	Immediate, event-driven deletion logic	Bulk time-based cleanup lifecycle handles for free

FAQs

Do lifecycle rules cost anything to run?

The evaluation is free; you pay only the per-object transition request fee and the destination class's storage and retrieval costs. For cold data this is almost always a net saving.

Why did my Put wipe my other lifecycle rules?

PutBucketLifecycleConfiguration replaces the entire configuration. It is not additive. Read the current rules, add or edit, and send the complete set back every time.

How quickly does a transition happen?

Asynchronously, usually within a day of the object reaching the threshold age. S3 processes lifecycle actions in a daily batch, so it is never to-the-second.

Which storage class should I transition to first?

Why did tiering small files increase my bill?

Does expiration delete objects on a versioned bucket?

Not really. It adds a delete marker over the current version, hiding it but keeping the data. Use NoncurrentVersionExpiration and expire delete markers to actually free storage.

Can I target objects by tag instead of prefix?

Yes. A Filter can match a tag, a prefix, or both. To combine conditions, wrap them in Filter.And with Prefix and Tags.

How do I clean up failed multipart uploads?

Add AbortIncompleteMultipartUpload with DaysAfterInitiation to a rule. S3 will abort and delete orphaned parts that would otherwise bill invisibly.

What is Intelligent-Tiering and when should I use it?

How do I remove a lifecycle configuration?

Call DeleteBucketLifecycle (boto3 delete_bucket_lifecycle, SDK v3 DeleteBucketLifecycleCommand) to clear all rules on the bucket.

Multipart Upload & the Transfer Manager - the incomplete uploads lifecycle rules clean up.
S3 Advanced Basics - listing and deleting the objects rules operate on.
S3 via SDK Best Practices - cost-control habits for high-volume buckets.
Amazon S3 via SDK: Buckets & Objects - the object model underneath.

Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).

Lifecycle Rules & Storage Class Transitions

Search Documentation

Lifecycle Rules & Storage Class Transitions