Cloudfront Vs Amazon S3: Learn How They Compare To Make The Right Decision For Your Business
Disclosure: Your support helps keep the site running! We earn a referral fee for some of the services we recommend on this page. Learn more
photo credit: getButterfly via photopin cc
From database hosting to servers hosted in the cloud, Amazon offers a wide variety of Web services. However, most webmasters find themselves considering just one of the two: Amazon Simple Storage Service (S3) or Amazon Cloudfront. While Cloudfront is actually built on top of Amazon S3, these two services have very different purposes and should not be used interchangeably.
Which solution is better for your your site? It depends on your goals, but knowing which service is right for you can help you avoid potentially costly mistakes.
Big ‘n’ Thrifty: Using Amazon S3
Amazon S3 is similar to many other hosting solutions, storing your files at a central location for access. It generally offers less expensive bandwidth and storage than traditional shared or virtual private server (VPS) hosting accounts, as well as greater reliability and faster access to your data.
Amazon S3 is ideal when low cost of bandwidth and storage is more critical than speed of access. Some good examples would include non-public-facing elements of your site (like storage and access to backups) and large downloads (like podcasts, software, and games).
Small ‘n’ Speedy: Using Cloudfront
Cloudfront, on the other hand, is all about speed of access. Whenever you upgrade an S3 bucket to Cloudfront, your data is immediately pushed out to their edge locations around the world. This gives users much faster access to the data, but this speed comes at a cost. Each edge location has an associated cost in addition to the regular Amazon S3 fees. Very active or very large files can generate significant fees.
This makes Cloudfront best suited for smaller, static files when speed matters more than economy. Good examples include images, JavaScript, and CSS files. These smaller files need to load quickly, but they will use only a minimal amount of bandwidth, making them cost-effective to distribute over the content delivery network (CDN).
Smaller files are most noticeable when they fail to download quickly, especially when that failure prevents a website from loading properly. Shaving milliseconds off the loading time of site images can dramatically affect the overall loading time of the site. Using Cloudfront makes the most sense with small- to moderately-sized files that carry minimal increased costs but provide a major boost in performance with increased speed.
The rules for using these services are far from absolute. Twitter, for example, uses Amazon S3 instead of Cloudfront for hosting avatar and other image files. S3 provides adequate speed, and Cloudfront would have been cost-prohibitive with such a large number of files. Consequently, Twitter relied on Amazon S3 for some time, although it has since switched to Akamai for its avatar hosting.
Both tools have their place. Amazon continues to offer both (and has even expanded S3 by offering Reduced Redundancy Storage), but choosing the wrong solution for your business needs can compromise user experience and create needless expense. Using the right tool for the job can help you keep things speedy and user-friendly—without breaking the bank.
Keep up with posts like this by subscribing to our RSS feed, or following @WhoIsHosting on Twitter.
quicloud, LLC
October 30, 2014
Please research your material before you put things up for public consumption and end up spreading more confusion. This is a horrible, horrible article with several *huge* mis-interpretations and outright wrong info. Leaving some clarification here for those who stumble onto this page:
CloudFront is NOT built “on top” of S3. S3 *can be* the origin server for CF, but it doesn’t have to be (you can also use your own origin server — for static distributions).
S3 is an Object Store, CF is a CDN. The only time it makes sense to compare these two is when you’re talking about delivering content out of one or the other. They are different tools for different purposes. Read the wikipedia articles on “object storage” and “content delivery network” before trying to compare them.
It’s not an “either or” when using S3 or CF… because they are different tools, you use them for different purposes.
When delivering static content, CF is *always* lower bandwidth costs (because the tiered discounts are steeper for CF than S3)
Mis-statements:
” This makes Cloudfront best suited for smaller, static files when speed matters more than economy.”
-completely, totally wrong. CF is for when you want the benefits of a CDN (lower latency, offloading the serving of static content, streaming audio, video). S3 is for when you want the benefits of an object store (high durability, low storage cost/GB, high concurrent throughput)
“Whenever you upgrade an S3 bucket to Cloudfront, your data is immediately pushed out to their edge locations around the world.”
-Wow… I’m usually not cruel, but… did you even bother to read the AWS CF FAQ before trying to write this? CF is a *pull* mechanism… the edges are not populated until a user accessing through a CF url tries to pull (and gets a cache miss from the edge). At that time, the origin server is consulted & the content is pulled to the edge. There is no way to “immediately push content out to the edges”.
“Using Cloudfront makes the most sense with small- to moderately-sized files that carry minimal increased costs but provide a major boost in performance with increased speed.”
-Wrong. CF makes the most sense for ANY files of ANY size when you need lower latency. You can also use it for streaming.
There are at least 2-3 other blatantly wrong mis-statements in here, but hopefully anyone who reads this knows enough now to not commit any of the original article to memory.