At the beginning of November, CloudFlare released an article about how to use it's service with S3, providing a free CDN layer.  Being a loyal user of CloudFlare for several years and always interested in being able to provide added value to clients and my own site, I decided to give it a try while setting up a new blog site


If you are not aware, a CDN (Content Delivery Network) is a service designed to optimize the delivery of your web assets, and has two notable benefits.

Reduced Bandwidth to S3 Buckets

If successful this would drastically reduce the asset bandwidth costs, to near zero, as CloudFlare caches most static asset types (css, js, jpg, gif,pdf,swf, svg, ico, png, jar and more), so S3 only has to serve them a few times to CloudFlare, having subsequent requests coming directly from CloudFlare caches.  This is of particular use to bloggers, who distribute content on platforms like Flipboard, which itself doesn't cache images for articles you post, and instead uses your bandwidth, which you pay for on S3.  If your article starts getting traction/goes viral, and your image is of even a remotely decent quality, you could be on the hook for a lot of $$$, as you are paying for every time your article is shown to a user.  On a site I recently worked on, this translated into over $400 a month, and we weren't even hitting the big times.

Faster Page Load Times

S3 is not designed to efficiently server assets for website, which is why Amazon also provides the CloudFront service, it's answer to converting your S3 buckets into a CDN, but unlike CloudFlare you have to pay for it.  In most cases CloudFront is less expensive than S3, but under some circumstances it is on par or more expensive.  The reason why most people tend to use CDN's is because they are designed to decrease asset delivery time, by caching them for quick retrieval in geographically optimal locations around the world, so that they can be served faster and have a shorter distance to travel to get to your user's computer.

The Drawbacks

When I first read the article my first impression was that is was a hack, which made me skeptical, but now having gone through the process for 2 sites, it is actually not all that complicated and can be completed in about 15 minutes, with only two notable warnings.

Backward Compatibility

This seems to be the primary issues, but only for those of you who are currently serving assets directly from your s3 buckets (aka, and only if you have assets in the wild using that bucket name (like on Flipboard) which you don't want to start 404ing, because you will need to rename that bucket.  If you do have assets in the wild and care about continuing to serve them, you can still use this process however it won't work on those existing assets urls, but will for those going forward.  To do this, you simply create a new bucket for this process, and copy over all your assets to that new bucket, and serve the assets from your new CDN going forward.

S3 Direct URLs Won't Support HTTPS

Because this process asks you to name your bucket the same as your CDN host name, it will contain dots (.), e.g. "", and S3 does not support SSL/HTTPS for buckets named that way.  "" will generate a security error, whereas "" would not.  But do not fret, because CloudFront has you covered.  CloudFront provides SSL/HTTPS services for all domains that it is providing service to, so "" will work without error.


In order to implement this CDN, you must first have an AWS account, and access to a domain name.

The Process

The process if fairly well outlined in the CloudFlare article, but can be broken down into 6 steps

  1. Create a CloudFlare account
  2. Assign it as your domains name servers
  3. Decide on the domain/sub-domain for your CDN, e.g.
  4. Create an s3 bucket using your CDN's domain as the bucket name, e.g. bucket name:
  5. Using CloudFlare's domain services, create an ANAME record, pointing your domain to your S3 bucket domain, e.g. =>
  6. Use your CDN domain name for all your S3 assets, e.g.

Graphic Designed by Freepik