This week I will start to explain about AWS CDN service , Cloudfront. With Cloudfront , we can distribute of our services’ static and dynamic contents using AWS edge servers. By using Cloudfront, users can reach our services with lower latency and this makes better user experience and also keeps our servers free as possible. In this post I will create an S3 bucket and use this bucket as origin for my distribution.
First of all, let’s create a bucket names wekanban, create some paths and upload some files. In our distributions, we can use path names as origin names like wekanban/images or wekanban/css etc ( this feature has been enabled recently http://aws.amazon.com/about-aws/whats-new/2014/12/16/amazon-cloudfront-now-allows-directory-path-as-origin-name/ )
Creating the bucket:
After that I upload my css,fonts,img and js files to the folders. Of course if I try to access any file now, access will be denied (We did’t enable public access for our files)
Now it is time to create our distribution. On Cloudfront console , I click “Create Distribution”. Here there are two options, web and rtmp. As it says , web is used for web distributions and rtmp is used for media streaming. We continue with web distribution.
In origin domain name, I will select my S3 bucket. As you see when we click , it shows us our buckets and we can select which we want to use. You can also use another EC2 or on-premise server as your origin server and then you have to use the correct domain name for it.
In origin path , I won’t use any path. If I want to use different distribution settings for different file types , I have to define the path like /img or /js. But here I will use same setting so unless I define it , Cloudfront will cache it recursively.
Origin Id is a description , and I leave it as default.
If we want to restrict access to the bucket , we should enable it. Here there are some options.
1- If we don’t want to restrict access, we should make the files in the bucket publicly accessible. In this way users can directly access the files using S3 url and this makes more cost for us.
2- We can restrict users and they only can access the files via Cloudfront url.
3- We can use signed-urls (restricting access for Cloudfront objects. I will write another post about this topic.) for our distributions.
I will choose the second option. now , I have to choose an access identity for Cloudfront, a user for Cloudfront that will have access permissions on our buckets. I can create a new one or use an existing one. Of course, there should be policy for this user on our bucket. We can select Cloudfront to create one or we can give the permission manually ( we can use both ACL or bucket policies for our S3 bucket ). I choose “Yes, Update Bucket Policy”.
In Default cache behavior settings, I leave all the options as default. These settings can be fine tuned according to your application. For example, if we want to cache cookies, how long and restrict access for user. You can find the details in AWS Cloudfront developer guide http://awsdocs.s3.amazonaws.com/CF/latest/cf_dg.pdf
In distribution settings, we can select the price class ( which edge locations we want to use ). Also we can use cname for the Cloudfront Urls. Instead of using Cloudfront generated links, we can use our domain name like http://www.wekanban.com/image/image1.jpg. If we set the protocol policy as HTTPS ( in default cache behaviour settings ) ,
we can use Cloudfront certificates or the certificates we uploaded via IAM ( if you choose to use CNAME, this option must be selected ). Default root object is used for to response to your default page when a user tries to access the root URL( for example , if I set it to index.php , and user goes to www.wekanban.com it will redirect to www.wekanban.com/index.html ). Other options are related to logging and log destination bucket. By default, distribution state is enabled and if you click “Create Distribution”, Cloudfront will start to take action.
In distributions tab , we can see the status of our distribution. As you see, the domain name is “dhc3hoc3059rw.cloudfront.net” and it is in progress. This will take some time and after that we will be able to server our files.
After a while, we see that it is deployed. We can now test the result. I had already uploaded files and let’s try to access it via Cloudfront URL.
And as expected, we can browse it and this image is served by Cloudfront edge servers.
If I want to browse the image using the S3 url, access will be denied, since we configure only access via Cloudfront.
In my next post I will configure signed-urls. If you have any question or comment, please feel free to write and don’t forget to share please.