Automating Archive Lifecycle Transitions

Q: How do I make S3 archive objects automatically as they age?

Set a lifecycle rule with a Transitions array via PutBucketLifecycleConfiguration, naming a Days age and an archival StorageClass such as GLACIER or DEEP_ARCHIVE. S3 runs the policy for you - no cron job needed.

Q: Can one rule transition through several classes?

Yes. A single rule's Transitions array can chain multiple steps - for example STANDARD_IA at 30 days, GLACIER_IR at 90, and DEEP_ARCHIVE at 365 - cooling the object stage by stage.

Q: Why did applying a new rule delete my other rules?

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

Q: Why did tiering small files raise my bill?

STANDARD_IA and Glacier classes apply minimum object sizes (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 warm.

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

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

Writing an object straight into DEEP_ARCHIVE works when you already know it is cold. But most data does not start cold - it starts warm, gets read for a while, and cools off over weeks or months. Re-tiering it by hand does not scale.

Lifecycle transitions solve this. You declare, once, that objects move into cheaper archival classes as they age, and S3 enforces the policy continuously with no code running on your side. This page shows how to write those transition rules with the SDK, how to chain them so data cools in stages, and the gotchas that catch 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": "archive-logs",
        "Filter": {"Prefix": "logs/"},
        "Status": "Enabled",
        "Transitions": [{"Days": 90, "StorageClass": "GLACIER"}],
    }]},
)

// --- 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: "archive-logs",
    Filter: { Prefix: "logs/" },
    Status: "Enabled",
    Transitions: [{ Days: 90, StorageClass: "GLACIER" }],
  }]},
}));

When to reach for this:

Data that starts warm and predictably cools with age (logs, backups, records, media).
Cutting storage cost automatically without a scheduled job or manual re-tiering.
Enforcing a retention policy that tiers, then eventually expires, aged data.
Applying one archival policy consistently across a prefix or the whole bucket.

Working Example

Apply a staged policy that cools objects through the archival classes and then expires them, then read the configuration back to confirm.

# --- Python (boto3) ---
import boto3
 
s3 = boto3.client("s3")
bucket = "my-bucket"
 
s3.put_bucket_lifecycle_configuration(
    Bucket=bucket,
    LifecycleConfiguration={"Rules": [{
        "ID": "cool-then-expire",
        "Filter": {"Prefix": "records/"},
        "Status": "Enabled",
        "Transitions": [
            {"Days": 30, "StorageClass": "STANDARD_IA"},
            {"Days": 90, "StorageClass": "GLACIER_IR"},
            {"Days": 180, "StorageClass": "GLACIER"},
            {"Days": 365, "StorageClass": "DEEP_ARCHIVE"},
        ],
        "Expiration": {"Days": 2555},   # ~7 years
    }]},
)
 
current = s3.get_bucket_lifecycle_configuration(Bucket=bucket)
for rule in current["Rules"]:
    print(rule["ID"], rule["Status"], len(rule.get("Transitions", [])), "transitions")

// --- 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: "cool-then-expire",
    Filter: { Prefix: "records/" },
    Status: "Enabled",
    Transitions: [
      { Days: 30, StorageClass: "STANDARD_IA" },
      { Days: 90, StorageClass: "GLACIER_IR" },
      { Days: 180, StorageClass: "GLACIER" },
      { Days: 365, StorageClass: "DEEP_ARCHIVE" },
    ],
    Expiration: { Days: 2555 },   // ~7 years
  }]},
}));
 
const current = await s3.send(new GetBucketLifecycleConfigurationCommand({ Bucket }));
for (const rule of current.Rules ?? []) {
  console.log(rule.ID, rule.Status, (rule.Transitions ?? []).length, "transitions");
}

What this demonstrates:

One rule chains four transitions, cooling objects step by step as they age.
A single PutBucketLifecycleConfiguration replaces the entire rule set - it is not additive.
Filter scopes the rule to a prefix; Expiration deletes objects once retention ends.
GetBucketLifecycleConfiguration reads the live policy back for verification.

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

{
  "Rules": [
    {
      "ID": "cool-then-expire",
      "Filter": { "Prefix": "records/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" },
        { "Days": 180, "StorageClass": "GLACIER" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 2555 }
    }
  ]
}

Deep Dive

How Transitions Run

A lifecycle configuration is an array of rules, each with a Filter, a Status, and actions. A Transition names a Days age and a target StorageClass. S3 evaluates rules asynchronously - typically once a day - so an object crosses its transition boundary within about a day of the threshold, not to the exact second.

Chaining the Archival Classes

One rule can carry several transitions, moving an object into progressively colder classes over time. A common shape is Standard, then STANDARD_IA around 30 days, then GLACIER_IR or GLACIER around 90, then DEEP_ARCHIVE for long-term retention. You transition forward through the cost curve; lifecycle does not move objects back to warmer classes.

Transition Constraints Worth Knowing

