Subnetting for AWS and Azure VPCs: Preventing IP Overlap in Cloud Networks

When designing cloud network infrastructure on AWS or Azure, one of the most critical—and most commonly underestimated—decisions is choosing the right VPC CIDR blocks and subnet allocations. Get this wrong, and you'll spend weeks renumbering your entire infrastructure or be forced into awkward workarounds that complicate network security and monitoring. Get it right from the start, and your cloud architecture scales cleanly for years.

IP overlapping is the silent killer of cloud migrations. It happens when the CIDR blocks of your on-premises network overlap with those in your cloud VPC, making direct site-to-site connectivity impossible without complex NAT configurations. The solution is careful planning of your address space before you provision any cloud resources. This guide walks through the principles and gives concrete recommendations for AWS and Azure VPC design.

Both AWS and Azure support RFC 1918 private address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) for VPCs. AWS allows VPCs from /16 to /28 in CIDR notation. Azure Virtual Networks support prefixes from /16 to /29. The choice of VPC CIDR size depends on the expected number of subnets, EC2 instances, and private IP requirements.

The most common mistake is choosing a /16 VPC with 10.0.0.0/16 simply because it's familiar. While this gives 65,536 addresses, it consumes your entire 10.0.0.0/8 private range in one shot, leaving no room for future VPCs, on-premises networks, or other private ranges that might need to communicate with your cloud environment. A better practice is to use a /20 or /21 within 10.0.0.0/8, reserving the rest of the private space for other uses.

AWS recommends the following subnet strategy: allocate at least one subnet per Availability Zone within each region, and segment further into public (has internet route via Internet Gateway), private (no direct internet route), and protected (for regulated workloads requiring additional security controls). Each subnet must have a unique CIDR block within the VPC range.

A common pattern for a production VPC with 3 AZs and 3 tiers (web, application, database) would be: 9 subnets total, each with a /24 CIDR block. If your VPC is 10.0.0.0/20, your subnets might be: 10.0.0.0/24 through 10.0.8.0/24. This gives you 256 addresses per subnet, of which 251 are usable after AWS reserves 5 addresses in each subnet.

AWS NAT Gateway charges are based on data processing and duration, so minimizing the number of NAT gateways by routing through anEgress Gateway or VPC endpoints can significantly reduce costs. Planning your CIDR allocations with this in mind—placing resources that need external access in subnets with shared NAT infrastructure—improves both cost efficiency and network architecture.

Azure's approach to subnetting differs from AWS in that subnets are required for every NIC configuration, and Azure reserves 5 addresses per subnet (compared to AWS's 5). Azure's default routing automatically creates system routes for inter-subnet communication, but user-defined routes can override this for custom routing policies like forced tunneling.

Azure's delegated subnet model also means certain services like Azure Bastion, Azure Firewall, or Azure VPN Gateway require dedicated subnets (called gateway subnets). These must be /27 or larger in CIDR notation. Forcing these services to share subnets with other workloads creates security risks and management complexity.

Before touching the cloud console, audit your entire address space: every on-premises location, branch office, existing cloud environment, and partner network that will need connectivity. Assign each a non-overlapping CIDR block from RFC 1918 space. For organizations with complex multi-cloud strategies, consider using a /8 or /9 at the top level and carving it up across environments.

Tools like our IP Subnet Calculator help you verify that your planned allocations don't overlap and that each subnet has sufficient address space for its intended workload. Running such calculations before provisioning cloud resources takes minutes and prevents days of rework later. Remember: in cloud networking, the cost of renumbering is measured in developer time and deployment risk, not just infrastructure expense.