The camps are well and truly established. In the red corner we have yes-www and in the blue corner we have no-www. But who should we back? Having recently spent some time reorganizing my IT estate, I can certainly say that from what I experienced, there is definitely a clear winner…

Shared Hosting to Big-Boy-Pants

Having only recently put on a pair of big-boy-pants and started to seriously use AWS for all my deployments, I had previously served most of my non application sites through a shared hosting package.

Whilst some of you may scoff at this, I still believe it has some benefits for very simple projects: namely that backups, server failures, email configuration etc are all managed for you. Any issues, just contact the support desk and they will be more than happy to assist. For just a simple client project to get them up and running with a site and email, I still feel its the best choice.

Recently though, I’ve started to look at utilizing AWS more for my own sites. The simple and clean approach offered by AWS to enable super speedy static sites to be set up in moments with S3 and Cloudfront is just too temping to miss. Coupled with low cost and ease of deployment, its an all round winner.

But the stumbling block comes when you start looking at your namespace server.

Its all in a CNAME

I recently set out to move this site from my shared hosting plan to AWS as a static site served through S3 and Cloudfront. Its a fairly trivial process until you come to domain mapping between your sites URL and the Cloudfront end point.

Sometime ago I setup my domain name with my shared hosts nameservers. This then gives my shared host control over the routing of my domain name.

This simple but effective system allows you to map any of your subdomains to a completely separate URL. This is way more powerful than a simple 301 redirect. This is a very permanent address mapping change. The change actually gets propagated across all the worlds nameservers so they know which server to contact when they receive a request for your URL. You can often find very odd quirks that mean your laptop browser and your mobile internet browser may get your page from two different end points because the mapping has not yet reach one of the ISPs servers.

As an example, for sometime I have had a CDN hosted through S3 and Cloudfront. The Cloudfront end point is something along the lines of d111111abcdef8.Cloudfront.net.

Through my shared host, I was then able to setup a subdomain cdn.mydomain.com and map it to the Cloudfront end point through a DNS CNAME change. Now every request to cdn.mydomain.com would be mapped to the Cloudfront subdomain. Nice huh!?

What’s all this got to do with www and non-www URLs I here your cry?

Its All About Scalability

When you prefix www. to your domain you are actually creating a subdomain. The following are all examples of a subdomain:

  • cdn.mydomain.com
  • app.mydomain.com
  • blog.mydomain.com
  • www.mydomain.com

As shown above, its possible to map any subdomain to another URL, thus allowing your nameserver to reside with one provider, and the hosting of your site with another.

The problem now comes if we want to CNAME mydomain.com - its just not possible. Your main domain has to use something known in DNS language as an A record. This cannot be mapped to a URL and instead has to be mapped to a static IP address.

Using services like Cloudfront, it is impossible to point your domain to a Cloudfront static IP. The whole point of Cloudfront is that edge servers all over the world hold a copy of your content which can be served quickly to clients. The URL that Cloudfront provides you is masking the fact that the content coming through it is coming from many different places.

Now, I haven’t read into this in depth, but I’d imagine that the only way to serve content from AWS via mydomain.com would be to spin up an EC2 instance and assign it a static IP. I can then update the A record for mydomain.com and it would be mapped to my EC2. But no scaling, no Cloudfront - very restricted.

Use www. To Help You Scale

My conclusion to all this is that I’m all for prefixing my main site with www.. I’m sure there are workarounds, but its the only easy way I know that will give me ultimate flexibility with how I serve my content.

It now also provides even greater benefit in that I now have a camp to align myself with - yes-www! Im completely ditching my main domain for hosting content. Its now simply a puppet master in the background, spawning flexible subdomains at my command. No more messing around with changing redirects and SEO optimization when I suddenly decide to change camp. All redirects will now be a 301 from mydomain.com to www.mydomain.com. All SEO canonicalization will be pointed towards www.mydomain.com. I for one am now happy to be able to put all this uncertainty behind me and implement all my projects in the same way.