What Is a VPC? Virtual Private Clouds Explained

A VPC, or virtual private cloud, is an isolated, software-defined network carved out of a public cloud provider’s shared infrastructure. It gives an account its own private IP address range, subnets, route tables, and gateways — the same building blocks as a traditional data center network, except defined entirely in configuration rather than wired by hand. Every major cloud provider offers one, and almost nothing else gets provisioned before it: a VPC is the network that everything else — servers, databases, load balancers — plugs into.

Why isolation matters in a shared cloud

Public clouds run enormous numbers of customers’ workloads on the same physical hardware and network fabric. Without isolation, one customer’s traffic could in principle interfere with or observe another’s. A VPC solves this at the networking layer: even though the underlying hardware is shared, each VPC gets its own private address space, and traffic inside it is invisible to every other account by default. Two different companies can both use the 10.0.0.0/16 address range in their own VPCs with zero conflict, because the ranges only have meaning within their own isolated network.

This isolation is what makes it safe to run a database with no public IP at all — reachable only from other resources inside the same VPC, the way a bastion host is often the only machine with a route in from the outside.

The building blocks

A VPC is made of a handful of composable pieces:

• CIDR block. The VPC’s overall private IP address range, like 10.0.0.0/16 — roughly 65,000 addresses to carve up.
• Subnets. Smaller slices of that range, each pinned to a single availability zone. A common pattern is a public subnet (has a route to the internet) and one or more private subnets (does not) within each zone.
• Route tables. Rules that decide where traffic from a subnet goes — to the internet, to another subnet, to a VPN, or nowhere.
• Internet gateway. Attached to the VPC to give public subnets a path to and from the public internet.
• NAT gateway. Lets resources in a private subnet initiate outbound connections (for software updates, API calls) without accepting any inbound connections from the internet.
• Security groups and network ACLs. Firewall rules — security groups apply per-resource and are typically stateful (a response to an allowed inbound request is automatically allowed back out); network ACLs apply per-subnet and are typically stateless, requiring explicit rules in both directions.

Public vs private subnets

The public/private subnet split is the core design decision in almost every VPC layout. Public subnets host things that need to be reachable from the internet — load balancers, bastion hosts, reverse proxies. Private subnets host everything that doesn’t — application servers, databases, internal caches — and rely on a NAT gateway for the outbound-only internet access they still need for patching and third-party API calls.

	Public subnet	Private subnet
Route to internet gateway	Yes	No
Reachable from the internet	Yes (if a public IP is assigned)	No
Outbound internet access	Direct	Via NAT gateway only
Typical residents	Load balancers, bastion hosts	App servers, databases

Connecting VPCs to each other and to on-prem networks

Real infrastructure rarely lives in a single VPC. VPC peering connects two VPCs directly so resources in each can reach the other over private IPs, without the traffic ever touching the public internet — useful for splitting a large system across accounts or environments while still letting services talk to each other. At larger scale, a transit gateway acts as a central hub so dozens of VPCs can interconnect without a full mesh of individual peering connections between every pair.

Connecting a VPC back to a physical data center or office network typically goes through a site-to-site VPN or a dedicated private circuit, extending the same private-address-space model across the boundary between “cloud” and “everything else” the organization already runs.

VPCs and DNS, load balancing, and other services

A VPC is the network layer; most other cloud services attach to it rather than replacing it. A managed database still runs inside a private subnet with a security group controlling which resources can reach its port. A load balancer usually spans multiple public subnets across availability zones for redundancy, then forwards traffic inward to backend instances in private subnets. Internal DNS resolution inside a VPC typically resolves private hostnames to private IPs automatically, separate from public DNS.

Common misconfigurations

• Overly permissive security groups. A rule allowing inbound traffic from 0.0.0.0/0 on a database port defeats most of the point of putting it in a private subnet in the first place.
• Forgetting NAT costs and bottlenecks. NAT gateways are typically billed per hour and per gigabyte processed, and a single one can become a throughput bottleneck for a large fleet of private-subnet instances if not sized or distributed correctly.
• Overlapping CIDR ranges. Two VPCs that need to be peered later but were provisioned with the same address range require an unpleasant re-addressing exercise. Planning non-overlapping ranges up front avoids this.
• Single-AZ subnets. Placing all subnets in one availability zone removes the redundancy a multi-zone cloud region is designed to provide.

The takeaway

A VPC is the private, software-defined network every other cloud resource sits inside — subnets, route tables, and gateways standing in for the routers and cabling of a physical data center. Getting the public/private subnet split right, keeping security group rules tight, and planning non-overlapping address ranges up front are the decisions that matter most; nearly everything else in a cloud architecture is built on top of whatever those choices establish.