Virtual Private Cloud – Segmentation, Subnets and Gateways

Virtual Private Cloud (VPC) is one of the (essential) services from AWS that offers cloud users the ability to create isolated instances of virtual data centers. Any EC2 instances created in the AWS will require to be part of a VPC for internal and external connectivity. AWS VPC can be customized by segmenting the VPC into multiple subnets based on the business requirement and leverage the route-table and different gateways to control the communications from/to each subnet. 

VPC with Internet and NAT Gateway

Let us discuss the concept further with an example shown below:

In the above example, we created two different types of VPC for different customers catering different business requirements. For example, NyaCorp requires the below:

• REQ1 --> Any workloads in public-subnet can communicate with all other workloads in the VPC and also can be reached from the Internet.
• REQ2  Any workloads in private1 subnet can communicate only with other workloads in the VPC but not with Internet.
• REQ3  Any workload in provate2 subnet can communicate with other workloads in the VPC and can trigger outbound session to the Internet but not inbound.

Accordingly, A new VPC named Nyacorp-vpc is created with a CIDR block of 172.16.0.0/16 assigned and an Internet gateway named Nyacorp-igw. As part of this new VPC, 3 subnets were created in 1 availability zones (us-east-1a) from us-east region. 

• The subnet to cater REQ1 named as Nyacorp-subnet-public1-us-east-1a is created in us-east-1a availability zone. 
• The subnet to cater REQ2 named as Nyacorp-subnet-private1-us-east-1a is created in us-east-1a availability zone
• The subnet to cater REQ3 named as Nyacorp-subnet-private2-us-east-1a is created in us-east-1a availability zone.

Each such created subnet will have its own dedicated route table with a list of routes to steer the traffic accordingly. 

• Nyacorp-subnet-public1-us-east-1a is created as a public subnet and so the route-table will have the CIDR entry 172.16.0.0/16 with target as local and a default route with a target as the internet gateway.
• Nyacorp-subnet-private1-us-east-1a is created as a private subnet and so the route table will only have a CIDR entry 172.16.0.0/16 with target as local.
• Nyacorp-subnet-private2-us-east-1a is also created as a private subnet and so the route table will only have a CIDR entry 172.16.0.0/16 with target as local.

It could be noted that both Nyacorp-subnet-private1-us-east-1a and Nyacorp-subnet-private2-us-east-1a don’t have any connectivity to the Internet gateway. While this is expected for Nyacorp-subnet-private1-us-east-1a, we need an outbound triggered internet connection from Nyacorp-subnet-private2-us-east-1a.

To address the need of Nyacorp-subnet-private2-us-east-1a, we create a NAT gateway named Nyacorp-nat-gw with a connection to the internet gateway and associate the NAT gateway to Nyacorp-subnet-private2-us-east-1a. Now, the route table of Nyacorp-subnet-private2-us-east-1a is populated with a default entry towards the NAT gateway.

The resource map of the above scenarios is represented below:

It could be noted that each subnet have its own route table where the one associated to public subnet is connected to Internet gateway, the other route table associated to private2 is connected to the NAT gateway and the 3rd route table associated to private1 doesn’t have connectivity to both Internet gateway or the NAT gateway.

VPC with VPN Gateway

Let’s now take another customer RaasaCorp who would like to have all the VPC traffic (including internet) to be steered towards the corporate Datacenter. 

In this case, a VPC is created with no Internet gateway or NAT gateway. Instead, a VPN gateway is created and associated to the VPC. This VPN gateway is used to establish secure VPN tunnel to the corporate datacenter. 

A default route is created in the route table towards the VPN gateway to steer all the traffic towards the datacenter over the secure VPN tunnel.

VPC Configuration using AWS Portal and Terraform

 

Virtual Private Cloud (VPC) is one of the (essential) services from AWS that offers cloud users the ability to create isolated instances of virtual data centers. VPC offers complete control over the cloud networking for the instances created in the AWS cloud. It allows us to create multiple subnets for micro segmenting the virtual instances in different subnets and leverage the network ACL and Security Groups to control inter-subnet communication. It also offers internet connectivity to the instances created in the AWS cloud. 

By default, each AWS region will be created with a “Default” VPC that cannot be deleted. Any VPC has region-wide scope with a default CIDR of 172.31.0.0/16. Any VPC can be configured with one or more subnets from the CIDR block where each subnet is local to the Availability Zone (AZ) within the AWS region. 

We can custom configure our own VPC to cater the business need. It involves the basic four steps as shown below:

• Create a VPC in the relevant AWS region and assign the name.
• Configure one or more subnets for each AZ within the AWS region.
• Configure one or more route-table
• Configure the Internet Gateway.

This article explains how to configure VPC using both the AWS portal and terraform configuration. 

VPC Configuration using AWS Portal

The user is expected to have AWS account created and logged into the portal to create the VPC. Below is the configuration procedure depicted while creating the VPC from the AWS portal:

A graphical representation of the VPC creation flow is shown in the portal as below:

VPC Configuration using Terraform

The basic terraform configuration involves the below:

