Silvrback is hands down the best blogging platform for tech bloggers and definitely one of the best blogging platforms overall. Let it be clear that this article is to demonstrate how your Silvrback blog (or really any website for that matter) can utilise a CDN. It is not meant to point out any flaws or infer that Silvrback is inadequate in any way.



If this has (or will) inspire you to get your own domain, I would highly recommend iwantmyname.com. Apart from the fact it lets you search hundreds of new gTLDs it also has a custom page for Silvrback!



This article looks much longer than it actually is because it contains many screenshots and some explanation to try and make it as simple to follow as possible. Let's begin...

When it came time to add my own domain (elliot.land) I wanted the following - in order of highest importance first:

  1. HTTP and HTTPS support.
  2. With and without www.
  3. Faster.
  4. Allow the domain to be used for other things in future.

The Existing Solution

I bought my domain through Godaddy and fortunately there is already a setup guide on Silvrback for this exact scenario:



Unfortunately this doesn't tick any of my 4 requirements. Time for a CDN...

What is a CDN?

A Content Delivery Network (CDN) is one or more data centres that can serve out static content very fast. It's fast because the pages do not have to be generated (at least not after the first time, we'll get to this). Furthermore, routing is done on a geographic basis so the assets come from the nearest data centre. Here is a pretty visualisation:



In a nutshell the pages are served from the data centre and rarely have to back to the origin server where the content is generated until such a time that the CDN decides that the content is now to too old and needs to be refreshed. This is called the TTL (Time-to-live) and is specified as the number of seconds the page (or asset, these are interchangeable) can be delivered to clients without getting the latest version from the origin.

What You Will Need

I chose to use the Amazon CDN product called CloudFront because I'm quite familiar with other AWS services; they are rock solid, reliable and cheap. We will also be using Route 53 for DNS to route the domain to CloudFront. Heres what you'll need:

  1. An SSL certificate. This is optional if you want your domain to have HTTPS.
  2. An AWS account to create and use the services. You are only billed for your usage. I have more information about cost below this.

These would be the steps taken. They shouldn't take more than an hour if this is the first time you've done this, probably less if your savvy with sort of this stuff.

  1. Create a CloudFront Distribution.
  2. Setup distribution Behaviors. These are the rules dictating how to serve the content.
  3. Create a Hosted Zone in Route 53. To setup all the DNS records for you domain.
  4. Update the name servers for your domain to point to Route 53.

There will be no effect on your existing domain until the last step when the name servers are changed over. The is a test checklist at the end before you change over the name servers.

Cost

If you chose to use AWS there will be a cost involved. What it really comes down to is:

  • US$0.50 per month for Route 53 to pay for one Hosted Zone.
  • US$0.085 per GB for CloudFront. It's very hard to determine how much traffic you would be doing before hand but unless your doing a lot you should be fine. There is no contract and the stats of usage are almost realtime, turn off at any time.



If everything looks good so far you should take the time to read all the rest of the article before you begin. This is a good way to really understand how the steps will happen to prevent any unnecessary confusion.

1. Create the CloudFront Distribution

Log into the AWS console, navigate to CloudFront and click Create Distribution:



You will be presented two choices, you want to select Get Started under the first choice, Web.

For the Origin Settings we need to fill in:

  • Origin Domain Name: This is the custom domain you will be using (without a subdomain).
  • Origin ID: Just a identifier for when your have multiple origins. You may change the auto-generated value if you like.
  • Origin Protocol Policy: The recommended value here is Match Viewer to allow both. You must use HTTP Only if you do not have an SSL certificate for your domain. We will add the certificate later if you do have one.



  • Viewer Protocol Policy: Use whatever you prefer here, but as above you must have an SSL certificate if you want to use HTTPS.



  • Price Class: This is up to you. You can read more about price classes here.
  • Alternate Domain Names: Here you want to add any subdomains that you will be using, for example the www subdomain. You can change these later but CloudFront will only respond to the domains specified here.
  • SSL Certificate: If you have an SSL certificate for you domain you must upload it here. Otherwise CloudFront will not be able to serve content over HTTPS. If you only care about HTTP you need not use this.



The final rules do not need to be changed just yet. We will setup more behaviours for the distribution next:



Finally click Create Distribution. It will take 10 minutes or so to propagate around to all the data centers and you can see the progress in the main CloudFront panel.



