This blog will cover how to serve your static assets from an Amazon S3 bucket & configuring that bucket to be served by Amazons Cloudfront Content Delivery Network (CDN) service for optimised delivery of assets across the world. if you are unfamiliar with what a CDN can do for you then I recommend reading the following article Jack Whitey - CDN
Throughout this article I assume that you already have an Amazon AWS account. If you do not, then please visit Amazon AWS and register an account before continuing.
Login to your Amazon Account and then visit the 'My Console' tab. Once you have located this visit the S3 tab and create a bucket.
Give the bucket a relevant name and just choose Region 'Us Standard'.
You've now created your amazon S3 bucket. Nice. But, it's not much use, so let's upload an image file to it. Click the upload button and upload a random image file on your machine to it. Hit start upload and then watch. Once it's uploaded it should appear in the left hand side bucket. If it does, click it and change the tab on the top left to 'Properties' here you'll find a link to the item. Click it and you should be faced with a permission denied XML output alot like the image below.
This is good as I want to expose you to an important part of S3, permissions. Permissions in terms of Amazon S3 mean whether or not something is public or privately viewable. Complicated rules can be created to determine the visibility of any item in any S3 bucket.
In our case we just want this file to be publicly viewable. So, we'll just click properties on the image and then permissions and add a new rule for 'Everyone' to Open/Download and save. Now if you click the same link once the save has been successful you should see the image served.
Well done! This is your first image being served from the Amazon S3 bucket service. Although this is now being served by Amazon S3 you can go better. Serving that same image via Amazons own CloudFront service will perhaps give your site a bit more global oomph! CloudFront syncs your bucket across all Amazons data centres around the world and routes requests to the nearest (most local) data centre. This should ensure that all static assets are served from a geographically closer location than if you just hosted it from the US only region.
To enable CloudFront for your application you need to head back to your Amazon Console and open the CloudFront Service. Once you have it open follow the steps below:
The distribution will take about 10 minutes to spin up. Once it's done the important thing to note is your domain name for example - d3pmoderwnmasf.cloudfront.net/. This is the base URL for your buckets contents when served over CDN (you can also use the CNAME you registered).
Depending on how quickly your CNAME resolves you will be able to access your file via d3pmoderwnmasf.cloudfront.net
or your CNAME.
In a small test against serving from an S3 bucket from the US region versus calling the bucket via the CDN I was serving an image asset at an average of 130 ms from the bucket and 30 ms from the CDN. The biggest part of which was probably that being in the UK my requests from the CDN we're probably being routed to the EU Ireland data centre accounting for a dramatically quicker geographical serving.
You can now link to these assets very easily in your code by using your CDN URL.
So thats serving assets from an S3 bucket, but, where does Wordpress come in I here you ask? Continue reading as this is where it all gets interesting.
If you are looking to scale a Wordpress site and serve all assets via an S3 bucket fronted by the AWS CloudFront CDN then this is where things get interesting.
In part II - Serving Wordpress assets from AWS S3 and AWS CloudFront »
I deal with how to configure Wordpress to upload all uploaded content to the Amazon S3 bucket automatically and how to use a third party service such as beanstalkapp.com to automatically push static assets to S3 when a new deployment is ready at the source code level (it's very neat).