In this assignment you will be using a web application that is provided to you (MiniTwit – a
simple Twitter clone) and deploying it in EC2 using many of the features you would want to use
for a service of this type. First you will set up your AWS account to be ready to create EC2
instances (virtual servers), and then you will create an instance and SSH to it. Then you will run
the MiniTwit application and see that you can reach and use the app from your web browser.
Next you will set up an EC2 instance to automatically start the MiniTwit application when the
instance launches, so that you don’t need to SSH in and run it manually. Then you will
configure Elastic Load Balancing (ELB) to distribute user (browser) connections between
multiple MiniTwit servers, and configure Auto Scaling to scale the number of MiniTwit servers
out and in, depending on the load (i.e., how many browser requests are hitting them each
second).
Also, here are a few top-level documentation pages that you may use now and in future
projects too.
Part 1: Setting up EC2
In this part, you will create a single EC2 instance and run a simple web application on it using
the Flask framework for Python. Before you start, you will need your AWS account fully set up,
per the instructions that were emailed to you.
First, log in to AWS and go to the EC2 service. (You can use the AWS search bar, or expand “All
Services” and find EC2 in the Compute section.) If you’re in the right place, you should see a
toolbar on the left with options like Instances, AMIs, Volumes, Security Groups, etc. The first
thing you need to do is make sure you’re connecting to the correct Region (i.e., the correct data
center – Amazon has several datacenters worldwide for running AWS services). On the upper
right, between your account name and “Support” it should say the name of a location (e.g.,
Oregon, Ohio, N. Virginia, etc.). If it does not say Oregon, then click on it and choose the option
“US West (Oregon)” from the drop down. It should now say Oregon, and you will be using the
Oregon Region (data center) from now on. (You shouldn’t need to do this ever again, unless
you change it, but it’s always a good idea to double check each time you log in.)
Create a Key Pair
The next thing you need to do is go to the “Key Paris” section (under the NETWORK & SECURITY
heading). You should see a button at the top of the main pane called “Create Key Pair” – click on
this. You will be prompted to give it a name – name it whatever you think makes sense. (It won’t
matter much, since you’ll probably only have one key pair for now.) Your browser will then
prompt you to download a file with a .pem extension – this file contains your private key, which
you will use to SSH to your EC2 instances. Save your .pem file somewhere safe – if you lose it,
you cannot recover it! Should you lose your .pem file, your key pair will become useless; you
will need to create a new key pair then, save the new .pem file, and associate all your EC2
instances with the new key pair.
You will need to be sure the permissions are set correctly on your .pem file – if not, SSH may
refuse to connect! On Linux or MacOS, open a command prompt and change to the directory
containing your .pem file. Then set the permissions to read-only for the file owner with this
command:
chmod 400 <pem key file>
Configure a Security Group
Finally, configure a default Security Group. This is basically a firewall, which restricts what kind
of network traffic from which hosts (machines on the network) is allowed to reach your EC2
instances. Click on “Security Groups” (under the NETWORK & SECURITY heading). There should
be one security group already there with a name along the lines of “default”. Select that
security group. In the details section below the list of security groups, you will see
“Description”, “Inbound”, “Outbound”, etc. Click on the “Outbound” tab. It should say
something like “All traffic – All – All – 0.0.0.0/0”, which basically means instances using this
security group can send any network traffic to anywhere. This is fine; what they’re allowed to
receive is the real security concern, so now click on “Inbound”. You should see a rule that says
it will accept all traffic of all types incoming from a particular Security Group ID, and that ID
happens to be the ID of this group – in other words, instances in this security group can send
anything to other instances in the same security group. We’ll need to add a couple things to let
us reach these instances from outside the cloud, though. Click on the Edit button, and then use
the Add Rule button to add the following incoming rules:
SSH – TCP – 22 – Custom – 66.194.72.0/24
a. this allows SSH to your instances from campus computers, such as cs1.seattleu.edu
b. the “Description” field is optional, but you may want to enter something to remind
yourself of what this rule is for when you look at it again weeks or months later
SSH – TCP – 22 – My IP
c. choosing “My IP” instead of “Custom” will automatically fill in your current IP
d. this allows SSH to your instances from the computer you are currently using – this
may be redundant if you are on campus, but setting this up with your home IP
address may be convenient for working from home
e. Note: if you change to a different computer, this does not follow you! so make sure
you’re on the computer you want to use for your work when you set up this rule.
Custom TCP Rule – TCP – 5000 – 0.0.0.0/0
f. this allows connecting to your instances from anywhere on port 5000, which we will
use instead of the default HTTP port 80 in order to keep our service a little more
private (although not really because anyone can easily find port 5000 by trial-and-
error) – in effect, the service on port 5000 will be publicly accessible!
Now that all that’s done, you probably won’t need to mess with it any more. (Maybe
occasionally, but not frequently… e.g., if you want to update the “My IP” rule for a new
location…)
Part 2: Launching an EC2 Instance
Now that everything’s set up, let’s launch an EC2 instance and run a web service. Click on
“Instances” (under the INSTANCES section), then click on the “Launch Instance” button. Now
you will have to choose which AMI (disk image) to use for your EC2 instance’s virtual hard drive.
On the left are several categories – choose the “My AMIs” category, then check the “Shared
with me” option.
You should see an image called “Flask Base” (possibly with a version number, like “Flask Base
v1.3”). If you do not see this AMI listed, please contact the instructor.