Azure VNet vs AWS VPC vs GCP VPC
The networking vocabulary maps across the three clouds almost perfectly. Almost. The one row that doesn't is the shape of the network itself.
New to cloud? CAMPUX is a free, build-first course. Start here →
An Azure VNet, an AWS VPC, and a GCP VPC network are the same thing: a private software-defined network you carve into subnets, control with route tables and firewall rules, and connect out with peering or a VPN. Nearly every term maps 1:1. The one real difference is the network's regional scope — an Azure VNet is regional with zone-spanning subnets, an AWS VPC is regional but each subnet is pinned to one availability zone, and a GCP VPC is global. Get that one row wrong and you design the wrong subnet layout.
Networking is the friendliest chapter to cross between clouds, which is a relief after the account and identity models where almost nothing lines up. Here the primitives really are synonyms — private network, subnet, route table, firewall, gateway, peering. You can read most of the table straight across in an afternoon. So this piece is short on the mapping and long on the single place it lies, because that place genuinely costs people a redesign.
The mapping, term for term
Same building blocks on all three: a private address space, subnets inside it, something to filter traffic, something to route it, and a few ways to connect the network to other networks and to on-premises. Here's the glossary.
| Concept | Azure | AWS | GCP |
|---|---|---|---|
| Private network | Virtual network (VNet) | VPC | VPC network |
| Subnet | Subnet | Subnet | Subnet |
| Host / resource firewall | Network Security Group (NSG) | Security Group | VPC firewall rules |
| Subnet-level stateless filter | NSG does both (subnet or NIC) | Network ACL | Firewall rules + hierarchical policies |
| Route table | Route table | Route table | Routes |
| Network-to-network peering | VNet peering | VPC peering | VPC Network Peering |
| Site-to-site to on-prem | VPN Gateway | VPN Gateway (Site-to-Site) | Cloud VPN |
| Private dedicated link | ExpressRoute | Direct Connect | Cloud Interconnect |
| Outbound NAT | NAT Gateway | NAT Gateway | Cloud NAT |
| Private access to a service | Private Endpoint / Private Link | VPC Endpoint (PrivateLink) | Private Service Connect |
Read that top to bottom and you'll notice how little needs a footnote. Subnet is subnet. A route table is a route table. Peering is peering. If this were the whole story I'd send you back to the hub and call it done. But two rows have asterisks — the subnet, and the firewall — and one of them is the reason this article exists.
The leak: what "regional" means changes the subnet
All three networks have a scope — the geography they live in — and this is the row every cheat sheet flattens. It isn't cosmetic. The scope decides how you lay out subnets and whether you need peering to reach another region, and it's different on each cloud.
Azure VNet — regional, subnets span the zones
A VNet lives in exactly one region. Inside it, a subnet is not tied to an availability zone — a subnet spans all the zones in the region, and you place a resource in a zone when you deploy the resource, not by choosing a zonal subnet. So on Azure you carve subnets by tier — web, app, data — and let the platform spread instances across zones. To reach a VNet in another region, you use VNet peering. This is the model taught in the virtual networks and subnets class.
AWS VPC — regional too, but each subnet is pinned to one AZ
An AWS VPC is also regional, so far so familiar. Here's the surprise coming from Azure: every subnet belongs to exactly one availability zone. A subnet cannot span AZs. That means high availability on AWS is a thing you build in the subnet layout — you deliberately create one subnet per AZ (a web subnet in us-east-1a, another in us-east-1b, and so on) and spread instances across them. On Azure you'd never make a subnet per zone; on AWS you must. Same word, "subnet," opposite habit.
GCP VPC — global, subnets are regional inside it
GCP breaks the frame entirely. A VPC network is a global object — one VPC spans every region on the planet. Subnets inside it are regional. So two VMs in different regions of the same VPC talk over private IP with no peering at all. Coming from Azure or AWS this feels wrong the first time; you go hunting for the peering step to connect region A to region B and there isn't one, because they were never separate networks to begin with.
On Azure you carve subnets by tier and let zones sort themselves out. On AWS you carve one subnet per zone by hand. That's the whole surprise.
"VNet = VPC = VPC" is true for the network object and almost everything hanging off it. What does not carry across is the scope. Azure: regional network, zone-spanning subnets — design by tier. AWS: regional network, one subnet per availability zone — design your own multi-AZ spread. GCP: global network, regional subnets — no peering needed between regions. If you copy an Azure subnet plan onto AWS you'll end up with no zone redundancy; if you copy an AWS plan onto GCP you'll build peering you never needed.
The smaller asterisk: where the firewall attaches
The other row worth a beat is the firewall. All three filter traffic to your resources, but the thing you attach and where you attach it differ, and that shapes how you reason about a rule.
- Azure NSG attaches to a subnet or to a NIC (or both) — you can filter at the boundary of a whole tier or right at one machine. One NSG type does the job an AWS Security Group and Network ACL split between them.
- AWS Security Group attaches to the instance (really its network interface) and is stateful; the stateless, subnet-level filter is a separate object called a Network ACL. Two mechanisms, two places.
- GCP firewall rules live at the network level and don't attach to a resource at all — they target resources by network tag or service account. You write "allow port 443 to anything tagged
web," and tagging a VM opts it in.
None of this is a leak on the scale of the regional model — it's the same idea with three attach points — but it's the second thing that catches people, so it's worth knowing before you go looking for a "security group" on Azure and find an NSG that behaves a little differently.
One more habit that differs: the default network
Small but real. AWS and GCP both hand you a default VPC in a fresh account or project, so you can launch an instance the minute you sign in. Azure does not — a new subscription has no VNet, and you create one before you can deploy anything that needs private networking. It's why an Azure tutorial opens with "first, make a VNet" and the AWS or GCP version skips straight to the VM. If you learn on Azure, you'll build the network by hand every time, which is a good habit to carry over; the default networks on the other two are a convenience you usually replace in production anyway.
So how should you actually approach it?
Learn the network on Azure, where you build the VNet and its subnets deliberately and the region-versus-zone split is clean: regional network, zonal placement decided per resource. Once that's solid, AWS is "same network, but I pin each subnet to an AZ myself," and GCP is "same network, but it's global so I stop thinking about peering across regions." The firewall rows follow the same pattern — one concept, re-learn the attach point. Everything else on the table you can read straight across without a second thought. That's the order we teach it, and it's why the concepts-first path carries between clouds so cheaply.
Common questions
Is an Azure VNet the same as an AWS VPC?
Almost — both are a private software-defined network you carve into subnets, control with routing and firewall rules, and connect out to other networks or on-premises. The one real difference is the subnet. An Azure VNet is regional and its subnets span all the zones in that region, so you don't design a subnet per zone. An AWS VPC is regional too, but every subnet is pinned to a single availability zone, so on AWS you deliberately create one subnet per AZ. Same network, different subnet rule.
Why is a GCP VPC global when Azure and AWS are regional?
It's a genuine design difference, not a mislabel. A GCP VPC network is a global object — one VPC spans every region, and each subnet inside it is regional. That means two workloads in different regions of the same VPC talk over private IPs with no peering. On Azure and AWS the network is scoped to one region, so you connect networks in different regions with peering (VNet peering, VPC peering). Coming from Azure or AWS, the GCP model feels wrong at first because you go looking for a peering step that isn't there.
What is the AWS or GCP equivalent of a Network Security Group?
An Azure Network Security Group maps to an AWS Security Group and to GCP VPC firewall rules — all three filter traffic to and from your resources. But the attach point differs. An NSG attaches to a subnet or to a NIC. An AWS Security Group attaches to the instance or its network interface, and AWS adds a separate stateless subnet-level filter called a Network ACL. GCP firewall rules live at the network level and target resources by network tag or service account rather than by attaching to one. Same job, three attach models.
Do the three clouds create a default network for you?
AWS and GCP both create a default VPC in a new account or project so you can launch something immediately. Azure does not — a new subscription has no VNet, and you create one before you can deploy resources that need private networking. It's a small thing, but it's why an Azure walkthrough starts with "first, make a VNet" while an AWS or GCP one can skip straight to launching an instance.