What disappears from the bill of cheap storage

Comparing clouds by the price of a stored gigabyte is like comparing cars by the price of a litre of petrol. The line exists, it's easy to find, and it doesn't explain the bill at the end of the year.

In long-term archiving the effect is stronger, because the classes that are cheapest per gigabyte are precisely the ones that push cost onto the other lines. The provider isn't hiding this: it's in the public pricing table. What happens is that the table has six or seven dimensions and the comparison being passed around has one.

This text describes how the billing is structured and shows how to build the calculation. It carries no prices: prices change by region, by class and by month. You take the numbers from your provider's table, in your region, on the day you make the decision.

The lines that make up the invoice

1. Storage per gigabyte-month

The obvious line. It's proportional to the average volume retained, not to the volume uploaded. If you keep old versions, the average volume grows even if the "live" data stays constant.

Two common traps here. The first is the minimum billable object size: several cold classes bill each object as if it were at least a certain size, regardless of its actual size. Whoever stores millions of small files pays for more volume than they uploaded. The second is the per-object metadata overhead, which some classes add to every stored object. Both are documented on the storage class pages and both are invisible in a price-per-TB comparison.

2. Requests

Every operation is billed: writing, reading, listing, querying metadata, initiating a retrieval. The price is per block of requests and varies by type — writes cost more than reads — and by class. In general, the colder the class, the more expensive the request.

This line is negligible for those storing large files and dominant for those storing small ones. A backup of ten million files performs ten million write operations, at a minimum. After that, each full listing of the bucket is another batch of requests. If this is your situation, see the article on the cost of backing up millions of small files.

3. Transitions between classes

Lifecycle policies aren't free. Moving an object from one class to another is usually billed per transitioned object, at a price in the expensive-operations range. A policy that automatically pushes everything into the coldest class after 30 days looks like a saving and may be an expense, depending on the number of objects and how much longer they will actually be kept.

4. Minimum retention and early-deletion charges

Cold classes bill a minimum storage duration. If the object is deleted, moved or overwritten before that period is up, you pay the difference to the minimum. The charge is proportional: delete halfway through and you pay the other half.

This changes the design of the backup, not just the price. Short retention in a cold class is the worst of both worlds: you pay the cold class minimum and get none of its benefit. Weekly rotation of data in a class with a several-month minimum generates a systematic penalty, every month, without any line on the invoice being called "penalty".

5. Retrieval

This is where the biggest difference between archive classes lives. Retrieving cold data usually has three components added together: a price per gigabyte retrieved, a price per retrieval request and, in some classes, the choice of an urgency tier that multiplies the first. Expedited retrieval can cost several times more than standard — and standard can take hours.

There's also the case of early retrieval in classes that apply an additional charge when data is read before completing the minimum duration.

The detail that almost always slips by: retrieving is not the same as downloading. In many services, retrieval merely places the object in an accessible state for a number of days that you choose. Downloading is the next line.

6. Data egress

Transfer out of the cloud is billed per gigabyte, almost always with tiered pricing by volume band and varying by region. Egress to the internet, egress to another region and egress to another cloud all have different prices.

Ever since providers started offering egress waivers for customers migrating entirely to another vendor, it has become common to treat egress as a solved problem. It isn't. The waiver covers closing the account, not Tuesday's restore.

For a recovery plan, this is the decisive line: the cost of restoring 1 TB is retrieval plus egress, and it shows up on exactly the day you have the least room to argue about an invoice.

7. The side lines

Cross-region replication (duplicated storage, more requests, more transfer). Calls to the key management service, billed per cryptographic operation. Inventory reports. Access logs — which are objects and take up space. Incomplete multipart uploads, which keep counting as billed storage until someone configures a rule to remove them. Versioning without expiration of old versions.

How to build the calculation

A spreadsheet with six variables settles most decisions:

monthly_cost =
    average_volume_TB          x price_GB_month
  + new_objects_per_month      x price_write_request
  + transitioned_objects       x price_transition
  + volume_deleted_before_minimum x price_proportional_penalty

cost_of_one_restore =
    TB_restored x price_retrieval_GB
  + objects_restored x price_retrieval_request
  + TB_downloaded x price_egress_GB (in the correct band)

Three recommendations on how to fill it in:

Project 36 months, not one month. Archiving is a long-term decision. Add up the accumulated storage using your data's real growth rate, not its current one.

Include at least one restore per year in the scenario. If you never restore, you don't have a backup — you have an expense. One full restore per year and one partial restore per quarter is a reasonable floor for the calculation. The cost of restoring is the number that separates the cheap from the falsely cheap.

Do the maths per object, not just per TB. Divide the volume by the number of files. If the average size is small, requests and per-object minimums dominate, and price per gigabyte stops being a criterion.

It's worth confirming everything in the primary sources: S3 storage classes, S3 pricing, Cloud Storage classes and Azure Blob access tiers.

Where this advice doesn't hold

This text does not compare providers and does not say which one is cheaper. The answer depends on your object profile, your region and your read frequency. Two companies with the same volume in TB can have invoices an order of magnitude apart, and both be correct.

Nothing here is measurement. It's a description of how billing is structured, according to public documentation. You get the numbers from your provider's table.

Cold storage is the wrong choice in several cases. Frequently read data, data with retention shorter than the class minimum, restores with a tight deadline and datasets dominated by tiny files: in those four scenarios, the class that is cheapest per gigabyte tends to come out more expensive in total. On the deadline question, the article on Deep Archive restores in practice details what the latency means operationally.

Optimising cost is not the first problem. If recovery has never been exercised, the price is secondary — and that's the subject of why the restore is the part nobody tests.

Cheap storage exists. It's just rarely cheap for the reason that shows up on the first line of the table.

NubliVault is Nublify's backup product: it packs millions of small files and stores them in a cloud different from the one they came from. How it works · Security