Lab 2: Networking in the cloud Overview: As with any virtual environment networking is one of the most important aspects that must be addressed. Amazon’s Web Services gives you enough networking options to meet almost any need that could be done in a physical environment. In this lab you will learn about: · Public IP Addresses · Private IP Addresses · Elastic IP Addresses · Virtual Private Clouds · Internet gateways · Amazon DNS & DHCP Public IP, Private IP and Elastic IP Addresses Public IP addresses are addresses that can be reached from anywhere on the Internet. These workas regular IP address that routable on the internet. When you launch an instance into EC2 your instance is automatically given a Public IP and a Private IP address. The private IP address works for Amazon’s internal networks and allows you to send traffic between your instances without having to route it through the public internet. This is important from a cost perspective because all internal traffic is free of charge. During this class you will not find it terribly important to limit the amount of external traffic but in a real world scenario the charges can quickly add up. Public and private IP addresses are only assigned through DHCP which means that the addresses are not static. Every time you stop and start the instance the address will change. Using these default settings gives you very limited functionality for your instances. Elastic IP addresses work a lot like public static addresses in that they are addresses that are given to your account that can be attached to any instance and it won’t change unlike your other IP addresses. If you want to run a temporary web server this would be an important option. Because the server is always up and you need to access it with a consistent address, you would attach an elastic IP to reach the server. What’s best about elastic IP addresses is that they can be moved from one instance to another and the address stays the same. There is no charge for elastic IP addresses unless you have some that are not assigned to an instance. In this case amazon will charge the account a small fee for every hour that the IP address is free. If you are no longer in need of an elastic IP address remove it. Note: When you stop an instance that is associated with an elastic IP address, the address will disassociate itself upon shutdown Pinging Externally and internally 1. First launch two micro Linux instances like you did for Lab 1. Make sure they are both in the same security group. 2. Name one MachineA and the other MachineB. 3. Connect to MachineA via SSH 4. Looking at your instances from the Instance Library, select Machine A and scroll down to the DNS information. 5. Looking at the Public DNS you can see the public IP address for your instance. The address is the sequence of numbers between ec2 and .compute-X.amazonaws.com. In the screenshot above it is 50.16.55.68. This is the address that can be used to communica ...

1. Lab 2:
Networking in the cloud
Overview:
As with any virtual environment networking is one of the most
important aspects that must be addressed. Amazon’s Web
Services gives you enough networking options to meet almost
any need that could be done in a physical environment.
In this lab you will learn about:
· Public IP Addresses
· Private IP Addresses
· Elastic IP Addresses
· Virtual Private Clouds
· Internet gateways
· Amazon DNS & DHCP
Public IP, Private IP and Elastic IP Addresses
Public IP addresses are addresses that can be reached from
anywhere on the Internet. These workas regular IP address that
routable on the internet. When you launch an instance into EC2
your instance is automatically given a Public IP and a Private IP
address. The private IP address works for Amazon’s internal
networks and allows you to send traffic between your instances

2. without having to route it through the public internet. This is
important from a cost perspective because all internal traffic is
free of charge. During this class you will not find it terribly
important to limit the amount of external traffic but in a real
world scenario the charges can quickly add up.
Public and private IP addresses are only assigned through
DHCP which means that the addresses are not static. Every time
you stop and start the instance the address will change. Using
these default settings gives you very limited functionality for
your instances.
Elastic IP addresses work a lot like public static addresses in
that they are addresses that are given to your account that can
be attached to any instance and it won’t change unlike your
other IP addresses. If you want to run a temporary web server
this would be an important option. Because the server is always
up and you need to access it with a consistent address, you
would attach an elastic IP to reach the server. What’s best about
elastic IP addresses is that they can be moved from one instance
to another and the address stays the same.
There is no charge for elastic IP addresses unless you have
some that are not assigned to an instance. In this case amazon
will charge the account a small fee for every hour that the IP
address is free. If you are no longer in need of an elastic IP
address remove it.
Note: When you stop an instance that is associated with an
elastic IP address, the address will disassociate itself upon
shutdown
Pinging Externally and internally
1. First launch two micro Linux instances like you did for Lab
1. Make sure they are both in the same security group.
2. Name one MachineA and the other MachineB.
3. Connect to MachineA via SSH

