Network concepts for Virtual Private Cloud - Part 1

In this post, I would touch at a higher level about few of the networking terms in Amazon Web Services (AWS).

Virtual Private Cloud (VPC)

You can create your own private cloud on AWS. Private Cloud consists of machines talking to each other. Each machine on the network would need an IP address so that they can talk to each other. You can create multiple Virtual Private Cloud on AWS. You only need to have

• Name for your VPC
• IP address range that you might use — You can make changes to IP address ranges at any time

Your Virtual Private Cloud can spread across the entire world. You can have a machine in California or in NY or in any other Availability Zone. Part of your Virtual Private Cloud in NY region can run on 10.10.10 addresses, part in Asia region can run on 20.20.20 addresses. These parts are subnetworks or Subnet of your Private Cloud.

If your VPC has 2 IP address ranges: 10.10.10.0/24 & 20.20.20.0/24. If you have assigned IP address range 10.10.10.0/24 to Subnet A then you can not assign it to Subnet B. Subnet can only use part of the IP range allocated to VPC. If you try to assign 120.120.10.0/24 to Subnet A in earlier case, AWS will throw an error.

If you want to impose a rule that machines in US can not talk to Asia, you can do so by editing route table. You can create multiple route tables in VPC which can be attached to a subnet or subnets.

Let’s say, we have an important service on machine1 running on port 8090 on Subnet A; that needs to be accessible to all hosts in the VPC. Assuming routing tables are placed so that machines can communicate to machine1. To keep your cloud secure, you would only allow access to a port 8090. This can be achieved by defining a rule or an Access Control. Group of such Network related Access Controls is called Network Access Control List (Network ACL). You can create Network ACLs in your private cloud and attach it to a subnet.

In current state, out Virtual Private Cloud is truly private. None of the machines in the private cloud can talk to internet and vice versa. Using Internet Gateway (IGW), you can expose private cloud to the internet.

Before exposing your private cloud to the internet, it’s important to review Network ACLs & route tables from Network Security point of view.

Approach to a secure network

In VPC, you can create

• Public & Private subnet in Availability Zone(s)
• Create route tables for both subnets
• Create Internet Gateway & only add route to it in public subnet’s routing table

Machine-B in private subnet can not access internet as private subnet does not have a route to IGW. What if at a later point of time, Machine-B wants to access internet?

• We want to keep private subnet unaccessible from the internet
• But allow Machine-B access to the internet
• Such service needs to be between Internet Gateway & Machine-B

NAT Gateways comes to rescue. You can create a NAT Gateway in a public subnet. NAT Gateway has it’s own IP address it needs route to IGW. If private subnet has a route to NAT Gateway then Machine-B can access internet.

Following is a high level diagram illustrating above concepts:

Snapshot from the new AWS Console

Let’s consider the following scenario:

Notice that

• There is no connection between public & private subnet
• Each VPC has a route table — it gets associated with all the subnets that does not have a custom route table (If you add new IP address ranges to your VPC, it would also get added to the main route table)

Missing connection between public & private subnet

To allow machine to connect to internet, we would use NAT Gateway. The setup would now look like following:

Things to notice

• A new route table was attached with private subnet to forward all traffic to the NAT gateway
• NAT Gateway is connected to private subnet via Elastic Network Interface and it would be assigned an Elastic IP address (public IP address, private ip address) where private ip address would be within subnet’s IP address range.

Our private cloud is securely connected to the internet. Assume that Machine-B in private subnet needs to store logs to a secure place so that it’s accessible by other machines. You can upload it to a Simple Storage Service (S3) bucket. One way for Machine-B to upload data to S3 bucket would be through NAT Gateway to Internet Gateway to S3 bucket & make necessary changes in the routing table.

As S3 bucket & Machine-B both are on-AWS, What if you don’t need to go through Internet Gateway to connect to S3? What if you have another route to connect to your own S3 bucket ? This is the fundamental idea behind a Private Link.

Private Link can be used to connect with

• Simple Storage Service (S3), Dynamo DB
• Other Amazon Managed services such as Apache Airflow, SageMaker and so on
• Other Virtual Private Cloud managed by other companies who would offer their Software-as-a-service

With Private Link, Machine-B will now connect to S3 bucket via an endpoint.

In this medium post, we reviewed following networking concepts at a high level:

• Virtual Private Cloud
• Subnet
• Route table
• Network Access Control List (Network ACL)
• Internet Gateway
• NAT Gateway
• Private Link

Part 2 can be found at https://jigarr.medium.com/networking-in-vpc-part-2-95ac26ba8864