Amazon provides a variety of hosting capabilities under the name “Amazon Web Services” (AWS).
These are often described as ‘cloud’ servers. Products offered are:
- EC2 – Elastic Compute Cloud – Application servers
- S3 – Storage – also known as EBS (elastic block store) – Disc blocks that can either be served directly, or attached to an EC2 server.
- CloudWatch – monitoring for EC2 servers (CPU, network, disc IO)
- CloudFront – a CDN (notice how confusing the name is)
- Elastic Load Balancing – yeah yeah yeah
- Elastic MapReduce – for proper techies
All of these services are charged per use, so by hour, by gigabyte (memory), by gigabyte (bandwidth), by gigabyte (disc), etc.
It is well worth keeping an eye on costs, as it’s easy to run up a big bill without realizing.
One of the great features is that there are no setup fees, so it’s very easy to create and destroy servers without running up large bills.
If something isn’t working, simply start again.
Application servers can be created using one command or a few clicks. A server is called an “instance”, and is created from an image called an “AMI”.
Amazon provide a set of AMIs to build from. So does ‘alestic.com‘, who provide good ubuntu images.
They can be created in a variety of sizes, varying in memory, CPU and disc space.
These servers can also be quickly “terminated”. This means that they’re deleted from the ether and can never be retrieved.
A server is charged from creation to termination.
Since application servers can be so easily created and destroyed, one needs a location where data is stored persistently.
EBS blocks can be created and mounted onto EC2 instances. An EBS store can only attach to one EC2 at a time, but an EC2 instance can have many EBS stores.
If running a persistent (long-running) application server, you should mount an EBS store and link it symbolically to the EC2 instance. You then put all your files directly into EBS. Should you need to upgrade your application server, you simply attach the EBS to a new instance and destroy the old one.
Larger servers are already based on EBS stores.
I’m not going to go into EBS stores in this post. I’ll focus on EC2.
If you haven’t used Amazon AWS before, I strongly recommend following this guide with your own Amazon account.
It will cost around a dollar.
Working with EC2 – Setup
Getting started with Amazon Web Services is the trickiest bit, and can often be off-putting.
Once you’re set up then it’s much easier. So hang in there.
- Get an Amazon account
- Get your keys
- Create an instance
- Get connected
- Get serving
Get an Amazon Account
Head here and hit the signup button.
You can use your existing Amazon account.
You are agreeing to be billed monthly for any costs you incur, so you won’t get any more warnings!
Get your keys
You should be directed to security where you’ll be asked to download an
X.509 key. Do that, and put it somewhere (very) safe.
This is needed when you use command-line-tools (later steps).
On that same screen, you can create a “Key Pair”. Do that, and download the two files it gives you. This should be a
PEM file and a
Again, keep them safe. The
PEM file is the one we’ll use.
Rather than using passwords for SSH (SO last century), Amazon require you to use these files to authenticate yourself when connecting.
I’m on a Mac, so I copy the
PEM file to a ”
.ssh” folder in my user folder.
You need to
chmod 400 the file to prevent a connection error.
Let’s say I created a keypair called ”
kennethkey”, I can now do this.
cd ~/.ssh chmod 400 kennethkey.pem ssh-add kennethkey.pem
This will add the key for the duration of my Terminal session.
Create an instance
Now you’re set up, head back to the browser and find your way to the AWS Management Console.
This is where you can do most of your work with Amazon.
This console is new, so many documents you find online don’t describe working with it.
Don’t worry about that.
What can we see?
Tabs on the top – we only need “Amazon EC2”
Top nav – to Products for details of pricing (can be useful), and to Account for details of costs to date (can be scary).
Stick with the console for now.
On the left is the nav. Choose “EU West” as your region unless you’re doing something US-centric. Do that now.
Have a quick look through the other links on the left.
- Instances – we can create servers in here
- Volumes – create EBS blocks here
- Elastic IPs – here you can assign fixed IPs
- Security Groups – here you manage the “firewall”, opening ports as required.
- Key Pairs – manage those keys here (unlikely to be needed)
The others you can investigate yourself. Beware of Snapshots, which are a way to store incremental backups, but tend to be more complicated than expected.
Let’s start with an Instance.
Go to the Instances view, and click “Launch Instance”.
You now choose an image (AMI).
Just pick the “Basic 64-bit Fedora Core 8”, which is a 64-bit machine (meaning we can get larger varieties), and is a linux variant.
In the next page you can choose the “Type”. This is the size for the instance, and this affects the pricing. The pricing is annoyingly not displayed here though.
For this case, we chose a beefy
c1.xlarge, which is 96cents an hour.
Choose defaults for the rest of that page.
On the next screen you can enable cloudwatch, which is about 15cents an hour extra. Leave the rest as defaults.
On the next screen choose the keypair you created earlier.
Finally, Choose a security group. Let’s just choose the default (don’t create a new one).
If you’re working on real projects, you can create and name security groups, which helps you see which servers are doing what in the console later on. I find this easier than trying to memorize the code names for each machine.
Continue and Launch.
You’ll see your instance appear in the list as “pending”.
After about 30 seconds, it will be “running”.
You are now being charged.
We connected our new instance to the Security Group called “default”.
Before we access that instance, we need to open the ports.
In the Console, head to “Security Groups”.
Click “default” and in the bottom panel create lines for HTTP (just choose HTTP in the dropdown and click save)
And SSH (again, choose SSH in the dropdown and save)
We can now connect via SSH.
Head back to the Instances window.
Click our instance, which is now “running”.
In the bottom window you can see various details.
“Public DNS” is the name of the machine for the outside world. It’ll be something like this:
Right click the instance and choose “Connect”.
A window appears giving you instructions for connection.
On my Mac I just open a Terminal window.
Because I used ”
ssh-add” earlier, I don’t need the
-i <keypair> option.
But if I didn’t use
ssh-add, I would
cd to the directory where I stored the
PEM key first.
Once you’ve entered the command, you should get straight into the machine as root!
Some AMIs have LAMP already installed. We chose a vanilla AMI, so we have nothing but the OS.
For the purposes of this demo, let’s install Apache.
yum install httpd
And start it:
Now we can go to the website:
We should see the Fedora Test Page!
Install the command line tools
Amazon provide a whole set of command line tools to help you work with instances. These are always added first for any new feature, so they offer more options than are available through the console, for example to use the RDS features.
Get the Developer Tools here
Put them somewhere permanent on your system
Follow the instructions for setup here:
It’s long and complicated, but IMHO that’s because it’s built in (ptui) Java.
Specifics for Mac
mkdir ~/Documents/ec2-tools mv /Users/kenneth/Downloads/ec2-api-tools-1.3-46266 ~/Documents/ec2-tools mkdir ~/.ec2 mv /Users/kenneth/Downloads/X.509keys/* ~/.ec2
Add the following to ~/.profile
#Amazon EC2 Command line tools export EC2_HOME=~/Documents/ec2-tools export PATH=$PATH:$EC2_HOME/bin export EC2_CERT=~/.ec2/cert-#######.pem (match your key names) export EC2_PRIVATE_KEY=~/.ec2/pk-########.pem export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home export EC2_URL=https://ec2.eu-west-1.amazonaws.com
Then run this command:
(This just runs the stuff in the .profile)
Check that it’s all peachy with this command:
You can now create instances on the command line.
A word of warning: Internal bandwidth costs are not charged (eg, between two instances, or between your instance and your RDS), but if your machines are in different physical regions, the bandwidth is treated as external. I ran up bandwidth charges of a terabyte in my first week, which proved hugely costly. Be sure to check your regions.
We can view our servers like so:
Or even create a new one like this:
ec2-run-instances -n 1 --key kennethkey ami-bdc0ebc9 -t c1.xlarge
Rip it down
Ok, we’ve had some fun, and incurred about a dollar in fees.
Let’s ditch our server.
Head back to the console, and right-click the instance(s).
Our server will be destroyed and we’ll stop being charged.
Our SSH session will be kicked off.