AWS - Virtual Private Cloud (VPC)

Subscribe Send me a message home page


Table of Contents

Introduction

We can think of VPC as logical datacenter in AWS or a mini cloud inside AWS. It has following components:

When we create a VPC, AWS creates a default Route Table, Network Access Control List (NACL) and a default Security Group. However, AWS does not create any subnets and internet gateway.

Some facts about AWS VPC:

We can launch instances in the subnets, assign custom IP address and control the network traffic with a VPC. When we create an AWS account, AWS will set up a default VPC in each AWS Regions. The default VPC is user friendly and can be used immediately without any further configuration. Note that all subnets in default VPC have a route out to the internet and each EC2 instance in the subnets has both public and private IP addresses.

Other VPC related topics that are not covered in this post:

VPC Diagram

The diagram below shows the structure of a VPC. The orange box represents the "border" of VPC. Internet Gateway is the entry point to our VPC. Incoming traffics from the internet needs to be directed to the Internet Gateway in order to enter VPC.

Subnets are basically clusters of EC2 instances. We can define multiple subnets in a VPC. There are two types of subnets

EC2 instances launched in a public subnet have public IP address and they can be accessed from the internet.

Note that there are two types of traffics:

The routing for incoming traffics is handled by AWS automatically. For example, if we launch an EC2 instance in a public subnet, AWS will assign a public IP to this instance which can be then used to ssh into the host. When we ssh to the host, the request will be sent to the Internet Gateway and AWS will route the traffic to the EC2 instance. This is all set up automatically and we don't need to configure anything.

Most of the custom configuration is related to (1) routing table and Network Access Control list attached to subnets and (2) outgoing traffic routing. For a public subnet to communicate with the internet, we just need to attach the internet gateway to the public subnet. To enable outgoing traffic for private subnets, we have two options

NAT Gateway is preferred because it's more scalable and we don't need to manually install software patches. You may find a comparison table in appendix.

In the diagram below, the dotted blue line represent an incoming traffic and the dotted purple line represent an outgoing traffic. The top subnet has a NAT Gateway so it's a public subnet.

VPC_diagram.png

Note: A general pattern is to use public subnet as a middle man between private subnet and the internet. Examples are:

VPC Endpoint

Suppose we want to download a file in S3 from an EC2 instance in a private subnet. Without VPC endpoint, the request will be routed to the NAT Gateway, then it goes through the internet and eventually gets to S3. This is the blue path in the diagram below.

Because our VPC and S3 are both in AWS, we don't really need to go through the internet. What we can do is to create a S3 endpoint and add it to subnet (in this case, it's the private subnet). With the VPC endpoint, request from the EC2 instance will be routed to S3 directly inside AWS without going through the internet. This is the green path in the diagram.

VPC_endpoint.png

Appendix

NAT Gateway vs. NAT Instances

NAT Gateway NAT Instances
  • Redundant inside the Availability Zone
  • Preferred by the enterprise
  • Starts at 5Gbps and scales currently to 45Gbps
  • No need to patch
  • Not associated with security groups
  • Automatically assigned a public IP address
  • Remember to update your route tables
  • No need to disable Source/Destination Checks.
  • When creating a NAT instance, disable Source/Destination Check on the Instance
  • NAT instances must be in a public subnet.
  • There must be a route out of the private subnet to the NAT instance, in order for this to work.
  • THe amount of traffic that NAT instances can support depends on the instance size. If you are bottlenecking, increasing the instance size.
  • You can create high availability using Autoscaling Groups, multiple subnets in different AZs, and a script to automate failover.
  • A NAT instance is always behind a Security Group.

----- END -----

Want some fun stuff?

/static/shopping_demo.png


Comments