Subnetting

Subnetting divides a larger IP network into smaller address ranges by extending its network prefix. In Classless Inter-Domain Routing (CIDR) notation, the number after the slash specifies how many bits identify the network. An IPv4 /16 contains 65,536 addresses, while a /24 contains 256. Dividing 10.20.0.0/16 into /24 subnets creates 256 distinct ranges, such as 10.20.1.0/24 and 10.20.2.0/24. Longer prefixes mean smaller networks, and each subnet must start on a boundary appropriate to its size.

Cloud designs typically allocate address space hierarchically: an organization reserves large blocks, assigns smaller blocks to Regions and virtual networks, and subdivides those into workload subnets. For example, an organization might reserve 10.0.0.0/8, allocate 10.20.0.0/16 to one VPC, and use separate /24 subnets for application and database workloads in each Availability Zone. In AWS, a VPC is regional and each subnet belongs to one Availability Zone. A resilient application therefore uses multiple subnets across multiple zones rather than treating a subnet as a multi-zone resource.

Subnet sizing must account for usable addresses, not just the mathematical block size. In a standard AWS IPv4 subnet, five addresses are reserved, so a /24 provides 251 assignable addresses and a /26 provides 59. Capacity planning should include instances, container networking, load balancers, private endpoints, managed-service network interfaces, and temporary scaling or deployment capacity. Small subnets conserve address space but can exhaust unexpectedly; large subnets simplify growth but consume scarce IPv4 space. An existing AWS subnet cannot be resized in place, so correcting an undersized allocation usually requires creating another subnet and migrating resources.

A subnet is an address and routing boundary, not an automatic security barrier. In AWS, subnets in the same VPC can normally communicate through local routing unless security controls restrict traffic. Use route tables, security groups, network ACLs, and firewalls to implement the intended segmentation. A public subnet has a route to an internet gateway, but that route alone does not make every resource internet-accessible: an IPv4 instance also needs a public address and permissive security controls. A private subnet can have outbound internet access through a NAT gateway without supporting unsolicited inbound internet connections.

Across accounts, Regions, VPCs, and on-premises networks, coordinate allocations before establishing connectivity. Two isolated VPCs can both use 10.20.0.0/16, but ordinary routing cannot unambiguously connect identical destination addresses in both networks. AWS VPC peering rejects overlapping VPC CIDR blocks. Transit Gateway also does not resolve overlap; overlapping VPC address ranges are not propagated as normal distinct destinations. Adding more-specific routes is not a general solution because duplicate addresses, local routing behavior, and return-path requirements remain.

The preferred long-term overlap solution is renumbering one network into unique address space. When renumbering is impractical, address translation can expose unique translated ranges, with additional operational complexity and potential application limitations. For access to a specific service rather than an entire network, a private endpoint architecture such as AWS PrivateLink can connect consumers and providers despite overlapping CIDRs. This does not provide unrestricted routed connectivity between the networks. DNS must direct clients to the appropriate endpoint or translated address.

Choose connectivity patterns separately from address allocation: peering can suit a small number of direct relationships, while a transit hub can simplify larger multi-account topologies. Both require deliberate routes and return paths. Contiguous allocations can support route summarization, reducing routing-table complexity, but summaries must not accidentally advertise ownership of unrelated networks. Centralized IP address management helps track assignments, detect conflicts, and preserve growth space. IPv6 uses the same prefix-based principles, although capacity planning generally emphasizes consistent hierarchy and provider constraints rather than conserving individual addresses.