Transitions are one-directional toward colder, cheaper classes - there is no warm-up transition.
Each destination class carries a minimum storage duration (90 days for Glacier classes, 180 for Deep Archive), so back-to-back transitions still owe the minimums.
STANDARD_IA bills a 128 KB minimum object size, so tiering many tiny objects can cost more than leaving them warm.
A single PutBucketLifecycleConfiguration overwrites the whole configuration - read, modify, and write the full set to change one rule.

Transition Versus Direct Write

Use lifecycle transitions for data that starts warm and cools with age. For data you already know is cold at write time, skip the wait and set StorageClass directly on put_object - it lands in the archival class immediately, with no transition delay and no transition request fee.

Gotchas

Put replaces, it does not append - a second PutBucketLifecycleConfiguration wipes the previous rules. Fix: read the current config, edit it, and put the complete set back.
Expecting instant transitions - rules run about once a day, so a change is not exactly at the day boundary. Fix: treat thresholds as "within a day" and verify with GetBucketLifecycleConfiguration.
Tiering tiny objects into IA or Glacier - minimum object sizes and durations can make small files cost more archived. Fix: keep small, short-lived objects in Standard, or use Intelligent-Tiering.
Deleting before the minimum duration - transitioning to Glacier then deleting early still bills the class minimum. Fix: only transition objects that will outlive the destination's minimum.
Assuming lifecycle warms objects back up - transitions only go colder; there is no automatic un-archive. Fix: restore with restore_object when you need a cold object read.
Filter shape confusion - combining a prefix and tags needs an And wrapper. Fix: use Filter.And with Prefix and Tags for multi-condition rules.

Alternatives

Alternative	Use When	Don't Use When
Lifecycle transitions (this page)	Data starts warm and cools predictably with age	Data is born cold - write the class directly
Direct `StorageClass` on put	You already know the object is cold at write time	Data should cool gradually over time
S3 Intelligent-Tiering	Access patterns are unknown or fluctuate	Access is predictable and explicit rules are cheaper
`CopyObject` with new StorageClass	A one-off re-tier of specific objects now	Ongoing, age-based policy - use lifecycle
S3 Batch Operations	Re-tiering millions of existing objects at once	Continuous, age-triggered transitions

FAQs

How do I make S3 archive objects automatically as they age?

Set a lifecycle rule with a Transitions array via PutBucketLifecycleConfiguration, naming a Days age and an archival StorageClass such as GLACIER or DEEP_ARCHIVE. S3 runs the policy for you - no cron job needed.

Can one rule transition through several classes?

Yes. A single rule's Transitions array can chain multiple steps - for example STANDARD_IA at 30 days, GLACIER_IR at 90, and DEEP_ARCHIVE at 365 - cooling the object stage by stage.

Why did applying a new rule delete my other rules?

PutBucketLifecycleConfiguration replaces the entire configuration; it is not additive. Read the current rules with GetBucketLifecycleConfiguration, 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 roughly daily batch, so it is never to-the-second.

Should I use lifecycle transitions or write the class directly?

Use transitions for data that starts warm and cools over time. If the object is already cold when you write it, set StorageClass directly on put_object to skip the transition delay and its per-object request fee.

Can lifecycle move an object back to a warmer class?

No. Transitions only go toward colder, cheaper classes. To read a cold GLACIER or DEEP_ARCHIVE object, issue a restore_object to stage a temporary readable copy - lifecycle will not un-archive it.

Why did tiering small files raise my bill?

STANDARD_IA and Glacier classes apply minimum object sizes (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 warm.

Can I target objects by tag instead of prefix?

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

Lifecycle Rules & Storage Class Transitions - the full lifecycle feature, including expiration and versioning.
S3 Glacier Storage Classes via S3 API - the archival classes these rules target.
Archival Storage's Retrieval-Time Trade-off - choosing which class to cool into.
Archival Storage Best Practices - designing retention and avoiding surprise costs.

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": "archive-logs",
        "Filter": {"Prefix": "logs/"},
        "Status": "Enabled",
        "Transitions": [{"Days": 90, "StorageClass": "GLACIER"}],
    }]},
)

// --- 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: "archive-logs",
    Filter: { Prefix: "logs/" },
    Status: "Enabled",
    Transitions: [{ Days: 90, StorageClass: "GLACIER" }],
  }]},
}));

When to reach for this:

Data that starts warm and predictably cools with age (logs, backups, records, media).
Cutting storage cost automatically without a scheduled job or manual re-tiering.
Enforcing a retention policy that tiers, then eventually expires, aged data.
Applying one archival policy consistently across a prefix or the whole bucket.

Working Example

Apply a staged policy that cools objects through the archival classes and then expires them, then read the configuration back to confirm.

# --- Python (boto3) ---
import boto3
 
s3 = boto3.client("s3")
bucket = "my-bucket"
 
