The Cloud Network Model - VPC, Region, AZ, Subnet
- A VPC (AWS, GCP) or VNet (Azure) is your own isolated layer 3 network on the provider's shared hardware: you pick the address space, subnets, routes and firewalls.
- A region holds several availability zones (separate data centres). A subnet is a CIDR slice, and where it lives differs per cloud: one AZ in AWS, a whole region in GCP and Azure.
- Every subnet loses a few addresses to the provider: 5 in AWS and Azure, 4 in GCP. A
/24gives 251 usable addresses in AWS. - Plan CIDRs once. A VPC's primary range cannot be resized, overlapping ranges cannot be peered or routed together, and every company picks
10.0.0.0/16. - "Public subnet" is a routing fact, not an addressing fact. Routes belong to the VPC routing page; this page owns the shape of the network.
Mental model
A VPC is an office building you lease floor by floor. The lease (your CIDR block) says which room numbers are yours. Each floor is a subnet, a wing of the building is an availability zone, and the building's city is the region. Other tenants share the same concrete and elevators, but they cannot walk into your floors, and you decide which doors face the street.
Where it breaks: in a real building the walls are physical. In a cloud the "walls" are software rules on the host, and two tenants can both be given the address "room 10.0.1.5" without ever meeting.
A VPC is a Linux network namespace plus a routing table plus iptables, that the provider hot-wires for you across thousands of hosts. The subnet is a prefix in that routing table. The provider's control plane writes the equivalent of ip route and iptables rules onto every hypervisor whenever you click a button.
Where it breaks: there is no real switch and no real layer 2. The "Ethernet" is an overlay (AWS runs it on its Nitro cards, GCP calls its stack Andromeda). There is no broadcast domain, so ARP is answered for you rather than flooded, and you cannot put a NIC in promiscuous mode to sniff a neighbour's traffic.
How it works
Start from the physical hierarchy, because every design decision sits on it.
- A region is a geographic area, for example
us-east-1in AWS oreurope-west1in GCP. - A region contains several availability zones (AZs): separate data centres (or groups of them) with independent power and cooling, joined by low-latency links. Spreading across zones survives a data-centre failure; spreading across regions survives a regional one. GCP and Azure also use the word zone.
- A VPC is the virtual network you create inside that hierarchy. You give it one or more CIDR blocks (the math is in IPv4 addressing and subnetting), then cut subnets out of it.
Worked example: carving a /16 into nine /24 subnets
The plan in the figure, checked with Python's ipaddress module:
| Tier | AZ 1 | AZ 2 | AZ 3 | Usable each (AWS) |
|---|---|---|---|---|
| Public (load balancers, NAT) | 10.0.0.0/24 | 10.0.1.0/24 | 10.0.2.0/24 | 251 |
| Private (application) | 10.0.10.0/24 | 10.0.11.0/24 | 10.0.12.0/24 | 251 |
| Data (databases) | 10.0.20.0/24 | 10.0.21.0/24 | 10.0.22.0/24 | 251 |
- The VPC
/16is 216 = 65,536 addresses. It splits into 256 possible/24blocks of 256 addresses each. - Nine
/24blocks use 9 x 256 = 2,304 addresses, about 3.5 percent of the VPC. The gaps (10.0.3.0to10.0.9.0, and so on) are left on purpose so each tier can grow without renumbering. - The tier offsets (0, 10, 20) are a convention, not a rule: the third octet tells you the tier at a glance in a flow log.
- Per subnet, AWS removes 5 addresses, so a
/24has 256 - 5 = 251 usable.
Reserved addresses per subnet
| Address (in 10.0.1.0/24) | AWS | GCP | Azure | Purpose |
|---|---|---|---|---|
| 10.0.1.0 (first) | Reserved | Reserved | Reserved | Network address |
| 10.0.1.1 | Reserved | Reserved | Reserved | Default gateway or VPC router |
| 10.0.1.2 | Reserved | Usable | Reserved | AWS: DNS resolver (base + 2). Azure: DNS mapping |
| 10.0.1.3 | Reserved | Usable | Reserved | Held for future use |
| 10.0.1.254 (second to last) | Usable | Reserved | Usable | GCP: held for future use |
| 10.0.1.255 (last) | Reserved | Reserved | Reserved | Broadcast (not supported, still reserved) |
| Total reserved | 5 | 4 | 5 | |
| Usable in a /24 | 251 | 252 | 251 |
Sources: AWS subnet sizing, GCP subnet ranges, Azure VNet FAQ.
Name map across the three clouds
| Concept | AWS | GCP | Azure | Gotcha |
|---|---|---|---|---|
| Private network | VPC (lives in one region) | VPC network (global) | Virtual Network, VNet (lives in one region) | A GCP VPC spans regions; the other two do not |
| Subnet scope | One AZ | One region, all its zones | Inside one VNet, spans all AZs of the region | Subnet-per-AZ is an AWS habit, not a law |
| Zone | Availability Zone | Zone | Availability Zone | AWS zone names are mapped per account; compare AZ IDs, not names |
| Internet path | Internet gateway you attach | Default route whose next hop is default-internet-gateway; nothing to attach | Default outbound path, public IPs, or a NAT gateway | GCP has no IGW resource |
| Reserved per subnet | 5 | 4 | 5 | Count them before sizing a tiny subnet |
| Smallest subnet | /28 (16 addresses) | /29 (8 addresses) | /29 (8 addresses) | A /28 leaves 11 in AWS |
| Sharing a network across accounts | VPC sharing (subnets shared with other accounts) | Shared VPC host project | Hub VNet plus peering | Different tools for the same sharing problem |
Name-map sources: AWS VPC CIDR blocks, GCP VPC overview, Azure VNet overview. For the GCP product view of the same ideas (subnet modes, firewall, Shared VPC, exam traps) read GCP ACE: VPC.
Where a subnet lives
What this means for high availability: in AWS you build one subnet per AZ per tier and put one replica in each. In GCP and Azure one subnet already covers every zone, so you choose the zone when you create each VM or resource, and the subnet is not the failure boundary.
Deep dive
Sizing and the allowed range
- AWS accepts a VPC primary block between
/16(65,536 addresses) and/28(16 addresses) (AWS docs). Subnets can be as small as/28too. - Azure subnets run from
/29down to/2, and IPv6 subnets must be exactly/64(Azure VNet FAQ). - GCP recommends keeping subnet ranges no larger than
/8and forbids ranges that overlap Google public IPs or reserved RFC blocks (GCP subnets).
| Prefix | Total addresses | Usable in AWS or Azure (minus 5) | Usable in GCP (minus 4) |
|---|---|---|---|
| /16 | 65,536 | 65,531 | 65,532 |
| /20 | 4,096 | 4,091 | 4,092 |
| /24 | 256 | 251 | 252 |
| /28 | 16 | 11 | 12 |
Quotas, as of 2026-10: AWS defaults to 5 VPCs per region, 200 subnets per VPC and 5 IPv4 CIDR blocks per VPC (adjustable up to 50). These move; read the live table in Amazon VPC quotas before you design around them.
The non-overlap rule
Two networks with overlapping ranges cannot be routed to each other: a router given 10.0.0.0/16 on both sides has no way to say which one 10.0.5.9 means. In Python, ip_network("10.0.0.0/16").overlaps(ip_network("10.0.5.0/24")) is True and overlaps(ip_network("10.1.0.0/16")) is False. AWS rejects peering between VPCs with overlapping CIDR blocks (VPC peering basics), and the same wall applies to transit gateways and VPN routes. GCP adds a trap: auto mode networks use subnets from 10.128.0.0/9, so a custom range inside that block cannot peer with them (GCP subnets).
So the rule is: allocate non-overlapping blocks centrally, before the first VPC exists, including blocks for on-premises networks you may connect later. Connection options are on private connectivity.
Growing a VPC: secondary CIDRs, not resizing
An AWS VPC's primary CIDR is fixed for life, and so is each subnet's. When you run out you add a secondary CIDR block to the VPC (up to the quota above) and create new subnets in it; the existing ones never change size (AWS docs). Your options when full are, in order of pain: new subnets from spare space inside the existing block, a secondary CIDR, IPv6 or prefix delegation, or a new VPC.
Kubernetes pods eat addresses
With the Amazon VPC CNI plugin every pod gets a real VPC IP from the node's subnet (EKS IP optimization guide). A /24 private subnet (251 usable) is therefore a node limit and a pod limit at once. Give the application tier far more room than the plan above: the same three AZs with a /20 each take 3 x 4,096 = 12,288 addresses, about 19 percent of the /16. EKS can also hand out /28 prefixes per network interface instead of single IPs (EKS prefix delegation). Pod networking in depth is on Kubernetes networking.
The default VPC
Every AWS region of an account has a default VPC with the range 172.31.0.0/16 and one /20 public subnet per AZ (AWS default VPC docs). It exists so the first run-instances call just works. Nobody should build production on it: the ranges are identical in every account and region, so they always overlap. Teams usually delete it or leave it empty and create their own.
IPv6 in a VPC
AWS assigns an IPv6 block to a VPC as a /56 and typically a /64 to each subnet (the subnet sizing page now also allows lengths from /44 to /64 in steps of 4), and you cannot pick the range yourself (AWS IPv6 docs). Because IPv6 addresses are globally unique and plentiful, there is no overlap problem, no secondary-CIDR dance and no NAT. AWS also reserves the first four and last address of each IPv6 subnet (subnet sizing). A dual-stack subnet carries both families; an IPv6-only subnet carries only IPv6. Azure subnets must be /64 for IPv6. Address format and structure: IPv6.
AZ names are not the same across accounts
AWS shuffles the mapping from zone name (us-east-1a) to physical zone per account, so your 1a may be a colleague's 1c. The stable identifier is the AZ ID (for example use1-az1). When two accounts must land in the same physical zone, compare IDs (AWS RAM docs on AZ IDs).
North-south versus east-west
North-south traffic crosses the VPC edge: users to a load balancer, a server to the internet through a NAT gateway. East-west traffic stays inside: service to service, app to database, pod to pod. In a microservice architecture most bytes move east-west, and the cross-AZ share is billed per gigabyte by AWS, so a chatty design that spreads callers across zones pays for it. East-west is also where lateral movement happens after a breach, which is why security groups restrict it (security groups vs network ACLs). Edge paths are covered in NAT gateways and egress.
Multi-account and hub-and-spoke
Large organisations run many accounts (or projects) rather than one giant VPC, to bound blast radius and billing (AWS: Organizing your environment using multiple accounts). Two VPCs in different accounts cannot reach each other until you connect them. The usual topologies:
- Hub and spoke: workload VPCs (spokes) attach to a central transit network (hub) that handles shared egress, inspection and on-premises links. AWS's product for the hub is Transit Gateway; the routing and attachment details belong to the routing and private-connectivity pages.
- Shared network: one account owns the VPC and shares subnets with others (AWS VPC sharing); GCP's equivalent is a Shared VPC host project with service projects.
Whichever shape you pick, the CIDRs come from one central allocator.
Textbook vs real world
| The textbook says | Production does | Why |
|---|---|---|
| A subnet is a broadcast domain | There is no broadcast; the virtual network answers ARP for you | The network is an overlay run by the hypervisor, not a switch fabric |
| A router is a box you configure | The VPC router is implicit, one per VPC, and you only edit route tables | The provider owns the data plane; your handle on it is the route table |
| 10.0.0.0/8 has room for everyone | Almost every team picks 10.0.0.0/16, so acquisitions and partner links collide | Defaults and tutorials all start with the same range; see the central allocator below |
| Subnets map to zones | True in AWS only; GCP and Azure subnets span zones | Each provider chose a different scope for the same word |
| Resize the network when it fills up | Add a secondary CIDR or build a new VPC | Primary CIDR blocks are immutable, and every route and firewall rule elsewhere refers to the old prefix |
| Public subnet means public IPs | Public subnet means a route to an internet gateway | Reachability is decided by routes, then by firewalls; the IP is only a precondition |
In production
- Central CIDR allocation. AWS ships VPC IPAM, a service that plans, tracks and enforces CIDR allocation across accounts and regions so no two VPCs get overlapping ranges (What is IPAM).
- Account vending. AWS Control Tower sets up a multi-account landing zone with guardrails, so each new account arrives with a network baseline (What is AWS Control Tower).
- Shared VPC host projects. On GCP a central team owns the VPC network in a host project and service projects attach workloads to it, so network policy stays in one place (Shared VPC).
- One network stack, software-defined. Google describes how its virtual networking is built, why it stays isolated and how it ships changes without downtime in the Andromeda paper (NSDI 2018).
History and evolution
- 1996 RFC 1918 reserves
10.0.0.0/8,172.16.0.0/12and192.168.0.0/16for private use, the three ranges every VPC still draws from. - 2006 EC2 launches on EC2-Classic: instances share one flat network with other customers. Isolation and your own address plan were not possible, which is what customers pushed back on.
- 2009 Amazon VPC launches, giving each customer a private address space, subnets and VPN to on-premises. Classic and VPC then ran side by side for over a decade.
- 2016 VPCs gain IPv6 (AWS announced it in December 2016), the first answer to running out of private IPv4 space.
- 2018 AWS adds Transit Gateway so many VPCs can hang off one hub instead of a mesh of peerings; multi-VPC and multi-account became the norm.
- 2021 IPv6-only subnets and VPC IPAM arrive in AWS, aimed at address exhaustion and overlap at scale.
- 2022 EC2-Classic is retired on 15 August 2022 (AWS announcement); every new instance lives in a VPC.
- Now GCP VPC networks are global, AWS VPCs and Azure VNets are regional, and all three support dual-stack addressing.
- Next IPv6-only subnets and centrally managed address planning reduce how much depends on one hand-picked
/16.
Hands-on
List what you have. Commands are real; output below is abbreviated and values are illustrative.
The second line is the default VPC. Now the subnets of one VPC with the AZ and the free-address count:
A fresh /24 shows 251 available, which is the 256 - 5 reserved arithmetic from above. The same listing on the other clouds:
In GCP the subnet list has a REGION column and no zone column, which is the regional scope made visible. In Azure the VNet row has a location and no zone.
Do the CIDR arithmetic locally (macOS and Linux, no ipcalc needed). This prints real output:
To see the AZ-to-AZ latency your account actually has, ping an instance in another zone. The cloud docs promise "low latency", not a number, so measure it.
Gotchas
Interview questions
Show answer
A VPC is your own isolated virtual network inside a cloud provider: you choose its IP range, cut it into subnets, and control routing and firewalls, all on shared physical infrastructure. You need it so your workloads sit on a private address space that only the paths you add can reach, rather than on a shared flat network. On a plain LAN you would own the cables and switches; here you own the rules, and the provider owns the wires.
Follow-ups:
- What is the default VPC? A pre-built VPC (172.31.0.0/16 in AWS) that lets your first instance launch with internet access; do not use it for production.
- How is it different from an on-prem LAN? There is no broadcast or real layer 2, routes are software tables, and capacity is elastic.
Show answer
A region is a geographic area. It contains several availability zones, which are separate data centres with independent power and cooling, connected by low-latency links. You spread across zones to survive a data-centre failure and across regions to survive a regional outage or to be closer to users.
Follow-ups:
- Why three AZs rather than two? With three you can lose one and still hold quorum or keep two-thirds of capacity, and consensus systems need an odd number.
- What is the latency between AZs? The docs promise low latency but give no fixed figure; measure it with ping between zones.
Show answer
A route in its route table sending 0.0.0.0/0 to an internet gateway. A public IP address alone is not enough, and neither is the subnet's name. A private subnet has no such route and reaches the internet, if at all, through a NAT device.
Follow-ups:
- Can an instance with a public IP in a private subnet be reached from the internet? No; with no route to the gateway the return path does not exist.
- Where do routes get explained in full? The VPC routing page.
Show answer
Usually a /16: 65,536 addresses is room for growth across tiers and AZs, and it is the largest block AWS allows. It must not overlap any other network you might connect, including on-premises and acquired companies. Subtract 5 reserved addresses per subnet, and remember Kubernetes pods consume one VPC address each.
Follow-ups:
- You ran out of IPs. What now? Use spare ranges inside the block, add a secondary CIDR, enable IPv6 or prefix delegation, or move to a new VPC.
- Why not take a
/8? AWS tops out at/16, and a huge block makes overlap with other teams more likely.
Show answer
In AWS a subnet lives in exactly one AZ and the VPC is regional. In GCP the VPC network is global and each subnet is regional, covering all zones. In Azure the VNet is regional and a subnet spans all AZs in that region. Reserved addresses differ too: 5 in AWS and Azure, 4 in GCP.
Follow-ups:
- What does that mean for HA design? In AWS you create one subnet per AZ per tier; in GCP and Azure you pick the zone per VM and one subnet covers them all.
- What does it mean when porting a design? Do not copy subnet counts across clouds; re-derive them from the failure domains you want.
Show answer
You cannot route or peer overlapping ranges, so you never peer them. In the short term, expose only the specific services each side needs, for example through PrivateLink-style endpoints or a NAT translation layer, so that neither side needs to see the other's address space. The long-term fix is to re-IP one side into a non-overlapping block, which is slow and risky. To stop it happening again, allocate every block from a central allocator such as IPAM before any VPC is created.
Follow-ups:
- Why does NAT help? It rewrites one side's addresses to something that does not collide, at the price of lost source identity and extra state.
- How do you prevent it? One IPAM, per-environment blocks, and a rule that nobody creates a VPC with a hand-picked range.
Show answer
Run one central allocator that carves a large private block into per-environment and per-region pools, then hands out a fixed-size block (say a /16 or /20) to each account on creation. Make the pools contiguous so each environment or region summarises into one route. Reserve space for on-premises and for future regions.
Follow-ups:
- What does summarisation buy you? A transit gateway route table can hold one prefix per environment instead of one per VPC, which keeps tables small and rules readable.
- What about growth? Leave unallocated space in every pool and allow secondary CIDRs from a second pool.
Fun facts
- The AWS VPC DNS resolver is at the VPC range base plus two (so
10.0.0.2for a10.0.0.0/16VPC) and also at the fixed link-local address169.254.169.253(AWS DNS docs). - The instance metadata service answers at the link-local address
169.254.169.254, an address that exists in no subnet. - A
/28AWS subnet has only 16 - 5 = 11 usable addresses, so nearly a third of it is the provider's.
Cheat sheet
- 5 / 4 / 5 - reserved addresses per subnet in AWS / GCP / Azure
- 251 - usable addresses in an AWS or Azure
/24(252 in GCP) - /16 to /28 - allowed AWS VPC block sizes
- /29 - smallest Azure subnet
- 172.31.0.0/16 - AWS default VPC range, with a
/20subnet per AZ - /56 and /64 - AWS IPv6 VPC and subnet sizes
- 10.128.0.0/9 - range used by GCP auto mode subnets
- 169.254.169.254 / 169.254.169.253 - metadata service / VPC DNS resolver