Cold storage is a bet on how often you will read the data
Every object storage tier is the same product with a different price split. Hot tiers charge more per gigabyte-month and little or nothing to read. Cold tiers charge a fraction of the storage price and bill every byte you read back, plus a per-request restore fee, plus a minimum number of days per object. Choosing a tier is therefore not a storage decision at all — it is a forecast of read volume over the object's life.
Two mechanisms convert a cheap tier into an expensive one. The first is retrieval: at typical rates, reading a gigabyte once from deep archive costs roughly as much as storing it there for a year and a half. Data you scan monthly does not belong in a tier that charges per read, no matter how cheap the storage line looks.
The second is the minimum billing duration, and it is the one that catches teams out because it is invisible in a rate card comparison. Infrequent access tiers commonly bill a minimum of 30 days per object, archive tiers 90, and deep archive 180. Write an object, delete it a week later, and you are billed as if it had lived the full minimum. On a bucket of short-lived objects that multiplies the storage line by the ratio of the minimum to the actual lifetime — which is exactly what the surcharge column in this calculator shows.
Lifecycle policies exist because of this arithmetic. Objects are hottest when new and cold within weeks, so the right answer is usually not one tier but a schedule: hot for 30 days, infrequent access for 90, archive after that. What this calculator gives you is the comparison a lifecycle rule should be based on.
The three terms, and why GB-months rather than GB
Storage is billed per gigabyte-month, so the annual storage cost is not volume times rate. It is the sum of each month's volume times the rate. With monthly growth g, twelve months of a volume V come to V · ((1+g)¹² − 1) / g gigabyte-months, which collapses to 12V when growth is zero. At 2% a month the factor is 13.41209 rather than 12, so ignoring growth understates a growing bucket by about 12%.
The minimum-duration term is a multiplier on storage, not an extra charge. If your objects live 45 days and the tier bills a 90-day minimum, you pay for 90 days of storage on every object: a factor of 90 ÷ 45 = 2. The factor is max(1, d_min / d_life), so it disappears entirely once your average object outlives the minimum — which is why the surcharge column reads zero for a 400-day archive and dominates a 20-day one.
Retrieval is the simplest term and the most often forgotten: monthly read volume × 12 × the tier's per-GB retrieval rate. It is charged on bytes restored, and it is independent of how long the data sat there. Per-request charges also apply and are not modelled here; on buckets of millions of small objects those can exceed the byte charges, so check them separately.
Setting two tiers equal gives the crossover. Standard matches infrequent access when the storage saving equals the retrieval bill: R* = M(r_std − r_ia) / (12 r_ret). Below that monthly read volume the colder tier wins; above it, the hot tier does. The same construction works for any pair of tiers.
Worked example: 50 TB growing 2% a month, read 500 GB a month
You store 50,000 GB today, it grows 2% a month, you read back 500 GB a month, and the average object survives 400 days. Rates are $0.023, $0.0125, $0.004 and $0.00099 per GB-month, with retrieval at $0.01, $0.03 and $0.02 per GB for the three colder tiers.
- GB-months for the year. 50,000 × (1.02¹² − 1) ÷ 0.02 = 50,000 × 13.41209 = 670,604 GB-months.
- Minimum-duration factors. The average object lives 400 days, which is longer than every minimum (30, 90 and 180 days), so all four factors are 1 and there is no surcharge.
- Standard. 670,604 × $0.023 = $15,423.90, with no retrieval charge.
- Infrequent access. Storage 670,604 × $0.0125 = $8,382.56, retrieval 500 × 12 × $0.01 = $60.00, total $8,442.56.
- Archive instant. Storage 670,604 × $0.004 = $2,682.42, retrieval 6,000 × $0.03 = $180.00, total $2,862.42.
- Deep archive. Storage 670,604 × $0.00099 = $663.90, retrieval 6,000 × $0.02 = $120.00, total $783.90 — the cheapest of the four.
- Retrieval share. $120.00 ÷ $783.90 = 15.3% of the winning tier's cost, low enough that the choice is not sensitive to read volume.
- Crossover against infrequent access. ($15,423.90 − $8,382.56) ÷ (12 × $0.01) = $7,041.35 ÷ $0.12 = 58,678 GB a month. You would have to read more than the whole bucket every year before Standard became the cheaper choice.
Deep archive wins here by a factor of nearly twenty against Standard, and it wins because two things are true at once: the objects are long-lived, so no minimum-duration surcharge applies, and the read volume is 1% of the stored volume a month. Change either and the ranking moves. At a 45-day object lifetime, the same deep archive bill would be four times higher.
How to read the comparison before you write a lifecycle rule
Look at the retrieval share first. If retrieval is under about 20% of the winning tier's cost, the decision is robust and you can act on it. If it is over half, the tier is not really cheaper — it is a different pricing shape that happens to score well on this month's read volume, and one unusual restore will reverse it. The calculator warns when that share passes 50%.
Then look at the surcharge column. A non-zero surcharge means your objects die before the tier's minimum billing duration, and that is a hard signal to move up a tier rather than down. Short-lived objects belong in Standard even when they are never read, because the minimum duration turns a 95% storage discount into a penalty.
Treat the crossover figure as a monitoring threshold, not a one-time answer. Set an alert on monthly restore volume at the crossover, because the tier decision was made under an assumption about reads that nobody revisits. Analytics teams re-scanning an archive for a new model is the usual way a cheap tier becomes an expensive one.
Finally, remember what the tier does not change. Requests, replication and the transfer out to whoever is reading the data are all billed separately, and on read-heavy workloads the egress bill can exceed the storage bill several times over. Storage tiering is only one of the levers; check it against the overall unit cost before declaring a win.
How many reads a tier tolerates before Standard is cheaper
| Tier | Storage per GB-year | Retrieval per GB | Minimum duration | Reads per GB-year to match Standard |
|---|---|---|---|---|
| Standard | $0.27600 | $0.00 | None | Unlimited |
| Infrequent access | $0.15000 | $0.010 | 30 days | 12.60 |
| Archive instant | $0.04800 | $0.030 | 90 days | 7.60 |
| Deep archive | $0.01188 | $0.020 | 180 days | 13.21 |
Deep archive tolerates more reads than archive instant at these rates only because its storage is so much cheaper; it still takes hours to restore, so the constraint there is latency rather than money.
The minimum duration applies to the object, not the bucket
Transitioning an object to a colder tier starts its minimum-duration clock again. A lifecycle policy that moves objects to infrequent access at day 30 and then to archive at day 45 pays the infrequent access 30-day minimum in full even though the object only spent 15 days there. Space transitions at least as far apart as the minimum duration of the tier being left, or the policy costs more than leaving the data where it was. Small objects deserve particular care: below a tier's minimum billable object size, typically 128 KB, you are charged as if each object were that size.
What this model leaves out
- Per-request charges. PUT, GET, lifecycle transition and restore requests are all billed per thousand or per ten thousand. On buckets of millions of small objects these can exceed the byte charges entirely.
- Minimum billable object size. Cold tiers round small objects up, commonly to 128 KB, which inflates the effective rate on thumbnail-sized data.
- Restore latency. Deep archive restores are measured in hours and expedited restores cost several times the standard rate. A tier you cannot read fast enough is not a candidate however cheap it is.
- Replication and versioning. Cross-region replication duplicates both storage and transfer, and non-current versions keep accruing storage until a lifecycle rule expires them.
- Intelligent tiering. Automatic tiering adds a small per-object monitoring fee and moves objects for you; it usually beats a hand-written policy on unpredictable access patterns and loses on predictable ones.
- Egress to the reader. Retrieval charges get the data out of the tier; transfer charges get it out of the provider. They are separate meters.
Where tiering fits among the other storage decisions
Tiering is the cheapest storage lever because it needs no code change, but it is the second thing to do. The first is deletion: expiring non-current versions, incomplete multipart uploads and orphaned build artefacts routinely removes more cost than any tier change, and it removes the retrieval risk with it. Run an inventory report before a lifecycle policy.
After that, the choice is between a hand-written lifecycle rule and automatic tiering. A rule is free and optimal when access falls off predictably with age. Automatic tiering charges a small monitoring fee per object and wins when access is unpredictable or bimodal, because it moves objects back to hot on access rather than charging you a retrieval fee each time.
For backup and disaster-recovery data specifically, the retention policy and the recovery time objective decide the tier before price does: data you must restore within an hour cannot live in deep archive whatever it costs. Price that separately against the backup and DR cost calculator, and read the storage total alongside the rest of the infrastructure bill in the commitment analysis, since storage is one of the few large line items commitments do not cover.