Auditing an Existing Subnet Plan Before a Cloud Migration

Existing subnet plans often start from a Confluence page, router export, and a network engineer who cannot remember all the subnets in use. The goal is to prove that every subnet still fits its purpose and does not overlap with others before migrating to the cloud. The audit process involves gathering all router, switch, and firewall interface descriptions, DHCP scopes, DNS zone files, cloud account ranges, VPN configurations, and documenting the last time each subnet was touched.

First principles subnet math is crucial. For each row in the inventory spreadsheet, calculate the network address, broadcast address, usable host range, and prefix length. Subtract allocated subnets from the parent block and identify free CIDR ranges for migration. Perform these calculations manually for the top five entries to ensure reliability.

Common audit failure modes include overlapping allocations from acquisitions, the "only a few hosts" myth, documentation lag, and asymmetric VPN ranges. Address these issues by identifying parent blocks, right-sizing subnets, cross-checking against DHCP leases and firewall logs, and ensuring site allocations are distinct.

During the audit meeting, follow a practical checklist: merge inventory sources into one sheet, verify each row's purpose and owner, re-derive CIDR math, perform overlap and containment tests, right-size prefix lengths, and confirm cloud ranges are unique. Sign off on the audit with a reviewer's name and date.

For the new cloud ranges, implement a prefix budget by reserving contiguous /16s per region or business unit. Within each /16, allocate /20s for infrastructure, shared services, and application subnets. This approach ensures clean summary routes, easier capacity planning, and straightforward audit answers. Additionally, consider IPv6 prefixes for each VPC to future-proof the architecture.