Up Front - Zone Apex delivery from AWS Cloudfront

AWS Cloudfront is a superb CDN (Content Delivery Network), and not just for the obvious reasons (delivery of dynamic, static and streaming content to a global network of edge locations). As an infrastructure component it can chop a substantial chunk from your virtual resource and hosting budget along with substantial increases in security and uptime if used for full site delivery.
As yet zone apex/root domain mapping isn't natively supported however with some lateral thinking TLD resolution for static sites to a CF distribution can be achieved.

Stage 1 - Create your origin server and subdomain

For reasons which will become apparent as we progress if you want to resolve your zone apex to a CF distribution you will need to host your site in webspace outside of your web root. This could be a subdomain/vhost on an EC2 Micro or somewhere else, it doesn't really matter.
Create the sub and relevant A record to the IP in your DNS, you don't have to use AWS Route 53 DNS but it is recommended. In this example we are using 'yourdomain.com' as the TLD with a subdomain of 'origin.yourdomain.com' and an IP of 123.45.67.89. The A record for this would be :

origin.yourdomain.com   A   123.45.67.89

Once created upload your webfiles, acknowledge TTL and test (Note - your web menu and file structure must be relative to the site as oppose to domain specific).

Stage 2 - Creat the CF distribution

With the subsite resolving the next step is to create the Cloudfront distribution to cache and deliver it, this is done through the AWS Management UI. We will be creating a 'download' distribution (as oppose to 'streaming') - Fig:1

Fig:1 - Create a download distribution

Next, provide the origin domain name plus a suitable ID and choose ports - Fig:2

 

Fig:2 - Origin domain name

Choose distribution settings and provide a WWW enabled CNAME. You can also specify the default root object here (i.e index.html or index.php etc) - Fig:3

 

Fig:3 - Distribution settings

On saving you'll be returned to the main Cloudfront management UI. Your new CF distribution will be listed and given a name, something like a12bcd34ef5ghi.cloudfront.net. It will take a short while until state enabled drops in but once you have the green light we can move on to the next stage to configure the custom cache behaviours.

Stage 3 - Custom Cache Behaviours

Cache control headers determine how frequently each edge location gets an updated version of a file from the origin and Cloudfront provides you with two options for configuring the TTL. Select Use Origin Cache Headers if your origin server is adding a Cache-Control header to control how long your objects stay in the CloudFront cache, or (easier for full site caching) select Customise to specify a minimum time that objects stay in the CloudFront cache regardless of Cache-Control headers. Custom cache config is accessed from the behaviours tab inside Distribution settings and in our example we have set a TTL of 172800 seconds (2 days) - Fig:4.

 

Fig:4 - Default cache behaviour settings

Stage 4 - DNS configuration

In DNS management create a CNAME record for WWW to point at your CF distribution. For example :

www.yourdomain.com  CNAME  a12bcd34ef5ghi.cloudfront.net

Again, acknowledge TTL and test, both the WWW and the CF URL should resolve to your site.

Stage 5 - Zone Apex to WWW (CF)

Those of you on the ball will probably be here already, but yes, the final stage is simply to apply a 301 redirect from the zone apex/domain root to WWW and this is easily done with a .htaccess file entry in the zone apex webspace. There is no requirement to host any other files in this space other than the .htaccess. Here are the entries for our example :

RewriteCond %{HTTP_HOST} ^yourdomain\.com$ [NC]
RewriteRule ^(.*)$ http://www.yourdomain.com/$1 [R=301,L]

As mentioned at the start, the .htaccess redirect is the reason you need separate origin space, without it you would just get stuck in a redirect loop.

So, once done if you access http://yourdomain.com you should be redirected to http://www.yourdomain.com, which in turn (via the CNAME entry) resolves to the CF distribution.

You can test how this speeds things up using the Cirronix domain as an example. First access the site via a browser to populate the CF edge location nearest to you - http://cirronix.com, then try pinging both the WWW and non WWW version(s) from a terminal window and note latency to both. Depending on where you are you will see differing times. 

The zone apex for cirronix.com is held in the AWS EU region and a ping to it from an AU based EC2 server returns around 350ms, pinging the WWW (the CF dist) drops in at around 2ms, which is quite rapid when you consider the origin files are (at time of writing) being served from a £50 Dell Mini 9 Netbook sourced from eBay sat in the corner of my home office.

Of course a home-hosted netbook is not the ideal for serious business hosting and I will be migrating back to a low end EC2 quite soon, however as an example of just what can be achieved using a CF 'download' distribution it's a great (and fun) example.

Summary and benefits

It's obvious that by implementing a CF distribution your content and website delivery will be substantially enhanced, with requirements for powerful virtual server resource no longer a priority (case and point the Dell Mini 9), however there are also both security and uptime benefits to consider. 

For example, in the case of the Dell Mini the 'actual' website content, files and 'server' IP are inaccessible, a ping merely returns the CF distribution IP and the zone apex space contains nothing more than a .htaccess file. The same would be true were it hosted back on EC2 and for the budget conscious you can hook up a resilient EC2 Micro for around $10 per month.

With uptime resilience catered for via cache control TTL this means that should your backend systems fail your website will still be up and being served globally, quickly and securely, even if your origin server has completely thrown the towel in. Cache control headers are fully configurable down to a minimum TTL of 0 seconds and you can use CloudFront's Invalidation feature to expire a file sooner than the preset TTL should you need to update content.

Gotchas and workarounds

One downside with CF is with regard to HTTPS (SSL) site delivery, as although HTTPS on port 443 is facilitated there is no SSL pass-through and the identifier is tagged to the CF distribution, as such visitors to SSL enabled sites will receive a certificate mismatch warning. It is expected that AWS will address this issue in the near future.

The second issue relates to HTTP request methods as CF presently only supports GET and HEAD. This causes problems if you're using a website contact form as they invariably function through POST requests and will return a 403 submit error. There are a couple of workarounds for this. The first, easiest and most lateral is just to use a simple secure email link instead (I find most people have email and are able to click a link). The second option is to modify your code so the action parameter includes the actual URL for your form origin, rather than a relative path, for example :

<form id="Form" method="POST" action="http://origin.yourdomain.com/contact">

The form mod does let you keep your contact form method intact however somewhat negates any security benefits gained from masking your origin server location and IP behind a CF distribution. Personally I have no issues with a trimmed down contact page and there are an abundance of methods available to mask listed email addreses against spambot harvesting it. And let's be honest, if a visitor to your site can't send an email or dial a phone number they're probably not looking for your services anyway.

If you would like to find out more about the Cloudfront CDN service for site or content delivery, or if you require advice and assistance to migrate or deploy across other areas of AWS please feel free to contact us directly - http://cirronix.com/contact 

Cirronix have been delivering AWS solutions since 2008 and offer both registered AWS Consulting Partner and AWS Business Professional status. We would be more than happy to hook up for a chat to discuss your requirements.

More information on AWS Cloudfront is available HERE.