Overview

In this episode series, I thought we would take a look at hosting static websites on AWS, using S3, CloudFront, and Route 53. The plan is to register a domain, create a simple static site, and have it running on AWS, all for just a few dollars a month.

You are actually looking at the final product of what we are going to create throughout this series. It is a simple static website, hosted on AWS, using the custom domain websiteinthecloud.com. But there is something special about this site, it is actually hosted entirely on the CloudFront content delivery network, meaning that it is likely cached geographically close to you.

There are many reasons why you might want to host a static site besides load times. Maybe, you have a personal blog, a side projects landing page, or even a corporate initiative, where you need some type of web presence. For example, say you had a massive influx in traffic, you might not even know about it, since CloudFront will seamlessly handle it for you.

Let’s Get Started

Okay, so now that you know what we are going to do, and why we might want to do it, how do we get started? Well, Amazon actually has a great guide on how to host static website on AWS, and it is a great reference. They sum it up, as the ability to easy and inexpensively use AWS to host static web content, then over here they have it broken up into steps that you can follow.

We are not actually going to follow this guide, because I like to do things in a different order, but I wanted to show you this at the outside, as it is packed with useful information. The general theme of what we are going to cover, is summed up nicely here, where we are going to configure a S3 bucket to host our website, speed up access to that S3 bucket via the CloudFront content delivery network, and finally we will associate our custom domain with the CloudFront distribution.

What Are We Building (Full Cloudfront)

Lets have a look at a few diagrams, as it should give you an idea of what we are trying to do, and I think it will explain something complex rather quickly.

First, we are going to start out with a new S3 bucket, since I am not sure how familiar you are with AWS, S3 stands for Simple Storage Service, and it is basically like a cloud storage on steroids. You can create S3 buckets in the various regions, where AWS has data centres located, but this bucket will be in the US.

Next, we will configure CloudFront, this is a geographically distributed content delivery network, which helps improve page load times by locating the content close to end users. Basically, instead of having our website only hosted in the US on S3, we can cache it in various edge location around the world, in this case the US, Europe, and Asia.

Finally, we are going to purchase the domain websiteinthecloud.com, so we need some way of resolving that domain to an IP address, via a name server. For this, we are going to use Route 53, which is an AWS hosted DNS solution. Funny enough, I downloaded the AWS icon pack, where they give you the logos for their various services, not sure why this one is a sheriffs badge.

Okay, at this point, all we need it some example website content to put into the S3 bucket down here, and we have a working static website hosted on AWS using S3, CloudFront, and Route 53. We are going to use the bootstrap framework, along with a free theme, to create the static site you viewed just a couple minutes ago. For lack of a better name, I am going to call this the full CloudFront solution, and we will compare this with a similar static hosting architecture in just a minute.

Model Traffic Flow (Full Cloudfront)

So, how does something like this work? Well, lets say we open up a browser and make a connection to websiteinthecloud.com. We are going to hit Route 53, since our domains DNS records are stored there, this will point us to a geographically close CloudFront distribution where the apex domain websiteinthecloud.com is cached, since this is our first request, it will result in a cache miss. CloudFront will reach into the S3 bucket where our static website is stored, and fetch the index.html page, seamlessly returning it to the user. The more times you do this for various pages, the CloudFront cache will become populated with our site, so you can services huge amounts of traffic, directly to servers that are geographically close to your end users. Any cache misses will seamlessly be fetched from the S3 bucket. The default ttl for caches objects in CloudFront is 24 hours, what is means is that, CloudFront will expire content after 24 hours, and connect into your S3 bucket for fresh versions.

I used this exact model, for well over a year, when serving up this site to end users. It gave me the flexibility to not worry about hosting a website, especially one that was not getting much traffic, so the pay as you go part of AWS really helped.

War Story

Funny story about this, someone posted my site to Reddit when I was first starting out, and gave me a massive influx of traffic for a couple days. I never even knew about it, until I was casually checking Google Analytics and noticed over 200 people on the site. To say I was floored would be an understatement, when you are used to 10 hits a day, and there are 200 people on the site, at one time, it was pretty exciting.

Now, if I was using some type of content management system, this could have turned into a curse, and I might suffer from the slashdot effect. Basically, in full panic mode, trying to add additional capacity to service this influx of unexpected traffic, crossing my fingers that the sites does not die. A day later, the traffic was back to normal, and I was pretty happy for my little static site solution. So, there is a little war story for you.

What Are We Building (Hybrid S3 Cloudfront)

There is one other static hosting architecture that I wanted to review before to configure all this. This is a bit of a hybrid, in that we use S3 and CloudFront at the same time. S3 serves our main website, and CloudFront for assets, things like images, stylesheets, and javascript.

So, we have S3 here, again hosted out of a US data centre, this will serve websiteinthecloud.com, along with www.websiteinthecloud.com. Then we will configure something like assets.websiteinthecloud.com, sitting on CloudFront for our images, stylesheets, and javascript. We will use Route 53 again, but rather than point our domain directly at CloudFront, like we did last time, we will configure the main site to point at S3, and assets coming off CloudFront. Then we push our website to S3, just like before, and I am going to call this the hybrid S3 and CloudFront static hosting model.

