Hosting a Static Website on Amazon and Azure: Part 1-Site Preparations


Until recently, our company website, mallardcomputer.com, was hosted with a major hosting provider’s shared hosting plan. Pricing wasn’t too bad, and our website performance was running fine, but we wondered if we could simply get a better deal with our web hosting elsewhere, especially due to the fact that we have a relatively small website without too many hits a month, and also since we consult with a few nonprofit clients who also have extremely tiny websites with few hits a month, we wanted to see if we could save them some money as well.

Another company I work for informed me of their decision to move all of their infrastructure to Amazon Web Services, and their CTO informed me that since my company website was a simple website, I could pull it off hosting it in Amazon’s Simple Storage Service, Amazon S3, dirt cheap. After much research, I found out that indeed, it would be quite easy to pull off hosting my company website itself in Amazon S3, and the pricing isn’t too bad either. Amazon S3 customers get a “free tier” for the first year as long as they don’t go over that tier, and after that, pricing would be about 14-15 cents per GB each month, possibly a few pennies more if the website got a high amount of hits that month. In addition, performance and reliability should be better running in a major datacenter service like Amazon S3 than it would be with a traditional hosting provider due to the fact that Amazon S3 has a much larger infrastructure to handle all the “big guys” for their storage needs, so serving my company’s little site up on their massive datacenters should be a piece of cake.

We also learned of another one of the major cloud services players in the market, Windows Azure from Microsoft, and decided to do a little research on how easy it would be to host a website in Windows Azure as well (using their Blob Storage feature). Their pricing is similar to Amazon’s, again they offer high performance and reliability, and we wanted to gain some experience on their interface as well, so we signed up with a three month free trial with them as well. In the end, we chose Amazon S3 over the two to host our website due to the fact that we like the way Amazon handles URL’s a little better than Azure, plus Amazon S3 is easier to work with on our Macs than Azure was, but both services offered good performance, great prices, and pleasant to work with interfaces.

Over the next few blog posts, I’m going to show how to host an entire static website out of using either Amazon S3 or Windows Azure Blob Storage. It was an interesting experiment to say the least, and I hope it ushers in a new and simple way for small churches and nonprofits with simple websites to be able to host their websites extremely affordably.

Now there is one catch to everything I’ve said so far. Notice I’ve said static websites. When I mean static websites, what I mean is one has to be careful how the website is constructed in order to pull off hosting out of Amazon S3 or Azure Blob Storage. Amazon S3 and Azure Blob Storage is just that, storage accounts. So while a website can have plenty of pictures, video elements, documents, and HTML it wants, it can’t have any form of “web applications” or scripting (such as PHP scripts) running on the server. They simply will not function at all and just sit there dormant on Amazon S3 or Azure Blob Storage. “Web applications” are meant for Amazon’s EC2 and Azure’s Compute functions, which tend to get quite costly, about 12 cents an hour, which equals to more around $70-100/month, which costs significantly more than a traditional shared hosting package. However, static websites can have as much HTML, HTML5, JavaScript (JavaScript is considered “static”), and CSS one wants, so provided one can PHP-free their website (or are not running any “web applications”), one can easily host their static website in Amazon S3 or Azure Blob Storage.

So “Step 1” was examining our company website and seeing if we used any PHP scripts on our website, and if there was anything we could do to PHP-free our website. After giving it a thorough look, it seems we were using PHP scripts in three areas.

The first area we were using PHP in was our mobile site redirection. We use RapidWeaver, a nice Mac app from RealMac Software, to build our website. We use it because it makes it much easier to build our website without having to code everything from the ground up. Much of it can be done through WYSIWYG, and we only have to dive into the code when we need to make certain changes (such as we’ve tweaked the CSS we’re using in our theme to give off our custom colors, and there’s times when we use web widgets, etc.). RapidWeaver also allows for the extension of plugins to make the software more powerful, and we were using the plugin Mobilize from NimbleHost (By the way, great plugin, great company) to pull off our mobile site redirection, and it sure made setting up mobile site redirection extremely easy. However, Mobilize solely relies on PHP code to pull off mobile site redirection, which obviously wasn’t going to function when we ported our website over to cloud storage. So we had to find another way to pull off our mobile site redirection.

It turns out that there’s a simple line of JavaScript code (since JavaScript is fully functional in storage accounts) that can be placed at the top of a website’s HTML document that would allow one to easily add mobile site redirection to their website in a matter of seconds. I’ve attached the text file containing this JavaScript code to the bottom of this blog entry (just in case anyone needs it), and all one has to do is replace “mobile.mywebsite.com” with the location of their mobile site, insert this JavaScript code as far up in the top of the website’s HTML document as possible, and instant mobile site redirection. Ours is set to go to our mobile site we built using UBIK.com, a great free service that makes it extremely easy to build mobile sites.

The second area we were using PHP was in our contact forms. We were using RapidWeaver’s default templates for contact forms, which looked and functioned great, but as in all server-side contact forms, they relied solely on PHP. The solution to this problem was actually quite simple. There’s some great hosted form solutions out there such as JotForm, and even Google Docs makes it extremely easy to create a contact form, complete with spreadsheet responses and emailing, and when done, all one has to do is iFrame the link to the form right in to their website. No server-side processing needed. In our case, since we only needed rudimentary basic contact forms, our company’s SharePoint Online package from Office 365 (that’s the subject for another blog entry) has the ability to create public-facing SharePoint pages, and one of the templates included is a basic contact form, so we created our contact forms on our Office 365 SharePoint Online public pages and iFramed them into our website.

The third area (and last area) we were using PHP was with our blog. We were running a hosted WordPress Blog to house our press release feed, making it easier for people to follow our press releases through RSS. Any web developer will tell you that WordPress is heavily PHP as well. In this case, it was another simple solution. Since we weren’t using many plugins on our hosted WordPress Blog, we decided to switch our hosted WordPress Blog over to WordPress.com and allow WordPress.com to handle our blog hosting for us. We also found a template over there we were happy with, and basic blog hosting with them is free, so we were happy about that. WordPress.com does include a few premium features for the extra cost, so for $12 per year, we opted in the custom domain option to have a custom subdomain mapped to our blog. What we no longer have to worry about with our WordPress Blog is all the security patches and updates we used to have to rollout on a regular basis. All we have to do now is simply blog.

With those few optimizations in place, we were ready to try our hand at hosting our site with the major cloud storage providers, and coming up in my next blog entry, I’ll discuss how to take a fully static website and host it entirely out of an Amazon S3 bucket so that it appears to the public, looks the way it should, and maps perfectly with a custom domain. After that in another blog entry I’ll go through the instructions on how to basically do the same thing, just using Azure Blob Storage, so readers will get a chance to see both environments at work and a general comparison of the two. Stay tuned for more!