Blog

Creating a New Cron Job on AWS Linux AMI

Cron is a time-based program used explicitly to initiated other programs at particular times on a Linux system. AWS Linux AMI comes with cron pre-installed and configured, like every other modern Linux installation. The base configuration allows for set up of a task that should be run hourly, daily, weekly or monthly as well as any other time period.

Quick Job Setup

Setting up a job to run hourly, daily, weekly or monthly is very quick. These instructions assume you have already setup an AWS instance and have an SSH client (like PuTTY) available.

  1. Log in to your instance via the SSH client. Transfer to the root user.
  2. Go to the '/etc' directory
  3. Open the appropraite 'cron.XXXXX' directory. For example, if you want to add an hourly task, open the 'cron.hourly' directory.
  4. Create a new file (shift+F4)
  5. Add a single line for each job you want run. For example if you want to run a PHP script, type "/usr/bin/php -q /path/to/script/script.php", substituting for the correct path to PHP and the script file.
  6. Save the file. The name doesn't really matter so long as it is unique. Cron will call every file in the directory at the appropriate time and run the commands in each file.

Custom Job Setup

Setting up a job to run at custom time requires you to understand the crontab syntax. The syntax is not terribly complex (it is similar than Regular Expressions) but is complex enough that you don't want to deal with it if you do not need to.

Crontab Syntax

Crontab is the configuration structure for cron jobs. Simply, the files are composed of two parts: the settings followed by the jobs.

Crontab settings

The settings section states what should be run, where it is located, who should run it (as in Linux User) and a few other special commands. In the below example, the first 4 lines are settings and the last line is a job.

Example crontab file

  • SHELL=/bin/bash
  • PATH=/sbin:/bin:/usr/sbin:/usr/bin
  • MAILTO=root
  • HOME=/
  • 01 * * * * root run-parts /etc/cron.hourly
  • "SHELL" identifies which shell state you want to run the scripts under. If it is not included, most systems will default the shell indicated in '/etc/passwd' or just fail to run.
  • "PATH" is location of the cron initiated scripts. If you are regularly running scripts in '/usr/bob/scripts' you could add the path here to avoid having to type '/usr/bob/scripts' for every script. In the above example, the PATH line would become "PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/bob/scripts"
  • "MAILTO" is the address of the webmaster who will receive an email every time these scripts are run.
  • "HOME" is the home directory for cron. It is basically prefixed to any relative path name you use in any script. It is only actually useful if you are going to be running many scripts from the same crontab file.

Crontab jobs

The settings section is the easy part of crontab files. Each job is composed of seven fields each separated by a space. Any field that is not set identified with an asterisk (*). minute hour day month weekday user cmd

  • minute is the minute the job is to be run.
  • hour is the hour (on a 24 hour clock) when the job is to be run.
  • day is the numerical representation of the day of the month. The values range from 1-31.
  • month is the month's numerical representation. The values range from 1-12.
  • weekday is the day of the week you want the job to be run on. The values range from 0-7, with Sunday being 0 & 7. If the day and weekday are both specified, the command runs when EITHER is true.
  • user is the Linux user you want to run the command.
  • cmd is the command to be run. This is no different than the commands in the quick job setup section above.

With the exception of day and weekday, all of the other time commands must be true in order for the script to run. Crontab also supports step function (non-whole number inputs) and ranges. Ranges work just like page ranges do in most word processors with comma (,) separating individual values and dashes (-) representing all values from the first number to the second number. For example, "3-5,7" would fire on 3, 4, 5, and 7. Step functions use a forward slash to fire when the value becomes a whole number. For example a minute value of "*/15" would fire every 15 minutes, when the current minute divided by 15 is a whole number.

Creating a new Crontab File

These instructions assume you have already setup an AWS instance and have an SSH client (like PuTTY) available.

  1. Log in to your instance via the SSH client. Transfer to the root user.
  2. Go to the '/etc/cron.d' directory
  3. Create a new file (shift+F4)
  4. Add each setting value as its own line at the beginning of the file. The above example file's values should work on the AWS Linux AMI installation.
  5. Add crontab job lines for each job you want to run.
  6. Save the file. The name doesn't really matter so long as it is unique. Cron will call every file in the directory at the appropriate time and run the commands in each file.

