Preparing Amazon Web Services (AWS) for an Auto-Scaling WordPress Site

Preparing Amazon Web Services (AWS) for an Auto-Scaling WordPress Site

In my last article I covered the basics of Amazon Web Services (AWS). Now it’s time for some hands-on configuration. The example I’ll be working with in the next few posts is a WordPress based site. I’ll leverage a bunch of services within AWS to support my site – Route 53 for DNS, RDS (MySQL as a Service), Elastic Load Balancers in front of auto-scaling EC2 instances (monitored by CloudWatch), ElastiCache, Simple Storage Services (S3), and CloudFront. As you can see, this setup will be very different from the shared hosting or VPS server you might be on today. Taking advantage of these different AWS services lets me scale much easier (and automatically) than just installing everything on a single server.

Before we can begin building out the infrastructure and services, we need to configure permissions in AWS:

1. If not existing, create an AWS account (https://aws.amazon.com/)
2. Log into your AWS Console (https://console.aws.amazon.com/) and go to Identity and Access Management (IAM).  Create a new user so you can authenticate to the AWS services (in a production workload I would probably create several users and assign different role-based permissions, but a single user account will work for my demo).  Save the user credentials!
3. In IAM, create a new group.  Use the Policy Generator Wizard to create a policy that allows access to the services we are using.  Assign your user to the new group.

Next we’ll configure some of the AWS services that we’ll use for WordPress:

Configure Elastic Load Balancers

In the AWS Console, go to Elastic Compute Cloud (EC2).  Under Network & Security, click Load Balancers.  Create a new Load Balancer.  Name it (I’ll use WordPressELB for this demo), and configure listeners.  The only listening port I need is 80 (HTTP) – you may need others.

Configure your health check options.  I used HTTP as the ping protocol, against port 80.  My path is /index.php.  I have a response timeout of 5 seconds (this is the amount of time the ELB will wait for a ping response before it suspects an EC2 instance behind it as being unhealthy.  Choose your health check interval.  30 second ping intervals seem about right for me, so I’ll keep the default 0.5 minutes.  The Unhealthy Threshold is set to 2 by default – this means that after two failed ping health checks the instance will be marked as unhealthy and the web server will be disabled in the ELB configuration.  I dropped the Healthy Threshold down to 2 for this demo so to speed things up, but you may want to set it a bit higher to make sure an instance is really healthy before being added back into the ELB rotation.

I’m not going to add any EC2 instances to my ELB yet, so just click through the wizard to complete the creation of your new load balancer.  Before we move on to the next AWS service, we need to do a couple more things.  Select your new ELB, switch to the Instances tab and add the ELB to all the availability zones in the region your application is deployed to (us-east for me).  This will ensure that your load balancer keeps servicing requests even if an AWS Availability Zone has problems.

Finally, on the Description tab, copy the DNS name for the ELB.

Configure Route 53 to Host DNS

In the AWS Console, go to Route 53.  Create a Hosted Zone for your domain (assuming you want to host DNS on Route 53).  I’ll be using myawsdemo.com for my example.  Note the Delegation Set servers and configured your domain Name Servers to these values.  Add any records (A or CNAME) to your Hosted Zone Record Set needed to support your site.  I have created two records: 1.) a CNAME for wordpress.myawsdemo.com, pointing to the Elastic Load Balancer DNS name copied in the previous step, and 2.) a CNAME for static.wordpress.myawsdemo.com to be used by our CloudFront distribution later in the process (you can give this a temporary value and set the TTL low).

Configure EC2 Security Group

In the AWS console, go to EC2.  Create a new Security Group.  I’ve named mine “Wordpress”.  The rules I’m going to use are:

From Source 0.0.0.0/0 (i.e. anybody on the Internet)

• TCP 22 (SSH)
• TCP 80 (HTTP)
• TCP 443 (HTTPS)

Next I’ll create two rules – one for ALL UDP, one for ALL TCP, and apply it only to the WordPress Security Group.  This will be used for intra-EC2 instance communication (more on that in a bit).  In a production environment, you would obviously create more strict rules, use multiple security groups, create an AWS VPC, or a combination of all of these.

Configure MySQL RDS Instance

Now we’re ready to get started with deploying WordPress components to AWS.  WordPress at a minimum requires a MySQL database and a web server (I’ll use Apache) with PHP support.  Let’s get those running on AWS.  First, the database.  We’ll use AWS Relational Database Service (RDS) to run our MySQL instance ‘in the cloud’ (Database as a Service).  In the AWS Console choose the RDS service.

First, create a RDS Security Group.  Once created, edit the group and add in your EC2 security group to allow EC2 web server instances to access your database.

Next, choose Instances in the sidebar menu and launch a new MySQL DB.  A micro instance ought to be enough to get you started.  I am enabling Multi-AZ deployment so if there is a problem in one AWS Availability Zone, the load balancer instances and EC2 instances in surviving AZ’s keep on keepin on.  I’m allocating 10GB of space for my database.  My DB Instance Identifier is ‘Wordpress’, with a unique username and password.  Put the database into your database security group and choose your backup/maintenance windows.  Once created, view the details of your RDS instance and note the Endpoint address.

With the RDS MySQL instance created, we’ve got the bulk of the underlying infrastructure in place for a basic WordPress install.  In the next post, I’ll walk through the WordPress installation and configuration to take advantage of AWS ElastiCache, S3, and CloudFront.

Series Links:
Part 1: Introduction to Amazon Web Services (AWS)
Part 2: Preparing Amazon Web Services (AWS) for an Auto-Scaling WordPress Site
Part 3: Installing WordPress on AWS
Part 4: Configuring AWS Auto Scaling for WordPress