What Is a VPC in AWS? A Beginner's Guide

A VPC (Virtual Private Cloud) is a logically isolated section of AWS where you define your own private network: its IP address range, subnets, route tables, and gateways. Every EC2 instance, database, and load balancer you create lives inside one, which is why it's usually the first thing you design when you start building on AWS.

Why AWS puts everything inside a VPC

AWS runs millions of customers' workloads on shared physical hardware, so it needs a way to give each customer a network that behaves like it's theirs alone — one where you control which resources can talk to each other, which can reach the internet, and which stay completely private. The VPC is that boundary. When you create an AWS account, you already get a default VPC in each region so you can launch an EC2 instance immediately, but any real application should run in a custom VPC that you design on purpose, not the default one.

The building blocks of a VPC

A VPC on its own is just an address range (for example 10.0.0.0/16). The pieces you add on top are what make it useful:

• Subnets — smaller slices of the VPC's IP range, each tied to a single Availability Zone. You typically create at least one public and one private subnet per AZ.
• Route tables — rules that decide where traffic from a subnet is allowed to go.
• Internet Gateway — attached to the VPC so that resources in public subnets can reach, and be reached from, the internet.
• NAT Gateway — lets resources in private subnets initiate outbound internet connections (for updates, API calls) without accepting inbound connections.
• Security groups — stateful, instance-level firewalls that control inbound and outbound traffic for specific resources.
• Network ACLs (NACLs) — stateless, subnet-level firewalls that act as a second layer of filtering.

Public subnet vs. private subnet

A subnet is "public" simply because its route table sends internet-bound traffic (0.0.0.0/0) to an Internet Gateway — nothing more. A subnet is "private" when its route table has no direct path to an Internet Gateway, usually routing outbound traffic through a NAT Gateway instead. This distinction is the core design decision in almost every AWS architecture: put anything that must be reachable from the internet (a load balancer, a bastion host) in a public subnet, and keep anything that holds data or runs business logic (application servers, databases) in a private subnet.

A simple VPC design you'll see everywhere

Most production setups follow the same pattern, repeated across two or three Availability Zones for redundancy:

1. A public subnet per AZ holding an Application Load Balancer and, if needed, NAT Gateways.
2. A private subnet per AZ holding EC2 instances or containers behind the load balancer.
3. A further-isolated private subnet per AZ holding the RDS database, with security groups that only allow traffic from the application subnet.

This three-tier layout shows up in the AWS Well-Architected Framework, in SAA-C03 exam scenarios, and in almost every real job's infrastructure — so it's worth being able to draw and explain from memory, not just recognise on a diagram.

Where VPCs show up on the AWS exams and in interviews

VPC questions are heavily weighted on AWS Certified Solutions Architect – Associate (SAA-C03) and come up constantly in DevOps and cloud engineering interviews. Common questions include: how do you connect two VPCs (VPC Peering or Transit Gateway), how do you connect a VPC to an on-premises network (Site-to-Site VPN or Direct Connect), what's the difference between a security group and a NACL, and why would a private subnet still need a NAT Gateway if it has no internet-facing traffic coming in.

The fastest way to actually learn this

Reading about VPCs only gets you so far — the concepts click once you build one by hand. Create a VPC from scratch with public and private subnets across two AZs, attach an Internet Gateway and a NAT Gateway, launch an EC2 instance in each subnet, and test which one can reach the internet and which one can't. Break it on purpose (remove a route, tighten a security group) and figure out why traffic stopped. That hands-on cycle is exactly what separates candidates who can recite the definition from ones who can design and defend a network architecture in an interview.