Difficulty: Easy
Description
CloudFront distributions with compression disabled transfer uncompressed assets to end users, inflating CloudFront Data Transfer Out (DTO) costs. Enabling automatic compression (Gzip and Brotli) on a cache behavior shrinks compressible text objects (HTML, CSS, JS, JSON, XML, SVG, fonts, etc.) by roughly 65–80% before they leave the edge. Because CloudFront bills on bytes served, that size reduction lowers your DTO bill — but only on the portion of your traffic that is compressible text. The impact on your total bill depends on your content mix, and it requires zero changes to your origin or application code.
Selection Criteria
The CloudFront distribution has at least one cache behavior with Compress objects automatically set to
false.That cache behavior uses a cache policy with a TTL > 0 (CloudFront won't compress when caching is off).
The distribution serves compressible content types (
text/html,text/css,application/javascript,application/json,image/svg+xml,application/xml, etc.).CloudFront Data Transfer Out for this distribution exceeds $5/month (a minimum threshold so the upside is worth acting on).
The origin does not already return compressed responses (a
Content-Encodingheader), since CloudFront won't re-compress content the origin already compressed.
Expected Saving
Compression reduces the size of compressible text objects by 65–80% (JS ~77%, HTML/CSS ~70–80%, JSON ~70–85%). The reduction on your total DTO bill is smaller, because it applies only to the compressible share of your traffic — images, video, audio, and other already-compressed formats don't benefit. In practice:
Text-heavy distributions (web apps, APIs, static sites): roughly 30–45% off DTO once you blend compressible and non-compressible bytes.
Media-heavy distributions (images, video): little to no change, since most bytes aren't compressible.
Example: a distribution serving ~10 TB/month of typical mixed web traffic (HTML, JS, CSS, JSON alongside images) could save on the order of $3,000–$4,000/year — a ~30–40% reduction on its DTO. Every byte saved maps directly to a lower bill, and the change happens at the CloudFront edge with no origin work, making it one of the lowest-effort CloudFront optimizations available.
Note: AWS itself frames this conservatively — charges may drop "depending on the proportion of compressed to uncompressed requests." Your actual result tracks your content mix.
Operational Impact
✅ No downtime required — enabling compression is a configuration change that takes effect within minutes of distribution deployment.
⏳ Not retroactive — CloudFront compresses objects as they're (re)fetched from the origin, not the copies already sitting in the edge cache. Existing cached objects compress as they expire and refresh, or immediately if you invalidate them, so the bill drop ramps in rather than appearing instantly.
⚠️ Pre-compressed origins — if the origin already sends
Content-Encoding(e.g. gzip), CloudFront serves that as-is and won't re-compress. No conflict, but no additional benefit from this setting either.⚠️ Size limits — CloudFront only compresses objects between 1 KB and 10 MB (1,000–10,000,000 bytes). Smaller files and already-compressed formats (JPEG, PNG, MP4, ZIP, PDF) are excluded.
⚠️ Content-Type is AWS-defined, not configured — CloudFront compresses a fixed list of content types matched against the
Content-Typeresponse header from your origin; you can't add to that list in the cache policy. What you do control: make sure your origin sets correctContent-Typeheaders, and that the cache policy enables both Gzip and Brotli.⚠️ Brotli prerequisites — Brotli requires a cache policy (not legacy cache settings), and browsers only negotiate Brotli over HTTPS; Gzip covers the rest.