Quickly add Amazon Cloudfront as a CDN
The way it works is that you point your image URLs to Amazon, and Amazon knows how to map those onto the images which continue to live where they are on your webserver and to be accessible by their own URLs. If Amazon gets a request for an image it doesn’t have, it grabs it from your server and serves it – but then caches them all so the next request (or 10,000 requests!) will hit Amazon’s servers and not yours. It also helps a bit because the domain is different and there is a limit on how many parallel requests browsers will make to any given domain, so you get more parallel requests on your page too.
Configurable Image Paths
I was able to switch out my image paths very easily because all images in the system had a path like $config['productImagePath'] – mostly this can help on dev platforms if they’re not all the same, but also it helps if you need to move your images at a later date, as I had known could happen (and it did!). If this isn’t already in place, you need to go find every image and make its URL configurable.
Set up Amazon Cloud Front
Head over to your Amazon Web Services console https://console.aws.amazon.com (it’ll prompt you to sign up or log in as appropriate) and look for “Amazon CloudFront” in the “Storage” section.
Click the “create distribution” button and configure a few things:
- Delivery method: web
- Origin domain name:
[domain where the images are served from right now] - Price class: choose which regions you need your images served from, it affects the cost
Then you need to wait for a few minutes while the cogs turn and it all gets created.
Testing Your Setup
You will get a URL for your CloudFront that looks like http://uttergobbledegook.cloudfront.net and you use that in place of the source domain you set earlier. So if your images were at http://mygreatsite.com/product_images/whisk.jpg now you should be able to request http://uttergobbledegook.cloudfront.net/product_images/whisk.jpg in your browser. Once it’s cached, the response time should be very quick too.
Now go back and where your configuration settings once pointed to a URL on your own site, they will now point to the path under the CloudFront domain … you probably need different distributions for your various staging/live platforms, and these can be enabled and disabled differently.
I found this was a very painless way of getting a CDN into place – no changes to the development platforms, minor config changes to the staging/live platforms, and the images stay in the same place that they always lived!
Whatever Next?
There are actually a few things you can do from here:
- Use a
cnamealias to make a nicer URL such ashttp://static.mygreatsite.com - Tweak the caching rules to make sure they make sense for your application, they are very VERY configurable
- If the images you’re serving are assets rather than upload files, consider deploying them straight to S3 and setting up your CloudFront to server from there
Did this work for you? What did I miss? And did Amazon update their interface since I wrote this post (this happens often). Please leave a comment :)
Succinct and very beneficial. Thanks for the great post!
Hello,
we have also added cloudfront to our setup, but so far we can’t see a improvement in loadtimes for remote sites.
Have you a reliable way to measure cdn performance?
We did try with http://www.webpagetest.org/,
it seems to load our static content from aws edge servers,
but load times in asia + south america are just very very slow…
We saw a speed up in performance but as a result of reducing server load. How much it helps each user load the page will vary from application to application though
For starters, I’d look into alternatives like EdgeCast, Akamai (both very affordable via resellers) or fastly. Cloudfront has lots of random issues which you can read about on the AWS forums and stackoverflow. To say the least: response time with Cloudfront compared to other CDNs is subpar.
Using a CNAME — I’d also not do this. It’s only cosmetics. It’ll bite you as soon as you need SSL which is either not possible with Cloudfront (issues with the browser since the certificate won’t work) or will be very expensive to setup since you’ll have to get your CDN provider to announce/distribute your SSL certificate. In addition, just by using a CNAME you’ll introduce more potential breakage and issues into the stack for little benefit.
Another thing to take into account is to introduce versioning with a CDN so you don’t have to constantly run an invalidation — e.g. you change style.css but the change won’t be picked up before the cache runs out. This may or may not impact your website. You can always manually invalidate but it’s easier to have something like style-x.y.z.css so you don’t have to do it. This is probably the biggest gotcha for people who are new to caching and CDNs. ;)
So yeah, on using S3 — viable alternative, but I found that using a transparent proxy still yields the best results and doesn’t require additional steps in the build an deployment process.
@Andre: A reliable way to test CDNs is something like pingdom. Run pingdom against a couple URLs (e.g. jquery hosted on various CDNs) for a few weeks and compare by origin location which is most interesting for you. Done this before on my own blog but I haven’t updated in a while (I hope a link is alright in this case):
http://till.klampaeckel.de/blog/archives/100-Shopping-for-a-CDN.html
Is it better to manually configure CDN on your website? I am using Cloudflare on my PHP site which is via a PaaS (https://www.cloudways.com/en/php-cloud-hosting.php ) that allows automatic configuration. I was wondering if it is better to do it manually or not.