AWS VPC
Last updated
Last updated
Virtual Private Cloud or VPC is an isolated virtual network within the AWS Infrastructure. It is similar to Internet side and Intranet side of an organization's own on-premises data center. Hence, just like any traditional network, VPC supports the following:
IPv4 and IPv6 addresses
NAT
Can be connected to new or existing VPCs
Can be connected to on-prem network with the help of VPN
Also note that, VPCs can be designed to be equally scalable to accommodate more resources.
Now, let's see some technicality of the VPCs. The fundamental blocks of VPCs can consist of the following:
Subnets of a particular CIDR block.
Implied Router implementing the route table. Route Tables controls the flow of traffic in, out and within a VPC.
Internet Gateway (IGW) providing path to and from the Internet for instances with public IP.
NAT Gateway (NGW) [Public NGW for providing egress only path for instances with no public IP, to reach the internet i.e., internet devices cannot connect back to the source instance and Private NGW for communication with instances in other VPCs]
Egress-only Internet Gateway which supports only IPv6 internet traffic.
Virtual Private Gateway (VGW) for providing termination point in a VPC for a VPN Connection or AWS Direct Connect.
Note: One can also use NAT instances available as part of Community AMIs as shown below instead of NAT Gateways, simply because they are cheaper:
Now, let's use all the above concepts to see practical implementation:
Step 1: Create a VPC with CIDR Block:
Step 2: Create Subnets from the CIDR block of the VPC:
Step 3: Associating the Subnet with VPC Route Table
Step 4: Creating Internet Gateway and making changes in route table for Internet Traffic.
Now, to put an instance such as a web server in the pub-net range, it is required to follow the steps of setting up an EC2 given here.
Consider the scenario that there is a VPC, which has a subnet consisting of two EC2 instances with no Public IP Attached to them and the use case is to only provide outgoing traffic. The architecture might look like this:
Well the above network architecture will fail miserably, because of following reasons:
Internet Gateway is still required to sort of provide the path for the NAT Gateway Public IP to connect with Internet. This can be seen in solution point 2 as mentioned in AWS Docs (https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-troubleshooting.html#nat-gateway-troubleshooting-no-internet-connection).
Hence, the correct Network architecture can be as shown below:
Step 1: To construct the above diagram, one can first create two instances with no Public IPv4 addresses in private subnet:
Step 2: Create NAT GW in public subnet
Step 3: Edit the route table of a private subnet
Step 4: Similarly, add the route of Internet Gateway to a public subnet
What is VPC Endpoints?
These are basically endpoints that allows to connect AWS services that are completely private and not exposed to the Internet for direct communication or Access.
How VPC Endpoint can be created?
To connect with instances with only private IP Addresses, one requires a way to connect with them. This can be done with the help of EC2 serial console if the instance supports it or one can go with VPC Endpoint of type EC2 instance connect; the latter is shown below:
Now, let's connect with EC2 instances
Step 5: Post connecting to one of the instances in the private subnet, one can simply check outgoing traffic as shown below:
For communication between instances in two separate VPCs, one can use AWS VPC Peering connection. For the below peering connection to work, the route table of the two VPCs also needs to be edited to have a route in their respective route tables, such that when traffic to vpc-a is required to go from vpc-b, then vpc-b route table must have a route of source as ip range of vpc-a and target as peering connection.
Note that for Site (On-Prem) to VPC connection, apart from AWS Direct Connect, one can use a Transit VPC. Transit VPC is like a common hub or gateway to AWS Cloud VPCs. Various Site to Site VPNs can terminate at Transit VPCs and this Transit VPC would have access to other VPCs, where necessary workloads are there. This effectively reduces the no. of connections as shown below:
Before Transit VPC:
After Transit VPC:
One thing that must be noted that for the transit VPC to be implemented, following are the steps:
Create (Instantiate) a Virtual router with elastic N/W Interface & elastic IP and place it in transit VPC.
Create a Customer Gateway (just an object like representation of the physical or virtual router device) representing Office A Router, Office B Router and Virtual Router in Transit VPC.
Create a Virtual Private Gateway in VPC A, VPC B & VPC C in order to further create a Site to Site VPN between that of virtual private gateways and virtual routers.
Similarly, have a site to site connection between physical router of Office A & Office B with that virtual router for dynamic propagation of routes via BGP.
Also note down that if two physical sites need to have a site to site VPN, then using concept of CloudHub in AWS, they can be joined. Implementation is similar to above transit VPC process, i.e. creating customer gateways object of routers of the two offices. Creating Virtual Private Gateway, which would be having VPN connection with both the customer gateways and lastly route propagation.
