Relocating to the Cloud

When it comes to migrating a website to AWS [1], there is usually a reason: in our case, an overly sluggish Drupal installation, hosted in a data center. Before making such a move, however, you need to ensure that the site scales automatically, is highly available, and is easy to manage. In AWS, you can point and click to compile such an environment with very little effort – as long as you are not afraid of vendor lock-in.

Figure 1 shows the typical status quo: A website runs on a server at a data center, uses a database, and is usually accessible via an Internet gateway with a static IP address. Either the provider operates the site themselves, or they use a hosted service. As a result, this traditional setup exposes a website to multiple single points of failure.

Figure 1: Traditional website setups typically contain multiple single points of failure.

Regardless of who operates the site, if one of the components has a problem, the website is no longer accessible. In addition, changes to such an environment are time-consuming; keeping the site in sync with the development stack causes extra work. Also, this scenario does not scale automatically: If the server load drops or rises, you have to manually make changes to the hardware.

Finally, unexpected (sometimes even expected) traffic spikes can lead to server overload and downtime. By choosing a suitable architecture in Amazon's cloud, most of these scenarios can be avoided (but not in every instance).

Lift & Shift

There are least two ways to migrate your Drupal setup from your server to the cloud. The first is known as lift and shift migration. AWS acts as an ordinary hosting service provider here; you just need to move the web server along with its dependencies into a single instance of Amazon's Elastic Compute Cloud (EC2) and connect to the Relational Database Service (RDS) to store the data there. The website can then be accessed via the Internet. However, there is little to be gained with this approach: The site is still neither highly available nor does it scale automatically.

Distributed AWS

A second approach, which I focus on in this article, not only migrates the application and its dependencies into the cloud, but it also deploys load balancers and implements a strategy for AWS regions and availability zones (AZs).

AWS regions consist of multiple AZs, which you can imagine as independent data centers. They communicate with each other as if they were on the same network. If a server or even an entire AZ fails, the load balancer redirects the traffic to another AZ, where a copy of the Drupal installation is already waiting to take over the job. In this scenario, you install servers in multiple AZs and tell the load balancer their IP addresses.

Managed Administration

The architecture in Figure 2 may look a bit complicated, but it is relatively easy to create. The Elastic Beanstalk service helps to implement it. Alternatively, you can describe the components as an AWS CloudFormation [2] (I do not cover this practical approach to larger setups in this article). Table 1 shows which other services are involved in the scenario.

Figure 2: The architecture for a highly available and scalable site in AWS looks complicated, but it is quite easy to set up.