s3.put_bucket_lifecycle_configuration(
    Bucket=bucket,
    LifecycleConfiguration={"Rules": [{
        "ID": "cool-then-expire",
        "Filter": {"Prefix": "records/"},
        "Status": "Enabled",
        "Transitions": [
            {"Days": 30, "StorageClass": "STANDARD_IA"},
            {"Days": 90, "StorageClass": "GLACIER_IR"},
            {"Days": 180, "StorageClass": "GLACIER"},
            {"Days": 365, "StorageClass": "DEEP_ARCHIVE"},
        ],
        "Expiration": {"Days": 2555},   # ~7 years
    }]},
)
 
current = s3.get_bucket_lifecycle_configuration(Bucket=bucket)
for rule in current["Rules"]:
    print(rule["ID"], rule["Status"], len(rule.get("Transitions", [])), "transitions")

// --- 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: "cool-then-expire",
    Filter: { Prefix: "records/" },
    Status: "Enabled",
    Transitions: [
      { Days: 30, StorageClass: "STANDARD_IA" },
      { Days: 90, StorageClass: "GLACIER_IR" },
      { Days: 180, StorageClass: "GLACIER" },
      { Days: 365, StorageClass: "DEEP_ARCHIVE" },
    ],
    Expiration: { Days: 2555 },   // ~7 years
  }]},
}));
 
const current = await s3.send(new GetBucketLifecycleConfigurationCommand({ Bucket }));
for (const rule of current.Rules ?? []) {
  console.log(rule.ID, rule.Status, (rule.Transitions ?? []).length, "transitions");
}

What this demonstrates:

One rule chains four transitions, cooling objects step by step as they age.
A single PutBucketLifecycleConfiguration replaces the entire rule set - it is not additive.
Filter scopes the rule to a prefix; Expiration deletes objects once retention ends.
GetBucketLifecycleConfiguration reads the live policy back for verification.

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

{
  "Rules": [
    {
      "ID": "cool-then-expire",
      "Filter": { "Prefix": "records/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" },
        { "Days": 180, "StorageClass": "GLACIER" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 2555 }
    }
  ]
}

Deep Dive

How Transitions Run

Chaining the Archival Classes

Transition Constraints Worth Knowing

Transitions are one-directional toward colder, cheaper classes - there is no warm-up transition.
Each destination class carries a minimum storage duration (90 days for Glacier classes, 180 for Deep Archive), so back-to-back transitions still owe the minimums.
STANDARD_IA bills a 128 KB minimum object size, so tiering many tiny objects can cost more than leaving them warm.
A single PutBucketLifecycleConfiguration overwrites the whole configuration - read, modify, and write the full set to change one rule.

Transition Versus Direct Write

Gotchas

Put replaces, it does not append - a second PutBucketLifecycleConfiguration wipes the previous rules. Fix: read the current config, edit it, and put the complete set back.
Expecting instant transitions - rules run about once a day, so a change is not exactly at the day boundary. Fix: treat thresholds as "within a day" and verify with GetBucketLifecycleConfiguration.
Tiering tiny objects into IA or Glacier - minimum object sizes and durations can make small files cost more archived. Fix: keep small, short-lived objects in Standard, or use Intelligent-Tiering.
Deleting before the minimum duration - transitioning to Glacier then deleting early still bills the class minimum. Fix: only transition objects that will outlive the destination's minimum.
Assuming lifecycle warms objects back up - transitions only go colder; there is no automatic un-archive. Fix: restore with restore_object when you need a cold object read.
Filter shape confusion - combining a prefix and tags needs an And wrapper. Fix: use Filter.And with Prefix and Tags for multi-condition rules.

Alternatives

Alternative	Use When	Don't Use When
Lifecycle transitions (this page)	Data starts warm and cools predictably with age	Data is born cold - write the class directly
Direct `StorageClass` on put	You already know the object is cold at write time	Data should cool gradually over time
S3 Intelligent-Tiering	Access patterns are unknown or fluctuate	Access is predictable and explicit rules are cheaper
`CopyObject` with new StorageClass	A one-off re-tier of specific objects now	Ongoing, age-based policy - use lifecycle
S3 Batch Operations	Re-tiering millions of existing objects at once	Continuous, age-triggered transitions

FAQs

How do I make S3 archive objects automatically as they age?

Can one rule transition through several classes?

Yes. A single rule's Transitions array can chain multiple steps - for example STANDARD_IA at 30 days, GLACIER_IR at 90, and DEEP_ARCHIVE at 365 - cooling the object stage by stage.

Why did applying a new rule delete my other rules?

How quickly does a transition happen?

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

Should I use lifecycle transitions or write the class directly?

Can lifecycle move an object back to a warmer class?

Why did tiering small files raise my bill?

Can I target objects by tag instead of prefix?

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

Lifecycle Rules & Storage Class Transitions - the full lifecycle feature, including expiration and versioning.
S3 Glacier Storage Classes via S3 API - the archival classes these rules target.
Archival Storage's Retrieval-Time Trade-off - choosing which class to cool into.
Archival Storage Best Practices - designing retention and avoiding surprise costs.

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

Automating Archive Lifecycle Transitions

Buscar en la documentación

Automating Archive Lifecycle Transitions