3. 4. Looking at your instances from the Instance Library, select
Machine A and scroll down to the DNS information.
5. Looking at the Public DNS you can see the public IP address
for your instance. The address is the sequence of numbers
between ec2 and .compute-X.amazonaws.com. In the screenshot
above it is 50.16.55.68. This is the address that can be used to
communicate with the machine from the public Internet. The
Private IP address, 10.28.133.227, is the address that can only
be reached by internal Amazon instances.
6. Before we can actually issue a ping command we need to
allow for that type of traffic. Remember in Lab 1 you set your
security group (firewall) to only allow SSH traffic.
7. Go to Security groups and select the security group you
selected in Lab 1
8. Add 2 new rules. Both are Custom ICMP rules: one for Echo
Replies, and one for Echo Requests
Make sure to apply the changes!
9. Now that the rules have been implemented, you should be
able to ping from MachineA to MachineB, from your personal
computer to MachineA and MachineB, and you should still be
able to ping from MachineA to any external
addressDeliverables:
· Screenshots of the three ping scenarios as described in Step 9
· Implement your own Firewall Rule that will only allow for
internal IP addresses to be able to ping machines
Implement An elastic IP address
1. From the navigation menu on the left, go to Elastic IPs
From this screen you’ll see a list of all Elastic IPs for the
account. If the Address is associated with an instance, the
Instance ID field will have a value. Use the Address that is
assigned to you or your group.

4. 2. Select an address and go to Associate Address on the top
menu bar
3. A new pop up will appear and will ask you to select your
instance. If your instance doesn’t have a name you will have to
navigate back to get the instance ID.
4. Once your address has been associated the fields will be
populated
Deliverables:
· Screenshot of your newly associated address
· Screenshot of a ping sent from your local machine to the new
Elastic IP
· Screenshot of you logging in to the instance using the elastic
IPVirtual Private Clouds
While the IP addresses that we’ve talked about up to this point
may work for some situations, they are not long term solutions
for production environments. This is where Virtual Private
Clouds come in. Virtual Private Clouds is a service that lets you
set up a virtual network topology so that you can customize it
with subnets and your own routing. This gives you more
flexibility on which instances are publicly reachable - such as
webserver - and which should only be accessed internally – like
a database server.
There are a number of ways that a VPC can be setup
The first two options is what we’ll be concerned with in this
class, more specifically the first for now. This option will allow
us to create a network topology that will still be able to access
the Internet and other Amazon services. For future projects you
may want to practice and implement using a VPC with Public
and Private Subnets.
The later two options are best used for corporations. VPN
allows for more secure connection to the Amazon instances and
is another layer of security that some organizations may be

5. concerned with. For example if you are an organization that
hosts proprietary information on Amazon and don’t want anyone
capturing your data as it is transmitted, a VPN tunnel may be
one of the technologies that you will leverage to provide added
security. However, since we are not going to be using any VPN
tools this is out of the scope of the class.
When creating a VPC using the VPC Wizard, the system will
create all the necessary component to get the topology that you
want. In reality it sets up several parts for you:
· Virtual Private Cloud – This is the actual network setup that
has the CIDR notation and determines how many hosts your
VPC will be able to handle
· Subnets – You can create more than one subnet for your VPC.
This is how you would be able to create a private subnet that
would not be immediately accessible from the outside
· Internet Gateway – If the topology that you setup is supposed
to be accessible through the public Internet then an Internet
Gateway is what it will use to communicate with everything
outside of the VPC
· Route Tables – Think of these as the rules that you would
apply in a router. This is what is going to be controlling the
traffic that is generated from your topology. You can set certain
kinds of requests to only go to a certain machine. For example
any HTTP 80 requests should only be directed to your web
server. When you first create a VPC, the system will create two
route tables one will be marked as main and the other one will
not. The main route table is what your VPC will first try to use
when traffic is trying to find its way. This route table says that
anything with a certain address range (what you identified as in
your CIDR notation) should be handled as local traffic. So if
one of your instances is trying to communicate with another
instance within the VPC the main route table will identify that
it is local communication and will route it to the proper place.
However, if the traffic is determined not to be local then it will
go to your second route table that says “redirect everything else
that is not local traffic (0.0.0.0/0 - anything) to the Internet