We are not actually going to configure this hybrid model, as we will focus on the fully CloudFront static hosting option, but I will talk about it along the way. It will be easy to go that route if you want. By the way, I have totally made these names up, just wanted something to reference throughout this series, so that you will know what I am talking about.

Model Traffic Flow (Hybrid S3 Cloudfront)

So, lets model how requests might flow in this architecture. Someone makes a request for websiteinthecloud.com, since Route 53 is acting as our nameserver, it will handle the request, and point the person at our S3 bucket hosting the apex domain websiteinthecloud.com. They download the index.html page, and this page has some includes, things like images, stylesheets, and javascript, which just so happen to be hosted on assets.websiteinthecloud.com, served via CloudFront. We hit a cache miss, just like before, CloudFront pulls the content out of the S3 bucked, returning the files to the end user, and the cache is now primed. So, if we have a huge influx of traffic, our S3 bucked might serve a fraction of that traffic, but the bulk will be fired off to CloudFront, for things like common includes. If there are any cache missed, CloudFront will seamlessly serve them too, by pulling the files from S3.

The reason I call this a hybrid architecture, is that you can swap out S3 here, for say a virtual machine running your dynamic content. The source of where CloudFront pulls files from does not need to be a S3 bucket, it could be a web server too. Say for example, that you have some type of web app, where you need to support users logins, and you want to speed up your site. This is the configuration that I use today, this episode is served off it, so hopefully it was speedy. But, I really want to focus on static content for this episode series, and in the future we can talk about scaling out dynamic sites, as that is a pretty huge topic.

Maybe this was a little long winded, but I really wanted to set the stage, so that you know what we are trying to do, and why we are trying to do it.

AWS Simple Monthly Calculator

Before we go and register our websiteinthecloud.com domain, I just wanted to address a couple things, especially if you are new to AWS. One thing that comes up all the time is, well if AWS is pay as you go, how can I estimate my bill? What is something like this going to cost? Well, there is a site called AWS Simple Monthly Calculator, that will greatly help in estimating the costs, so I just wanted to quickly show you it.

Down the left hand site here, you can the various service offerings from AWS, things like S3, Route 53, and CloudFront. You can see up here, this free usage tier checkbox, AWS offers heavy discounts for new users, so they can play around with things and not pay too much. Lets uncheck this for now, just so that we can get a worse case scenario costing, of what our mocked up environment will run us.

We are under the S3 service offering, and lets say, we are going to use 1 gig of storage. So, that is going to cost a few cents a month. With S3, you actually pay by the request, for things like put and get requests. So, lets say when we upload the site, we are going to use ten thousand put requests, and one hundred thousand get requests. Then we need to estimate the bandwidth being used, well since we are going to have CloudFront sitting in front of this S3 bucket, serving all the request, bandwidth should not be that crazy. Lets say, 2 gigs inter region, this means transfers from when CloudFront pulls files out of the S3 bucked to populate the cache. Then 1 gig each for data transferred in and out of S3 as we upload our website content. As you can see, hosting a small site on AWS with just S3 is dirt cheap, but now lets see what Route 53, and CloudFront add to the bill. I should mention, that these are total guesses, but you get the idea, just play around with the values and see what you come up with based off your traffic numbers. If you are thinking about moving over to AWS, look at your current stats, plug those number into this calculator, then you can get a good idea of what you are looking at.

Next, lets head over to Route 53, configuring 1 hosted zone, for our websiteinthecloud.com domain. With Route 53, you bay be the millions of DNS queries served, so the smallest we can choose is 1 million, but for a small site this is more than sufficient.

Finally, lets head over to CloudFront. So, the big one here, is bandwidth. For a small blog, 50 gig might be sufficient, it all depends on how large of files you are serving, and how many people you expect. This edge location traffic distribution comes into play too, in that some regions cost more. But, lets just leave these default, and assume the worst case. You could play around with these, say for example, that you know most of the traffic will from the the USA and Europe, then the bill will drastically drop. With CloudFront you can also select what price class you want, which will limit the regions your content is cached it, so this helps shape the billing profile.

So, you can see, for just a few dollars a month, you get access to an extremely cool hosting solution. If you are new to AWS, then you qualify for the free tier, and as you can see this drastically reduced the price for 12 months. You can actually check out the free tier page, where they walk you through the various allocations provided, this like compute, storage, database, CloudFront, etc.

Wrapping Up

Okay, so that is basically what this series is about, now lets go register our domain. My domain register of choice is namecheap, as they just work for me, and I have never had any issues. Surprisingly enough, when I was brainstorming this episode idea, the thought behind it was a website in the cloud, so I was pretty happy to see that it was available. So, for this episode, we will use the websiteinthecloud.com domain, I picked up Whois Guard, as I hate getting spam from the public listings of whois records, and I also picked up a SSL cert for a couple bucks. My thinking is that, we can create a follow up episode, where we add SSL to this domain via AWS.

Okay, so that it is for this episode, throughout the rest of this series, we will build out this full CloudFront solution, hosting the apex or root domain websiteinthecloud.com, along with www.websiteinthecloud.com. By proxy of all this, you will learn about this hybrid model too, as the steps are almost exactly the same.