Installing Common PHP Extensions

PHP is a simpler programming language which offers the power of the more complex object orientated languages without some of the more complex data management issues. PHP is commonly used to develop dynamic web content, especially content based upon a database like MySQL. PHP is an on-demand compiled language, where it uses the Apache2 web server to compile the PHP code when the script is run.

In a practical sense, you must have Apache installed to use PHP on your server. If you do not have Apache currently installed, instructions can be found here. Instructions for installing PHP after you have installed Apache can be found here.

The base PHP distribution comes with a lot of the core features, but only core type features. You will often run across situations where you need a PHP Extension or Application Library. PHP extensions are divided between 2 repositories; PECL and PEAR. The difference between the repositories is the type of files each contain. PECL contains C compiled files while PEAR contains special PHP classes. This makes the PECL extensions faster and more powerful than PEAR extensions, however they can have robustness issues since programming in C is much more challenging.

Installing PECL

These instructions assume you have already setup an AWS instance and have an SSH client (like PuTTY) available.

  1. Log in to your instance via the SSH client. Transfer to the root user.
  2. Use PECL to install pecl extension
  3. Press "Y" when it asks if you want to install the extension. Depending on the extension, there may be multiple options you can choose during the installation.
  4. Verify the installation occurred correctly by starting/restarting the httpd service

Summary of command line inputs (example uses pecl_http extension)

  • $ sudo su
  • $ pecl install pecl_http
  • .....
  • $ service httpd restart

Popular PECL extensions

ExtensionDescriptionPHP-Devel?
pecl_http HTTP request & response processing Y
mailparse Parsing email addresses N

Installing PHP-Devel

Some of the extensions, the PECL ones in particular, require the php-developer package to work properly. If you get an error like "needs php-devel to be installed' when you attempt to install a package, you will need to install the php-developer package.These instructions assume you have already setup an AWS instance and have an SSH client (like PuTTY) available.

  1. Log in to your instance via the SSH client. Transfer to the root user.
  2. Use YUM to install PHP-Devel
  3. Press "Y" when it asks if you want to install the extension.
  4. Verify the installation occurred correctly by starting/restarting the httpd service

Summary of command line inputs

  • $ sudo su
  • $ yum install php-devel
  • .....
  • Do you want to install PHP-Devel (Y/N): Y
  • $ service httpd restart

Note about PHP-Devel

When I installed PHP-Devel it changed the ownership and permissions of my session directory. This caused session_start() to fail with a "Permission Denied (13)" error. To fix the error I had to change the ownership back to the Apache user/group that is used when PHP is run on the session directory.

Installing and Configuring PHP on AWS Amazon Linux AMI with Apache2

Apache2 is the standard Linux web server. It deals with all of the http and https requests sent to the server and complies PHP scripts. PHP is a simpler programming language which offers the power of the more complex object orientated languages without some of the more complex data management issues. PHP is commonly used to develop dynamic web content, especially content based upon a database like MySQL.

In a practical sense, you must have Apache installed to use PHP on your server. If you do not have Apache currently installed, instructions can be found here.

Installing PHP

These instructions assume you have already setup an AWS instance and have an SSH client (like PuTTY) available.

  1. Log in to your instance via the SSH client. Transfer to the root user.
  2. Use YUM to install php
  3. Press "Y" when it asks if you want to install PHP
  4. Verify the installation occurred correctly by starting/restarting the httpd service

Summary of command line inputs

  • $ sudo su
  • $ yum install httpd
  • .....
  • Do you want to install PHP 5.x (Y/N): Y
  • $ service httpd restart

Configuring PHP

