By: Laureline David & Michael Rohrer

• Gain experience with an Infrastructure-as-a-Service offering
• Create a service from scratch using virtual machines
• Assess the performance of a virtual machine

In this lab you will perform a number of tasks and document your progress in a lab report. Each task specifies one or more deliverables to be produced. Collect all the deliverables in your lab report. Give the lab report a structure that mimics the structure of this document.

AWS Regions Available (closest in bold):

• US East (N. Virginia)
• US East (Ohio)
• US West (N. California)
• US West (Oregon)
• Canada (Central)
• EU (Ireland)
• EU (Frankfurt)
• EU (London)
• Asia Pacific (Singapore)
• Asia Pacific (Sydney)
• Asia Pacific (Seoul)
• Asia Pacific (Tokyo)
• Asia Pacific (Mumbai)
• South America (São Paulo)

ec2-35-157-96-150.eu-central-1.compute.amazonaws.com

ubuntu@ip-172-31-14-128:~$ hostname
ip-172-31-14-128
ubuntu@ip-172-31-14-128:~$ uname -a
Linux ip-172-31-14-128 4.4.0-64-generic #85-Ubuntu SMP Mon Feb 20 11:50:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

We cannot ping the remote host since the security group does not allow ICMP traffic through.

We can modify the security group to allow ICMP traffic through from the outside.

$> ping -c 5 ec2-35-157-96-150.eu-central-1.compute.amazonaws.com
PING ec2-35-157-96-150.eu-central-1.compute.amazonaws.com (35.157.96.150) 56(84) bytes of data.
64 bytes from ec2-35-157-96-150.eu-central-1.compute.amazonaws.com (35.157.96.150): icmp_seq=1 ttl=46 time=25.7 ms
64 bytes from ec2-35-157-96-150.eu-central-1.compute.amazonaws.com (35.157.96.150): icmp_seq=2 ttl=46 time=25.9 ms
64 bytes from ec2-35-157-96-150.eu-central-1.compute.amazonaws.com (35.157.96.150): icmp_seq=3 ttl=46 time=28.9 ms
64 bytes from ec2-35-157-96-150.eu-central-1.compute.amazonaws.com (35.157.96.150): icmp_seq=4 ttl=46 time=25.5 ms
64 bytes from ec2-35-157-96-150.eu-central-1.compute.amazonaws.com (35.157.96.150): icmp_seq=5 ttl=46 time=25.7 ms

--- ec2-35-157-96-150.eu-central-1.compute.amazonaws.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 25.558/26.405/28.958/1.286 ms

ubuntu@ip-172-31-14-128:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 02:ae:76:ea:cc:27  
          inet addr:172.31.14.128  Bcast:172.31.15.255  Mask:255.255.240.0
          inet6 addr: fe80::ae:76ff:feea:cc27/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1
          RX packets:310 errors:0 dropped:0 overruns:0 frame:0
          TX packets:344 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:41911 (41.9 KB)  TX bytes:37675 (37.6 KB)

We can see that the network interface's IP address is not the public address shown in the AWS console. This is because instances are launched inside a VPC (Virtual Private Cloud) and uses a gateway to access the outside world. The gateway maps the public IP to the private IP and enforces security rules.

Elastic IP: 35.157.81.210

Why is it a good idea to create an Elastic IP Address for a web site (our web application)?

It is prefereable to use EIPs to manage public instances since they do not refresh every time an instance is powered up (including reboots). It also makes the usage of Route 53 easier.

Why is it not sufficient to hand out as URL for the web site the public DNS name of the instance?

An instance's public DNS record is linked to its public IP which, as mentioned before, can change unless the instance is associated to an EIP. An optimal solution would be to combine an EIP and usage of the Route 53 service to provide DNS resolution.

Instances are billed by the hour, partial hours count as one full hour.

The instance was up for 2 hours and cost $0.11

At 730hrs per month, the instance would cost $39.42