This weekend, on a lark, I decided to do some experimentation with Amazon’s AWS services. I have been using their S3 for backing up my home Mac for a while, but since I use Arq it was really not a serious dive into the AWS infrastructure. However, when I started down that path, I had to do some interesting things, like create an IAM user profile, and the like.
Then I saw some tutorials that looked interesting, including one on how to setup a WordPress instance on an EC2 virtual machine. Since I have setup many WordPress sites, on a variety of hosting solutions, I thought why not give it a throw?
Fortunately, for the first year you are a customer, you have access to a “Free Tier” that pretty much allows you to run 1 VM solutions up to 750 hours each month. More than enough to play without paying.
The TL;DR answer: Is isn’t difficult, but there are some extra steps that AWS brings into it than using a major hosting site, even one where you start with a plain VM (like Digital Ocean). It gets you closer to the iron, and you can’t help but to gain an appreciation for the background processes that are in play.
Getting EC2 setup
This was a little more involved than what I had to go through for the S3 storage for my backup. Fortunately, there is a sub-tutorial to walk you through the process here, as it is not intuitive. You need an IAM user, like with S3. I created a new one for this tutorial, so I wouldn’t risk fouling up my storage.
Then you need to create a key pair. Couple of key points (nice pun, eh?) is that it has to be in the region you are located or are planning on running your VM’s in. You can’t use the same key pair for say US-West-1 and US-East-1. Keep that in mind if you are doing something with geography spanning servers.
Additionally, the key pair is crucial, as it is the ONLY way to log into your VM when you start it up. There is no fallback to password if you lose your key. The Amazon build of linux has no ability to login from a simple SSH connection without the key authentication. This is very important to remember (and don’t forget to protect your key file, lose it, and you are screwed).
Then you need to create a Virtual Private Cloud (VPC). I am sure this is wildly complicated in the background, but it was pretty simple to setup. I will admit that apart from following the script, there wasn’t much drama here.
Then you need to create a security group. Again, this is one of those “I’m sure it is complicated, but for this project it is simple” things.
Creating a VM instance
Now it is time to create the instance. Here it is pretty straightforward, but there are an awful lot of choices. The tutorial points you at a simple AMI (Amazon Machine Instance), which is a pretty plain Linux installation, 1CPU, .5GB ram, 20GB disk space. You select the key to use, the VPC you created, and the security group and you push the button to fire it up.
About 2 minutes later, you have yourself a running VM, with an Amazon DNS name, an auto-assigned IP address (but one that will change whenever you power off / on the VM), and you can begin the work.
It is a very basic install. No web services, no PHP, no MYSQL, nuthin’. But it runs.
I should mention that connecting to it isn’t as trivial as you would think. If you are used to just SSH’ing in, using the stored RSA keys, you will run into a speedbump.
First, you must enumerate the keyfile (xxxx.pem) on the command line for SSH with the -i switch. You also must put the full path to the file. You can’t assume it is in your path. (in my case, I dropped it in my user directory, changed the permissions to 400, and used the ~/tutorial_1.pem)
Second, you can use the temporarily assigned public IP address from the EC2 dashboard, or the FQDN which is some long thing with your account number in it. I bet you can guess what I did…
Fortunately, there is a mini-tutorial on accessing the machine, as it is enough different than say Digital Ocean, that it is good to have this help.
The details: it was a t2.micro instance with EBS storage, it is the “Free tier” which is good for tutorial usage.
Installing a LAMP stack
Here is where my experience in prior hosting falls short. I have virtually always started with a VM that had a LAMP stack (LAMP stands for Linux – Apache – MySQL – PHP) installed and configured. However, with the EC2 machines, that isn’t installed. Fortunately, my belief that this was mysterious, and difficult was erroneous.
Turns out that it is pretty trivial to get a complete, functioning, and configured LAMP stack running. Again, there is a tutorial for this here. I will point out that it isn’t difficult, but to really understand what you are doing (and I am in the category of being knowledgeable enough to be dangerous) requires you to dig a little deeper.
I will point out that if you are using an Ubuntu machine, this tutorial won’t work verbatim, but it is mainly due to the different package manager.
Last point: and this is a good thing, as it guides you to run the ‘mysql_secure_installation’ script that plugs the main holes in the default MySQL installation. Cool, I always wondered how to run that, and what were the right options…
Now, you are ready to install WordPress.
This is where I was again on familiar territory. Since I didn’t have MyPHPAdmin installed (in general a bad idea unless you have SSL/TLS configured, as it sends a lot of commands in the clear), I got to muck around in MySQL. Not difficult, but you have to type the commands EXACTLY, or they will fail. Yep, I did a few gaffes.
Then you download the latest WordPress package, edit the wp-config.php with the database information and you’re ready to go.
It took me about an hour, maybe an hour and a half to get it running, to where I could log into the admin interface. Compared to a typical webhost, where there is either a 1-button install and it takes 3 minutes, or where you have to copy the WordPress files, and create a database (7-ish minutes), it was more complicated, but I will admit that I learned a lot.
Additionally, I grabbed an Elastic IP (that is one that remains constant when the VM restarts), and I investigated how to map one of my parked domains to it (again, it is trivial using their DNS service Area 53).
This was barely a toe dipped into the AWS pond. I did get an appreciation of what is done for me when I spin up a new droplet at Digital Ocean, or create a hosted WordPress for a friend on a standard shared hosting provider (like Hostgator, or Dreamhost).
I did learn that the AWS ecosystem is quite complex, yet, I now have an appreciation for how many services can prototype, build, and scale a service. I now believe that a bold statement I read, that sometime in the future, no rational company will build a datacenter, they will just leverage the scale and scope of an Amazon or Google (or whomever grows to challenge these behemoths).
I do have a newfound appreciation for Serverpilot that automates the setup and running of most of my WordPress instances…