The question this answers
This data has not been read in eight months — where should it live, and what does it cost to get it back?
The platform accumulates uploads, exports, database backups and logs. Regulation requires seven years of financial records. Support occasionally needs a file from two years ago within a working day. Everything else is read within a week of being written and then never again. Storing all of it at the same rate for seven years is a straight line on a cost graph that only goes up.
An automatic, rule-driven progression from expensive-and-instant to cheap-and-slow, with deletion at the end, so storage cost tracks the age profile of the data instead of its total volume.
Four tiers, and what each one actually trades
Storage tiers trade storage rate against access characteristics. Hot storage is the most expensive per gigabyte-month and has no retrieval charge, no minimum duration and millisecond access. Each colder tier lowers the storage rate and adds constraints: a per-gigabyte retrieval charge, a minimum billable storage duration, and increasing access latency — from milliseconds, to minutes, to hours for the deepest archives.
The lifecycle below is the progression with the risk at each transition. Read the archive state carefully, because that is where the trap lives. A tier at a fraction of hot pricing looks like an obvious win until you notice three separate charges layered on it: retrieval per gigabyte, a per-request fee, and a minimum storage duration that bills for the full period even if you delete the object on day two. Move actively-read data into an archive tier and the retrieval charges alone can exceed what you were paying to store it in hot.
The rule that makes this safe is simple: tier on *access pattern*, never on age alone. Age is a good proxy for access pattern for most data, and it is a terrible one for the exceptions — a compliance archive read during every audit, a media library where old items are occasionally rediscovered, a backup set you intend to test regularly. Measure access before writing the policy, and re-measure after.
- 1Hot / standarddays to weeks
Highest storage rate, no retrieval charge, no minimum duration, millisecond access. Where data is written and where recent data is read from.
Leaving everything here forever. The bill grows monotonically with total volume and nothing ever reduces it.
- 2Warm / infrequent accessweeks to months
Lower storage rate, a modest per-GB retrieval charge, a minimum duration of roughly a month, still millisecond access.
Objects that turn out to be read often — the retrieval charges quietly exceed the storage saving, and nothing alerts you.
- 3Archive / coldmonths to years
Much lower storage rate. Retrieval is charged per GB and per request, latency is minutes to hours, and the minimum billable duration is commonly 90 to 180 days.
The three-part trap: retrieval cost, early-deletion charges for the unmet minimum, and a restore that takes hours during an incident that cannot wait hours.
- 4Deep archiveyears
The lowest storage rate available, with retrieval measured in hours and the longest minimum duration.
Suitable only for data you are confident you will not read. If a compliance request arrives with a short deadline, the retrieval time may not fit inside it.
- 5Deletepermanent
The only state that actually reduces the bill. Governed by a retention policy derived from regulation and from what the business genuinely needs.
Deleting something a regulator or a court later requires; or, far more commonly, never reaching this state at all because no owner will approve deletion.
The policy is a few lines; the retention decision is the work
Mechanically a lifecycle policy is trivial — a set of rules matching a prefix or a tag, each with an age threshold and a target tier or an expiry. The example below is a provider-neutral shape covering four classes of data with different profiles: uploads that age gradually, logs that are worthless after a month, backups on a regulatory clock, and a bucket with versioning where the non-current versions are their own cost problem.
That last rule is worth calling out because it is the most commonly missed. Versioning keeps every overwritten version of every object, invisibly, and each one is billed at full rate. A bucket with versioning enabled and no non-current-version expiry rule can hold several times the data anyone thinks it holds. The same applies to incomplete multipart uploads, which are partial objects left behind by failed transfers and billed as storage forever, in a listing most people never look at.
The hard part is not the policy syntax. It is getting someone to decide the retention period, because deletion is irreversible and every stakeholder's incentive is to keep everything. The productive framing is to separate what regulation requires (a fact you can look up), what the business genuinely uses (measurable from access logs), and what is kept because nobody decided (the actual target). Write the reason next to each rule so the next person can re-derive it instead of assuming it is legally mandated.
1{2 "rules": [3 {4 "id": "user-uploads",5 "filter": { "prefix": "uploads/" },6 "transitions": [7 { "afterDays": 30, "tier": "warm" },8 { "afterDays": 180, "tier": "archive" }9 ],10 "note": "Read heavily in week 1, rarely after month 1. Measured, not assumed."11 },12 {13 "id": "application-logs",14 "filter": { "prefix": "logs/" },15 "expiration": { "afterDays": 30 },16 "note": "Metrics cover long-term trends. Raw logs older than 30d have never been read."17 },18 {19 "id": "database-backups",20 "filter": { "prefix": "backups/" },21 "transitions": [22 { "afterDays": 7, "tier": "warm" },23 { "afterDays": 90, "tier": "archive" }24 ],25 "expiration": { "afterDays": 2555 },26 "note": "7 years: financial retention requirement. Restore tests read from warm only."27 },28 {29 "id": "noncurrent-versions",30 "filter": { "prefix": "" },31 "noncurrentVersionExpiration": { "afterDays": 90 },32 "abortIncompleteMultipartUpload": { "afterDays": 7 },33 "note": "The two invisible line items: superseded versions and abandoned partial uploads."34 }35 ]36}The retrieval trap, priced
The cost panel separates storage from access, which is the split that makes archive tiers legible. Storage is what people compare when choosing a tier. Retrieval, per-request charges and early-deletion penalties are what actually determine whether the choice was correct, and all three are invisible until you read the data back.
Two scenarios illustrate it. A backup set moved to deep archive to save on storage, then read in full during a disaster-recovery test, can generate retrieval charges in one afternoon that exceed a year of the storage saving — and the restore takes hours, which may fail the recovery time objective outright. See Restore Testing and RPO & RTO; a backup you cannot restore inside your RTO is not a backup that meets the requirement. Meanwhile a lifecycle rule that moves objects to archive after 30 days, applied to data with a 90-day minimum duration, pays the full 90 days for every object regardless — so an aggressive policy on short-lived data costs more than leaving it in hot.
The correct approach is unexciting and effective. Measure the access pattern before writing the policy. Keep anything with a recovery-time requirement in a tier that meets it. Apply archive tiers to data you genuinely expect never to read. And test a restore from each tier you use, once, so the retrieval time and cost are facts rather than assumptions — that test is also the only way to discover that the restore path does not work.
Bars are relative weights, not currency. Real rates depend on provider, region, commitment and volume.
Key points
- Tier on measured access pattern, not on age alone. Age is a good proxy for most data and a bad one for the exceptions that cost the most.
- Archive tiers carry three hidden charges: per-GB retrieval, per-request fees and a minimum billable duration of months.
- Deletion is the only state that actually reduces the bill, and it is the state most organizations never reach.
- Non-current versions and abandoned multipart uploads are billed at full rate and are invisible in an ordinary listing.
- Anything with a recovery-time requirement must live in a tier that can meet it — a deep-archive backup may not restore inside your RTO.
- Test a restore from every tier you use, once, so retrieval time and cost are facts rather than assumptions.
- An aggressive transition rule applied to short-lived data costs more than leaving it in hot, because the minimum duration bills anyway.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • Lifecycle rules match objects by prefix, tag or age and are evaluated asynchronously by the storage service, typically once a day.
- • A transition rewrites the object's storage class in place; the object identity and path do not change, so applications keep working until they try to read from a tier with retrieval latency.
- • Cold tiers store the data on slower media or with a restore step, which is why retrieval is a request that completes later rather than a read that returns immediately.
- • Minimum billable duration means the object is charged for that period from the moment it enters the tier, whether or not it survives.
- • Expiration deletes the object permanently unless a legal hold, object lock or retention policy prevents it.
- • Versioning creates a new current version on every write and retains the previous ones as non-current versions, each billed independently.
- • Measure access by age before writing any policy — object-storage access logs or analytics answer this directly.
- • Always include a non-current-version expiry and an incomplete-multipart-upload cleanup rule. These two lines are free money in most accounts.
- • Write the reason beside each rule, especially the retention period, and note whether it is a regulatory requirement or a business choice.
- • Test a restore from each cold tier once and record the time and cost. This validates both the assumption and the restore path.
- • Keep backups needed for fast recovery in a tier that meets the recovery time objective, regardless of what the storage rate suggests.
- • Review policies annually; access patterns change and a rule tuned to a workload that no longer exists can be actively harmful.
- • A disaster-recovery restore from deep archive that takes hours and misses the recovery time objective, discovered during the disaster.
- • Retrieval charges from an unexpected bulk read — a migration, an analytics job, a legal discovery request — exceeding a year of storage savings in a single afternoon.
- • Early-deletion charges from a transition rule applied to data that does not live long enough to satisfy the minimum duration.
- • An expiry rule with a prefix filter slightly wrong, deleting data that should have been retained. Irreversible, and usually noticed much later.
- • Versioning enabled with no expiry rule, quietly multiplying the stored volume over years.
- • Objects tiered by age into archive while an application still reads them, turning a millisecond read path into an hours-long restore request.
- • Storage grows monotonically without lifecycle rules; nothing about growth pressures anyone to delete.
- • Per-request retrieval charges scale with object count rather than bytes, so many small objects are dramatically more expensive to restore than a few large ones.
- • Lifecycle transitions themselves carry a small per-object charge, which becomes material when a rule touches millions of small objects at once.
- • Versioned buckets scale with write frequency, not with distinct data, so a frequently-overwritten object set grows without adding information.
- • The dimension that runs out first is usually organizational: nobody will approve a retention period, so the policy never ships.
- • Deletion is a security control as much as a cost one. Data you no longer hold cannot be breached, and minimizing retention is a data-protection obligation in several jurisdictions.
- • Object lock and legal hold override lifecycle expiry, which is exactly what you want for audit logs and exactly what will surprise you when an expiry rule silently does nothing.
- • Archived data must stay encrypted, and the key must outlive it — a seven-year archive encrypted with a key rotated out of existence is unrecoverable data.
- • Access to lifecycle configuration is destructive-equivalent: whoever can edit an expiry rule can delete everything on a delay — see Audit Trails.
- • Storage rate falls with each colder tier and access constraints rise: retrieval charges, per-request fees, minimum durations and latency.
- • Retrieval is the meter that decides whether the tier choice was right, and it is the one omitted from every simple comparison.
- • Non-current versions and incomplete multipart uploads are pure recoverable waste in most accounts.
- • Expiry is the only rule that reduces the bill; every transition merely slows its growth.
- • All rates here are relative. Tier names, minimum durations, retrieval pricing and latency differ substantially between providers.
- • Storage volume by tier over time, which shows whether lifecycle rules are actually firing.
- • Retrieval volume and cost per tier — a rise here means a policy is fighting an access pattern.
- • Object count alongside bytes, because per-request charges track count and small-object sprawl is invisible in a bytes graph.
- • Non-current version volume as a distinct number, not folded into the bucket total.
- • Objects approaching expiry, so an irreversible deletion is anticipated rather than discovered.
- • The signal that lies: a falling storage cost after a transition rule ships. It can mean the rule worked, or that objects moved into a minimum-duration tier whose charges have not landed yet.
- • Delete instead of tiering. If nobody will ever read it and no regulation requires it, deletion is cheaper than every tier and simpler than every policy.
- • Do not write it in the first place: sampled logs, thinner exports and fewer redundant backup copies reduce the problem at the source.
- • Compress and consolidate small objects before archiving — per-request retrieval charges make object count matter more than bytes in cold tiers.
- • Intelligent-tiering options that move objects automatically based on observed access, for a monitoring fee, when the access pattern is genuinely unknown.
- • For a small bucket, do nothing. A lifecycle policy on a few hundred gigabytes is effort spent on a rounding error.
- • Colder tiers buy a lower storage rate and cost retrieval charges, minimum durations and access latency measured in hours.
- • Aggressive expiry buys real savings and reduced breach exposure, and costs the ability to answer a question you did not know you would be asked.
- • Automatic tiering removes the decision and adds a monitoring fee plus less predictable behaviour.
- • Consolidating small objects cuts retrieval cost and makes partial restores harder, because you now restore the whole archive to get one file.
What people believe, and what is true
Archive is cheaper, so archive everything old.
Cheaper to store and expensive to read. Data still being accessed generates retrieval charges that can exceed the storage saving, plus early-deletion charges if it does not stay.
Storage is cheap, so retention does not matter.
Cheap per gigabyte and growing without limit. Seven years of monotonic growth is a large number, and it is also a large breach surface.
The bucket holds what I uploaded.
With versioning enabled it also holds every superseded version and every abandoned multipart upload, all billed at full rate and absent from a normal listing.
Our backups are safe in deep archive.
They are cheap in deep archive. Whether they are safe depends on whether a restore completes inside your recovery time objective — which you only know if you have tested it.