Hosting your website in the Amazon Cloud
post-template-default,single,single-post,postid-917,single-format-standard,theme-bridge,bridge-core-3.0.1,woocommerce-no-js,qode-page-transition-enabled,ajax_fade,page_not_loaded,,qode_grid_1300,qode-content-sidebar-responsive,columns-4,qode-theme-ver-28.8,qode-theme-bridge,disabled_footer_top,disabled_footer_bottom,wpb-js-composer js-comp-ver-6.9.0,vc_responsive

Hosting your website in the Amazon Cloud

Hosting your website in the Amazon Cloud

This blog is now on the Amazon cloud!

After about a week of faffing about, I’ve finally got everything up and running on the Amazon Cloud (EC2) service.

I’ve now got 3 blogs running on a WordPress multi-site setup, plus another website served as a virtual host, all on a Amazon micro-instance.

I used a pre-cooked Linux image from Bitnami that already had Apache2, MySQL, PHP and WordPress installed, and launched it in the European region.

The Bitnami image worked right out of the gate, but since I wanted to use the multi-site functionality of WordPress, there were a ton of tweaks to make.

WordPress multi-site is a built-in feature that allows you to run as many WordPress sites as you wish, with just one physical install of WordPress. Plug-ins and themes need only be installed once, and can then be enabled across your entire network of sites. Most plug-ins can then be configured separately for each site.

Multi-site works fine on it’s own, but in order to really unleash it’s potential, it’s necessary to install a Plugin called WordPress MU Domain Mapping which allows WordPress to determine which of your sites to serve based on the web address used to access your site. For example, even though my WordPress installation is on if you visit, you will be redirected to and WordPress will then redirect you to the clandaly directory. All this without touching the Apache2 configuration to enable virtual hosting (More on this later).

The problem I encountered was the location of the WordPress files. They weren’t in the htdocs directory, where Apache2 stores web files. Apache2 can serve files from any directory with some tweaking, but the main issue was that the WordPress files can’t be within a directory like they normally are, they need to be in the Apache2 root folder, wherever that might be.

I only discovered this after setting up the multi-site, creatng all three blogs, and importing all the data from the existing versions. Ouch, such is the joy of computers.

This wasn’t a limitation of the Multisite setup, rather of the WordPress MU Plugin. I duly moved all the WordPress files, and tried the site. It worked fine until I tried to install a plugin. I got a request for FTP login details, as WordPress was complaining that it couldn’t write the needed file update itself.

Thus began my reintroduction in to the world of UNIX file permissions and process owners. I haven’t had anything to do with the UNIX command line for almost 18 years, since college, and I wasn’t much of a fan back then. I’m more of a GUI kind of guy. I’ve now seen enough of chown, chmod and sudo to last a life-time.

Anyway, to cut a long story short, the process owner of the WordPress files had become root, because I used “sudo” to move them, so I changed those to the same process as Apache2. I also wrestled with permissions, but that was mostly a waste of time as it was the process owner issue that was causing the problem. Once I had corrected the process settings, I was able to install plug-ins as normal, and I completed the multi-site setup again

This time everything worked, hooray! There was some more fun and games setting up the Apache Virtual hosts, but once I found some examples online it turned out to be very straightforward. There aren’t any special requirements with regards to WordPress multi-site, as long as your blog requests (for whatever blog) go to the main domain name.

For those sites that were being virtually hosted, I emptied the A records, and set a CNAME record to point at my main domain, This acts as an alias, so effectively when someone enters the virtually hosted web address in their browser, the DNS lookup will determine that it should be redirected to Once there, Apache uses the header information sent by the web browser to determine what site they are looking for.

That’s where the Virtual host configuration within Apache comes in to play, as it is here that we setup the connection between the website the user wants to browse and the actual directory on my server that holds the relevant files.

The one last hurdle I had to make it over was getting the web address of each blog on the mult-site to resolve to the public web name. For example, In my multi-site setup I have a site called, which is actually resides at The redirection was working fine, in that if a visitor typed in their browsers, they would see the Clan Daly blog, but the address in their browser would change to show the actual location. That looks tacky and unprofessional, and might also lead people to believe some sort of phishing was taking place.

I tried changing the siteurl in the Domain Mapping plugin, and also in the wp_options table for that blog (multisite creates a seperate set of tables for each blog, with the site id in the table name) but that just broke the redirection. I couldn’t find anything online to help, partly because it was hard to describe the problem accurately enough to limit own the results.

Finally, in a fit of madness, I tried creating a virtual host entry in the Apache2 config file for, and it worked! The address now displays as expected, and the blog permalinks still work. I’ve listed the steps I took below in case it can help someone else, using Clan Daly (the sub blog) and (the main site on which the blogs are located) as the example.

1. Set a single CNAME record for pointing to

2. Create a Clan Daly blog in WordPress Multi-site

3. Create a site in the Domain Mapping plugin, using the Site ID from the Multi-site settings for the Clan Daly blog

4. Edit the wp_x_options table and change the siteurl and home records to (they will previously have read where x is the Site ID

5. Lastly, create a virtual host record in the Apache2 httpd.conf file. This needs a Servername of which in turn points to the Apache2 root directory. We don’t need to explicitly direct this host to the clandaly directory, firstly because it doesn’t physically exist, and secondly because the the domain mappng plug-in will deal with displaying the correct blog to the viewer.

Overall, getting on the cloud turned out to be much simpler than I anticipated, and my sites are now much more responsive than they were on my old host.

If you’re in the throes of setting up your own cloud empire, feel free to share your experiences in the comments section.

No Comments

Post A Comment