• Create terraform variable listing one or more Availability Zones with a type string
• Create terraform variable listing one or more subnets with a type string
• Create aws_vpc resource to configure the VPC
• Create aws_subnet resource to configure the subnets in each AZs within the region.

The same configuration is as below:

resource aws_vpc "nyacorp-new" {

cidr_block = "172.16.0.0/16"

instance_tenancy = "default"

tags = {

Name = "NyaCorp-VPC"

}

}

variable "availability_zones" {

type = list(string)

default = ["us-east-1a", "us-east-1b"]

}

variable "public_subnet_cidr_block" {

type = list(string)

default = ["172.16.0.0/20", "172.16.128.0/20"]

}

variable "private_subnet_cidr_block" {

type = list(string)

default =["172.16.16.0/20", "172.16.144.0/20"]

}

resource "aws_subnet" "public_subnets" {

count = length(var.public_subnet_cidr_block)

vpc_id = aws_vpc.nyacorp-new.id

availability_zone = element(var.availability_zones, count.index)

cidr_block = element(var.public_subnet_cidr_block, count.index)

}

resource "aws_subnet" "private_subnets" {

count = length(var.private_subnet_cidr_block)

vpc_id = aws_vpc.nyacorp-new.id

availability_zone = element(var.availability_zones, count.index)

cidr_block = element(var.private_subnet_cidr_block, count.index)

}

Once the terraform configuration is applied using "terraform apply", it could be noted that the VPC is created along with the subnets. But the internet gateway is not. While portal-based configuration, creates the internet gateway by default for the VPC, it needs to explicitly be configured while using Terraform. 

Below is the resource configuration required to create the internet gateway for the VPC:

resource "aws_internet_gateway" "nyacorp-igw" {

vpc_id = aws_vpc.nyacorp-new.id

tags = {

Name = "NyaCorp-IGW"

}

}

There are other different ways to configure the VPC or to configure more granular details using terraform. This article attempts to clarify the basic requirements to configure the VPC using the AWS portal and using Terraform.

Basics of AWS Virtual Private Cloud (VPC)

Virtual Private Cloud (VPC) is one of the (essential) services from AWS that offers cloud users the ability to create isolated instances of virtual data centers. VPC offers complete control over the cloud networking for the instances created in the AWS cloud. It allows us to create multiple subnets for micro segmenting the virtual instances in different subnets and leverage the network ACL and Security Groups to control inter-subnet communication. It also offers internet connectivity to the instances created in the AWS cloud. 

 

Any EC2 or other instances created in the AWS must be associated with a VPC to get network connectivity.  

 

Each AWS region will be assigned with a unique VPC. In other words, VPC is local to the region. AWS assigns a default VPC for each region for each cloud user. The default VPC created by AWS is assigned with a CIDR of 172.31.0.0/16. This default VPC can be deleted on a per-region basis and the users are free to create their own instance of VPC for better control.  

 

Below is a snapshot from the AWS console that highlights different options to create the default VPC and the custom VPC. 

 

 

Using the "Create default VPC" option will create the default VPC for the respective region with a CIDR of 172.31.0.0/16 and auto-creates subnets for each availability zones (AZ) in the region by assigning a block of subnets from the CIDR. For example, Ohio is one of the regions with 3 AZ. When a default VPC is created in this region, there will be 3 subnets created with /20 block assigned from the CIDR as shown below: 

 

 

Using the "Create VPC" option will create a custom VPC and the user must assign a CIDR value and create the subnets for relevant AZ manually. 

 

Below is an example figure that shows a total of 3 VPCs in N. Virginia (US-East), Ohio (US-Central), and Mumbai (Asia-Pacific) regions. For clarity, we illustrated different CIDR while in reality, the default VPC will always have 172.31.0.0/16.  

 

 

 

 

Each region will have more than one AZ and a subnet is assigned for each AZ. In the N. Virginia region, there are 6 AZs. Each AZ will have a unique subnet that is assigned from the region CIDR block. For example: 

• All AZs in N. Virginia region is assigned with subnets from 172.31.0.0/16 

• All AZs in Ohio region is assigned with subnets from 172.32.0.0/16 

• All AZs in Mumbai region is assigned with subnets from 172.33.0.0/16 

 

Each default VPC will also come with its own dedicated Internet Gateway that connects all the subnets to the internet.  

 

Each Subnet will have its own Route table with a minimum of 2 entries as below: 

 

• Local destination address. 

• The default route (0.0.0.0/0) pointing to the VPC's Internet Gateway  

  

Below is a snapshot of one of the subnets from the Ohio region where it could be noted that the Route table is populated with 2 entries as explained earlier. 

 

 

The Network ACL for the default VPC will have rules for both inbound and outbound traffic. By default, it allows all traffic both inbound and outbound direction which as the readers could imagine is a serious security threat and not a recommended design. Below is a snapshot of the Network ACL from the Ohio region. 

 

 

When an EC2 instance is created in one of the AZ, the IP address from the respective subnet is assigned to the instance and the Route table with a default route pointing to Internet GW will offer full connectivity to the EC2 instance. 

 

 

Reference 

https://aws.amazon.com/vpc