Compression to reduce cloud cost: fewer bytes, lower bills
Compression shrinks the bytes you store, transfer, and scan, and cloud bills those bytes. Compressing data can cut storage, egress, and query cost at once, for a little CPU. Here is where compression pays and where it does not.
Quick answer
Cloud bills bytes, storage per GB, egress per GB, analytics per GB scanned, so compressing data cuts all three at once for the cost of some CPU. Compress data at rest (columnar formats, gzip), responses in transit (HTTP compression), and logs and backups. The tradeoff is CPU to compress and decompress, which is almost always worth it except for tiny or already-compressed data.
Almost every cloud cost is measured in bytes: gigabytes stored, gigabytes transferred, gigabytes scanned. Compression reduces the byte count, so it reduces the bill across all three at once. For a modest CPU cost to compress and decompress, it is one of the highest-leverage and most overlooked cost levers, because it helps everywhere data is measured.
Where compression cuts cost
| Where | Cost reduced |
|---|---|
| Data at rest (columnar, gzip) | Storage per GB |
| Responses in transit (HTTP compression) | Egress per GB |
| Analytics data (Parquet, ORC) | Bytes scanned per query |
| Logs and backups | Storage and transfer |
Storing data compressed shrinks the storage bill. Serving compressed HTTP responses shrinks egress, often the largest transfer cost. Analytics on columnar, compressed formats scans far fewer bytes, cutting per-scan query cost, as in Athena optimization. Compressing logs and backups cuts their storage and transfer.
The CPU tradeoff
Compression costs CPU to compress and decompress, so the question is whether the byte savings outweigh the CPU cost. For storage, transfer, and scanned data, the answer is almost always yes, because those bytes are billed repeatedly (every month stored, every read transferred, every query scanned) while compression is paid once or is cheap per operation. The exceptions are tiny data (overhead exceeds savings) and already-compressed data (images, video, encrypted blobs), which does not shrink further.
Using compression well
Store analytics data in compressed columnar formats, enable HTTP response compression at the CDN or application, compress logs and backups, and choose compression levels that balance ratio against CPU (higher levels compress more but cost more CPU). Skip compression only for tiny or already-compressed data. Because it reduces bytes everywhere, compression compounds with caching and CDN to lower total cost.
FAQ
How does compression reduce cloud cost?
Cloud bills bytes, storage per GB, egress per GB, analytics per GB scanned, so compressing data reduces the byte count and cuts all three at once. For the cost of some CPU to compress and decompress, it lowers storage, transfer, and query cost simultaneously, which makes it high-leverage.
Where should I use compression to save money?
Store data at rest compressed (columnar formats, gzip) to cut storage, serve compressed HTTP responses to cut egress, use columnar compressed formats like Parquet for analytics to cut bytes scanned, and compress logs and backups. Compression helps everywhere data is measured and billed.
What is the tradeoff with compression?
CPU to compress and decompress. For storage, transfer, and scanned data the byte savings almost always outweigh the CPU cost, because those bytes are billed repeatedly while compression is paid once or is cheap per operation. The exceptions are tiny data and already-compressed data like images and video.
When should I not compress data?
For tiny data, where compression overhead can exceed the savings, and for already-compressed data (images, video, encrypted blobs), which does not shrink further and just wastes CPU. Also weigh very high compression levels, which cost more CPU for diminishing ratio gains. Otherwise, compression usually pays.
Does compression reduce egress cost?
Yes, significantly. Serving compressed HTTP responses reduces the bytes transferred to clients, and egress is often the largest transfer cost. Enabling response compression at the CDN or application is a straightforward way to cut egress for text-based content like HTML, JSON, and JavaScript.
Does C3X account for compression in cost estimates?
C3X prices the infrastructure from your Terraform. Compression affects usage-driven costs, storage volume, egress, and bytes scanned, which you model as usage assumptions. Estimating compressed versus uncompressed byte volumes shows the saving compression provides across those lines.
What to do next
Model your data volumes before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.