A VPC (virtual private cloud) is a logically isolated virtual network inside a public cloud in which the customer defines its own private IP address range, divides it into subnets, and controls routing and traffic filtering for the resources it contains. It is the foundation of cloud networking: virtual machines, containers, managed databases and load balancers are placed into a VPC, and every packet they send is governed by its rules.
The isolation is enforced by the provider’s software-defined network, not by dedicated hardware. Many customers share the same physical infrastructure, yet traffic from one VPC cannot reach another unless an administrator explicitly connects them. Azure uses the name virtual network (VNet) for the same concept, while AWS and Google Cloud use VPC.
How a VPC is built
A VPC starts with an address space in CIDR notation, usually taken from the private ranges defined in RFC 1918: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. The administrator then carves that space into subnets and attaches the components that decide where traffic may go.
| Component | Function | Key behavior |
|---|---|---|
| Subnet | Slice of the VPC address range | Bound to one zone or region, depending on provider |
| Route table | Decides the next hop for each destination | Most specific prefix wins |
| Internet gateway | Connects the VPC to the public internet | Enables inbound and outbound public traffic |
| NAT gateway | Lets private resources reach the internet | Outbound only, hides private addresses |
| Security group | Firewall attached to a network interface | Stateful, allow rules only |
| Network ACL | Firewall attached to a subnet | Stateless, allow and deny rules |
A subnet is called public when its route table sends 0.0.0.0/0 to an internet gateway, and private when it does not. This distinction is purely a matter of routing, which is why one misconfigured route can expose resources that were meant to stay internal.
Address planning and subnet sizing
IP address planning is the VPC decision that is hardest to reverse. Ranges that overlap with on-premises networks or other VPCs cannot be peered or routed cleanly, so large organizations allocate non-overlapping blocks centrally before the first VPC is created.
Providers also reserve addresses in every subnet for the network address, the router, DNS and broadcast. AWS and Azure reserve five addresses per subnet, and Google Cloud reserves four. The table applies the AWS rule to common prefix lengths.
| Prefix length | Total addresses | Usable addresses | Typical purpose |
|---|---|---|---|
| /16 | 65,536 | 65,531 | Entire VPC range, not usually one subnet |
| /20 | 4,096 | 4,091 | Large container or Kubernetes subnet |
| /24 | 256 | 251 | General application tier |
| /26 | 64 | 59 | Small database or management tier |
| /28 | 16 | 11 | Smallest allowed subnet in AWS |
Kubernetes clusters that assign VPC addresses to every pod can consume thousands of addresses quickly, which makes undersized subnets a frequent cause of failed scaling events.
How VPCs differ across major providers
The VPC concept is shared, but scope and defaults differ between providers, and designs copied from one cloud to another often break on these details.
| Aspect | AWS VPC | Azure VNet | Google Cloud VPC |
|---|---|---|---|
| Scope of the network | Regional | Regional | Global |
| Scope of a subnet | Single availability zone | Regional | Regional |
| Reserved addresses per subnet | 5 | 5 | 4 |
| Instance-level firewall | Security groups | Network security groups | VPC firewall rules |
| Peering transitivity | Not transitive | Not transitive | Not transitive |
A global Google Cloud VPC can span regions without peering, whereas AWS and Azure designs need one network per region connected through peering or a transit hub.
Connecting a VPC to other networks
A VPC is isolated by default, so every external path must be added deliberately. The right option depends on the number of networks, the required bandwidth and whether traffic may cross the public internet.
| Option | Connects | Main trade-off |
|---|---|---|
| VPC peering | Two VPCs, one to one | Simple, but not transitive and hard to scale |
| Transit gateway or hub | Many VPCs and on-premises sites | Central routing, extra per-gigabyte cost |
| Site-to-site VPN | VPC and on-premises network | Encrypted over the internet, variable latency |
| Dedicated interconnect | VPC and data center via private link | Stable bandwidth, longer setup and higher cost |
| Private endpoint | VPC and a managed service | Keeps service traffic off the internet |
Peering is non-transitive: if VPC A peers with B and B peers with C, A still cannot reach C. A full mesh of n VPCs needs n(n−1)/2 peerings, so 10 VPCs need 45 connections, which is why hub-and-spoke designs dominate at scale.
Security responsibilities inside a VPC
A VPC provides network isolation, not complete security. Under the shared responsibility model the provider secures the underlying fabric, while the customer is responsible for routes, firewall rules, exposure and monitoring.
Sound practice layers several controls: private subnets for workloads, least-privilege security groups that reference other groups instead of broad address ranges, flow logs for investigation, and private endpoints so that traffic to managed services never leaves the provider network. Network rules complement, but never replace, identity-based access control.
Common VPC design mistakes
Most VPC incidents stem from early design shortcuts that become expensive to undo once workloads are running.
- Overlapping CIDR ranges that block later peering or hybrid connectivity.
- Undersized subnets that run out of addresses during autoscaling.
- Default VPC in production, which often has public subnets and permissive settings.
- Rules open to 0.0.0.0/0 on administrative ports such as SSH and RDP.
- Single-zone layouts that turn one zone failure into a full outage.
- Unplanned NAT traffic, where data processing charges grow with every gigabyte leaving private subnets.
Explained without jargon
A VPC is like a private office floor in a shared building. The building, its power and its elevators belong to the cloud provider, but your floor has its own locked doors, its own room numbers and your own rules about who may enter.
Inside the floor you decide which rooms face the street and which stay internal. Nothing from another tenant’s floor can walk in unless you build a door on purpose. That is the core idea: shared infrastructure, private and controlled network space.
A typical use case
A retail company moves its online store to the cloud. The network team creates a VPC with the range 10.20.0.0/16 in one region and splits it across three availability zones. Each zone receives a small public subnet for the load balancer and NAT gateway, a /20 private subnet for application containers and a /24 private subnet for the database.
Only the load balancer accepts traffic from the internet. Application security groups allow inbound connections solely from the load balancer’s security group, and the database accepts traffic only from the application tier on its database port. A site-to-site VPN links the VPC to the warehouse system, whose range 10.50.0.0/16 was chosen to avoid overlap.
When one availability zone suffers an outage, traffic shifts to the remaining two. The store stays online, and the database is never reachable from the internet.