Design Menace

Setting up a EC2 Server on Amazon: Part 1

Amazon Web Services

Before we get too far into this, one important thing to note is that when we refer to an instance, we are basically referring to a server.  It’s not it’s own server, but that is how it is referred to.  Also important to note is that everything on Amazon’s Web Service is billed hourly. (You can find the pricing for EC2 here.)  This is actually really nice, because there are no long term contracts, and your only charged for what you use.  If you run through the following demo, it will probably end up costing you less than a dollar, and take you about 10 minutes to setup.

A great example of why this structure is really nice, is when your site ends up taking on a lot of traffic, all of a sudden.  This can cause your site to go down very quickly, so once you realize your getting pounded, AWS allows you to easily replicate your server into multiple identical instances, and then load balance the immense amount of traffic your receiving over all of these.  You can make a number of new instances, then when your traffic dies down again, you can terminate the instances you don’t need anymore.  In the end, your only charged for what you use.  Now standard hosting companies will more than likely charge you upgrade and setup fees, and possibly make you sign long term contracts.  Having dealt with this before, I can tell you, this will cost you way more than just adding and removing instances.  But, I’ll be going into these types of things more in a future post…for now let’s go ahead and dive into setting up an instance.

When it comes to EC2 instances, the Community AMI’s were made by people who know what they are doing.  And this is awesome, because it gives me a jump off point to start my server.  If I were just to do a regular basic install, without utilizing the Community AMI’s, I would have an empty box.  No OS, nothing, nada, zippy!  So, this allows me to pick an OS, and start there.  I usually go with Ubuntu, and you can find the most recent builds at Alestic (  Once, I click on”us-east-1″ I am presented with a bunch of different builds.  I choose the “Karmic EBS boot.” (See images below.)

The important thing here is the EBS (Elastic Boot Store) boot.  It does cost more because you are utilizing the EBS storage system, but it is ALOT safer.  The EBS store will store the data, including in this case the database, in a different location that can be backed up easily.  You can attach EBS storage to different EC2 instances, so if your EC2 instance that your building all of a sudden disappears, which I have read has happened before, then your data is safe.

Now that I know which install of Ubuntu I am going to install (in my case, ami-563dd73f,) I am going to get logged into the AWS console ( and Select EC2 from the Tabs at the top.  For some reason the control panel is UNGODLY slow, so have patience.  Once it does finally load, you will see a button that says “Launch Instance.”  Click this link, and a Request Instances Wizard will popup.  Within that wizard are three tabs, one being “Community AMIs.”  Click that tab, and enter the AMI id (in my case, ami-563dd73f) and it will search and find this build. (Again, it takes forever.)  Once it pop’s up click “Select” on the right, and run through the wizard.

Through each of the next 6 steps, for the most part, your going to be clicking on Continue at the bottom, but I will go through all of the steps.

The first step allows you to setup the size, number of instances, and which zone they are on.  I never really care which zone it is in, and you really don’t need to unless your setting up additional instances or services, so for the purpose of this demo, I am choosing a Small instance because that is all I need.  In the future I can easily upgrade this…but that is for another time.  So I am just going to go ahead and click Continue.

If your like me, the second step isn’t going to make any sense to you.  You can choose the Kernel ID, and RAM Disk ID, but I have always chosen the Default and been fine, so that is what I will do now.

The third step is really just for organization purposes.  You can create Key-Value pairs that allow you to identify what the instance is.  For example, if you had 10 web servers load balanced, a database server, and an additional server that handles ad serving, it would be good to identify what is what.  So knock yourself out, but it’s not required.

The forth step is critical for security.  When you connect to the server later on using SSH, you will have to pass along a file basically saying that you are you.  Anyone, who has this file will be able to connect, so enter a name (ie. sublet, jhunter, Initial_Test) and click “Create & Download your Key Pair.”  MAKE SURE YOU SAVE IT AND KNOW WHERE IT IS!

The fifth step is also critical for security.  Basically, when you start server it is completely shut off from the outside world.  You will have to open up the ports in order for people to access it.  My next post in this series will cover this, so I am not going to get into it now.  Everyone has access to the “default” security group which gives you a place to start, but you might as well “Create a New Security Group,” as we will be going over that next.

The final step is to just look over the settings…if you want…and then click Launch.  It doesn’t take long to setup…maybe a few seconds but once it’s done, you will have essentially created a new server.

The next post will be on setting up the security group so you can SSH in to system and pull it up on a standard web browser.  Till next time!