Cloud Fundamentals: VPCs and VNets Explained
Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI
The Planning Call That Almost Went Sideways
I was advising a client on their cloud architecture as they planned an Azure Red Hat OpenShift (ARO) deployment. Early in the planning phase, someone pulled up the client's existing network address ranges next to the new environment we were designing.
They overlapped.
Nothing was broken yet — we caught it before anything got deployed. But it meant a Microsoft networking engineer had to get pulled into the conversation before we could move forward. I have seen the exact same pattern show up on AWS engagements too. Different cloud, same root cause: whoever set up the original network picked an address range without thinking about what it might need to connect to later.
That planning call is the reason this article exists. If you understand how VPCs and VNets actually work — and why overlapping address ranges are such a common trap — you will catch this before it costs you weeks of rework.
The Gated Neighborhood
A VPC (AWS, GCP) or VNet (Azure) is your own private, fenced-off section of the cloud provider's network. Nobody else can just wander in, and by default, nothing inside can be reached from the outside.
Think of it like a gated neighborhood:
- The cloud provider is the country the neighborhood sits in
- Your VPC or VNet is the gated neighborhood itself — your property line
- Subnets are the streets inside the neighborhood
- A gateway is the front entrance where traffic gets in and out
- Security groups and firewall rules are the locks on each individual door
Diagram generated with AI assistance.
You do not get to build anything — a server, a database, a Kubernetes cluster — until you have decided where the streets go. That decision is your CIDR block (short for Classless Inter-Domain Routing) — the range of IP addresses your neighborhood is allowed to use.
This is exactly where my client's planning call ran into trouble. Two separate environments had each been handed the same kind of address range, without anyone checking whether those ranges would ever need to talk to each other.
Why Overlapping Address Ranges Break Everything
Here is the part that surprises people who are new to this: two networks with overlapping IP ranges cannot be connected. Not "connected with extra configuration." Cannot.
If your neighborhood and my neighborhood both have a street called "10.0.1.0," and we try to build a road between them, nobody's mail knows which house it is going to. Cloud routing works the same way. VPC peering, VNet peering, Transit Gateways — none of them can route traffic between two networks that claim the same address space, because the routing table cannot tell the two ranges apart.
This is not a rare edge case. It happens constantly during:
- Company mergers and acquisitions, when two organizations' networks need to connect
- Multi-cloud or hybrid-cloud projects, when an on-prem network needs to reach a cloud VPC
- Managed OpenShift deployments, like the ARO example above, where the cluster's network has to coexist with whatever else the client already has running
Catching it during planning, like we did on that ARO engagement, means a design conversation. Catching it after deployment means re-architecting a live environment — the same kind of expensive, undocumented rework we covered in Infrastructure as Code, just one layer down the stack.
The Same Shape, Three Different Clouds
Every major cloud provider uses the same basic idea — an isolated network you carve into subnets — but the specific rules differ, especially once you add managed Kubernetes into the picture.
AWS — VPC
A VPC is regional. Each subnet inside it lives in a single availability zone, so you create separate subnets in different zones for redundancy, and decide which ones are public (reachable from the internet) and which are private.
Azure — VNet
A VNet works the same way conceptually. This is the environment from my client story — the CIDR block for the VNet has to be planned carefully before an ARO cluster ever gets deployed into it, because that address space has to coexist with whatever else the client is already running.
GCP — VPC (with a twist)
GCP's VPCs are global rather than regional, which is a real structural difference from AWS and Azure. Subnets are still regional, and you still reserve dedicated, non-overlapping ranges for whatever you deploy — the same planning discipline applies, just with a different top-level shape.
Three different providers, three slightly different rule sets — but the same underlying question every time: have you reserved enough non-overlapping address space for everything this network needs to talk to?
Quick Recap
Here is everything we covered today:
- A VPC or VNet is your own isolated, fenced-off network inside a cloud provider — nothing gets in or out until you decide how
- CIDR blocks define the address range your network is allowed to use, and they have to be planned before you build anything on top
- Overlapping CIDR blocks cannot be connected — not with extra configuration, not with a workaround. Peering and routing tables cannot tell two identical ranges apart
- This shows up constantly in mergers, hybrid-cloud connections, and managed OpenShift deployments like ARO
- AWS VPCs and Azure VNets are regional and follow a similar subnet model
- GCP VPCs are global rather than regional — a real structural difference, though the planning discipline is the same across all three
What's Next
Article 12 — IAM and Identity Across Clouds
Now that you understand how cloud networks are fenced off, the next question is who gets to walk through the gate. In Article 12 we cover IAM — the system that decides which users and services can actually do anything once they are inside your VPC or VNet.
Written by Pipeline & Prompts | Byte size guides on DevOps, Cloud and AI
Found this useful? Share it with someone about to plan their first cloud network — and save them the planning call I had to sit through. Follow along for a new article every week.
Top comments (0)