CloudFront is AWS own CDN (Content Delivery Network). CDNs are primarily used for caching, and many customers also use AWS CloudFront CDN as a security layer, or use it to handle network spikes. With AWS CloudFront CDN, when a user requests a webpage or an image, the request is routed to one of Amazon’s 225+ edge server locations. If the edge server already has the resource cached, it’s served to the client. If the resource isn’t on the edge server, it makes a request to a larger edge server called a regional edge cache, if it’s not there, the request arrives at an origin server that houses your application. The edge server then saves a copy of the response locally so it can handle the next request without pestering the origin server. This reduces load on the origin server, helping you keep the instance housing your application small, and is able to reduce latency for clients by moving commonly requested resources closer to the requestor. This is great for your latency, and user experience, but how does it impact your costs?
This guide will walk you through the following:
AWS CloudFront pricing starts with a very simple pricing model, you’re charged per GB transferred to the internet and for every HTTP request. There are also lots of optional features, like encryption, logging, Origin Shield, file invalidation, and edge server Lambda invocations that can also incur additional CloudFront costs.
The AWS CloudFront cost is billed per GB transferred from any CloudFront edge server out to the internet. Once you start transferring more than 40TB of data, you are charged less per GB, and the cost continues to decrease the more data you transfer until you hit 5PB. Like most AWS services, these costs vary by region. The initial rate for the serving data to the cheapest regions (United States, Mexico, Canada, Europe and Israel) is $0.085 per GB, and this cost doubles to $0.170 when serving data to the most expensive region (India). You’re also charged for requests that send data to your origin application, like WebSocket connections, or data attached to PUT requests from a client. Because CloudFront is intrinsically global, the region you’re billed for isn’t determined by where your application lives, but by where the requests to your application originate. You can manage these costs by setting a price class on your CloudFront distribution that excludes certain regions from your edge server network.
You can get an Amazon CloudFront pricing discount by committing to a regular level of use (typically at least 10TB transferred per month for a year long commitment period). Unlike many other services, these CloudFront “Reserved Instance” prices are not published, but if your organization can reasonably commit to transferring that data over a long time period, it could reduce your costs, so contact AWS and ask. You can also get a 30% discount by signing up for the CloudFront Security Savings Bundle. You have to commit to spending a specific amount on CloudFront services every month for a least a year, and it’s a great deal if you’re also considering utilizing the Amazon Web Application Firewall (WAF) because 10% of your commitment value is generated as WAF credit.
Another factor of AWS CloudFront pricing is being charged per 10,000 HTTP requests, and you’ll pay a premium of about 25% to handle HTTPS requests. These CloudFront costs also vary based on the region the request originated in, but the pricing difference is less dramatic than for data transfer, dropping from a 100% premium for data transfer to the most expensive regions to a 10% premium for handling requests from these areas.
Origin Shield is an additional caching layer that operates (and is priced based on) the availability zone of your origin server. All requests to your origin server go through this single caching layer, so users accessing different edge servers in different locations can be served the same cached content, and applications operating multiple CDNs have access to a unifying caching layer. This service is charged at the same rate as HTTP requests, adding to the cost of any request that makes it past an edge server. CloudFront also allows you to encrypt specific fields so only applications that have access to the decryption key are able to see sensitive data. This service costs $0.02 for every 10,000 requests that are encrypted (in addition to the HTTPS request costs). You have the option of generating and monitoring real time logs at a cost of $0.01 for every 1,000,000 log lines written. Finally, you can provide custom SSL certificates and domain name for your CloudFront distributions for $600 per month.
Now, with the understanding of Amazon CloudFront pricing and the many cost factors that contribute to its usage, there are several practical and common methods to reduce CloudFront costs. In the following, we’ll cover ways to reduce S3 and EC2 costs with CloudFront, the best way to configure CloudFront, and how to increase your cache hit ratio to trim costs.
Reducing AWS S3 and EC2 Costs With CloudFront
One of the most common uses of CloudFront is delivering web and media content stored in an S3 bucket or EC2 instance to clients all over the world. At low data volumes, the cost of using S3 is actually cheaper because every month you get the first GB transferred out free, but as soon as you start to increase your usage, the cheaper per GB cost of serving data from CloudFront kicks in. In a cheap region like US East Ohio, that inflection point is 18 GB.
Once the amount of data transferred out to the internet increases, the pricing gap for data transfer costs starts to widen. Once you start transferring terabytes of data, the distance between serving content from an origin like S3 and using CloudFront to deliver content opens up dramatically.
It’s important to realize that CloudFront has a special status in the AWS universe. Normally, you’re charged for data transferred between availability zones. However, data transferred from AWS services to CloudFront servers doesn’t cost a cent. If you’re transferring a very small amount of data out to the internet, it’s cheaper to not use CloudFront, but if you’re transferring data between zones, or are dealing with larger data transfer costs, CloudFront is almost always going to save money. This special status also makes it cost effective to always pair CloudFront with hosting your origin server on the AWS network. If you self host your origin server, or use a different provider, those data transfer savings vanish, and you have to pay to transfer data into CloudFront, which means anytime an item is not in the cache, you’re paying twice, once to transfer data to the CDN, then again to transfer the data to the client.
Comparing the cost of handling HTTP requests between S3 and CloudFront is less straightforward. If your application is exclusively serving GET results, handling requests out of an S3 bucket is significantly cheaper. In US East Ohio, you’ll pay $0.004 per 10,000 requests made directly against an S3 bucket, but you’ll pay at least $0.0075 to serve requests from CloudFront, making it almost 90% more expensive. This calculation is flipped once you start mixing in POST requests. The price doesn’t change based on request type for CloudFront, but it shoots up by more than 100% for S3 buckets, you’ll pay $0.05 to serve up 10,000 POST requests, so CloudFront becomes the better deal, offering an 85% discount on these types of requests.
For most applications, data transfer costs and savings on instance size will significantly overshadow the cost of serving requests, so this difference is rarely significant, but if a large portion of the costs for your CloudFront application are caused by many requests for small files, and you can guarantee those requests will primarily be GETs, then consider skipping CloudFront. On the subject of requests, you should also evaluate how necessary using HTTPS is for your application. Handling HTTPS requests adds about 25% to request costs, so if you’re not receiving sensitive data, using plain HTTP can save you a chunk of change.
One of the best ways to reduce requests to any web server is by caching content on the client’s browser. This basic idea applies twice when using CloudFront, because CloudFront adds a second layer of caching, files are also cached on edge servers. By default, all files served by CloudFront’s edge server expire after 24 hours, which is far too low for many types of content. You can increase the value of your CloudFront network by appropriately caching objects, particularly ones that you are confident will not change for a while. You can set how long both the client and edge server caches objects by setting the Cache-Control HTTP header at your origin server. You can also instruct your edge servers to implement their own caching policy by setting Time To Live (TTL) values when you create or update your CloudFront distribution. Be aware that edge server caching is important to plan and implement carefully because if you want to invalidate files before they expire, you can invalidate 1,000 paths for free each month but you’ll pay $0.005 per path invalidated after that limit.
A primary goal of the CloudFront CDN is to avoid inundating your origin server by allowing edge servers to efficiently respond to client requests. This functionality is undermined if most clients end up requesting content that isn’t cached. The ratio of requests that are handled by the edge server compared to the number of requests that arrive at the origin server is called the cache hit ratio. You can increase this ratio by understanding how the cache key works. When a resource is requested by a client, CloudFront generates a cache key (by default, this uses the domain of the distribution and the path of the requested object, but you can modify those settings then store the cache key and use it to serve future matching requests. To increase the hit percentage, consolidate application views to resolve to a single cache key and avoid adding data that might cause two requests with the same results to generate different cache keys, like creating two URLs that point at the same resource.
CloudFront can be configured to automatically compress some kinds of files. CloudFront compression will result in a faster load time for clients, and will decrease your costs as edge servers transfer smaller amounts of data to clients. In addition to using default compression, compress resources as they are generated by your origin server.
The CloudFront free tier is one of the most generous in the AWS family, you get 50 GB of data transfer out and two million requests every month for a year. If you aren’t already using CloudFront, the free tier can help you decide if it can help you downsize the instance serving your application or dramatically improve client experience by decreasing their load time.
Amazon CloudFront CDN makes serving resources from a globally distributed CDN simple. This can reduce latency, handle spikes in demand, and decrease the load on your application servers. Leveraging good caching policies, compression, and understanding how the cache key works allows CloudFront to perform these tasks effectively, which helps you get the most value from the service.
First published here