6. gateway”.
· DHCP Option Sets – These let you identify the name of your
domain, domain servers, ntp servers, netbios-name-servers, and
netbios-node-type. When a computer is added to your VPC the
first thing it will do is talk to the DHCP service to know what
information it will get from what machine. DHCP is what
automatically assigns IP addresses to machines when they first
join the network.
Using a VPC
For the following part of the lab you are going to replicate the
following setup:
You are going to launch 3 machines into a VPC. 2 will be
Ubuntu machines and one will be a Windows 2008 Server. One
of your Ubuntu machines will be running an NTP (Network
Time Protocol) server, one will be a regular machine, and your
Windows 2008 Server will have a service of your choice. The
purpose of this Lab is to utilize a VPC to launch an internal
network with modified DHCP options that point to your NTP
server and provide the same time to your 2 other machines.
1. Log on to the Amazon Web Services Console and Navigate to
VPC from the top navigation bar.
The VPC Dashboard page gives you a summary of all the VPC
services that you have deployed.
2. Go to Your VPCs and select the VPC ID that was assigned to
you. On a piece of paper write down your VPC ID, DHCP-
option set, and main route table.
3. On the left navigation bar, go to Subnets
4. Find the subnet that is assigned to your VPC by matching up
your VPC ID. Write down your subnet ID.These are important
for when you’re going to launch your instances. You need to
know your subnet ID and your VPC ID. Later you’ll also use

7. your DHCP ID to edit your DHCP options.
5. Navigate back to EC2 (Top Navigation Bar > EC2) and
Launch a new Instance.
6. You’re going to launch 2 smallUbuntu 12.04 servers into the
subnet that corresponds to your VPC (this is where writing
down the number helps). Make sure the instances are small not
micro. Micro instances cannot be launched inside of VPCs.
7. When you get to the Firewall page you will have to create a
new security group. Security Groups for VPCs are different than
previous ones we’ve used and so a new group has to be created.
Create the rules that we will need for this lab to work. We will
definitely need RDP, SSH, and NTP (UDP port 123)
8. Launch a Windows 2008 Server into the same VPC
9. Because all of these instances are within a VPC you will not
see a public DNS. You need to associate an Elastic IP address to
the machines that you will be connecting to. You can use 2 or 3
elastic IPs. In reality you can also just use 1 and move it from
instance to instance as you need to.
10. Using the Elastic IP address, SSH into the machine that will
be running your NTP server. Google search instructions on how
to install and configure an NTP server. When modifying the
configuration file add the following 3 servers
a. nist1-ny.ustiming.org
b. nist1-ny.ustiming.org
c. nist1-pa.ustiming.org
Make sure you are installing ntpd NOT ntpdate
11. Once you have installed and configured the NTP server
correctly issue the following command: sudo ntpq –c lpeer
The command should give you something like this:
12. Once the NTP server is setup, go back to VPC area and click
on DHCP Option Sets in the left navigation bar.
13. Create a new DHCP Option Set

8. 14. In the new pop up you are only going to fill out two fields:
a. Domain Name server: AmazonProvidedDNS
b. NTP Server: [IP address of your Ubuntu instance running
NTP server]
15. Now apply this to your VPC by going to Your VPCs on the
left navigation, selecting your VPC and clicking Change Your
DHCP Options Set and select the set you just created
16. Now log in to your other Ubuntu Instance and point the
ntpdate address to your NTP server. (you can Google search
this)
17. Logging into your Windows machine also point the time
update to your NTP server
18. Now add one more service to any of your machines and
include a screenshot. This could be DNS, Active Directory,
Webserver, etc..Deliverables:
· Include a screenshot for the following steps: 10, 11, 14, 16,
17, & 18