AWS VPC Explained: Build a Public and Private Network for Your Cloud Applications

When deploying an application on Amazon Web Services (AWS), launching an EC2 instance is only one part of the process. You also need to decide how your resources communicate, which services can access the internet, and how to protect internal workloads.

This is where an Amazon Virtual Private Cloud (VPC) becomes important.

A VPC provides a logically isolated network for AWS resources. By configuring subnets, route tables, gateways, and security groups, you can build a network that supports both public-facing applications and private backend services.

In this tutorial, we'll explore the core components of a VPC and walk through a simple network architecture.

What Is an AWS VPC?

An Amazon VPC is a virtual network dedicated to your AWS account in a selected AWS Region. You define an IP address range for the network and decide how resources within it communicate with each other and external networks.

For example, a web application might use a public subnet for its load balancer and private subnets for application servers and databases.

This separation helps control network access and reduces unnecessary exposure of internal services.

Understanding the Main VPC Components

1. CIDR Block

A Classless Inter-Domain Routing (CIDR) block defines the IP address range assigned to your VPC.

For example:

10.0.0.0/16

You can divide this larger range into smaller subnet ranges according to your architecture.

When planning CIDR ranges, avoid overlapping networks if your design may later connect to other VPCs or on-premises networks.

2. Public and Private Subnets

A subnet is a segment of a VPC's IP address range associated with a specific Availability Zone.

A public subnet has a route to an internet gateway. Resources need suitable public IP addressing and security rules to communicate directly with the public internet.

A private subnet does not have a direct route to an internet gateway. Resources in private subnets can still access selected external services through mechanisms such as a NAT gateway, if configured.

A common arrangement is:

  • Public subnet: Application load balancer or internet-facing web tier.
  • Private application subnet: Backend services and application servers.
  • Private database subnet: Database instances that should not be directly reachable from the internet.

3. Internet Gateway

An internet gateway allows communication between a VPC and the internet when routing, addressing, and security settings permit it.

To make a subnet public, you typically associate a route table containing a route such as:

0.0.0.0/0 → Internet Gateway

That route alone does not make every resource publicly accessible. Public IP addressing and applicable security controls also matter.

4. Route Tables

Route tables determine where network traffic is directed.

A simple public subnet route table might contain:

Destination Target
VPC CIDR Local
0.0.0.0/0 Internet Gateway

A private subnet might instead route internet-bound IPv4 traffic through a NAT gateway located in a public subnet.

The local route enables communication within the VPC's IP range. More specific routes and other network controls can influence how traffic reaches its destination.

5. Security Groups and Network ACLs

Security groups act as stateful virtual firewalls attached to resources such as EC2 instances and network interfaces. They control inbound and outbound traffic.

Network ACLs operate at the subnet level and are stateless, meaning inbound and outbound rules must be considered separately.

For example, a web server might allow inbound HTTPS traffic on port 443, while a backend server accepts application traffic only from the web tier's security group.

Avoid opening administrative ports such as SSH (22) or RDP (3389) to the entire internet unless there is a carefully justified and temporary need.

Build a Simple Public and Private VPC Architecture

Consider a small web application with a public web tier and a private application tier.

 Internet | Internet Gateway | Public Subnet Load Balancer | Private Subnet Application Server | Private Subnet Database

This diagram illustrates the logical separation of the tiers. In a production deployment, use appropriate Availability Zone distribution, subnet routing, security groups, and managed service options based on the application's requirements.

Step-by-Step AWS Console Lab

You can practise the concepts using the AWS Management Console.

Step 1: Create a VPC

  1. Open the Amazon VPC console.
  2. Select Your VPCs and choose Create VPC.
  3. Give the VPC a descriptive name, such as learning-vpc.
  4. Assign a CIDR block such as 10.0.0.0/16.
  5. Create the VPC.

Step 2: Create Two Subnets

Create a public subnet with a CIDR range such as:

10.0.1.0/24

Create a private subnet with:

10.0.2.0/24

For a more realistic multi-AZ lab, place the subnets in different Availability Zones and add corresponding subnets in a second zone.

Step 3: Configure an Internet Gateway

Create an internet gateway and attach it to your VPC.

Then create or update the public subnet's route table to include a default route to the internet gateway.

Associate the route table with the public subnet.

Step 4: Configure the Private Subnet

Associate the private subnet with a route table that has the local VPC route but no direct default route to the internet gateway.

If private instances need outbound IPv4 internet access for updates, configure a NAT gateway in a public subnet and route the private subnet's outbound traffic through it. A NAT gateway can incur charges, so check current AWS pricing before creating one.

Step 5: Configure Security Groups

Create security groups that follow the principle of least privilege.

For example:

  • Public web tier: Allow inbound HTTPS from approved sources.
  • Application tier: Allow only the required application port from the web tier's security group.
  • Database tier: Allow the database port only from the application tier's security group.

The exact rules depend on the application and the services being used.

Step 6: Verify the Configuration

Review each subnet's route table and confirm that the intended routes are present.

If you launch EC2 instances for testing, use appropriate addressing, security groups, and access methods. Avoid exposing instances unnecessarily, and terminate lab resources when finished.

Common VPC Configuration Mistakes

Creating a public subnet without a working internet path: A subnet needs the correct route, and a resource generally needs suitable public addressing and security rules for direct internet access.

Allowing all traffic in security groups: Broad rules may make testing easier initially but can expose services unnecessarily.

Using overlapping CIDR ranges: Overlap can complicate VPC peering, transit networking, and hybrid connectivity.

Forgetting NAT gateway costs: NAT gateways are managed resources with associated charges. They should be included in the lab budget.

Ignoring Availability Zones: Deploying everything in one Availability Zone can introduce a single point of failure.

Final Thoughts

AWS VPC networking is a foundational skill for cloud engineers. Understanding CIDR blocks, subnet design, route tables, internet gateways, NAT gateways, and security groups makes it easier to design secure and maintainable cloud environments.

Start with a small VPC lab, test each route and security rule, and gradually expand the architecture as you become more comfortable with AWS networking.

If you're developing your cloud skills, structured learning and hands-on labs can help you move from memorising services to understanding how they work together. Eduleem School of Cloud and AI offers cloud training with hands-on labs, trainer guidance, resume support, and mock interview preparation.

Explore the available programmes at Eduleem to learn more.

Always review the AWS documentation and pricing before deploying resources in a real account.