Design and Create VPC in AWS
This article will help design and create Virtual Private Network using the VPC designer tool and cloud formation template. It also describes VPC components in detail.
Join the DZone community and get the full member experience.
Join For FreeThis article describes the design and creation of Amazon Virtual Private Network (VPC) using the VPC Designer tool and Cloud Formation templates. It also provides details of VPC Components such as Subnets, Route tables, Security Groups, Internet Gateway, NAT Gateway, VPC endpoints, Network Interfaces, Network Access Control Lists (ACLs), and VPC Peering.
Amazon Virtual Private Cloud (VPC) enables you to create your own dedicated, logically isolated virtual private network in your AWS account. This virtual network closely resembles a traditional network that you operate in your own data center (on-premises). It provides the ability to define and have full control over the virtual network environment, including security, connectivity, and resource deployment. VPC spans multiple availability zones in an AWS Region.
An Amazon VPC is primarily focused on the following capabilities:
- Isolating your own AWS resources from other AWS Accounts.
- Protecting your AWS resources deployed in VPC from network Threats.
- Routing network traffic to and from your resources deployed in VPC.
VPC Components
The fundamental VPC components are:
- VPC CIDR Block
- Subnets
- Security Groups
- Network Access Control Lists (ACLs)
- Gateways (Internet, NAT)
- Route Table
VPC CIDR Block
VPCs and Subnets are associated with an IP address range that is a part of a Classless Inter-Domain Routing (CIDR) block, which will be used to allocate private IP addresses for the resources deployed in VPC. You can create a VPC by assigning either an IPv4 or IPv6 address.
Subnets
A subnet is associated with a CIDR block that is a subset of the '/16 CIDR block' of its VPC. A subnet must reside in a single availability zone. You can deploy AWS resources in a VPC after adding subnets to it.
Security Groups
A security group is considered the first-level defense and acts as a firewall for AWS resources deployed in a subnet to control incoming and outgoing traffic. Inbound rules control the incoming traffic to the instances, whereas outbound rules control the outbound traffic from the instances within the VPC.
Network Access Control Lists (ACLs)
An NACL is considered the second-level defense and acts as a firewall to the subnet that controls incoming and outgoing traffic. We can create rules to allow or deny network traffic to specific protocols through specific ports and specific IP address ranges. Network ACLs are stateless and have separate inbound and outbound rules.
Gateways
A Gateway connects a VPC to another network. The AWS resources residing in a VPC require connectivity outside of the AWS network, i.e., to the internet. A VPC must be attached to the Internet Gateway to access the Internet. NAT Gateway is used to enable the resources residing in a private subnet to connect to the Internet or other AWS services.
Route Table
A Route Table contains a set of rules, called routes, that determine where network traffic from a subnet or gateway needs to be directed. A Route Table is always associated with a subnet.
VPC Peering
A VPC peering connection is a networking connection between two VPCs that enables you to route traffic between them using private IPv4 addresses or IPv6 addresses. We can create a VPC peering connection between our own VPCs or a VPC in another AWS account. Instances in either VPC can communicate with each other as if they are within the same network. The VPCs can be in different Regions i.e., also known as an inter-Region VPC peering connection.
Prerequisites
We have provided a sample solution along with this article. To deploy this solution, we must have the following:
- An AWS account.
- AWS CLI with administrator permissions.
- Basic knowledge of CloudFormation templates.
Design a VPC Using VPC Design Tool
Amazon VPC supports both IPv4 and IPv6 addresses. Here, we will use IPv4 to design a VPC. When we create a VPC, we must specify an IPv4 address for the VPC. The acceptable address block will be between a '/16 netmask' (65,536 IP address) and a '/28 netmask' (16 IP address). AWS recommends that we specify the CIDR block from the private address ranges specified in RFC 1918.
| RFC 1918 range | Example CIDR block |
|---|---|
| 10.0.0.0 - 10.255.255.255 (10/8 prefix) | 10.0.0.0/16 |
| 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) | 172.31.0.0/16 |
| 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) | 192.168.0.0/20 |
RFC 1918 Standard
Let us discuss more IPv4 addresses.
An IPv4 address is 32 bits. An IP Address is shown as four decimal numbers representing 4 bytes (each byte is 8 bits, i.e. 8 * 4 = 32 bits).
| CIDR RANGE | Explanation |
|---|---|
| 10. 9 . 0 . 0 /16 8 + 8 |
CIDR / 16, first two digits will not change in this IP address range. 10 . 9 . (0 - 255) . (0 - 255) = 256 * 256 = 65536 private IP addresses are available for usage. |
| 10. 9 . 0 . 0 /18 8 + 8 +2 |
CIDR / 18, first two digits will not change in this IP address, and the third digit allows a range between 0 through 63. 10 . 9 . (0 - 63) . 0 = 64 * 256 = 16384 private IP addresses are available for usage. |
| 10. 9 . 0 . 0 /22 8 +8 +6 |
CIDR / 18, first two digits will not change in this IP address, and the third digit allows a range between 0 through 3. 10 . 9 . (0 - 3) . 0 = 4 * 256 = 1024 private IP addresses are available for usage. |
| 10. 9 . 0 . 0/24 8 + 8 + 8 |
CIDR / 24, first three digits will not change in this IP address. 10 . 9 . 0 . 0 - 255 = 256 private IP addresses are available for usage. |
| 10. 9 . 0. 0 /26 8+8+8+2 | CIDR / 18, first three digits will not change in this IP address, and fourth digit will allow a range between 0 through 63. 10 . 9 . 0 . (0 - 63) = 64 private IP addresses are available for usage. |
| 10. 9 . 0 . 0/32 8 + 8 + 8+ 8 |
CIDR / 32, all the four digits will not change in this IP address. 10 . 9 . 0 . 0 = 1 private IP address is available for usage. |
Let us now design a VPC and its subnets with an IP CIDR range. Please ensure the VPC CIDR range we use does not overlap with existing IP address ranges currently in use in your organization.
I am using a VPC designer tool to design subnets in a VPC.
VPC CIDR Range: 10.9.0.0/22
There are 1024 IP addresses available to allocate to our subnets.
Let us design two subnets in a VPC, one public and another private. This example takes three availability zones into consideration. We allocate 256 IP addresses for each private subnet using a 'CIDR /24' range. We then allocate 64 IP addresses for the first two public subnets using a 'CIDR /26' range. We then assign not 64, but 128 IP addresses to the last public subnet using a 'CIDR /25' range. This is possible as we would be left with 64 unused IP addresses, which we can assign to our third public subnet.
Refer to the screenshot below to understand how the allocation works.
VPC Creation
Let us now create a VPC using the information provided above from the VPC designer tool and design the CIDR range for our public and private subnets using the CloudFormation template.
AWSTemplateFormatVersion: "2010-09-09"
Description: This template deploys a VPC with a pair of public and private subnets spread across three Availability Zones. It deploys an internet gateway, defining routes to public subnets. It deploys three NAT gateways (one in each AZ), and routes them to private subnets. It also creates NACls for each Public and Private subnet.
Parameters:
pVPCCIDRBlock:
Description: Please enter the IP range for this VPC
Type: String
pPublicSubnet1CIDR:
Description: Please enter the IP range for the public subnet in the first Availability Zone
Type: String
pPublicSubnet2CIDR:
Description: Please enter the IP range for the public subnet in the second Availability Zone
Type: String
pPublicSubnet3CIDR:
Description: Please enter the IP range for the public subnet in the third Availability Zone
Type: String
pPrivateSubnet1CIDR:
Description: Please enter the IP range for the private subnet in the first Availability Zone
Type: String
pPrivateSubnet2CIDR:
Description: Please enter the IP range for the private subnet in the second Availability Zone
Type: String
pPrivateSubnet3CIDR:
Description: Please enter the IP range for the private subnet in the third Availability Zone
Type: String
Resources:
rVPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: !Ref pVPCCIDRBlock
EnableDnsSupport: true
EnableDnsHostnames: true
rPublicSubnet1:
Type: AWS::EC2::Subnet
Properties:
CidrBlock: !Ref pPublicSubnet1CIDR
VpcId: !Ref rVPC
AvailailityZone: !Select [0, !GetAZs '']
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: "Public Subnet (AZ1)"
rPublicSubnet2:
Type: AWS::EC2::Subnet
Properties:
CidrBlock: !Ref pPublicSubnet2CIDR
VpcId: !Ref rVPC
AvailailityZone: !Select [1, !GetAZs '']
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: "Public Subnet (AZ2)"
rPublicSubnet3:
Type: AWS::EC2::Subnet
Properties:
CidrBlock: !Ref pPublicSubnet3CIDR
VpcId: !Ref rVPC
AvailailityZone: !Select [2, !GetAZs '']
MapPublicIpOnLaunch: true
Tags:
- Key: Name
Value: "Public Subnet (AZ3)"
rPrivateSubnet1:
Type: AWS::EC2::Subnet
Properties:
CidrBlock: !Ref pPrivateSubnet1CIDR
VpcId: !Ref rVPC
AvailailityZone: !Select [0, !GetAZs '']
MapPublicIpOnLaunch: false
Tags:
- Key: Name
Value: "Private Subnet (AZ1)"
rPrivateSubnet2:
Type: AWS::EC2::Subnet
Properties:
CidrBlock: !Ref pPrivateSubnet2CIDR
VpcId: !Ref rVPC
AvailailityZone: !Select [1, !GetAZs '']
MapPublicIpOnLaunch: false
Tags:
- Key: Name
Value: "Private Subnet (AZ2)"
rPrivateSubnet3:
Type: AWS::EC2::Subnet
Properties:
CidrBlock: !Ref pPrivateSubnet3CIDR
VpcId: !Ref rVPC
AvailailityZone: !Select [2, !GetAZs '']
MapPublicIpOnLaunch: false
Tags:
- Key: Name
Value: "Private Subnet (AZ3)"
rPublicRouteTable:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref rVPC
Tags:
- Key: Name
Value: "Public Routes"
rPublicSubnet1RouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
RouteTableId: !Ref rPublicRouteTable
SubnetId: !Ref rPublicSubnet1
rPublicSubnet2RouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
RouteTableId: !Ref rPublicRouteTable
SubnetId: !Ref rPublicSubnet2
rPublicSubnet3RouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
RouteTableId: !Ref rPublicRouteTable
SubnetId: !Ref rPublicSubnet3
rInternetGateway:
Type: AWS::EC2::InternetGateway
Properties:
Tags:
- Key: Name
Value: "Internet Gateway"
rInternetGatewayAttachment:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
InternetGatewayId: !Ref rInternetGateway
VpcId: !Ref rVPC
rNatGateway1EIP:
Type: AWS::EC2::EIP
DependsOn: rInternetGatewayAttachment
Properties:
Domain: vpc
rNatGateway2EIP:
Type: AWS::EC2::EIP
DependsOn: rInternetGatewayAttachment
Properties:
Domain: vpc
rNatGateway3EIP:
Type: AWS::EC2::EIP
DependsOn: rInternetGatewayAttachment
Properties:
Domain: vpc
rNatGateway1:
Type: AWS::EC2::NatGateway
Properties:
AllocationId: !GetAtt rNatGateway1EIP.AllocationId
SubnetId: !Ref rPublicSubnet1
rNatGateway2:
Type: AWS::EC2::NatGateway
Properties:
AllocationId: !GetAtt rNatGateway2EIP.AllocationId
SubnetId: !Ref rPublicSubnet2
rNatGateway3:
Type: AWS::EC2::NatGateway
Properties:
AllocationId: !GetAtt rNatGateway3EIP.AllocationId
SubnetId: !Ref rPublicSubnet3
rPrivateRouteTable1:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref rVPC
Tags:
- Key: Name
Value: "Private Routes (AZ1)"
rPrivateRouteTable2:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref rVPC
Tags:
- Key: Name
Value: "Private Routes (AZ2)"
rPrivateRouteTable3:
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref rVPC
Tags:
- Key: Name
Value: "Private Routes (AZ3)"
rPrivateSubnet1RouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
RouteTableId: !Ref rPrivateRouteTable1
SubnetId: !Ref rPrivateSubnet1
rPrivateSubnet2RouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
RouteTableId: !Ref rPrivateRouteTable2
SubnetId: !Ref rPrivateSubnet2
rPrivateSubnet3RouteTableAssociation:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
RouteTableId: !Ref rPrivateRouteTable3
SubnetId: !Ref rPrivateSubnet3
rPublicDefaultRoute:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref rPublicRouteTable
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref rInternetGateway
rPriaveteNATGatewayRoute1:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref rPrivateRouteTable1
NatGatewayId: rNatGateway1
DestinationCidrBlock: 0.0.0.0/0
rPriaveteNATGatewayRoute2:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref rPrivateRouteTable2
NatGatewayId: rNatGateway2
DestinationCidrBlock: 0.0.0.0/0
rPriaveteNATGatewayRoute3:
Type: AWS::EC2::Route
Properties:
RouteTableId: !Ref rPrivateRouteTable3
NatGatewayId: rNatGateway2
DestinationCidrBlock: 0.0.0.0/0
rPublicSubnetNacl:
Type: AWS::EC2::NetworkAcl
Properties:
VpcId: !Ref rVPC
Tags:
- Key: Name
Value: "Public Subnet Nacl"
rPrivateSubnetNacl:
Type: AWS::EC2::NetworkAcl
Properties:
VpcId: !Ref rVPC
Tags:
- Key: Name
Value: "Private Subnet Nacl"
rPublicSubnetInbound:
Type: AWS::EC2::NetworkAclEntry
Properties:
NetworkAclId: !Ref rPublicSubnetNacl
Egress: false
RuleNumber: 10
Protocol: 6
RuleAction: 'allow'
CidrBlock: '0.0.0.0/0'
PortRange:
From: 1024
To: 65535
rPublicSubnetOutbound:
Type: AWS::EC2::NetworkAclEntry
Properties:
NetworkAclId: !Ref rPublicSubnetNacl
Egress: true
RuleNumber: 10
Protocol: -1
RuleAction: 'allow'
CidrBlock: '0.0.0.0/0'
PortRange:
From: 22
To: 65535
rPublicSubnetInbound:
Type: AWS::EC2::NetworkAclEntry
Properties:
NetworkAclId: !Ref rPrivateSubnetNacl
Egress: false
RuleNumber: 10
Protocol: -1
RuleAction: 'deny'
CidrBlock: '0.0.0.0/0'
PortRange:
From: 1024
To: 65535
rPublicSubnetOutbound:
Type: AWS::EC2::NetworkAclEntry
Properties:
NetworkAclId: !Ref rPrivateSubnetNacl
Egress: true
RuleNumber: 10
Protocol: 6
RuleAction: 'allow'
CidrBlock: '0.0.0.0/0'
PortRange:
From: 1024
To: 65535
rNaclPublicSubnetAssociation1:
Type: AWS::EC2::SubnetNetworkAclAssociation
Properties:
NetworkAclId: !Ref rPublicSubnetNacl
Subnet: !Ref rPublicSubnet1
rNaclPublicSubnetAssociation2:
Type: AWS::EC2::SubnetNetworkAclAssociation
Properties:
NetworkAclId: !Ref rPublicSubnetNacl
Subnet: !Ref rPublicSubnet2
rNaclPublicSubnetAssociation3:
Type: AWS::EC2::SubnetNetworkAclAssociation
Properties:
NetworkAclId: !Ref rPublicSubnetNacl
Subnet: !Ref rPublicSubnet3
rNaclPrivateSubnetAssociation1:
Type: AWS::EC2::SubnetNetworkAclAssociation
Properties:
NetworkAclId: !Ref rPrivateSubnetNacl
Subnet: !Ref rPublicSubnet1
rNaclPrivateSubnetAssociation2:
Type: AWS::EC2::SubnetNetworkAclAssociation
Properties:
NetworkAclId: !Ref rPrivateSubnetNacl
Subnet: !Ref rPrivateSubnet2
rNaclPrivateSubnetAssociation3:
Type: AWS::EC2::SubnetNetworkAclAssociation
Properties:
NetworkAclId: !Ref rPublicSubnetNacl
Subnet: !Ref rPrivateSubnet3
Outputs:
VPC:
Description: "VPC Id"
Value: !Ref VPC
PublicSubnets:
Description: "Public subnets"
Value: !Join [ ",", [ !Ref rPublicSubnet1, !Ref rPublicSubnet2, !Ref rPublicSubnet3 ]]
PrivateSubnets:
Description: "Private subnets"
Value: !Join [ ",", [ !Ref rPrivateSubnet1, !Ref rPrivateSubnet2, !Ref rPrivateSubnet3]]
The above code snippet creates a VPC with public and private subnets, NACLs, Internet Gateway, NAT Gateway, and Route Tables.
All CIDR ranges of subnets in a VPC should be a subset of a VPC CIDR range. In this example, the VPC creates a '/22 CIDR block' (with 1024 IPs) with three availability zones, and each availability zone has a set of public and private subnets. All our public subnets will be created using the '/26 CIDR' block, and all our private subnets will be created using the '/24 CIDR' block.
Public Subnets
Each Public subnet has its own route table attached to route the internet traffic through the Internet gateway. The resources deployed in EC2 Instances in public subnets can have their own public IPs or Elastic IPs (EIPs) that have a NAT attached to their Elastic Network Interface (ENI).
Private Subnets
AWS resources deployed in the private subnets are assigned only private IPs, and these resources cannot directly access the internet. Infrastructure in a private subnet gets access to resources or users on the Internet through a NAT Gateway. An AWS NAT gateway is a fully managed and highly available service (in a given availability zone). To provide high availability across the availability zones (AZs), it is recommended to have a minimum of two NAT gateways in different AZs. In the event that one AZ should become unavailable, the design choice of having two NAT gateways in two different AZs allows us to switch to an available NAT gateway.
Applications hosted on instances living within a private subnet can have different access requirements. Some services may require access to the Internet, whereas other services may require access to databases, applications, and users that are hosted on-premises. For this type of access, AWS provides two types of services: the Virtual Gateway and the Transit Gateway. The Virtual Gateway can only support a single VPC at a time, whereas the Transit Gateway is built to simplify the interconnectivity of tens of hundreds of VPCs, and then aggregate their connectivity to resources residing on-premises. Given that, we are looking at the VPC as a single unit of the network.
All diagrams below contain illustrations of the Virtual Gateway, which acts as a WAN concentrator for our VPC.
AWS provides two options for establishing private connectivity between our VPC and on-premises network: AWS Direct Connect and AWS Site-to-Site VPN.
AWS Site-to-Site VPN configuration leverages IPSec, with each connection providing two redundant IPSec tunnels. AWS supports both static routing and dynamic routing (through the use of BGP).
Note: BGP is recommended, as it allows dynamic route advertisement, high availability through failure detection, and failover between tunnels, in addition to decreased management complexity.
Conclusion
In this article, we learned how to design a VPC and subnets and defined their components. We ensured our VPC has internet and private network connectivity to the resources deployed within our VPC by defining an Internet Gateway, NAT Gateway, Virtual Gateway (VGW), and Direct Connect. We learned to describe components such as Route Table and NACLs. I hope this article helps you to understand, design, and define a virtual private cloud in simple and easy steps.
Opinions expressed by DZone contributors are their own.
Comments