What Is a VPC in AWS? Simple Explanation, Core Components, and Example

Simple explanation

Before AWS, you built networks in physical data centers: routers, switches, and firewalls managed by hand. A VPC replaces that physical infrastructure with software-defined networking. You get a private IP address space, and AWS gives you the tools to control every traffic path inside it.

When you create a VPC, you assign it a CIDR block like 10.0.0.0/16. That range is the address space for everything that runs inside it. You divide that range into subnets, each tied to a specific Availability Zone, and place your resources (EC2 instances, databases, containers) into those subnets.

The VPC itself does not route traffic to the internet by default. You attach an internet gateway for public access, add a NAT gateway for private outbound access, and write route tables to direct packets where they need to go. Security groups act as instance-level firewalls on top of all that. That combination of isolated address space, controlled routing, and layered firewall rules is what makes a VPC the foundation of nearly everything you build in AWS.

Why this matters

Without network isolation, any resource in AWS could potentially receive traffic from any other resource. A VPC creates a hard boundary around your infrastructure. Resources inside communicate over private IPs, and traffic crossing the boundary passes through gateways, route tables, and firewall rules you control.

Understanding VPCs is not optional knowledge. It underpins almost everything in AWS. Every EC2 instance, load balancer, RDS database, EKS cluster, and Lambda function running inside a VPC inherits this networking foundation. Getting it wrong creates security gaps and connectivity problems that are painful to diagnose later.

How a VPC works

Here is how traffic moves through a typical VPC when a user accesses a web application:

1. Request arrives. A user’s browser sends a request to your application’s public IP or domain name.
2. Internet gateway receives it. The internet gateway (IGW) attached to your VPC accepts the inbound connection. Without an IGW, no public internet traffic can enter the VPC at all.
3. Route table directs the packet. The route table for the public subnet has an entry sending internet-bound traffic to the IGW and local VPC traffic directly to the target. Route tables decide the path; they do not filter.
4. Security group evaluates the connection. Before the packet reaches your application, the security group attached to the resource checks whether the source IP and port are allowed. If no rule matches, the packet is dropped.
5. Private resources stay off the internet. Your database or app tier sits in a private subnet with no route to the IGW. It is only reachable from other resources inside the VPC, not from the public internet.
6. Private outbound traffic uses a NAT gateway. If a resource in a private subnet needs to call an external API or download a package, the request goes through a NAT gateway in a public subnet. The NAT gateway forwards the request and returns the response without exposing the private resource’s IP address.

Core components inside a VPC

CIDR blocks: defining your IP space

When you create a VPC, you assign it a CIDR block. A notation like 10.0.0.0/16 defines the pool of private IP addresses available inside it. The number after the slash is the prefix length; a shorter prefix means more addresses.

• A /16 provides 65,536 addresses. This is the most common starting size for a production VPC.
• A /24 provides 256 addresses. Too small for most VPCs.
• A /28 provides 16 addresses. The smallest block AWS allows.

Use addresses from the RFC 1918 private ranges: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. The 10.x.x.x space is the most common choice for AWS VPCs.

AWS reserves 5 IP addresses in every subnet: the first four and the last. A /24 subnet gives you 251 usable IPs, not 256. A /28 gives you 11 usable IPs, not 16.

Minimal example architecture

Here is a simple two-tier layout for a production web application: one VPC, two Availability Zones, public and private subnets separated by purpose.

VPC: 10.0.0.0/16

Public subnets (one per AZ):

• 10.0.0.0/24 in AZ-1, 10.0.1.0/24 in AZ-2
• Route table sends 0.0.0.0/0 to the internet gateway
• Hosts the load balancer, the only internet-facing component

Private subnets (one per AZ):

• 10.0.2.0/24 in AZ-1, 10.0.3.0/24 in AZ-2
• Route table sends 0.0.0.0/0 to the NAT gateway for outbound access
• No route to the internet gateway. These subnets are not publicly reachable.
• Hosts application servers and databases

Gateways:

• One internet gateway attached to the VPC
• One NAT gateway placed in a public subnet, with an Elastic IP assigned

Security groups:

• Load balancer SG: allow inbound 80/443 from anywhere (0.0.0.0/0)
• App server SG: allow inbound only from the load balancer SG, not from the internet directly
• Database SG: allow inbound only from the app server SG

This keeps your app and database off the public internet while allowing outbound access from private resources. It is the standard baseline for most applications and a good mental model before you explore more advanced patterns like shared VPC architectures.

Default VPC vs custom VPC

AWS automatically creates a default VPC in every region when you open an account. It is convenient for learning because you can launch an EC2 instance with zero networking setup. For production, create your own. See the full comparison on the Default vs Custom VPCs page.

When to use a custom VPC

You almost always want a custom VPC for anything beyond quick experiments. Here are the specific situations where the design decisions matter most:

• Public web applications. Put your load balancer in a public subnet, your application servers in private subnets, and your database in an isolated subnet with no outbound internet route.
• Private backends. Internal APIs or processing services that should never be directly reachable from the internet. Place them in private subnets and restrict them with security groups.
• Databases. RDS, Aurora, and ElastiCache should almost always live in private subnets with no public IP. Restrict inbound access to the application tier only.
• Hybrid connectivity. When connecting AWS to on-premises infrastructure via Site-to-Site VPN or Direct Connect, your VPC CIDR must not overlap with on-premises IP ranges. See the hybrid connectivity overview for the full picture.
• Multi-VPC architectures. When multiple VPCs need to communicate via VPC Peering or Transit Gateway, each VPC must have a unique, non-overlapping CIDR. Plan the full IP allocation strategy before you create any VPC.
• Container workloads. EKS clusters running inside a VPC use the VPC CNI plugin, which allocates pod IP addresses directly from subnet CIDR blocks. VPC sizing and subnet design have a direct impact on cluster capacity in ways that do not apply to most EC2 workloads.

VPC vs subnet vs security group

These three concepts operate at completely different levels. Beginners often conflate them because they all relate to controlling access.

The VPC provides the address space. Subnets divide that space and determine placement and routing. Security groups control access at the resource level. All three work together and you need all three to build a functional, secure architecture.

Creating a VPC with Terraform

This creates a VPC with DNS hostnames enabled and attaches an internet gateway. DNS support is on by default; enabling dns_hostnames is almost always needed for EC2 public DNS names and service name resolution.

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name        = "main-vpc"
    Environment = "production"
  }
}

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "main-igw"
  }
}

Creating a VPC with the AWS CLI

# Create the VPC
aws ec2 create-vpc \
  --cidr-block 10.0.0.0/16 \
  --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=main-vpc}]'

# Enable DNS hostnames (DNS support is already on by default)
aws ec2 modify-vpc-attribute \
  --vpc-id vpc-0123456789abcdef0 \
  --enable-dns-hostnames

# Create and attach an internet gateway
aws ec2 create-internet-gateway \
  --tag-specifications 'ResourceType=internet-gateway,Tags=[{Key=Name,Value=main-igw}]'

aws ec2 attach-internet-gateway \
  --vpc-id vpc-0123456789abcdef0 \
  --internet-gateway-id igw-0123456789abcdef0