The default configuration of PHP is just fine to use for 90% of applications. If you are going to be doing development on the server, it would be appropriate to make a few changes to the php.ini file for the particular development server. These changes should occur in the Apache2 hosting configurations ("/etc/httpd/conf.d/vhosts.conf" in the previous Apache2 instructions). The major setting you would want to change is turning off safe mode.

Installing and Configuring Apache2 on AWS Amazon Linux AMI

Apache2 is the standard Linux web server. It deals with all of the http and https requests sent to the server. Apache2 modules are also used to compile php scripts.

Installing Apache2

These instructions assume you have already setup an AWS instance and have an SSH client (like PuTTY) available.

  1. Log in to your instance via the SSH client. Transfer to the root user.
  2. Use YUM to install httpd (the apache2 web server application)
  3. Press "Y" when it asks if you want to install Apache
  4. Verify the installation occurred correctly by starting the httpd service

Summary of command line inputs

  • $ sudo su
  • $ yum install httpd
  • .....
  • Do you want to install httpd (Y/N): Y
  • $ service httpd start

Configuring Apache2

Configuring Apache2 is easiest done with a visual text editor, like included in WinSCP rather than through the command line and vi. You will need to restart the httpd daemon after changing the configuration files in order for the settings to take effect.

Examples settings
Apache system user webserv  
System group webcln  
Domain 1 example.com  
Domain 1 subdomain sub.example.com  

Basic Configuration

These settings will need to be changed whether you use a single domain or virtual domains.

  1. Open the file "/etc/httpd/conf/httpd.conf". Httpd uses the standard C-type commenting, so any line starting with a "#" is commented out and not used in configuring apache2
  2. Make sure "Listen 80" is uncommented.
  3. Change "User" to the desired linux user that you want apache to run as. The example user is "webserv"
  4. Change "Group" to the desired linux user that you want apache to run as. The example group is "webcln"
  5. Set the "ServerAdmin" to the server admin's email address.
  6. Add any other index files to "DirectoryIndex" list. Apache will search for the files in order they are listed. Separate multiple file names with spaces.
  7. Finish the configuration via the Single Domain Configuration OR the Virtual Domains Configuration. I recommend using the Virtual Domains Configuration model, because it easily allows for adding subdomains or redirecting other domains.

Single Domain Configuration

  1. Open the file "/etc/httpd/conf/httpd.conf" A single domain is setup fully within the core configuration file.
  2. Uncomment and make the appropriate changes to the following directives.
  3. Log in to your instance via the SSH client. Transfer to the root user ("sudo su").
  4. Verify the installation occurred correctly by starting the httpd service.
  5. Log in to your domain hosting account and change the DNS records to point to the correct IP address.
  • ServerAdmin webmaster@example.com
  • ServerName www.example.com:80
  • ServerAlias www.example.com
  • UseCononicalName off
  • DocumentRoot "/var/www/html"
  • ErrorLog /var/logs/error_log

