In Amazon S3, what does a bucket's Lifecycle configuration do, and what are the two kinds of action a lifecycle rule can take?
answer
- bucket-level rules, not per-object calls
- two verbs only
- filter by prefix, tag, or object size
- S3 runs it asynchronously in the background
- one-way down the cost waterfall
basics
~20 sAn S3 Lifecycle configuration is a set of bucket-level rules that act on objects automatically as they age. A rule takes one of two kinds of action: transition an object to a cheaper storage class, or expire (delete) it.
solid answer
~40 sS3 Lifecycle is a configuration you attach to a bucket, not something you call per object. Each rule has a filter that selects objects — by key prefix, by tag, by object size, or the whole bucket — and one or more actions keyed to the object's age in days. The two action families are **transition**, which moves the object to a cheaper storage class such as `STANDARD_IA`, `GLACIER_IR` or `DEEP_ARCHIVE`, and **expiration**, which deletes it. S3 evaluates the rules for you in the background, asynchronously, so a move can lag a day or two past the threshold — you never invoke it. Transitions run one way down the cost waterfall; getting an object back to S3 Standard means copying it, not writing a reverse rule.
code
json · 19 lines{
"Rules": [
{
"ID": "logs-tier-then-expire",
"Status": "Enabled",
"Filter": {
"And": {
"Prefix": "logs/",
"ObjectSizeGreaterThan": 131072
}
},
"Transitions": [
{ "Days": 30, "StorageClass": "STANDARD_IA" },
{ "Days": 90, "StorageClass": "GLACIER_IR" }
],
"Expiration": { "Days": 365 }
}
]
}go deeper
Be ready to name the two actions — transition and expiration — and to say that the configuration lives on the bucket and is applied by S3 automatically as objects age.
Explain the rule anatomy: filter by prefix, tag or object size, several transitions plus an expiration in one rule, ages measured from creation, and asynchronous execution rather than an instant move.
Show the operational instinct: never assume a transition has completed, verify the reported storage class before a dependent step, and know that a rule sweeping millions of small objects costs transition requests that can outweigh the savings.
Own the policy layer — a lifecycle standard applied across an estate through a template, decided from measured access data rather than a guessed 30-day threshold, with the one-way waterfall and the cost of un-archiving factored into the retention design.
## What a lifecycle configuration actually is A lifecycle configuration is a document attached to a bucket (`PutBucketLifecycleConfiguration` in the API, `aws s3api put-bucket-lifecycle-configuration` on the CLI). It contains a list of rules, and S3's own background machinery evaluates them against every object in the bucket. Nothing in your application calls it. This is the single most important framing: lifecycle is a *declarative policy about object age*, evaluated by S3, not an operation you trigger. Each rule has three parts: an identifier and a status (`Enabled` or `Disabled`), a filter that decides which objects the rule applies to, and the actions. ## The two kinds of action **Transition** changes the object's storage class. The classes you can transition into include `STANDARD_IA` and `ONEZONE_IA` (infrequent access), `INTELLIGENT_TIERING`, `GLACIER_IR` (Glacier Instant Retrieval), `GLACIER` (Glacier Flexible Retrieval) and `DEEP_ARCHIVE`. The object's bytes, key and metadata are unchanged; what changes is the per-GB storage rate you pay, and the retrieval terms attached to that class. **Expiration** deletes the object. In a bucket without versioning that is a permanent delete. In a versioned bucket, expiring the current version writes a delete marker instead of destroying data, which is a common source of surprise when a "cleanup" rule fails to shrink the bill. A single rule can carry several transitions plus an expiration, forming a staircase: Standard for 30 days, then Standard-IA, then Glacier at 90 days, then gone at a year. ## How rules are scoped The `Filter` element selects objects. It supports a key `Prefix` (`logs/2025/`), an object `Tag` key-value pair, `ObjectSizeGreaterThan` and `ObjectSizeLessThan` in bytes, and an empty filter meaning the entire bucket. To combine more than one condition you nest them under `And`: ```json "Filter": { "And": { "Prefix": "logs/", "ObjectSizeGreaterThan": 131072 } } ``` The size filters matter more than they look: they are how you keep a rule from sweeping up tiny objects that cost more in a cheaper class than they did in Standard. ## Timing: age, not access, and not instant The `Days` value is measured from the object's creation date, not from when it was last read. Lifecycle has no idea whether anyone is reading the data — if you want access-driven tiering, that is what S3 Intelligent-Tiering is for. You can also use `Date` for an absolute cut-off instead of a relative age. Execution is asynchronous. S3 queues eligible objects and processes them in the background; the object can still report its old storage class for a while after the threshold passes. Never build a workflow that assumes an object moved at exactly midnight on day 30 — if a downstream step depends on the class, read it back with `HeadObject` and branch on the reported `StorageClass`. ## The waterfall is one-way Lifecycle transitions only move down the cost/latency ladder: Standard to IA to Glacier classes to Deep Archive. There is no rule that promotes an object back to S3 Standard. If data turns out to be hot again, you copy the object over itself with the desired storage class (`CopyObject` with the same key and `StorageClass=STANDARD`), which is a billable PUT plus, for archived classes, a restore first. ## What lifecycle is not It does not move objects between buckets — that is replication. It does not compress or re-encrypt anything. It does not back anything up. And a transition is not free: each object moved incurs a lifecycle transition request charge, which is why a rule applied blindly to hundreds of millions of small objects can cost more than it saves. ## The shape of the answer in an interview Say it in one breath: bucket-level rules, filtered by prefix, tag or size, with two verbs — transition and expire — evaluated against object age by S3 in the background, one-way down the class waterfall. Then reach for the real question underneath, which is almost always "so how would you cut this S3 bill?"
- Is the Days value counted from when the object was uploaded or from when it was last read?From creation. Lifecycle is purely age-based and has no visibility into access patterns, so a file read every hour still transitions on schedule. If you need access-driven placement you use S3 Intelligent-Tiering, which watches reads and moves objects between its tiers itself.
- How soon after an object crosses the threshold does the transition actually happen?Not instantly. S3 evaluates rules asynchronously and queues eligible objects, so the move typically completes within a day or so of eligibility rather than at a precise moment. Any workflow that depends on the class having changed should confirm it by reading the object's reported storage class rather than assuming.
- Can a lifecycle rule move an object from Glacier back to S3 Standard when it becomes hot again?No. Transitions only go down the waterfall. To get an object back into S3 Standard you copy it onto itself specifying the Standard storage class — and if it sits in Glacier Flexible Retrieval or Deep Archive you must restore it first, because it cannot be read directly.
saying these in an interview costs you the question
- Thinks the transition happens instantly at the moment of eligibility
- Believes a lifecycle rule can promote objects back to S3 Standard
- Confuses lifecycle transitions with replication between buckets
- Assumes transitions are free because only metadata changes
- Thinks rules apply to whole buckets only and cannot be filtered