Amazon Web Service environment is a fully digital experience of a typical brick-and-mortar data center. All components, such as firewalls or load balancers, are fully digitalized. Likewise, all of the services that AWS offers, such as Elastic Compute servers, databases, or Lambda functions live within that ecosystem.
When running any type of service within Amazon Web Services, it is important to understand the concept of the Virtual Private Cloud (VPC). It tightens security around your services and helps with communication between multiple services.
Architectures can be as complex or simple as needed, which is the beauty of AWS. Understanding the core concept of the AWS VPC will help you with the architecture design.
What is VPC
Imagine your entire AWS account as a data center open for business for whatever applications or services you choose to run. A VPC is a slice within that data center that is determined by the Classless Inter-Domain Routing or CIDR range.
VPCs are a region-specific resource. Hence, a VPC created in region US-EAST-1 does not exist in any other region.
An example of a VPC IPV4 address could be 172.31.0.0/16
This means that this VPC has 65,534 hosts available for services to run on.
IPV4 Range: 172.31.0.1 – 172.31.255.254
When you create a VPC, you determine how many IP addresses can fit within that slice of the data center.
Each VPC can have subnets running within the availability zone. It also has its own route table to determine which services can talk to what. You can adjust Network Access Control Lists within a VPC to allow for specifying certain types of traffic to different destinations at the protocol and port level.
A public subnet means that the route table for that subnet can reach the public internet via the internet gate.
Creating a VPC
To view and create a VPC, navigate to the console URL for the specific region you are working in. In my example, I will use us-east-1:
Here we get an overview of all components that will go along with our Virtual Private Cloud. They are subnets, route tables, and internet gateways.
Click Your VPCs in the menu on the left and click Create VPC.
Name the VPC and provide the CIDR notation to determine the number of available hosts:
Click Create VPC.
Creating VPC Subnet
Now that a new VPC has been created we can create subnets within that VPC:
Click Create subnet
When you construct the VPC, you can also specify the Availability Zone the subnet will reside in.
You can also choose the size of the subnet with the CIDR notation. The number assigned to the subnet CIDR range must be equal to or smaller than the VPC CIDR range.
Here we are using 10.0.0.0/28. In our case, 10.0.0.0/16 (65K host) is allowed. We can assign 16 to this subnet. It is also worth noting that AWS reserves some address spaces. Thus, AWS /28 actually results in 11 possible hosts.
If we take a look at the Route Tables tab, we can see a route table automatically created for the VPC.
The route table and Network Access Control Lists (NACLs) configurations are outside the scope of this article. But it is important to know that a route table is automatically created when you are creating a VPC.
Now that a VPC has been constructed, and a subnet has been configured to run inside of that VPC, resources such as EC2 instances can be deployed inside of that Subnet!
VPC Peering is the concept of two VPCs in either two different regions or two AWS accounts that can communicate with one another. Resources deployed in the AWS account of company A can read a database from the AWS account of company B through the VPC peering.
VPC endpoints enable private connections between the VPC and the AWS Service. This is done through the AWS Private Link which means that the network traffic does not traverse the public internet and traverses Amazon’s backbone network instead.
A use case for the VPC endpoint would be to restrict the outgoing HTTPS traffic on a web server but save the ability to download contents from an S3 bucket in your account. You could configure a VPC endpoint that would allow the web server to communicate to the S3 bucket via the VPC endpoint.
We have covered that a VPC is a slice of private IP addresses within an AWS account. We have clarified how subnets fit into VPCs and defined the relationship of the route tables. Any subnet that does not have a route to an internet gateway is considered a private subnet. Finally, we have explored the concept of VPC peering and VPC endpoints and the use cases of each.
We hope that this article was useful for your workflow. Stay tuned for the next materials!