Virtual Domains Configuration

  1. Open the directory "/etc/httpd/conf.d/" and create a new file called "vhosts.conf"
  2. Copy the below configurations and exchange the example values for your server's values. You should leave a copy of the 'default' server at the top of the vhosts file. The first listing of either port (80 for http and 443 for https) will be used when a request does not match any other server name or server alias.
    Meaning of each parameter
    • NameVirtualHost - Indicated that the particular IP:PORT combination is a virtual host. Need this to instigate the VirtualHost tags later. The value should be structured as IP:PORT. The wildcard "*" can be used to identify any IP address. Port 80 is used for http connections while port 443 is used for https (secure) connections.
    • IfModule - Checks to see if a module is installed and usable. Anything within the tags will be processed only if the module indicated in the open tag is installed and usable.
    • VirtualHost - This tag identifies a particular virtual host. The contents of the tag must contain the parameters ServerName, and DocumentRoot in order to work. The IP:PORT combination listed in the opening tag must be initiated using the NameVirtualHost parameter.
    • ServerName - The name of the webserver, which is normally the web address, in quotes. Apache will be asked for the ServerName by the user's browser. Note: I use the value "default:80" as a catchall for incorrect inquiries to the server. If a user queries your server, on port 80, for ServerName which doesn't exist, the first VirtualHost will be returned as a default. A DNS error can create this situation, but a user can intentionally create this situation. This is possible by directly accessing the server IP address then spoofing the HTTP header with a different web address. You can actually test your own settings this way.
    • UseCononicalName - This is a name allocation directive for self-referential URLs. Setting it to 'on' forces Apache to use the hostname and port specified by ServerName where setting it to "off" allows it to first try the hostname and port supplied by the user then use the server values. Setting it to "off" can be a slight security issue, but will generally allow for faster processing of complex situations, especially those involving intranets.
    • ServerAdmin - This is the email address of the admin for the particular server, in quotes. This is not essential, but should be included to control the distribution of spam.
    • DocumentRoot - This is the directory apache will look for the appropriate web files.
    • ErrorLog - This is the error log file to be used for errors occuring with this virtual host.
    • SSLEngine - This runs the Apache mod_ssl engine which allows for secure connection and encryption of the information set to the user. You have to use this if you want to use the https protocol.
    • SSLVerifyClient - This forces the client to provide the certificate confirmation before receiving any information. This is impractical for most situations, except when using a company intranet. The client must already have the correct certificate in order to authenticate with the server.
    • SSLCertificateFile - The location of the ssl certificate file.
    • SSLCertificateKeyFile - The location of the ssl certificate key file..
  3. Create the directories for each virtual account. The example uses the home directory of "/var/www/vhosts" for all of the virtual hosts. Within this directory there is a directory for each domain and within each of those is a directory for the http files (httpdocs), the https files (httpsdocs) and the server files (var). You also need to create a blank "index.html" file in the http and https directories and an error log in the logs directory.
    • /var/www/vhosts/example.com/httpdocs/
    • /var/www/vhosts/example.com/httpsdocs/
    • /var/www/vhosts/example.com/var/logs/
    • /var/www/vhosts/example.com/var/certificates/
  4. Log in to your instance via the SSH client (PuTTY). Transfer to the root user ("sudo su").
  5. Verify the installation occurred correctly by starting the httpd service ("service httpd start").
  6. Log in to your domain hosting account and change the DNS records to point to the correct IP address.
Example vhost.conf file
  • NameVirtualHost *:80
  • <IfModule mode_ssl.c>
    • NameVirtualHost *:443
  • </IfModule mode_ssl.c>
  • <VirtualHost *:80
    • ServerName "default:80"
    • UseCononicalName off
    • ServerAdmin "webmaster@example.com"
    • DocumentRoot "/var/www/vhosts/default/httpdocs"
    • ErrorLog "/var/www/vhosts/default/var/logs/error_log"
    • <IfModule mode_ssl.c>
      • SSLEngine off
    • </IfModule mode_ssl.c>
  • </VirtualHost>
  • <IfModule mode_ssl.c>
    • <VirtualHost *:443
      • ServerName "default:443"
      • UseCononicalName off
      • ServerAdmin "webmaster@example.com"
      • DocumentRoot "/var/www/vhosts/default/httpsdocs"
      • ErrorLog "/var/www/vhosts/default/var/logs/error_log"
      • SSLEngine on
      • SSLVerifyClient none
      • SSLCertificateFile/var/www/vhosts/default/var/certificates/default.crt
      • SSLCertificateKeyFile /var/www/vhosts/default/var/certificates/default.key
    • </VirtualHost>
  • </IfModule mode_ssl.c>

Setting up WinSCP for AWS access

I am assuming you have already setup PuTTY for AWS access. If haven't yet, please follow the instructions at Setting up PuTTY for AWS access. Also, obviously, you need to have an AWS Instance setup. If you haven't setup an AWS Instance, you can find help at Setting up a Free Tier Amazon EC2 Instance.

These instructions assume you have already installed WinSCP on your computer. If you need WinSCP, it can be found at www.winscp.net. It is really easy to install on windows machines.

Configuration for AWS Instance access

