Cloud Subnets: How Network Segmentation Works Across AWS, Azure, and GCP
When you create a Virtual Private Cloud (VPC), you get a large IP address space — say, 10.0.0.0/16, which contains 65,536 addresses. A flat network with all your resources sharing that space would work technically, but it would make security controls nearly impossible, expose databases directly to web servers, and create routing problems as the environment grows. Subnets are how you divide that space into logical segments with distinct purposes, routing rules, and security policies.
Understanding subnets well is not optional for cloud architects. Nearly every security mistake in VPC design — databases accessible from the internet, web servers that can directly reach internal management systems, lateral movement after a breach — traces back to inadequate network segmentation.
What a Subnet Is and What It Controls
A subnet is a range of IP addresses within a VPC, defined using CIDR notation. A VPC with address space 10.0.0.0/16 might be divided into:
VPC: 10.0.0.0/16 (65,536 addresses) | +-- Public Subnet 10.0.1.0/24 (256 addresses) us-east-1a +-- Public Subnet 10.0.2.0/24 (256 addresses) us-east-1b +-- Private Subnet 10.0.10.0/24 (256 addresses) us-east-1a +-- Private Subnet 10.0.11.0/24 (256 addresses) us-east-1b +-- Data Subnet 10.0.20.0/24 (256 addresses) us-east-1a +-- Data Subnet 10.0.21.0/24 (256 addresses) us-east-1bEach subnet has:
- A route table that determines where traffic is directed
- An association with an Availability Zone (on AWS and GCP; Azure differs)
- Network access controls (security groups at the resource level, NACLs at the subnet level)
The route table is what actually defines whether a subnet is “public” or “private”. A public subnet has a route to an Internet Gateway (IGW). A private subnet does not — it either has no internet route at all, or it routes internet-bound traffic through a NAT Gateway that provides outbound-only access.
Public vs Private Subnets
The public/private distinction is one of the most important concepts in cloud networking, and it is frequently misunderstood.
Public subnet: Has a route to an Internet Gateway. Resources in this subnet can receive inbound traffic from the internet if they have a public IP and the security group permits it. Load balancers, bastion hosts, and NAT gateways typically live here. A web application’s EC2 instances should almost never sit directly in a public subnet — they should sit behind a load balancer that IS in a public subnet.
Private subnet: Has no route to the Internet Gateway. Resources here cannot be reached directly from the internet. However, they can reach the internet (for downloading updates, calling external APIs) through a NAT Gateway placed in a public subnet. Application servers, databases, caches, and internal services belong here.
Three-Tier Architecture Using Public and Private Subnets----------------------------------------------------------Internet |[Internet Gateway] |+--[Public Subnet]--+| Load Balancer || NAT Gateway |+--------------------+ |+--[Private Subnet (App Tier)]--+| EC2 / ECS Tasks || Application Servers |+--------------------------------+ |+--[Data Subnet (DB Tier)]------+| RDS / ElastiCache / DynamoDB || No internet route |+--------------------------------+
Security group rules:- Load Balancer: allow 443 from 0.0.0.0/0- App servers: allow 8080 from load balancer SG only- Database: allow 5432 from app server SG onlyHow AWS, Azure, and GCP Model Subnets Differently
The three major providers use the same underlying concept but implement it differently in ways that matter for multi-cloud and architecture decisions.
AWS: Subnets are strictly Availability Zone-scoped. A subnet in us-east-1a contains resources that run in Availability Zone 1a. If you want high availability across two AZs, you create two subnets. This means the typical HA deployment creates at least one subnet per tier per AZ — a three-tier, two-AZ architecture requires at least six subnets. Resources in different subnets communicate through routing and security group rules.
Azure: Subnets are scoped to a Virtual Network (VNet) region, not to individual Availability Zones. Azure’s Availability Zones are addressed at the resource level — you specify the AZ when deploying a VM, not when creating the subnet. An Azure subnet spans the entire region. This is architecturally simpler but means zone awareness requires explicit configuration at the resource level rather than being implicit from subnet placement.
GCP: GCP’s VPC is fundamentally different from AWS and Azure — it is a global resource, not regional. A single GCP VPC spans all regions. However, subnets in GCP are regional (not zonal). A subnet in us-central1 can contain resources from any Availability Zone within that region. This means a two-zone GCP deployment can use a single subnet rather than two, simplifying CIDR planning.
Subnet Scope Comparison--------------------------AWS: VPC (regional) --> Subnets (AZ-scoped) Multi-AZ = multiple subnets required per tier
Azure: VNet (regional) --> Subnets (regional, not AZ-scoped) Multi-AZ = single subnet, AZ chosen at resource level
GCP: VPC (global) --> Subnets (regional) Multi-AZ = single regional subnet covers all zonesCIDR Planning: Doing It Right the First Time
CIDR (Classless Inter-Domain Routing) notation defines IP address ranges. Getting this wrong at the start of a cloud deployment causes significant pain later — overlapping ranges prevent VPC peering and Transit Gateway connections, and subnets that are too small run out of IP addresses in ways that require destroying and recreating networking infrastructure.
Practical CIDR planning rules:
Plan for five times your expected resource count. If you plan to run 50 VMs in a subnet, allocate at least a /24 (256 addresses). AWS reserves 5 addresses per subnet for network, broadcast, routing, DNS, and DHCP — a /24 gives you 251 usable addresses. A /28 gives you 11 usable addresses and no room to grow.
Avoid RFC 1918 ranges used by on-premises networks. If your on-premises data centre uses 10.0.0.0/8, use 172.16.0.0/12 or 192.168.0.0/16 for cloud VPCs. Overlapping ranges prevent VPN and Direct Connect peering.
Use a consistent layout across regions. A predictable pattern — first two octets encode region, third octet encodes AZ and tier — makes network documentation and routing rules much easier to manage across dozens of VPCs.
Example CIDR Layout for Multi-Region Deployment--------------------------------------------------us-east-1: 10.0.0.0/16 Public-1a: 10.0.1.0/24 Public-1b: 10.0.2.0/24 Private-1a: 10.0.10.0/24 Private-1b: 10.0.11.0/24 Data-1a: 10.0.20.0/24 Data-1b: 10.0.21.0/24
eu-west-1: 10.1.0.0/16 Public-1a: 10.1.1.0/24 Public-1b: 10.1.2.0/24 Private-1a: 10.1.10.0/24 Private-1b: 10.1.11.0/24
Pattern: 10.[region].[az+tier].0/24This layout prevents overlap, documents itself, and scales cleanly to additional regions and tiers.
Well-designed subnets make security policies simpler (rules reference subnets, not individual IPs), reduce the blast radius of incidents (a compromised web server in a public subnet cannot directly reach the database because routing prevents it), and enable clean multi-AZ designs that survive Availability Zone failures. Getting subnet design right at the start is substantially easier than refactoring it after production traffic is running on top of it.