Hello, I'm mitch canter.

I’m a director of engineering

Living In nashville, tn.

For a while now, I’ve been diving more and more into the realm of the “server administrator” and setting up servers for clients. I started with Ramnode, but eventually moved to Digital Ocean because of its ease-of-use for a (then) newbie like myself.

Over the past few days, however, I’ve been migrating a client away from a big-box WordPress host over to something they have more finite control over. The process was nearly seamless, but it took a bit of trial and error to get the server tuned exactly the way I wanted it.

Over the next few days, I want to share that process with you. And the best part? Everything I’m doing is eligible for Amazon’s “Free Tier” program on AWS – meaning that it won’t cost you a cent for certain features.

How does AWS Work?

Amazon’s AWS is more like a “server shop”. We’re going to be focusing most of our time in the Elastic Cloud (or EC2). There are dozens of AMIs (Amazon Machine Instances) which are snapshots of servers in various states. Some are fresh out of the box, some have programs ready to go, and others are backups of live sites.  You can create your own, but there are plenty of ready-to-go server setups to choose from.  An AMI is then dropped onto an Instance – a (usually) virtualized computer segment. These instances have various tiers of computing power – ranging from a single core with 1g of ram to monster boxes that could out perform even your home desktop computer (a side note: some of them even have virutalized graphics cards that could technically be used to stream a video game through, but that’s a different post altogether!)

Once everything is set up and running you can jump into the instance the same way you’d get into your own server – at first via SSH, but then later through FTP if you choose to install an FTP server.

We’re going to be using one of the free tier eligible Linux servers and a free-tier plan with one processing core and one gig of ram. This should be more than fine to start out with. Plus, if you really like it, you can upgrade the server later with minimal downtime and start paying for it!

Step 0: Create the Account

Head on over to Amazon’s AWS and sign up for an account.

Once you log in, you’re treated to an overwhelming amount of options:

The first column has EC2 at the very top left. The second column has Identity & Access Management in the 3rd group. Those are the only two links we need to worry about for now.

Step 1: Creating your Identity

Before we set up the server, we need to ensure you’re able to do fun things on it, like log in.  So, we’re going to set up a user, a group, give that group administrator privileges, and then add you to it. This’ll let you use the Amazon Command Line Interface to generate access keys for your server.

Click on the Identity & Access Management link. You shouldn’t have anything there with a new account, so click on Users and then Create New Users.

Enter your name and then hit Create. Make sure you download the credentials it gives you.

I’ll say it again: MAKE SURE YOU DOWNLOAD THE CREDENTIALS IT GIVES YOU. Without those, you won’t be able to (eventually) log into the server.

Back at the IAM Management Home, click on Groups. You shouldn’t have any, so let’s create one. Name it something authoritative like “administrators” or “BigBosses”.

On the next screen, you’ll attach a policy – a set of rules for that group. We want them to have AdministratorAccess, which is the first policy you’ll see. Check the box and go to the next step.

Review on the next page and submit. Back to the Users page you go. Check the box next to your username and hit “User Actions” > “Add to Groups” and add that user to the group you’ve created.  Congratulations, you’ve made yourself an administrator in the Amazon Console. Now it’s time to set up the security stuff for the server (some of it, anyway).

Step 2: Authentication and Connection to the Server

Passwords are so 2012. We use keys to connect to this server, and that work you just did will allow you to generate the keys you need.

The AWS CLI allows you to control Amazon from your home terminal. We’re going to use a few basic functions of it, but if you hate GUIs then it’s worth learning to use to make your life better. And remember the one rule of thumb: if you can do it from the command line, you can automate it, and who doesn’t want to automate this eventually right?

Install the AWS CLI from Github and run

$ aws configure

from the terminal (as usual, don’t put in the $ – that’s just the prompt). Remember those credentials you were saving? Grab them and enter them when prompted.  For your home AWS Region, use this table to determine:

So now we can generate the key pair needed to access the server.  If you don’t have an .ssh directory on your machine, create one:

$ mkdir ./ssh

And then create your key pair (you can name it whatever you like – just make suer the bold parts below match):

$ aws ec2 create-key-pair --query 'KeyMaterial' --key-name key-name --output text > ~/.ssh/key-name.pem

Amazon will do its awesome technomagic and will spit out a file with your authentication key. Finally, restrict access to all but you:

$ chmod 400 ~/.ssh/key-name.pem

Remember what you called that file, by the way – you’ll need it in just a few minutes.

Step 3: Set up the Instance

Now for the fun part! Log back into the AWS console and visit the EC2 Page. Visit the “Instances” page – it should be empty – and click “Launch Instance”.

Step 1 has us choosing an AMI to use. I’m a huge fan of Ubuntu as a server, so let’s choose that.

Check the “Free Tier Only” box, and look for Ubuntu Server 14.04 LTS (HVM), SSD Volume Type. The AMI ID is ami-d05e75b8. Select it.

Step 2 has us putting that AMI onto an Instance. The “t2.micro” tier is free, but if you want some more horsepower and are willing to pay for it, by all means choose a different tier.

Important note: Amazon bills differently than other hosts. The formula is (simplified): Computing + Storage + Data Transfer. This means you pay for the instance (and sometimes the AMI) per hour, the storage per month, and the data transfer per gigabyte in AND out.

As a baseline, an “always on” t2.micro with 1 processor, 1GB RAM, 30GB of storage, and 75GB Bandwidth out would run ~$9.50 / month.

Don’t skip anything: go to the next section and accept the defaults. In the “storage” section, add on a 30GB “General Purpose SSD” – that’s the max the free trial will allow you. I would have it persist on termination, just in case you ever upgrade the server.

Move past the next section to the “Configure Security Group” section. Here’s where we’ll control the flow of traffic in and out of the instance. Create a new security group and name it something useful like “WordPressSecurity”.

To start with, we want to add SSH, HTTP, and HTTPS traffic rules. The HTTP/S rules can be open (from anywhere: 0.0.0.0/0). The SSH rule… well, if you’re going to be accessing the server from only one computer, then use that computer’s IP – it’ll absolutely be much more secure that way. For me, I travel a bit and need the flexibility to log in from other places. The key already provides an enormous amount of security compared to a password, so it’s OK in this case to open it. If you’d want, however, you can assign multiple IPs to open up – one per line.

Now is the moment of truth. Review the instance and hit the launch button! You’ll be prompted to choose a key pair once you launch – make sure you choose the one you generated back in the beginning – that’ll associate that file on your computer with being able to access the instance.

You’ll be taken back to the AWS Instances page. Once the light turns green, the instance will be up and running!

Logging in is simple. Simply type in:

$ ssh ubuntu@PUBLIC_HOSTNAME -i ~/.ssh/key-name.pem 

This will log you into the instance, and you can start updating packages, installing your server (Nginx, I hope!), and getting things ready to go.

What to Expect in Part 2

Part two will have us updating packages, setting up the server, WordPress, MySQL, and a few other goodies. For now, though, we have a server that is running and ready for all of the goodness we want to use it for.

This server is more than capable of running a WordPress site with little to no trouble – it’ll be faster than most shared hosting, and you don’t have to worry about what other sites are being hosted on it – meaning SEO / SERPS won’t go down due to having “bad neighbors”.

Let me know if you have questions and I’ll try to answer them the best I can, but in the mean time:

• Let me know if you try the setup, and if there were any sticky points.
• Any tips/tricks you can send over to help the process be streamlined
• If you got the server up and going, and can’t wait for Part 2 when we actually can run a website on it!