CloudFront is one of the services we’ve found often gets overlooked when it comes to cost efficiency. There could be several reasons for this, but our hypothesis is that most engineers are more familiar with compute and storage than the intricacies of CloudFront and how AWS charges for it.
We wrote this blog to show that significant cost reductions are possible for CloudFront with just a few adjustments and minimal engineering effort. This post is inspired by work we did for a client in the entertainment industry, which resulted in substantial savings on their CDN costs.
Understanding CloudFront Costs
Before diving into the tips, let’s quickly recap the primary drivers of CloudFront costs:
- Data transfer out to the internet: Often through HTTP GET requests (calculated in units such as GB or TB per month).
- Data transfer into your origin (e.g., S3, ALB): Typically via HTTP PUT or POST requests (also measured in GB or TB per month).
- Total number of HTTP requests within a given month.
Now, let’s explore the tips in detail:
Tip 1: Optimize File Formatting and Compression on the Origin
The primary use case for CloudFront is to serve static files to the internet (via HTTP GET), although it can also front dynamic APIs. A significant cost driver is the amount of data transferred in and out of CloudFront. From our experience, workloads often involve far more outbound data than inbound.
One overlooked opportunity is optimizing the static files stored in the origin (commonly S3), either through compression or format changes where feasible. This simple adjustment can yield significant savings.
For instance, a client in the entertainment industry was serving a large number of images in PNG format to their users. After analyzing their assets, we found that by using a third-party image compression tool, they could reduce file sizes by up to 80% without any noticeable loss in quality. Tools like TinyPNG are excellent for this purpose.
To implement this at scale, we used a Lambda function to compress and reupload the images back to S3. Once the process was complete, we refreshed the CloudFront cache to serve the optimized assets. The result? A noticeable reduction in their monthly bill.
Sometimes you might also be able to benefit from changing file format without major changes in your business logic. In the above example, we could have benefited more if we were to change the images from PNG format into Google WebP but there was a rare case in the app itself that prevented us from going into that direction thus we had to stick with PNG.
Tip 2: Enable Compression on the CloudFront Distribution
We talked earlier on the importance of optimizing your source on the origin, but don’t forget the CloudFront itself also offers optimization for certain file extension such as:
- application/javascript
- application/json
- text/html
- application/font
Ensure that compression is enabled for these file types, as it can significantly reduce data transfer costs when serving them at scale. Refer to this Amazon article for the full list of file extensions that CloudFront offers compression.
Tip 3: Set Appropriate Caching on CloudFront
Another crucial factor in CloudFront cost optimization is reducing the frequency with which CloudFront fetches assets from the origin. Lower origin requests improve both costs and performance.
The cache time-to-live (TTL) is controlled via the Cache-Control tag in the header. While there’s no universal TTL value, static assets like JPEG, PNG, or CSS files can often be cached for long periods (e.g., 31,536,000 seconds or 1 year) if they don’t change frequently.
Aim for a “cache hit” rate close to 100% for static objects. Below is an example of a nearly perfect cache hit rate from the AWS console:
Conclusion
CloudFront cost optimization involves more nuances than we could cover here, but the tips shared in this post address common areas often overlooked. These simple strategies can make a significant difference when applied at scale.
