Beginners Guide to AWS VPCs

A Virtual Private Cloud is a dedicated network in your AWS account that you can use to deploy private AWS services like EC2. VPCs are isolated networks that are deployed into an AWS region and can use all availability zones of that region.

A VPC consists of

• Subnets
• Routing tables that are associated with subnets
• NAT gateways
• An internet gateway

Each AWS Region comes with a default VPC which has one public subnet which can be accessed from the internet and route requests out to the internet.

VPC Router

Every VPC has a VPC router that handles the routing between subnets, Internet Gateway, and NAT Gateway. The +1 address in each subnet is reserved for the router.

The router uses Route Tables that are defined on a per subnet type basis and concrete subnet instances in an availability zone use a Route Table Association to identify their rout table.

Network Address Translation (NAT)

NATs map local devices to a public IPv4 address. A request from the internet to a local network device (with a private IPv4) passes the NAT Gateway which then maps the private IPv4 of the device to a public IPv4 that the NAT maintains.

This can be done in three different modes

• Static NAT
• Dynamic NAT
• PAT

Static NAT

Each device with its local, private IPv4 address gets mapped to one static public IPv4 address. So there is a 1:1 relationship between local device IPs and public NAT gateway IPs.

The AWS Internet Gateway operates in the Static NAT mode.

Dynamic NAT

The NAT gateway maintains a list of public IPv4 addresses. Each request from/to a local device gets mapped to one of the available public IPs. So there is no static public IP provided for each device, the IP changes on a per-request basis.

PAT

PAT stands for Port Address Translation and maps multiple local device IPs to the same public IP through ports. The NAT gateway associates a port on the public IP to a local device IP on a per-request basis.

This means that local devices are not directly reachable from the internet since they get associated with a different port for each request.

The AWS NAT Gateway operates in this mode.

VPC CIDR

The VPC CIDR defines the network range that the VPC spans. This range must be private and can be

• /28 at minimum (16 IPs, 14 usable)
• /16 at most (65536 IPs, 65534 usable)

A good range that you can use are 10.x.x.x/y CIDRs but try to avoid 10.0.x.x/y and 10.1.x.x/y since those are very popular ranges.

You should plan your VPC CIDRs beforehand and estimate how many regions in an account you want to use. Choose VPC CIDRs that do not overlap in the same organization and give yourself a buffer of 2-3 extra CIDR ranges in case your business use case grows.

E.g. calculation:

5 AWS accounts * (4 used regions + 2 Buffer) = 30 CIDR ranges

CIDR Sizes

Subnetting

A subnet is a smaller network within the VPC and can vary in

• How it can be accessed from outside of the internet
• How it can access the internet

You divide a VPC into subnets by providing the subnet a sub-range of the VPC CIDR.

So it is important to choose an appropriate CIDR range for your VPC in the first place to house all of your subnets. A subnet should have enough IPs to house all of the AWS services that you need to deploy into your VPC while leaving a proper buffer.

It is also important to keep in mind that each subnet can only use count(subnet_cidrs) - 2 IPv4 of the subnet CIDR since

• The first IPv4 …
• The last IPv4 …

Three-Tier Application

The Three - Tier Application is a VPC best practice that breaks a VPC into three subnets

• Web Tier - public subnet for frontend applications and public APIs
• Computing Tier - private subnet for private backend services
• Data Tier - private subnet for data services

Finding the correct Subnet Structure

The Three-Tier Application VPC structure is always a good starting point, but it makes sense to add a fourth spare subnet in case your business use case grows. It is quite difficult to resize VPCs once they are housing productive workloads so you should think ahead and be more generous with the number of subnets you provide.

Availability Zones

VPC subnets are deployed into availability zones, which means you need to provide a CIDR range for each subnet per availability zone. It is a good practice to go with 3 availability zones as a standard but keep a CIDR range for a potential 4th availability zone in reserve.

Internet Gateway

The Internet Gateway can provide static, public IPv4 addresses to resources deployed in a VPC subnet that route directly to the Internet Gateway (Static NAT). So resources within those subnets have a public IP address attached and can be accessed from the internet.

The Internet Gateway service runs in the AWS public zone and

Region resilient

NAT Gateway

The NAT Gateway uses the Port Address Translation (PAT) mode to temporarily map a VPC subnet resource (that routes to the NAT Gateway) to a port on the NAT Gateway public, static IPv4 address.

