IP Address Management¶
Every virtual network needs an address range that doesn't overlap with any network it might ever connect to: the hub, other spokes, on-premises, partners. Overlaps can't be fixed without rebuilding. The address plan is therefore decided once, recorded centrally, and ranges are handed out from it.
Status: planned
No address plan exists yet, and no VNets are deployed. The plan below is an example to agree on before the first VNet is built.
Principles¶
- Reserve one large block for Azure that doesn't overlap any on-premises or partner range, now or likely in future.
- Allocate fixed-size blocks per workload. A /24 by default, a /22 on request. Don't size each VNet one at a time.
- Keep regions separate: one block per region, so routes can be summarised.
- Record every allocation before it is used, and never reuse a range until the old network is gone.
Example plan¶
| Range | Purpose |
|---|---|
10.100.0.0/16 |
Azure, westeurope |
10.100.0.0/22 |
Connectivity hub (firewall, gateway, Bastion, DNS resolver) |
10.100.4.0/22 |
Platform and management subscriptions |
10.100.16.0/20 |
Production workload spokes (sixteen /24 blocks) |
10.100.32.0/20 |
Non-production workload spokes |
10.100.48.0/20 |
Sandboxes (never peered to the hub) |
10.101.0.0/16 |
Reserved for a second region |
Confirm 10.100.0.0/15 doesn't clash with any on-premises, VPN or partner network before adopting it.
Where allocations live¶
Use Azure Virtual Network Manager IP address management (IPAM) pools, which reserve address space centrally and hand it out to VNets. The alternative is a simple allocation file in the subscription vending repository. Either way:
- subscription vending takes the next free block when it creates a spoke;
- an MR records the allocation, so the history shows who has which range;
- policy can deny VNets with address space outside the allocated ranges, once enforced.