Classless Inter-Domain Routing (CIDR)

Classless Inter-Domain Routing replaces fixed class-based network boundaries with variable-length prefixes. In IPv4, 10.20.0.0/16 identifies a network whose first 16 bits are fixed, leaving 16 bits for addresses. It contains 65,536 addresses. A /24 contains 256 addresses, while a /28 contains 16. A larger prefix number therefore means a smaller address range. IPv6 uses the same principle with 128-bit addresses rather than 32-bit addresses.

CIDR blocks must align with their prefix boundaries. For example, 10.20.4.0/23 covers 10.20.4.0 through 10.20.5.255. The adjacent /24 networks 10.20.4.0/24 and 10.20.5.0/24 can be summarized as that /23 because they are contiguous and correctly aligned. Arbitrary adjacent networks cannot always be combined into one exact prefix. Routers generally select the longest matching prefix, so a matching /24 route takes precedence over a matching /16 route. Aggregation reduces route counts, but an overly broad summary can attract traffic for networks that are not reachable through the advertising router.

In cloud networks, engineers allocate a parent address range to a virtual network and divide it into subnets. Plan ranges hierarchically across accounts, Regions, environments, and on-premises sites. For example, reserve 10.64.0.0/12 for a cloud estate and allocate distinct /16 blocks to individual VPCs. This creates room for growth and potential summarization, although cloud routing services do not necessarily generate summary routes automatically. A subnet's size should reflect workload density, availability-zone placement, scaling peaks, and infrastructure addresses rather than an arbitrary convention that every subnet must be a /24.

Address capacity is not the same as usable workload capacity. A standard AWS IPv4 subnet reserves its first four addresses and its last address, so a /24 normally provides 251 assignable addresses and a /28 provides 11. Network interfaces, interface endpoints, load balancers, and container networking can consume additional capacity. Monitor free addresses per subnet, not just unused space across the VPC. Free addresses in another Availability Zone do not help a deployment that must allocate interfaces in an exhausted subnet. Include headroom for rolling deployments, failover, and temporary scaling.

When an AWS VPC needs more IPv4 space, an additional, nonoverlapping secondary CIDR block can provide space for new subnets, subject to association rules and quotas. For example, a VPC using 10.20.0.0/16 might add 10.21.0.0/16 after checking the enterprise address plan and AWS restrictions. Existing subnet CIDRs cannot be resized: create larger or additional subnets and migrate or redeploy workloads. Update external routes, security rules, network ACLs, DNS dependencies, and connectivity advertisements as necessary. Adding a secondary block does not enlarge an existing subnet or automatically move resources into the new space.

Overlapping CIDRs create ambiguous destinations when networks are connected. Two independently isolated VPCs can both use 10.20.0.0/16, but direct routing cannot uniquely identify which instance of 10.20.1.10 is intended. AWS VPC peering rejects overlapping VPC CIDRs, and AWS Transit Gateway does not make overlapping address spaces transparently routable. Adding a nonoverlapping secondary block does not remove the original overlap; peering remains unavailable while any VPC CIDRs overlap. Durable solutions include renumbering and migrating workloads. Alternatives include translating selected traffic into unique ranges or exposing a specific service through AWS PrivateLink instead of providing general network connectivity.

Subnet optimization balances growth capacity against address conservation and operational complexity. Very small subnets can exhaust quickly, while oversized allocations can strand scarce private address space and complicate future interconnection. Centralized allocation and utilization tracking reduce accidental overlap across accounts and Regions. IPv6 can reduce dependence on scarce IPv4 addresses, but applications, connectivity paths, and security controls must support it. CIDR itself is neither encryption nor an access-control mechanism: a route establishes a forwarding choice, not permission to communicate.