When the Status is Deployed we can test that the CloudFront endpoint is working by going to the Domain specified; which will be *.cloudfront.net.

You should see your blog, don't worry if the styles are not displaying correctly this is just because we're acting it through the CloudFront endpoint and some of the relative paths for resources cannot be found. This will not occur with you custom domain.

2. Setup CloudFront Behaviors

CloudFront “behaviors" are the rules for URLs based on regular expressions. You can use behaviours to fetch content from a different origin (like an S3 bucket, or another domain) and override the TTLs that come from the origin server. You may want both but the latter is the most useful right now.

We will create several behaviors. Navigate into the distribution and you will see a Behaviors tab. Click Create Behavior. I'll explain the first one in detail for mathjax/*.

  • Path Pattern: mathjax/* will match any url starting with mathjax/.
  • Origin: Where the content comes from. You will only have one origin.
  • Viewer Protocol Policy: Select the most appropriate one for if you have a SSL certificate installed or not.
  • Object Caching: This is where we can override the TTLs from Silvrback; by selecting Customize. I've set this to 1 day (86400 seconds).



To summarise the TTL for each:

  • email_subscriptions/*. Important: you must disable all caching here. This includes forwarding all headers and cookies. Otherwise it will return the error "The content could not be loaded." when clicking on subscribe.
  • mathjax/* is 86400. Despite not having MathJax turned on, it still serves all the assets for these out. They are by far the biggest assets served out.
  • assets/* is 86400. These are versioned (unique URLs) so you could set the TTL to a year if you want.
  • feed is 3600. This is the RSS feed. Adding new posts will not show in peoples feed readers for up to and hour. Fine for me since I post once per week.
  • favicon.ico is 86400. The little Silvrback icon in the location bar. I quite like the logo and love the fact it promotes Silvrback subtly.
  • / is 3600. One important thing here is you must Forward Query Strings because it uses query parameters to page through older posts in your archive. Unlike the other URLs that are not affected by URL parameters.
  • static/* is a route I setup to point to another origin, an S3 bucket. Anything requested on this URL will fetch from the S3 bucket. I know that these objects will never be changed under the same URL so i've added a bold 1 year TTL.
  • * is the default (catch all) rule. In this case, since it's the fallback, you will want it to pass the headers as-is straight through from the origin.

3. Create the Hosted Zone in Route 53

Log into the AWS console, navigate to Route 53 and click Create Hosted Zone:



The only field here you need to fill in is the domain (we will deal with subdomains later):



You can now click on the newly created hosted zone, and then click Create Record Set. This is the A record for the domain.

  • Name: Leave blank.
  • Alias: Yes
  • Alias Target: When you focus on this field you should see the CloudFront Distribution listed. If you do not see it click on the menu again, sometimes it sticks. If it still isn't on the menu it could be because the distribution is not ready yet. Try again in a couple of minutes.



And finally click Create.



You will create another A record the same way except this time add "www" into the Name field; assuming you want www.youdomain.com to point to your blog as well. You could point these A records to another server (allowing for different subdomains in the future), for example.

Once both A records have been created you should have four records in total in the hosted zone:



4. Update the Name Servers For Your Domain

This is the final stage where you will point your custom domain to Route 53. Before you do this you should run through this checklist:

  1. Make sure your blog comes up on the http://*.cloudfront.net URL. As stated earlier, some of the styles (such as the custom font) may not appear correctly. This is only while your accessing it through the CloudFront endpoint.
  2. If you are using an SSL certificate, check the https://*.cloudfront.net works as well. You will see the same thing as the http:// version.

Once everything looks good we need to get the name servers from Route 53. Under the record set will be an NS record containing the name servers:



Some registrars require you provide the IP only. You can use ping to lookup the IP for each name server:

$ ping ns-1778.awsdns-30.co.uk
PING ns-1778.awsdns-30.co.uk (205.251.198.242): 56 data bytes

Which ever registrar you are using for your domain will have their own name servers, you need to replace them with the name servers above. Here is an example of the name servers set on a Godaddy domain:



The changes will not be immediate. Computers around the world will be using their DNS cache for a while until it's looked up again. It's hard to know when this is fully propegated but the general rule is up to 24 hours. However, it's likely you will see the new domain in a couple of hours or less.

Here is the finished product, if your not looking at it already: