The Virtual Office Building
Imagine the public cloud (like AWS, Azure, or Google Cloud) as a gigantic, infinitely tall skyscraper owned by the provider. Everyone rents space in this building.
If you just threw your servers into this building randomly, they would be sitting in the hallway, accessible to anyone walking by. That's terrible for security.
A Virtual Private Cloud (VPC) is like renting an entire private floor in that skyscraper. You get to lock the doors to the main hallway. Inside your floor, you decide where the walls go, who gets which office, and most importantly, how people get in and out.
A VPC is your logically isolated virtual network in the cloud. You define the IP address range, create subnets (departments), configure route tables (hallway directions), and network gateways (doors to the outside world). It is the fundamental building block of cloud networking. Every resource you deploy in the cloud — virtual machines, databases, load balancers — lives inside a VPC, whether you explicitly created one or the cloud provider created a default one for you.
Why Not Just Use the Default VPC?
Every AWS account comes with a default VPC in each region. It works out of the box and is fine for experimentation. However, the default VPC is configured for convenience, not security: all subnets are public by default, and resources get public IP addresses automatically. Production workloads should always live in a custom VPC designed with explicit security boundaries, controlled routing, and a deliberate IP address plan.
Interviewers frequently ask: "What's the difference between a VPC and a subnet?" A strong answer: a VPC is the entire isolated network boundary — it defines the total IP address space and the logical isolation from other networks. A subnet is a subdivision of that space, tied to a specific Availability Zone, used to further segment resources by function and exposure level (public vs. private). The VPC is the building; subnets are the floors.