· Logically isolated AWS resource
· Can be securely integrated with internal systems via a VPN
· AWS is now defaulting to using VPC for EC2 instances
o Older accounts can still launch into "EC2 classic"
Ø Ability to simulate a private cloud within the public AWS infrastructure
o Utilize AWS resources in an isolated virtual network
o Provides complete control of the virtual network
§ IP address range, subnets, route tables, gateways, access control, etc.
§ Can control both inbound and outbound network traffic
Ø No costs for using a VPC
o Just pay for resources used
o There is additional hourly charge for a VPN connection
Ø As discussed earlier, EC2 is now requiring all instances in a VPC
Ø Additionally, you can create a Hardware Virtual Private Network (VPN) connection between your corporate datacenter and your VPC and leverage the AWS cloud as an extension of your corporate datacenter.
Ø Can specify hardware tenancy
o Default is multitenant
§ Hardware is potentially shared with many customers
o Dedicated
§ Hardware is dedicated for instances running in your VPC
§ Additional fees apply
o Host
§ Your instance runs on a Dedicated Host, which is an isolated server with configurations that you can control.
Ø You cannot change the tenancy of a default instance after you've launched it. You can change the tenancy of an instance from dedicated to host after you've launched it, and vice versa.
· Launch instances into a subnet of your choosing
· Assign custom IP address ranges in each subnet
· Configure route tables between subnets
· Create internet gateways and attach them to subnets (or not)
· Much better security control over your AWS resources
· Instance security groups
· Subnet network access control lists (ACLS)
· Default VPC is user friendly, allowing you to immediately deploy instances.
· All subnet in default VPC have an internet gateway attached.
· Each EC2 instance has both a public and private IP address.
· If you delete the default VPC the only way to get it back is to contact AWS.
· Allows you to connect one VPC with another via a direct network route using private IP addresses.
· Instances behave as if they were on the same private network
· You can peer PVC’s with other AWS accounts as well as with other VPCs in the same account.
· Peering is in a star configuration, i.e. 1 Central VPC peers with 4 other. No Transitive Peering!!!
VPC Peering is simply a connection between two VPCs that enables you to route traffic between them using private IP addresses. Instances in either VPC can communicate with each other as if they within the same network. You can create a VPC peering connection between your own VPCs, or with a VPC in another AWS account within a single region.
AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separated piece of physical hardware. There is no single point of failure for communication or a bandwidth bottleneck.
· You cannot create a VPC peering connection between VPCs that have matching or overlapping CIDR blocks.
· You cannot create a VPC peering connection between VPCs in different regions.
· VPC peering does not support transitive peering relationship.
Ø Used for servers that need to be accessed over the public Internet
o Least private option
o We have already used this during the class
Ø Used when some servers need to be accessed over the Internet while other servers need to be kept private
o Servers on the public subnet can be accessed from the Internet
o Servers on the private subnet cannot be accessed from Internet
§ If needed, servers on private subnet can connect outbound to the Internet on the public subnet using Network Address Translation (NAT)
Ø Used when some servers need to be accessed over the Internet while other servers need to be kept private
o Servers on the public subnet can be accessed from the Internet
o Servers on the private subnet can only be accessed over a hardware VPN connection
o Used to extend your private data center into the cloud
o Hardware VPN connection will make the VPC servers appear to be on your local private network
Ø Used to extend your private data center into the cloud
o Can only access VPC resources from behind your private VPN firewall
o Most private option
§ A hosted private cloud
Ø VPC with a single public subnet only
o Public-facing website
Ø VPC with public and private subnets
o Multitiered public-facing website
§ Web server in the publicly accessible subnet
§ Database and application servers in private subnet
Ø VPC with public and private subnets and hardware VPN access
o Web applications that require access to your internal data center
§ Public-facing web server running in AWS requires ability to access resources within your data center
Ø VPC with a private subnet only and hardware VPN access
o Seamlessly extend your data center to gain capacity required
o Can use for disaster recovery
§ Utilize VPC to host redundant systems and data
§ A fraction of the cost of traditional disaster-recovery options
1. Create VPC
Log in to the AWS console.
Navigate to Services->VPC->Your VPCs.
Click “Create VPC”.
When you create a VPC, you specify a set of IP addresses in the form of a Classless Inter-Domain Routing (CIDR) block (for example, 10.0.0.0/16). For more information about CIDR notation and what "/16" means, see
Classless Inter-Domain Routing.
You can assign a single CIDR block to a VPC. The allowed block size is between a /28 netmask and /16 netmask. In other words, the VPC can contain from 16 to 65,536 IP addresses.
You cannot change a VPC’s size after creating it. If your VPC is too small for your needs, you’ll need to terminate all of the instances in the VPC, delete it, and then create a new, larger VPC.
To create your VPC, go to the Create VPC dialog box, specify the following VPC details and then click “Yes, Create”.
CIDR Block: Specify the CIDR block for your VPC. I prefer 10.0.0.0/16.
Tenancy: Default tenancy: This is for running instances on shared hardware and is free of charge.
Dedicated Tenancy: This is for running your instances on single-tenant hardware. A $2 fee applies for each hour in which any dedicated instance is running in a region.
In the navigation pane click on “Subnets”.
Click “Create Subnet”.
Before we create a subnet, let’s understand the best practices for creating them.
You should create subnets across multiple availability zones, with each subnet residing within a single zone. Creating subnets in and launching instances across multiple availability zones will ensure a high-availability environment.
For this example, we created subnets using zones us-east1a, user-east1b and us-east-1c. These subnets are called “private subnets” because the instances we launch are not accessible from the Internet. In other words, these instances don’t have a public IP unless you assign an EIP.
EC2: 10.0.1.0/24 (us-east1a), 10.0.2.0/24 (us-east1b), 10.0.3.0/24 (us-east1c)
By default, instances that are launched into a VPC can't communicate with the Internet. However, you can enable Internet access by attaching an Internet gateway to the VPC.
Go to Internet Gateways in the navigation pane and click “Create Internet Gateway”.
Now attach the gateway to a VPC by right clicking on “VPC” and selecting “Attach to VPC”. We should have one Internet Gateway per VPC.
A route table contains a set of rules, called routes that determine where network traffic is directed.
Each subnet in your VPC must be associated with a route table that will control that subnet’s routing. You can associate multiple subnets with a single route table; however, you can only associate a subnet with one route table.
Creating a VPC automatically creates a main route table which, by default, enables the instances in your VPC to communicate with one other.
Go to Route Tables in the navigation pane and click on “Create Route Table”.
Do not associate any subnets with the main route table.
Now navigate to the main route table to add a route to allow Internet traffic to the VPC.
Go to Routes and specify the following values:
Destination: 0.0.0.0/0
Target: Select “Internet Gateway” from the dropdown menu.
As a best practice create separate route tables for each tier. This will provide more control in maintaining the security of each subnet.
Now associate the subnets to the route tables.
Click on one route table and go to the Associations tab.
Select the subnet and click “Associate”.
Here we had associate Subnet 10.0.1.0/24 as internet facing.
So Subnet 10.0.1.0/24 will be our webserver which will have internet facing.
Subnet 10.0.2.0.24 will be our Database server which will not have internet connectivity.
We will create an EC2 instance in each subnet.
Creating EC2 instance for webserver in subnet 10.0.1.0/24
Step1: Choose an Amazon Machine Image(AMI) (Amazon Linux AMI 2016.03.3 (HVM), SSD Volume Type)
Step2: Choose an Instance Type (General Purpose t2 micro)
Step3: Configure Instance Details
Step4: Add Storage
Step5: Tag Instance (MyWebServer)
Step6: Configure Security Group
Create a new Security Group.
Step7: Review Instance Launch
Step8: Create an new key pair & Launch Instance.
Creating EC2 instance for Database Server in subnet 10.0.2.0/24
Step1: Choose an Amazon Machine Image(AMI) (Amazon Linux AMI 2016.03.3 (HVM), SSD Volume Type)
Step2: Choose an Instance Type (General Purpose t2 micro)
Step3: Configure Instance Details
Step4: Add Storage
Step5: Tag Instance (MyDBServer)
Step6: Configure Security Group
Select an existing SG MyVPCSG
Step7: Review Instance Launch
Step8: Create an new key pair & Launch Instance.
Now we could see that MyWebServer got PublicIP & MyDBserver do not have Public IP address. Now to test our setup, we will connect with putty to both the host, and try to check whether internet is working on which server.
I tried to connect to the host MyWebserver using Putty, and found that Internet is working on the host.
[root@ip-10-0-1-13 ~]# ping google.com
PING google.com (172.217.5.14) 56(84) bytes of data.
64 bytes from lga15s49-in-f14.1e100.net (172.217.5.14): icmp_seq=1 ttl=47 time=7.79 ms
64 bytes from lga15s49-in-f14.1e100.net (172.217.5.14): icmp_seq=2 ttl=47 time=7.89 ms
64 bytes from lga15s49-in-f14.1e100.net (172.217.5.14): icmp_seq=3 ttl=47 time=7.91 ms
^C
--- google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 7.794/7.865/7.911/0.088 ms
[root@ip-10-0-1-13 ~]#
Now we will try to connect MyDB Server.
We are connecting to MyDBServer with Private IP address, as it has not having Public IP address
[root@ip-10-0-1-13 ~]# vi mynewkeypair.pem
[root@ip-10-0-1-13 ~]# chmod 600 mynewkeypair.pem
[root@ip-10-0-1-13 ~]# ssh ec2-user@10.0.2.181 -i mynewkeypair.pem
We could see that internet is not working on this server.
[ec2-user@ip-10-0-2-181 ~]$ ping google.com
PING google.com (172.217.1.78) 56(84) bytes of data.
^C
--- google.com ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7055ms
