You are setting the IPv4 addressing standard for a new AWS organization that will hold dozens of accounts and VPCs. How do you allocate CIDR ranges, and what are you optimizing for?

## Why this is a principal-level question Every other networking decision in AWS is reversible. You can re-route, re-tier, re-size instances, replace gateways. The address plan is the one artefact that gets baked into every VPC, every remote route, every firewall rule and every partner agreement, and undoing a bad one means renumbering running systems. Interviewers ask it because the answer reveals whether you think in terms of an estate over years or a diagram for today. ## The single hard constraint: no overlap Routed connectivity between networks requires unambiguous addresses. If two VPCs both use `10.0.0.0/16`, no routing construct can tell their `10.0.1.5` apart, so they cannot be joined. This is not an AWS limitation you can pay to remove; it is how IP routing works. The consequences show up years later, usually at the worst moment: an acquisition, a partner integration, a merge of two business units that each independently chose `10.0.0.0/16` because it is the example in every tutorial. So rule one is that address ranges are **allocated, not chosen**. No team picks its own CIDR. ## Structure the space so routes summarize A flat pool of non-overlapping ranges avoids collisions but produces sprawl: every remote route table ends up listing every VPC. Instead, carve hierarchically, so that whole groups can be expressed as one range: ``` 10.0.0.0/8 the estate 10.0.0.0/12 region A 10.0.0.0/14 region A / production 10.0.0.0/16 prod VPC 1 10.1.0.0/16 prod VPC 2 10.4.0.0/14 region A / non-production 10.16.0.0/12 region B ``` Now a rule that says "production in region A" is one prefix, not twenty. Fewer, coarser entries mean smaller route tables, simpler security rules, and reviews a human can actually read. Leave whole branches unallocated on purpose — the empty space is the plan's ability to absorb the next region or business unit without breaking summarization. ## Size for the decade, not the sprint Address space inside a VPC is free. There is no charge for a large CIDR, no performance difference, and no operational tax. What is expensive is being wrong downwards: subnets cannot be resized, VPC primary CIDRs cannot be shrunk, and adding a secondary CIDR later fragments the plan and forces route updates everywhere the VPC is reachable from. So allocate a VPC more than it needs, and leave unallocated space *inside* each VPC CIDR too, so future subnet tiers do not require an extension. The counter-pressure is real: RFC 1918 space is finite, and an estate that hands out a /16 to every sandbox exhausts `10.0.0.0/8` faster than it thinks. That is the actual tradeoff you are being asked about — headroom per VPC versus total addresses available — and the answer is tiering: production VPCs get generous allocations, ephemeral and sandbox environments get small ones from a separate pool that can be recycled, and the carrier-grade NAT range `100.64.0.0/10` is available as overflow for workloads that never need to be reached from corporate networks. ## Govern it with a system, not a spreadsheet A wiki page of allocations decays within a quarter. AWS VPC IP Address Manager (IPAM) is the purpose-built service: you define hierarchical pools, share them to accounts, and VPC creation draws its CIDR from the pool rather than from someone's memory, with allocations and utilisation tracked centrally. The important property is not the reporting — it is that provisioning without an allocation becomes impossible, which is the only control that survives organisational growth. ## Know the escape hatches, and their cost Sometimes overlap is unavoidable: you acquire a company, or a partner will not renumber. The honest answer is that you then stop trying to route between the networks and expose *services* instead of *networks*, or introduce address translation at the boundary. Both are real options and both are worse than having planned properly, which is the point to land: every escape hatch here is more expensive than the allocation discipline that would have avoided it. ## What to say last Summarise the optimization targets in order: correctness (no overlap), longevity (headroom and unallocated gaps), simplicity (summarizable hierarchy), and enforcement (allocation from a central pool at provisioning time). That ordering — rather than a specific prefix layout — is what the question is really testing.