AWS Edge Services - Cost optimization
In addition to its benefits for performance, security and availability of your web application, CloudFront can be used to reduce the costs of web application.
Achraf Souk
Amazon Employee
Published Apr 29, 2025
In addition to its benefits for performance, security and availability of your web application, CloudFront can be used to reduce the costs of web application. First, CloudFront's pricing model could reduce your origin costs. Second, you can configure your CloudFront and architect your application to decrease its costs. For more general guidance on optimizing costs using AWS services, consider the Cost Optimization Pillar of the AWS Well-Architected Framework. To monitor and understand your costs, use AWS Cost Explorer and AWS Budgets.
CloudFront's pricing model includes multiple dimensions, with the two most dominant ones being:
- The Regional Data Transfer Out (DTO) to Internet, which accounts for the amount of GBs served by CloudFront to users on the internet. Note that this pricing depends on the region of users, it's metered using binary gigabytes (i.e. 1 GB = 1024 MB), and it only includes the HTTP payload (e.g. excluding TLS handshake data transfer).
- The Request fees, which accounts for the number of HTTP(S) requests served by CloudFront. It also depends on the region of the users.
By default, CloudFront uses all its network to serve content for the best performance. Consider configuring Price Class options in CloudFront if you are willing to strike a tradeoff with the delivery costs.
CloudFront has an always on Free tier, that includes every month 1 TB of DTO and 10 Million HTTP(S) requests. If you are using AWS WAF in combination with CloudFront, consider an upfront commitment with the CloudFront security savings bundle to save up to 30% on the CloudFront charges. For larger volumes (10TB+), contact to obtain further reductions in return of a higher financial commitment, by signing a private pricing agreement. Note that the discount you can obtain is bigger when your overall traffic has a higher average size of delivered HTTP objects. As a consequence, it is recommended to use CloudFront for multiple workloads (API delivery and static file delivery) to increase the overall discount you can get in a private pricing agreement.
It's important to note that when used with an AWS based origin, CloudFront's DTO replaces the origin's DTO. As of such, you do not pay the Data Transfer Out (DTO) of the origin.
Finally, review and optimize your usage of CloudFront's optional features, that could generate extra costs, such as content invalidation.
According to CloudFront pricing, you can use 1,000 paths for invalidation each month at no additional charge. Beyond that it costs $0.005 per path requested for invalidation. A path listed in your invalidation request represents the URL (or multiple URLs if the path contains a wildcard character) of the object(s) you want to invalidate from CloudFront cache.
Consider the following tips to optimize the cost of invalidations using CloudFront:
- Rely on HTTP cache control mechanisms (e.g. Cache-Control header, URL versioning, conditional requests) by default, and prefer CDN based invalidations for break glass scenarios. For more details, read this blog.
- Use a wildcard in your invalidations when applicable to invalidate multiple files with a single invalidation request. For example, use /stories/sports/worldcup* to invalidate all articles related to Worldcup event, instead of invalidating them one by one.
You can monitor your Invalidations usage and set alarms using AWS Budgets.
CloudFront natively reduces the costs of your web application, by offloading your origin. First, CloudFront serve cacheable requests from its own cache, which reduces the scaling costs of your origin. You can optimize your CloudFront configuration to further offload the origin by increasing the Cache Hit Ratio (e.g. enabling Origin Shield). Second, CloudFront reuses TCP/TLS connections to your origin for dynamic requests (e.g. API calls), which reduces the number of new connections that needs to be handled by the origin, and the amount of TLS certificates egressing from the origin. This reduces the costs of origins like ALB because the LCU consumption decreases thanks to the reduced number of newly established connections per second and the number of bytes processed.
You can configure CloudFront to further reduce your costs in different ways. For example, compress text files using GZIP or Brotli to reduce DTO. Another example, when your application needs edge functions, prefer using CloudFront Functions when applicable because it's less expensive than Lambda@Edge. Read about best practices to optimize your edge functions to reduce their costs.
Finally, prefer using standard Cache-Control header to control the freshness of your cache instead of using invalidations as part of your normal operations. Cache-Control mechanism is more reliable, can control caching on the browser and doesn't have any costs (compared to CloudFront invalidations, beyond the qupotas of 1000 invalidations per month). Use invalidations for break glass scenarios.
The dominant component in AWS WAF cost are usually the request fees. You can reduce this cost in different ways:
- Enable AWS WAF exclusively on the CloudFront distribution that requires protection according to your threat modeling. For example, if your static content hosted on S3 do not require WAF protection, move them to a separate domain (e.g. static.example.com) on a separate CloudFront distribution, and only enable AWS WAF on the main distribution (e.g. www.example.com) which is serving your HTML files.
- When you subscribe to Shield Advanced, the AWS WAF request fees are included in Shield Advanced pricing. Shield Advanced charges a monthly subscription, and a premium fee on your application Data Transfer Out. If your application is request intensive (High request per second with low average payload, e.g. with APIs), Enabling Shield Advanced might help you reduce your overall WAF costs.
- Finally, some AWS WAF rules have additional costs, such as CATPCHA, AWS Bot Control or managed rules by vendors in the AWS Marketplace. Optimize these costs by scoping down such rules to specific conditions (e.g. only CAPTCHA suspicious IPs or only apply Bot Control on HTML requests), and by using at the end of the WebACL, giving the chance for prior free rules to block malicious requests at no additional cost. Read this blog for more in-depth explanation of WAF rule cost optimizations.
Note that CloudFront does not charge for requests blocked by AWS WAF, when it's associated with an AWS WAF WebACL.
There are techniques on the application level that you can implement to reduce the costs of CloudFront delivery. Consider the following techniques:
- Leverage browser caching to reduce the amount of requests delivered by CloudFront
- Implement ETags on your objects to enable conditional requests. Object refreshes with 304 Not Modified responses are cheaper to deliver compared to full fetches.
- Implement image optimization to compress images using modern formats such as WebP and Avif. In addition, lazy load images on your website to avoid downloading ones that are not rendered by browsers.
- Implement Adaptive Bit Rate streaming for video delivery. Consider QVBR video encoding. Consider delivering optimized rendition ladder according to device types. This blog explains this concept, however it was written using Lambda@Edge prior to launching CloudFront Functions.
- Use a Same Origin Policy if possible for API calls, which removes the cost of preflight CORS OPTION requests. Read this blog for further details.
- Consider all logging options and select most cost efficient one for you. CloudFront's standard access logs is provided at no additional charges, however it applies to all your traffic. On the contrary, CloudFront's real time logs are granularly configured by CloudFront Cache Behavior, and by required field for an incremental charge. WAF offers multiple logging options, the most cost efficient one being the one based on Kinesis Firehose. Note that you can filter logged requests based on dimensions like rule action or emitted label.
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.
Comments
Log in to comment