What is VPC in AWS, and how does it work?
Amazon Web Services (AWS) is a leading cloud service provider offering several compute, storage, and network services as Infrastructure as a Service (IaaS). This provides flexibility and scalability to businesses of all sizes according to their needs without managing on-premises IT infrastructure.
A virtual private cloud (VPC) provides an isolated virtual environment within AWS that we can customize according to our application requirements. This provides a secure networking environment for an application to communicate between the resources within the VPC and the outside world.
This blog will explore VPC’s basic components and significance in the AWS ecosystem. We’ll also look at an example scenario and learn how to effectively design, configure, and manage a VPC environment in AWS. So, let’s get started!
VPC in AWS
Virtual private cloud (VPC) is a fundamental component of AWS that allows us to create a virtual networking environment in the cloud. We can define a private network within the AWS Cloud and launch AWS resources, such as virtual compute resources (EC2) and storage (S3 buckets). To understand the importance of VPC in AWS, let’s start with some key benefits that VPC offers:
Multiple isolated environments: Imagine an organization with multiple projects, such as a customer-facing e-commerce platform and internal data analytics tool, that need to be isolated. VPC allows us to create isolated environments within the same AWS account to separate the infrastructure for the e-commerce platform and data processing servers. Each VPC operates independently with its IP address range, subnets, route tables, and security settings. This prevents interference between the two projects and provides clear boundaries for resource utilization.
Control over traffic: VPC gives us full control over the network configuration. We can organize our resources in different subnets within a VPC, where traffic to each subnet can be controlled through route tables.
Enhanced security: VPC offers us different security layers. The resources in a private network are inaccessible from the internet. We can also permit only a specific type of traffic into the VPC using the security groups or deny access using network access control lists (NACLs) to protect our resources from unauthorized access.
Access to the home network: We can connect our VPC to the on-premises IT infrastructure through a Site-to-Site virtual private network (VPN). A Site-to-Site VPN establishes an encrypted tunnel between the on-premises network gateway (VPN appliance or router) and the virtual private gateway (VGW) within the AWS VPC. This ensures that all data transmitted between on-premises resources and AWS infrastructure remains confidential and protected from unauthorized interception.
Let’s look at the different components of VPC that provide us with these benefits.
Components of VPC
Different components of VPC help us effectively design and manage our resources in a cloud environment.
Subnets
A subnet represents a range of IP addresses in a VPC. A subnet divides a network into smaller parts to control traffic within the VPC. There are primarily two types of subnets in VPC based on how we configure them:
Public subnets: As the name suggests, these subnets are accessible from the internet and are typically associated with resources such as applications’ frontends that need internet connectivity.
Private subnets: Resources like databases or applications’ backend servers need not be directly accessible online, therefore, they can be placed in a private subnet.
Subnets logically segment resources within a VPC, allowing us to isolate resources and applications to prevent any security threat. Additionally, we can separate resources into different subnets based on their characteristics. For example, deploying servers and databases into separate subnets allows each to scale independently based on demand without affecting the performance or availability of other components.
Route tables
Route tables define the rules for routing network traffic from the subnet. A route table contains entries that specify the destination IP address range and a target. Each subnet must connect to a route table. By default, a subnet has a main route table controlling traffic flow. However, this table can be customized according to our needs. Let’s take an example of a route table for a subnet:
Destination | Target |
| Internet gateway ID |
| Local |
The first entry in the route table allows access to the internet through an internet gateway (target) with a destination set to
0.0.0.0/0that represents all IPv4 addresses. This route table entry connects resources in a public subnet to the internet.The second route tells the subnet to route any traffic destined for the IP address range of
10.0.0.0/16within the local VPC.
Internet gateway
An internet gateway allows communication between the resources in a public subnet and the internet. A common use case of an internet gateway is to enable instances within the VPC to access external services, such as web servers, databases, or software repositories hosted outside the VPC boundaries.
NAT gateway
A network address translation (NAT) gateway allows outbound communications between the resources in a private subnet and the internet. However, the NAT gateway does not allow inbound traffic to initiate connections with those instances, providing a security layer.
Consider a backend server hosted on an EC2 instance in a private subnet. To access the internet, this instance connects to a NAT gateway device in a public subnet that allows internet access through an internet gateway. The NAT gateway replaces the instance’s source IP address with the NAT device’s address before sending the outward traffic, acting as a mediator between the instance and the internet.
Security groups
Security groups act as a firewall to an instance and control both inbound and outbound traffic at the instance level. Every VPC comes with a default security group that does not allow any incoming traffic but allows all outgoing traffic from the instance. However, we can create additional security groups for a VPC and specify the rules for both inbound and outbound traffic.
Let’s look at an example of security group inbound and outbound rules:
Inbound Rule
Source | Protocol | Port |
| TCP | 22 |
Here, the inbound rule allows the SSH traffic to the instance with an IPv4 address range 198.51.100.0/24.
Outbound Rule
Source | Protocol | Port |
| All | All |
The outbound rule with source 0.0.0.0/0 allows all outbound traffic.
Note that the security groups are permissive. This implies that we can only specify the rules that allow traffic from a specific port, protocol, or IP range. Additionally, security groups are stateful, implying they allow return traffic for connections initiated from the instances within a VPC. This avoids explicitly defining an inbound rule to allow the return traffic.
Note: Unlike route tables, we can connect multiple security groups with an instance.
Network access control lists
Network access control lists (NACLs) are associated with subnets and provide an additional firewall for the VPC by controlling the incoming and outgoing traffic. In contrast to security groups, NACLs explicitly deny or allow traffic from specific source and destination IP addresses, ports, and protocols.
Use case: Web application hosting
Now that we have learned how VPC works, let’s look at an example of managing resources in AWS to host a web application with a frontend server and a backend server.
The role of the frontend server is to service the customers and hence needs a connection to the internet. On the other hand, the backend manages data storage and processing and does not require inbound or outbound traffic from the internet.
Let’s understand how to configure different resources as follows:
Public subnet: We place the frontend in a public subnet and make it accessible from the internet. We utilize an internet gateway to enable internet access to the frontend. We must add a route with a destination
0.0.0.0/0with a target internet gateway to allow internet-routable traffic.Private subnet: We place the backend in a private subnet that is not directly accessible from the internet.
Security groups: There are two security groups: SG1 and SG2.
SG1: The first security group manages the inbound and outbound traffic for the public subnet. Since we want the applications’ frontend to be accessible from the internet by all users, we allow all inbound web traffic of HTTP (port 80) and HTTPS (port 443) for the public subnet. We do not need to apply any restrictions for the outbound traffic of the public subnet.
SG2: The second security group is attached to the private subnet. Since the private subnet hosts the applications’ backend, we can only allow inbound traffic from the frontend to communicate with the backend server running in the private subnet.
NACL rule for public and private subnets: Since NACLs explicitly deny or allow traffic at a subnet level, we can allow an administrator access via the NACL to both the frontend and backend from trusted IP addresses of type SSH (port 22). This ensures that only the authorized IP addresses can securely manage and troubleshoot instances within the public and private subnets. Furthermore, we restrict SSH access to specific trusted IP addresses to mitigate the risk of unauthorized access attempts and potential security breaches.
Now, our application’s frontend is accessible to the clients, and the backend is secure.
Next steps
If you want to learn about more use cases of VPC in AWS and get hands-on experience deploying resources on AWS, we encourage you to check out the following Cloud Labs on Educative.
