A cold tier is cheaper to keep and dearer to read. Setting the monthly saving equal to the retrieval charges gives one access rate, a*, above which cold costs more than hot. Data is then tiered by age, because access rates fall with age — and the age at which the profile crosses a* is the boundary.
Core ideas
The break-even is a single equation. The part that is easy to get wrong is which side of it old data is on, and the answer is not always the obvious one.
Moving a gigabyte from hot to cold saves hot − cold every month it stays there, and costs retrieval every time it is read back. Those are different units, and setting them equal is what produces a rate: a* = (hot − cold)/retrieval reads per gigabyte per month. Below that rate cold is cheaper; above it, the retrieval charges swallow the saving.
Data is tiered by age because access usually decays with age, not because old bytes are cheaper to store. The decision is always about the rate: here reads halve each month from eight per gigabyte, so a* is crossed at month three, and that is the age boundary. A profile that does not decay has no boundary at all.
At month zero a gigabyte is read eight times, which costs $0.080 in retrieval against a $0.019 saving. Moving it costs four times what keeping it hot would have. The rule that works is not “old goes cold” but “below a* goes cold”, and on this profile those coincide only from month three.
The material
The break-even as an equality, the integer search that turns it into an age, and what the whole-archive bill looks like on either side of it.
Let h be the hot price per gigabyte-month, c the cold price per gigabyte-month and t the retrieval charge per gigabyte read back from cold. A gigabyte read a times a month costs h hot and c + a·t cold, so cold is cheaper exactly when
a < a* = (h − c)/t.
c on this page is the cold-tier price throughout and is never a server count.
At h = $0.023, c = $0.004 and t = $0.010 the break-even is (0.023 − 0.004)/0.010 = 19/10, or 1.9 reads a gigabyte a month. A gigabyte read twice a month belongs hot; one read once a month belongs cold; and the difference between those two cases is a third of a cent, which is why this is done for petabytes rather than for gigabytes.
Each row above is a bucket of 1 000 gigabytes, one for every month of the archive’s twenty-four-month retention, which is why the hot column is a flat $23.00. The verdict flips between month two and month three, and nothing about the flip is approximate: it is a comparison of two exact figures at each integer age.
The access profile here is 8 × (1/2)ᵐ reads a gigabyte in month m, and the boundary is the smallest m with 8 × (1/2)ᵐ < 19/10. Evaluating that at each integer gives 8, 4, 2, 1 — the crossing is at m = 3. A logarithm would give 2.07… and then need rounding in a direction that has to be argued for; the search needs no argument.
Twenty-four monthly buckets of 1 000 GB is 24 000 GB. All hot: 24 000 × $0.023 = $552.00 a month. Tiered at month three: three hot buckets at $23.00 is $69.00, twenty-one cold buckets at $4.00 is $84.00, and the reads on those cold buckets come to about $20.00, for $173.00 in all. The saving is $379.00 a month, and 21 000 GB moved to earn it.
Moving too early is the expensive one. The month-zero bucket read eight times a gigabyte costs $84.00 cold against $23.00 hot: tiering it more than triples its bill. Anyone applying “archive anything over thirty days” to a profile whose reads have not yet decayed is doing exactly this.
Moving too late is cheap and dull. Leaving the month-twenty-three bucket hot costs $23.00 instead of $4.00, a loss of $19.00 a month on that bucket. It is real money at scale and it never causes an incident, which is why it is the error that survives in production for years.
One quantity is deliberately absent from a*: the amount of data. The break-even is a rate per gigabyte, so it is the same for a terabyte and a petabyte. Volume decides how much the decision is worth, not which way it goes — and that is why the archive-wide figures above are a separate calculation from the break-even itself.
Retrieval latency is not priced here at all. A cold tier that takes hours to restore is a different product from one that responds in milliseconds, and if the access has a deadline the cheaper tier may be unusable at any price. This page decides cost; the deadline is a constraint applied before it.
Interactive
Cold is cheaper to keep and dearer to read, and a* is where those meet
Method
One division, then one pass over the ages. The archive-wide figures come last.
Reads per gigabyte per month. Units matter here because the numerator is a monthly price difference and the denominator is a per-read charge, and getting them the wrong way up gives a plausible-looking number that is a month per read.
Reads per gigabyte per month at age 0, 1, 2, …. This is the step that usually has to be measured rather than assumed, and a profile that does not decay is a finding: it means there is no age boundary to find.
8, 4, 2, 1 against 1.9 gives month three. Every comparison is between two exact numbers, so there is no rounding to argue about and no direction to justify.
All hot, and tiered at the boundary. Include the retrieval charges on the cold buckets — they are the term the plan is trading against, and a saving computed without them is not a saving.
A restore time is a constraint, not a cost. If the data is needed within seconds and the cold tier answers in hours, the arithmetic above is irrelevant for that data however favourable it looks.
The archive keeps twenty-four monthly buckets of 1 000 GB each, and reads halve with every month of age from eight per gigabyte.
The m = 2 row is the one worth pausing on. Two reads a gigabyte is above the break-even of 1.9 by a tenth, and the bill agrees by a dollar: $24.00 cold against $23.00 hot. A break-even is a crossing, and a bucket sitting a tenth of a read above it really does cost more in the cheaper tier.
The retrieval line on the tiered plan is what a saving computed from storage prices alone would have left out. It is small here — about $20.00 against a $379.00 saving — only because the boundary was chosen where reads had already decayed. Move the boundary to month zero and that line becomes the whole bill.
For a faded attempt, slow the decay so that reads fall to 70% of the previous month rather than 50%. Predict first whether a* moves, then find the new boundary age by evaluating the profile, and read the new saving off the lab.
You should be able to compute a* = (h − c)/t with its units, evaluate a decaying access profile at each integer age to find the first one below it, and cost the whole archive on both plans with the retrieval charges included.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.