Your storage bill called. It wants a smaller file.

Where does a storage bill actually go?

Most cloud storage bills split into capacity, requests, retrieval, and data transfer. Capacity is the bytes you keep and how long they sit. Requests are the puts, gets, and lists. Retrieval is the fee some colder classes charge to read. Transfer is bytes leaving a region. Backups and replicas are extra copies of the same problem.

Start with the invoice, not a tool. On Amazon S3 the pricing page separates storage, requests, and data transfer, and it lists a storage class for each object. Google Cloud Storage and Azure Blob Storage publish the same kind of split: you pay to keep bytes, you pay to operate on them, and you pay when they leave. The labels differ. The habit is the same. If you only stare at the gigabyte-month rate, you will miss the line that is actually growing.

Capacity is the easy line to see and the slow line to feel. A terabyte at a low rate looks cheap until you keep it for years, replicate it, and version it. Request charges hide in the opposite way. A bucket of tiny objects can cost more to list and to transition than to store. Retrieval shows up the day someone restores a cold archive and discovers the cheap class was cheap only while nobody read it. Transfer shows up when a job, a customer, or a second region pulls the data.

Replication and backup are not a discount. They are a second and third copy, often in another class or another region. Cross-region replication stores the bytes again and moves them, so you pay capacity in two places and transfer between them. A backup product that keeps thirty daily copies is storing thirty copies of whatever you failed to shrink. Retention policy is a storage decision wearing a compliance hat.

Why does one file show up on more than one line?

The file is stored, then copied, then sent. Each of those actions has its own meter. A replica in another region is more capacity plus transfer. A backup is more capacity for as long as you keep it. A download is egress. A restore from a cold tier can add retrieval. Shrinking the file shrinks every copy you still make.

Picture a 1 GB object that you also replicate, back up for a year, and let customers download. The original gigabyte is not the bill. The bill is the original, the replica, every retained backup generation, and every gigabyte that crosses the network boundary your provider charges for. If five customers download it, egress sees five gigabytes even though you only stored one. If the backup tool keeps twelve monthly copies, capacity sees twelve, not one.

Versioning makes this worse in a quiet way. A versioned bucket keeps the bytes you thought you replaced. A delete can leave a marker and the old versions until a lifecycle rule actually expires them. AWS documents that lifecycle expiration and transitions have their own request considerations, and that some archival classes bill a minimum duration even if you delete early. The official S3 pricing page is the place to read those rules. This site does not restate a dollar rate.

That is why a ratio, if you ever earn one on your own data, multiplies through the bill. It does not apply itself. Compression before replication shrinks the replica. Compression before backup shrinks every generation you retain. Compression before a download shrinks egress only if you send the smaller object and the receiver can restore it. If you compress after the expensive copy, you paid full price for the copy you already made.

What does lossless compression change on the bill?

Lossless compression stores fewer bytes and returns the same bytes. Capacity, replicas, backups, and egress that carry the compressed object all see the smaller size. It does not remove a copy you choose to keep, and it does not waive a retrieval rule or a per-request fee. The ratio depends on the data. We will not invent one for you.

Lossless means the file that comes back matches the file that went in. There is no quality knob and no second encode. That matters for logs, datasets, checkpoints, backups, and source files, where a smaller different file is the wrong product. The decompressor has to travel with the data or already sit where you restore. On the published text benchmark, the total includes that decompressor. A ratio that ignores it is a different number from the total the benchmark ranks on, and we say so on the homepage.

What compression does not do is delete. If your policy is to keep seven years, you will still keep seven years. You will keep a smaller seven years. Tiering still has a job: cold classes exist for data you rarely read, and lifecycle rules exist so you do not pay a hot rate forever. Dedup still has a job when many objects are the same object. Compression is the step that changes the size of each object you decided to keep. The comparison page walks through those tradeoffs without pretending they are the same lever.

Already-compressed media is the honest exception. A file that is already a zip, or a video codec that spent its effort removing redundancy, may not shrink again. We say that on the video page, and we will say it if your sample does not move. Send the sample anyway if the bill is real. A measurement on your files is the only number we will stand behind for your files.

What should you measure before you switch tools?

Separate the invoice into capacity, requests, retrieval, and transfer, then name the copies. Note which bytes are hot, which are retained, and which leave the region. Pick a sample that matches the expensive class of data, not a toy file. Ask anyone you hire to measure that sample and to show the decompressor in the total.

A useful sample is boring and representative. Take a slice of the bucket that dominates the bill: a day of logs, a backup chain, a checkpoint, a dataset shard, a generated media folder. Include the small files if request charges are the pain, because a compressor that only shines on one huge blob will not fix a billion tiny objects. Write down the storage class and the retention, so a later quote cannot quietly assume you deleted the data.

Then write down the rate you actually pay, from your bill or from the provider page you trust, with the date you read it. Our calculator refuses to ship a cloud price list for exactly this reason. You type the dollars. You type the ratio you want to assume. The table shows 1× against that assumption so you can see whether the line is worth a project. It is arithmetic, not a case study.

If you want us in that measurement, send the sample and join the waitlist with the use case that matches. We will compress it and tell you what came back. We will not introduce a customer you have never heard of, and we will not borrow a ratio from the text benchmark and paste it onto your bucket. The text number stays on the text benchmark, labeled as such, as of Oct 14, 2026.

Questions.

Provider docs, not our price list.

• Amazon S3 pricing
• Amazon S3 cost optimization
• S3 Lifecycle documentation
• Google Cloud Storage pricing
• Azure Blob Storage pricing
• AWS guidance on data transfer costs

Links checked Oct 21, 2026. Rates and rules on those pages can change.