You need to access your AWS dashboard as well as WinSCP.

  1. Open your AWS Console (go to http://aws.amazon.com and login)
  2. Go to "EC2" under "Compute and Networking"
  3. Click on "Instances" under the "Instances" section of the Navigation pane. This will display all of the instances you currently have running. Clicking on the name of the instance will show the details of that instance below. Select the instance you want to configure WinSCP for then find the "Key Pair Name" and "Security Groups" values under the "Description" tab. If you haven't already done so for PuTTY, you will need to edit the security group in order to allow an SSH client (WinSCP in this case) to access your instance then confirm the security key with the key pair name.
  4. Find the value for "Public DNS" under the "Description" tab then highlight it (shift+ left click while selecting the text) and press CTRL+C to copy the text. You will need this value when setting up WinSCP and I find copy & pasting a whole lot easier than retyping something.
  5. Click on "Security Groups" under the "Networking & Security" section of the Navigation pane. This will show your security groups for this region. Click on the instance's security group to see the details of that group.
  6. Click on the "Inbound" tab to edit the firewall associated with this security group.
  7. SSH clients use port 22 for access, so you will need to verify that TCP port 22 (SSH) is listed on the table to the right. If it is not listed, or there is no table, select "SSH" under for "Create a new rule" then add your computer's ip address to the source line followed by "/32". AWS security groups use CIDR notation for IP address ranges. Simply, "/32" limits the range to a single IP address. Click "Add Rule" then click "Apply Rule Changes"
  8. Click on "Key Pairs" under the "Networking & Security" section of the Navigation pane. The "Fingerprint" for the "Key Pair Name" will be needed later to confirm your connection to the AWS Instance.
  9. Open WinSCP.
  10. Click on "New" to add a new session. Note, if this is the first time you've used WinSCP, you will automatically be prompted for a new session.image
  11. Choose "SCP" as the "File protocol"
  12. Choose "22" for "Port number". Note, you can actually use a different port than the default 22 to connect with the AWS Instance. You would have to make the appropriate adjustments to the ssh shell and the AWS Security Group. This can be good from a security standpoint, but is extremely risky from a setup standpoint. If you mess up the settings you will be permanently locked out of SSH access to the instance, generally making it worthless.
  13. Paste your instances' "Public DNS" value in the "Host name" box.
  14. Enter "ec2-user" as the "User name" and leave the "Password" box blank..
  15. Click on the "..." button in the "Private key file" box and open your private key that corresponds to the Key Pair Name" you generated when setting up the instance. This was the same file you opened in the PuTTYGen program earlier.
  16. Click "Save". There's no point in reentering this info every time you want to login.
  17. The first time you log in you will get a security fingerprint confirmation. This value should be the same as the one provided through the AWS console.
  18. Click "Login". This will log you in as the ec2-user user. This is fine for some stuff, but you won't be able to change to the root user without completing the last few steps.
  19. Open the file "/etc/sudoers"
  20. Find the line "Defaults reguiretty" and add "Defaults:ec2-user !requiretty" as the next line. This will allow WinSCP to transfer itself to the root user after logging on by using sudo su, just like in PuTTY.
  21. Disconnect. The disconnect option can be found under the "Sessions" menu.
  22. Click on the session you just created then click "Edit"
  23. Click on "SCP/Shell" on the left options. Note, "SCP/Shell" isn't listed under "Environment" check the "Advanced options" box at the bottom to display the option.
  24. For "Shell:" select "sudo su -" as the option. Make sure "Return code variable" is set to "Autodetect".image
  25. Click "Save"

When you log in, your shell access will automatically be changed to the root user allowing for complete access to all files. For most web development activities, root access isn't needed, however it makes life easier AND is essential for installing and configuring most of the software.

Setting up PuTTY for AWS access

PuTTY is a free open source SSH client. You will need to install it (basically download the installer and run it) if you have not already done so. Make sure you have both PuTTY and PuTTYgen programs.

Configuration for AWS Instance access

These instructions assume you have already setup an AWS instance. If you haven't setup an AWS Instance, you can find help at Setting up a Free Tier Amazon EC2 Instance.

  1. Open your AWS Console (go to http://aws.amazon.com and login)
  2. Go to "EC2" under "Compute and Networking"
  3. Click on "Instances" under the "Instances" section of the Navigation pane. This will display all of the instances you currently have running. Clicking on the name of the instance will show the details of that instance below. Select the instance you want to configure PuTTY for then find the "Key Pair Name" and "Security Groups" values under the "Description" tab. You will need to edit the security group in order to allow PuTTY to access your instance then confirm the security key with the key pair name.
  4. Find the value for "Public DNS" under the "Description" tab then highlight it (shift+ left click while selecting the text) and press CTRL+C to copy the text. You will need this value when setting up PuTTY and I find copy & pasting a whole lot easier than retyping something.
  5. Click on "Security Groups" under the "Networking & Security" section of the Navigation pane. This will show your security groups for this region. Click on the instance's security group to see the details of that group.
  6. Click on the "Inbound" tab to edit the firewall associated with this security group.
  7. SSH clients use port 22 for access, so you will need to verify that TCP port 22 (SSH) is listed on the table to the right. If it is not listed, or there is no table, select "SSH" under for "Create a new rule" then add your computer's ip address to the source line followed by "/32". AWS security groups use CIDR notation for IP address ranges. Simply, "/32" limits the range to a single IP address. Click "Add Rule" then click "Apply Rule Changes"
  8. Click on "Key Pairs" under the "Networking & Security" section of the Navigation pane. The "Fingerprint" for the "Key Pair Name" will be needed later to confirm your connection to the AWS Instance.
  9. Open PuTTYgen. Click on "Load" then choose the Key Pair file for the "Key Pair Name" of the instance. If you just created the instance following the above instructions, the key file is the one you had to save after you generated the "Key Pair Name."
  10. Click "Generate" to create the PuTTY usable security key. Save the file somewhere you will remember and can control, since access to this file will allow access to the AWS instance. Close PuTTYgen.
  11. Open PuTTY. The default "Category " should be "Session." If "Session" is not selected, select it.
  12. Click on the "Host Name (or IP address)" input and press CTRL+C to past your "Public DNS" address as the host name. Make sure "Port" is set to "22" and "SSH" is selected as the "Connection type:".
  13. Expand the "Connection" Category and expand the "SSH" section and click on "Auth."
  14. Click on "Browse" and open the Putty key you just created with PuTTYgen.
  15. Click on the "Session" Category again and choose "Save." This way you won't have to repeat setting up PuTTY every time you want to use it. NOTE: This is security weakness, because anyone with access to your computer would then be able to access your AWS Instance, however most people have their own private computer which limits the security risk. I just find it a pain to redo everything every time I want to access the server.
  16. Click "Open" to open the SSH connection.
  17. Type "ec2-user" at the "login as:" prompt. The "ec2-user" is the default user for the Amazon Linux AMI. You cannot login as "root" as a security measure.
  18. To transfer to the "root" user, type:
    $ sudo su

Installing the necessary software on an AWS Amazon Linux AMI server

There is a variety of software you will need to get your new AWS web server up and running. You probably already have the desktop clients if you every did any server work previously, the core server software however will need to be installed, depending on your purposes for the server. This page will be updated from time to time as new installation and configuration guides are added.

Desktop Clients

SoftwareDescriptionAvailable at:Documentation
  Free SSH client. Utilizes basic command line style interface   |
  Free SCP/SFTP/FTP client for Windows. Offers a graphical user interface to move and edit files.    

I am bias to Windows software. All of these programs run on Windows XP and Windows 7 (32-bit & 64-bit systems). If you are running a Linux or Mac system....well...they may work. The program's name link will go to instructions on configuring the software to access your AWS Instance.

Core Server Software

SoftwareUsageDescriptionDocumentation
Apache2 Website hosting The basic web server which deals with internet (http/https) traffic to the server.  
PHP Dynamic Websites (optional) Requires:Apache2 Scripting language for creating dynamic webpages. Used by most CMS, Wiki & Blog systems to manage content  
MySQL Database The basic free SQL database server. Used by many CMS, Wiki & Blog systems to store content.  
phpMyAdmin Database Administration (optional) Requires:Apache2, PHP & MySQL Graphical, HTML based admin tool for accessing and managing mySQL databases.  
Postfix Mail-Transfer-Agent (ie: email server) Accepts and sends email. Versatile and can be used with a variety of database structures.  
Courier Email Client Portal (optional) Requires:Postfix Offers a portal to access email via any client, including MS Outlook, Thunderbird & smart phones. Offers IMAP and POP3 systems.  
Spamassassin Email Spam filter (optional) Requires:Postfix Works with MTAs to prevent spam from arriving on server  
BIND9 DNS Server (optional) DNS server which allows you to create your own dns records.  

Note all of these programs are free, and most are open source. All of the installation instructions are specific to the Amazon Linux AMI. This stripped down version of Linux is a special Amazon derivative of Fedora. When I was originally setting up our servers, some of the differences between RedHat, Ubuntu, Debian and this version of Linux drove me crazy, therefore all of these instructions worked on the newest Amazon Linux AMI version (currently 2012.03).

Setting up a Free Tier Amazon EC2 Instance

Amazon AWS is currently offering a 'free tier' for 1 year. Simply you get a micro instance to get your server up and running, play with different settings and such. It is the standard free trial offer, but with a virtual server. If you've never used AWS before, I recommend using the free tier server to get acquainted with the capabilities of AWS then move to a real server later. Also, once you have all the settings working on the free tier instance, you can transfer to paid instance in 15 minutes. AWS Free Tier

  • 750  hrs/month Micro instance (613 MB of RAM, Linux or Windows)
  • 750 hrs/month Elastic Load Balancer (15 GB of data processing)
  • 30GB of EBS space
  • 5 GB of Amazon S3 standard storage

Setting up a New Instance

  1. Go to and login to your .
  2. Click on "EC2" under the Compute & Networking section. (Note you may have to choose your region at this point if it hasn't been setup yet.)
  3. At the "Amazon EC2 Console Dashboard" there should be a button in the middle of screen called "Launce Instance", Click it.
  4. The wizard will pop-up asking you to choose a type of wizard. Select "Class Wizard" and click "Continue" at the bottom right.
  5. Select the "Amazon Linux AMI ####.##"  AMI. It should be the top option under the "Quick Start" tab. Note, you can use any of the AMIs with a yellow star next to the select button for the free tier. The 32-bit version will be slightly easier to deal with later, but 64-bit version works just fine also.
  6. You will now need to determine the basic instance details. For the free tier, make sure the "Number of Instances" is set to 1 and the "Instance Type" is "Micro  (t1.micro, 613 MiB)". The "Availability Zone" doesn't matter right now so "No Preference" is fine. Click the "Continue" when the settings are correct.
  7. You now can determine some of the advanced options. The only thing you need to be concerned about is the "Shutdown Behavior" which should be set to "Stop". Click the "Continue" when the settings are correct.
  8. The next page is a the storage details. New instances default to a "Root Volume" which is effectively a new blank standard EBS volume.I recommend you uncheck the "Delete on Termination" checkbox to prevent you from accidentally erasing your data when the instance dies.Click the "Continue" when the settings are correct.
  9. Now you can set metadata you want to correspond with this instance. These key/value pairs will help with searching and administrating large clouds of multiple servers. In addition to the "Name" key, we generally always place a "admin" key with the value equaling the programmer who administrates the instance. You can place up to 10, and you can always change them later. Enter something for the "Name" key's value then press "Continue".
  10. The next step is absolutely essential to run a secure instance and have access via an SSH client. Instead of using usernames and passwords, AWS uses usernames and encryption keys, called "Key Pairs." This encryption level prevents brute force attacks against your instance. Enter a name (alphanumeric without spaces) then press the "Create and Download your Key Pair" button. You will be expected to save the key file somewhere on your locale computer; remember where because you will need this file later when setting up your SSH and SCP clients. Click "Continue" once you have created your Key Pair.
  11. The last setting you need to determine is the firewall. Amazon allows you to create an off-instance firewall to limit access to your instance. Click on the "Create a New Security Group" radio button then enter a "Group Name" and "Group Description". Leave the the "Inbound Rules" empty for now. Typically when you create an instance, you will you use a pre-created security group that you already setup for the purpose of the instance.  Click "Continue" once the new security group is created.
  12. This last page is just a review of the settings for your new instance. Look over them and make sure everything is correct then click "Launch." A few moments later your simple Free Tier instance will be up and running. The next step is getting access to it, then installing software and configuring everything. These will be discussed in future posts.

Amazon Cloud Hosting

Amazon is a huge player in the cloud hosting space. Cloud hosting is basically where a company fills a server farm with racks upon racks of physical computers, hard drives and routers. The company then uses software to combine the individual computers into a super computer which is then partitioned off into a series of virtual servers of varying sizes and types. The company then resells usage of these virtual servers to their clients. Amazon Web Services (the division which provides the service) offers a variety of different types of virtual servers, but the basic, and most flexible, is called Elastic Cloud Compute (EC2).

Amazon EC2

Instances

Instances can be thought of as the virtual processor, motherboard and RAM of the virtual server. Amazon offers three different types of Instances (On-Demand, Reserved, and Spot) and of varying different sizes.

On-Demand Instances

On-demand Instances are those you intend on using on a temporary basis. You are paying only for the amount of time you actually use the instance, so they are excellent for short-term projects and to get settings worked out.

Reserved Instances

Reserved Instances are instances which are dedicated to your account. They do not go away if you stop, or terminate them. Well, that is not quite correct. You are actually reserving usage of a particular type of instance, rather than a particular instance. The different levels of Reserved Instances are basically usage structures. You prepay to reserve an instance and in exchange get a discount on the hourly rate. Reserved Instances are ideal for long-term server applications, like website host, email servers, etc.

Reserved Instances Utilization Rates
  • Heavy Utilization - These instances are used 80%+ of the month.The core website and email servers.
  • Medium Utilization - These instances are used for 40-79% utilization rates. If you run a few heavy traffic websites, then these instances would be the load-balanced servers to support demand during peak times like the evenings and weekends.
  • Light Utilization - These instances are used for 17-30% utilization rates. This time frame corresponds really well with development servers that are started in the morning, run for 7-8 hours then turned off in the evening.

Spot Instances

Spot Instances are similar to on-demand instances, but are designed for special project type circumstances. Amazon obviously wants to keep all of their servers running all the time (ie. 100% utilization), however with the on-demand type structure, there are times when some servers are not being used. During these low slow times, Amazon would rather sell time on them temporarily for a discount rather than let them run empty. These temporary discounted servers are the spot instances. Spot instances work really well for periodically maintenance activities. To use a spot instance, you indicate the size of instance and the maximum price you bid for usage of that instance. Once the price for that size of instance goes below the bid price, the instance starts up and you get it until the prices goes back over your max bid price. Note you are only charged the actual price, not your bid price, so you can often pay less per hour than your bid price for spot instances.

EC2 Resources

Elastic Block Store Volumes

Elastic Block Storage (EBS) volumes are the virtual hard drives of the virtual server. There are two types of EBS Volumes, Standard and Provisioned  IOPS (Input/output Operations Per Second).

Standard EBS Volumes

Standard EBS volumes correspond the best to physical media hard disks. You can read and write to them at average rates and deliver about 100 IOPS. Unless you need high writing/ reading capabilities, a standard EBS is what you'd use.

Provisioned IOPS Volumes

Provisioned IOPS are for high read/write type situations. The most common examples is a database server. These volumes are very powerful, but also very expensive (relatively). There are other AWS Services offered, like S3, SES and RDP, but I currently don't use them some will avoid going into detail on those services until I use them.