A NAT Gateway must be

• deployed to a public subnet (a subnet that routes to an Internet Gateway)
• have an elastic IPv4 address (EIP)

Resources behind NAT Gateways cannot be accessed from the internet but can send requests out to the internet.

Each HTTP request that goes to the internet needs to go through a public IPv4 address. A TCP/UDP request has a source and destination IP address as well as a source and destination port. In the case of HTTP, these outgoing requests have an ephemeral source port that can only be reached from the internet resource that you call for the HTTP response.

The NAT Gateway provides an ephemeral source port to the elastic IP address attached to it for each request coming from a device in the private subnet. So outgoing internet requests are possible because internet resources can respond in the same request to the epihermal source port on the elastic IP address.

Subsequent requests from outside the internet to the epihermal port are not successful because the ephemeral ports are assigned on a per-request basis.

Routing Tables

A routing table contains route entries and tells each CIDR whether

• it needs to go through the next router, called “next hop”
• can reach the requested resource in the network of this routing device

e.g.

The table above tells the routing device that incoming requests that target an IPv4 within the 10.0.0/16 CIDR remain in the Local network.

The loopback address 0.0.0.0/0 is set to the Internet Gateway. That address basically matches all IPv4 addresses and routing tables use rules with the loopback address with the lowest priority. This makes sure that all requests that do not match any rule in the table get redirected to the Internet Gateway.

Routing tables prioritize rules with more specific CIDR ranges over less specific ones. A CIDR range is more specific if it targets a smaller IPv4 range, so when the network mask value is higher. 0 is the lowest network mask and matches all IPv4 addresses, so it has the lowest priority.

Route Associations

You typically have multiple subnets spread across availability zones in your region and it would be tedious if you have to define one routing table for each subnet. After all, a subnet needs a routing table to define how incoming/outgoing requests get routed.

You can define one or multiple routing tables in your VPC configuration and then create one route association per subnet which makes it unnecessary to define a separate routing table for each subnet.

You should create multiple routing tables if you have different types of subnets like

• public subnets
• private subnets
• private, isolated subnets

Thus, you define a routing table for each subnet type instead of each individual subnet. you then associate the routing table with the corresponding subnet, e.g. a private subnet instance gets associated with the private subnet routing table.

Subnets

Subnets are smaller parts of the VPC network that underly specific routing rules, provided through the associated Routing Table.

Public Subnets

A public subnet has a direct route to an internet gateway which attaches a public IPv4 to each resource ENI deployed to the subnet.

An External Network Interface (ENI) represents a virtual network card and is a bridge between actual AWS resources such as an EC2 instance and your VPC subnets. Requests to an AWS resource actually get targeted to its ENI which proxies the request to the resource.

Resources should only be deployed to a public network if they purposely should be reachable from the internet. This is necessary e.g. necessary for frontend applications or public APIs. Private APIs or DBMS on the other side should never be deployed in a public network so they do not receive a public IPv4 address.

Private Subnets

Private subnets do not route directly to the Internet Gateway and thus do not receive a static public IPv4 address. A private subnet can communicate to the internet by routing through a NAT Gateway to the Internet Gateway.

The NAT Gateway binds a resource from the private subnet to a port on the public static IPv4 (PAT) so resources in the private subnets can receive responses from websites that they may call from inside the VPC.

Private Isolated Subnets

Private isolated subnets are private subnets that have no route to a NAT Gateway and thus cannot reach the internet, nor can be reached from the internet.

This type of subnet is used to house critical infrastructure like managed data services such as RDS which do not need to communicate to the internet. In fact, it is a security advantage that the resources in this subnet cannon communicate to the internet. Otherwise, an attacker could transfer data out of the VPC upon compromising the isolated subnet.

High Availability in VPCs

Subnet instances are deployed into availability zones.

It is a good practice to deploy subnets into at least three AZs if the system is productive or only one AZ for SDLC or staging. Each CIDR range of subnets deployed in the AZs must not overlap and there is a cost of transferring data cross-az.

This makes the multi-az setup costly for staging and SDLC accounts.

VPC Configuration Flags

tenancy - defines where resources in the VPC get deployed to

• default - uses shared resources
• dedicated - uses dedicated hardware resources (premium price)

enableDnsHostnames - gives service instances in your subnets hostnames

enableDnsSupport - enables DNS resolution for resources in your DNS (Route53)