VPC — your private data centre in the cloud
A cloud provider packs millions of customers onto the same hardware. Your VPC is the wall around your slice of it — the thing that makes shared infrastructure feel like a private network you own.
What a VPC is
A VPC (Virtual Private Cloud) is a logically isolated slice of a cloud provider's network that's yours to shape. You pick a CIDR range — say 10.0.0.0/16 — and everything you build inside it (subnets, servers, load balancers, databases) lives in that private space. Nothing on the outside can reach in unless you open a door for it.
AWS calls it a VPC. Google Cloud calls it a VPC too. Azure went with VNet (Virtual Network). Different label on the tin, same thing inside.
The anatomy of a typical VPC
What you get in a VPC
Your own IP range
You pick the CIDR, usually a private RFC 1918 range. It's yours alone — nothing outside the VPC touches it.
Your own subnets
Carve that range up across Availability Zones and roles — public, private, db.
Full routing control
Route tables decide where each subnet's traffic goes — out to the internet, over to another subnet, across to a peer VPC, or back to your on-prem network over a VPN.
Isolation from other tenants
The hardware underneath is shared, but the provider guarantees your VPC's traffic never mingles with anyone else's.
Availability Zones — planning for outages
Every serious cloud region is split into multiple Availability Zones (AZs) — physically separate data centres in the same region, wired together with low-latency links. Spread your subnets across at least two AZs and run app instances in both. When one AZ goes dark, the other keeps serving traffic and nobody notices.
Connecting VPCs to other places
| Need | How |
|---|---|
| VPC ↔ internet | Internet Gateway (public), NAT Gateway (private outbound only) |
| VPC ↔ another VPC (same cloud) | VPC Peering, Transit Gateway |
| VPC ↔ on-premises | Site-to-site VPN, Direct Connect / ExpressRoute |
| VPC ↔ cloud managed service (S3, RDS) | VPC Endpoint / PrivateLink — traffic stays on the cloud backbone |
Say VPC A peers with B, and B peers with C. You'd expect A to reach C through B — it can't. VPC peering is strictly one-hop. When you need many-to-many, reach for a Transit Gateway (or a hub-and-spoke design).
A minimal Terraform-style sketch
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
enable_dns_hostnames = true
tags = { Name = "prod" }
}
resource "aws_subnet" "public_a" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.1.0/24"
availability_zone = "eu-west-1a"
map_public_ip_on_launch = true
}When a customer says "these two servers can't talk to each other," start with the boring question: are they even in the same VPC? Resources in separate VPCs can't reach each other at all until someone sets up peering — and remember, peering doesn't chain. If they are in the same VPC, the local route already wires them together, so the culprit is almost always a Security Group or NACL, not the network itself.
Key takeaways
- A VPC is your own isolated slice of the cloud provider's network.
- Pick your CIDR up front, then carve subnets across at least two AZs.
- Public subnets have a route to the internet; private ones don't.
- To reach other VPCs, your on-prem network, or managed services, pick the right connection primitive for each.
- It's the same idea whether you're in AWS/GCP (VPC) or Azure (VNet).