What is a virtual private cloud (VPC)? Explained simply
A virtual private cloud (VPC) is your own logically isolated network within a public cloud, where you control the IP address ranges, subnets, routing and security boundaries for your resources. The public cloud is, by definition, shared infrastructure — your virtual machines run in the same data centres as everyone else’s — and a VPC is the mechanism that makes your slice of it private: nothing can reach your resources except by paths you have explicitly created. AWS calls this a VPC; Azure calls the same idea a Virtual Network, or VNet. Almost everything you deploy in either cloud lives inside one, which is why cloud networking is both a foundational concept and one of the most heavily tested areas on associate-level certification exams. This article explains the problem a VPC solves, its building blocks in plain English, and how traffic actually gets in and out.
The problem a VPC solves
In a traditional data centre, isolation was physical: your servers sat in your building, behind your firewall, on cables you owned. The public cloud removes all of that — compute, storage and networking are shared services running on hardware you will never see. That efficiency is the whole point of cloud, but it raises an obvious question: if everyone’s workloads run on the same infrastructure, what stops someone else’s traffic reaching your database?
The answer is logical isolation. A VPC gives you a software-defined network that behaves as if it were physically yours: you choose its private IP address space, divide it into segments, decide what routes exist, and define exactly what traffic may cross its boundary. Two customers’ VPCs can run on the same physical hosts and remain completely invisible to each other. You get the economics of shared infrastructure with the isolation of a private network — which is precisely what the name promises.
The building blocks, in plain English
A VPC is assembled from a small set of components, and understanding what each one is for matters far more than memorising syntax:
- Subnets — subdivisions of the VPC’s address space, each living in one availability zone. A public subnet has a route to the internet; a private subnet does not, and is where databases and internal services belong.
- Route tables — the rules that decide where traffic from a subnet is sent next. A subnet is only “public” because its route table says internet-bound traffic goes to an internet gateway.
- Internet gateway — the VPC’s door to the public internet, allowing resources with public addresses to be reached from outside and to reach out.
- NAT gateway — the one-way door: it lets resources in private subnets initiate outbound connections (to download updates, say) while remaining unreachable from the internet.
- Security groups — virtual firewalls attached to individual resources, controlling which traffic may reach each one. They are stateful: if a request is allowed in, the reply is allowed out automatically.
- Network ACLs — a second, subnet-level filter that evaluates traffic entering or leaving a whole subnet. They are stateless, so rules must cover both directions, and they act as a coarse safety net beneath the finer-grained security groups.
How traffic flows in and out
Follow one request and the pieces click together. A user on the internet sends a request to your web application. It arrives at the internet gateway, and the routing you configured delivers it to a web server in a public subnet — but only if that server’s security group permits the traffic. The web server then needs data, so it calls the database sitting in a private subnet. That hop never leaves the VPC: it travels over the private network, allowed because the database’s security group accepts connections from the web tier and nothing else.
The reply retraces the path. Meanwhile, when the database server needs to fetch a software patch, it cannot be reached from the internet — but its outbound request can leave through the NAT gateway, which forwards it out and returns the response. The pattern this creates — a public tier that faces the world and a private tier that faces only the public tier — is the default architecture for almost everything deployed in the cloud, and exam questions return to it constantly.
AWS VPC and Azure Virtual Network
The concept is vendor-neutral, and both major clouds implement it with near-identical shapes. AWS calls it a VPC; Microsoft Azure calls it a Virtual Network (VNet). Both give you a private address space carved into subnets, routing you control, and layered firewalls — Azure’s network security groups play the role AWS splits between security groups and network ACLs, applied to subnets or individual network interfaces.
The mental model transfers almost entirely between the two, which is good news if you study both platforms: learn the concepts once, then learn each vendor’s names and boundaries. Both clouds also let you connect these private networks onwards — to each other (peering), to your office or data centre (VPN or dedicated private links), and to cloud services without touching the public internet (private endpoints). Those connections are the bridge topics that turn a single-network diagram into real enterprise architecture.
Why it is fundamental to security and architecture
Network design is the first security decision you make in the cloud, because it defines what is reachable at all. A database that sits in a private subnet with a security group admitting only the application tier is protected by architecture — even if an attacker discovers its address, no network path exists. Security reviews of cloud incidents repeatedly come back to the same root causes: resources placed in public subnets that never needed to be, and firewall rules left wide open. A well-designed VPC makes the secure configuration the default rather than an afterthought.
It is also the skeleton every architecture hangs from. Highly available designs spread subnets across multiple availability zones — the regions-and-AZs idea covered in our explainer on that topic — so that the failure of one zone leaves the network standing. Whatever you go on to build, the VPC decisions come first, which is why they are worth genuinely understanding rather than memorising.
Where VPCs show up in certification study
Networking is one of the most heavily tested areas at associate level, on both vendors’ tracks. The AWS Solutions Architect Associate leans on VPC design constantly — scenario questions hinge on public versus private subnet placement, security groups versus network ACLs, NAT gateways, and multi-AZ layouts. The CloudOps Engineer Associate approaches the same components from the operations side: connectivity troubleshooting, flow analysis and routing problems. On the Microsoft side, the AZ-104 Azure Administrator exam gives virtual networking a full domain of its own — VNets, subnets, network security groups, peering and name resolution.
Foundational exams such as Cloud Practitioner and AZ-900 only expect the concept — what a VPC or VNet is and why isolation matters. If you are preparing at associate level, treat this article as the map and go deeper with the networking lessons in our revision sections, where the exam-level detail lives.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.