Auditing an Existing Subnet Plan Before a Cloud Migration

Most subnet articles start from a blank piece of paper and end with a clean diagram. That is not the situation most teams are actually in. The situation is a Confluence page from 2019, a router config someone exported last quarter, and a network engineer who swears "the 10.40.0.0/16 is in use somewhere" but cannot remember where. The migration deadline is in three weeks. Your job is to prove, on paper, that every existing subnet still fits its purpose, that nothing overlaps, and that the new VPC ranges will not collide with anything that survives the cutover. This is the audit mindset. It is mostly arithmetic, a little detective work, and a lot of writing things down so the next person does not have to redo it. Treat the Audit Like a Code Review A subnet plan is a piece of infrastructure code. It deserves the same hygiene as a Terraform module: a source of truth, a diff against reality, and a sign-off. Before touching anything, gather the inputs into one place: - An export of every router, switch, and firewall interface description. The description string on GigabitEthernet0/0/0 is often the only thing that says "links to warehouse printer VLAN." - The DHCP scopes, including any helpers, reservations, and superscopes. - The DNS zone file, or at least the forward and reverse delegations your team owns. - Every cloud account's VPC, VNet, or project. Most teams have at least one "shadow VPC" that nobody admits to. - The site-to-site VPN and peering configuration. Encapsulated ranges count. Put these into a single spreadsheet with one row per subnet: purpose, CIDR, VLAN ID, gateway, DHCP range, DNS suffix, owning team, and last-touched date. The last column is the most honest one. If a subnet has not been touched since 2021, ask whether it still needs to exist. Build the Numbers, Not the Vibes Once the inventory exists, the next step is to reduce it to first principles. For every row, write down the network address, the broadcast address, the usable host range, and the prefix length. This sounds tedious, and it is, which is exactly why mistakes hide here. A reliable workflow: - Pick the largest block you actually control or peer with. For most enterprises this is a /16 from RFC 1918: 10.0.0.0/8 ,172.16.0.0/12 , or192.168.0.0/16 . - Subtract the subnets you have already allocated from that block. If two subnets overlap, you have already found your first bug. - Compute the remaining free space as a list of CIDR ranges. These are the candidates for the migration. The arithmetic itself is the same as the one covered in the step-by-step guide to calculating subnet bits from an IP and mask. Re-do it by hand for the top five entries in your inventory. If you cannot, neither can the on-call engineer at 2 a.m. Common Failure Modes the Audit Has to Catch A few patterns show up in roughly every audit I have run. Build the review checklist around them. Overlapping allocations from acquisitions. A merged company often keeps both legacy schemas alive. Two /20s that look unrelated on paper can share a /19 if someone carved them across the wrong boundary. The fix is to identify the parent block each subnet belongs to and walk the tree. The "we only use a few hosts" myth. A /24 has 254 usable addresses. Teams that ask for one "because we only need 30 hosts" almost always grow into it, then ask for another /24 instead of re-binning. Audits are a good moment to right-size: a /27 gives 30 hosts, leaves room to grow within the same /24, and is easier to summarize. Documentation lag. The spreadsheet says 10.20.5.0/24 is "Finance printers." The router says 10.20.5.0/24 is "Guest Wi-Fi pilot, temporary." One of those is wrong. Cross-check against DHCP leases and firewall logs. The truth is usually in the logs. Asymmetric VPN ranges. Site A uses 10.10.0.0/16 . Site B uses 10.20.0.0/16 . The tunnel comes up, but a host at A trying to reach a service at B cannot, because the corporate hub has a route summary that includes 10.10.0.0/15 and now covers B by accident. The mitigation is to keep site allocations inside distinct /16s and document the summary routes. A practical ordered checklist for the audit meeting: - Inventory sources exported and merged into one sheet. - Every row has a verified purpose and owner. - CIDR math re-derived for each row from first principles. - Overlap test: no two rows share any address. - Containment test: every row is inside the declared parent block. - Right-size test: prefix length matches the documented host count plus headroom. - Cloud test: every VPC range is unique against on-prem ranges. - VPN test: every encrypted tunnel's local and remote ranges are documented and non-overlapping with any other range on either side. - Sign-off recorded with date and reviewer name. Designing the New Ranges to Avoid the Same Mistakes The migration is the right moment to introduce a prefix budget. Treat your RFC 1918 space the way a sysadmin treats a disk: lay out a top-level partition scheme and stick to it. A workable pattern for a multi-VPC estate: - Reserve a contiguous /16 per region or per business unit. - Inside each /16, reserve the first /20 for infrastructure (bastion, DNS, monitoring, jump hosts). - Reserve the second /20 for shared services (CI runners, artifact caches, internal APIs). - The remaining /11 is for application subnets, sliced per environment (dev, staging, prod) and per tier (web, app, data). This gives you three properties for free. First, any summary route you advertise is clean and unlikely to cross-pollinate. Second, capacity planning is local: a team that needs more /24s asks inside its own /16, not against the whole /8. Third, audit answers become one-line: "Is this VPC inside its parent /16? Yes or no." The prefix budget also forces the conversation about IPv6. Most enterprises are still IPv4-only in production, but every modern cloud VPC supports dual-stack with essentially no extra cost. If your audit produces a single document that includes an IPv6 prefix per region (typically a /56 per VPC, carved from your ARIN or RIPE allocation), the next audit will not have to invent the scheme from scratch. Tooling and Verification Manual arithmetic is the right starting point because it exposes assumptions, but it does not scale to 400 subnets. Pick a calculator you trust, run every row through it, and then run the same rows through a second method. The two outputs should match exactly. A useful verification trick is to treat the inventory as a set of intervals on the number line and use simple set arithmetic: the union of all allocated subnets must be a subset of the parent block, and pairwise intersections must be empty. If you can express your spreadsheet as a list of [start, end] pairs and pass it to a 30-line script that flags any pair whose intervals intersect, you will catch the overlap that the human eye misses at row 47. Two references to keep on hand during the audit. RFC 1918 is the canonical source for private IPv4 allocation and is short enough to read in one sitting; the RFC 1918 document is the right anchor. For IPv6 planning, the Wikipedia IPv6 article covers address types and the recommended allocation sizes for organizations. Neither is marketing material; both are stable and unlikely to rot. Frequently asked questions How often should a subnet audit be performed? At least once a year, and any time a new site, cloud account, or major acquisition enters the picture. The cost of a yearly review is far less than the cost of discovering a collision during a Friday night cutover. What is the smallest team that can do this responsibly? One engineer who owns the spreadsheet, plus one reviewer who challenges every row. The reviewer does not need to be a network specialist; they need to be willing to ask "why is this /24 and not /27?" and to wait for a real answer. Should overlapping subnets be merged or kept separate? Merge only when the owning teams agree on a common gateway, DHCP scope, and security policy. Otherwise, re-bin the parent block: pick a new prefix length that holds both, and document the carve-out as a single allocation rather than two overlapping ones. What is the single highest-value artifact to produce? A signed diagram and spreadsheet that show, on one page, every subnet, its parent block, its purpose, and its owner. If a stranger can read that page and understand the network in five minutes, the audit has succeeded. This article was drafted with AI assistance and reviewed for technical accuracy before publishing. Top comments (0)