Every large Azure estate has a file called something like IP_Ranges_FINAL_v7_USE_THIS_ONE.xlsx. It lives on a SharePoint site three people can find. It is out of date. And at some ungodly hour, someone peers a new spoke, the address space collides with a range that was “reserved” in row 412, and traffic starts blackholing in a way that takes four engineers and a bridge call to unpick.
In commercial Azure, you’ve had a native fix for that for a while: IP address management inside Azure Virtual Network Manager. In the sovereign clouds — US Gov and Azure operated by 21Vianet in China — you didn’t. You had the spreadsheet. As of this Azure update, the feature is generally available in US Gov Virginia, US Gov Texas, US Gov Arizona, China North 3, and China East 3. That’s the whole story in one line. The interesting part is what it changes for the people who’ve been waiting.
The beats that got us here
A quick note before the timeline: the sequence below is reconstructed from public Microsoft release announcements, not from a single official history page. Treat the ordering as directional, not gospel.
First — AVNM itself lands. Azure Virtual Network Manager showed up as the answer to “I have 300 VNets and connectivity is a sprawl of manual peerings.” It gave you network groups, hub-and-spoke and mesh connectivity configurations, and centralized security admin rules. Useful. It also set up the plumbing for everything that came after, because once you have a control plane that understands your VNets as a fleet, address management is the obvious next thing to bolt on.
Then — IPAM arrives in commercial regions. This is the piece that mattered. Per Microsoft’s own feature documentation for commercial Azure, IPAM in AVNM gives you address pools — you declare CIDR blocks up front, carve them into child pools, and let the tool hand out non-overlapping space. It tracks allocation across VNets, flags conflicts, and shows utilization per pool. The point isn’t novelty. Third-party IPAM tools have done this for twenty years. The point is that it’s native, it reads your actual Azure topology instead of a CSV export, and it doesn’t need an egress path to some SaaS control plane.
Now — the sovereign expansion. Same capability, now switched on in the Gov and China regions listed above. The update itself is a regional GA notice; it does not publish a line-by-line feature diff against commercial. So if you’ve built muscle memory in commercial and expect it to transfer, expect mostly. More on that caveat below.
Why “same feature, different region” is a bigger deal here than it sounds
If you’ve never run in a sovereign tenant, the instinct is to shrug — a feature came to more regions, fine. But the whole reason these environments exist is that you cannot reach across the boundary. A federal system boundary running under FedRAMP High or the DoD Impact Levels doesn’t get to phone home to a commercial IPAM SaaS in East US. Azure China is a physically and operationally separate cloud run by a different operator; your commercial tooling doesn’t see it and shouldn’t.
So in these clouds, “just use a third-party IPAM appliance” means standing up, patching, accrediting, and paying for that appliance inside the boundary. Every tool you add inside an authorized boundary is another thing your assessor asks about. A native, first-party capability that’s already covered by the platform’s own authorization is one fewer appliance to defend in a control review. That’s the actual value here — not that IPAM is clever, but that it removes a box you’d otherwise have to own.
Let me be blunt about one thing, because the marketing will blur it: IPAM does not make you compliant. It doesn’t grant you a data-residency guarantee. The residency comes from running in the sovereign region in the first place. IPAM just lets you manage your address space without stepping outside that boundary. It’s the difference between “this is compliant” and “this doesn’t force me to do something non-compliant.” Anyone selling you the former is selling.
What it actually does, minus the brochure
The capability list below is drawn from Microsoft’s commercial IPAM documentation and the GA update’s own summary of what IPAM provides. The update advertises IP address planning, allocation tracking across VNets, conflict detection and subnet utilization visibility — but it does not itemize behaviour region by region. So confirm each of these against the Gov and China docs for the specific piece you’re going to depend on rather than assuming the commercial description ports verbatim:
- Address pools. In the commercial implementation you register root CIDR ranges, then subdivide into child pools that map to regions, environments, business units — whatever your allocation model is. The tool enforces that children stay inside parents and don’t overlap siblings.
- Allocation tracking. When a VNet draws address space from a pool, IPAM records it. You get a view of what’s assigned versus what’s free, instead of reconstructing it from Resource Graph queries at midnight.
- Conflict detection. Overlapping ranges get caught rather than shipped. This is the feature that pays for itself the first time it stops someone from peering two VNets that both think they own
10.20.0.0/16. - Utilization visibility. Per-pool consumption, so capacity planning stops being a quarterly panic.
Where this earns its keep is the topology the announcement is aimed at: a regional hub with dozens of spokes, replicated across two or three sovereign regions, where address space has to be globally non-overlapping because someday those regions will talk to each other over the hub. Get the plan wrong on day one and you’re re-IP’ing production subnets on day 400. There is no graceful way to re-IP a live subnet. Ask anyone who’s tried.
Wiring it up
Portal path is under your Network Manager resource, in the IP address management blade — create a pool, set the root CIDR, carve children.
Now the honest part on the CLI. I have not run these commands in the newly-GA sovereign regions — this update is fresh and I don’t have a Gov or China tenant to test against as I write. The snippet below reflects the commercial az network manager command surface and is illustrative, not a verified sovereign transcript. Command names and the exact extension version can and do differ, so run az network manager --help against your own installed CLI in your own tenant and let that be the source of truth, not this block:
Do your allocation modelling in a non-production Network Manager first. Pools are cheap to create and annoying to unwind once real VNets depend on them, and you want to discover your naming and hierarchy mistakes before anything is drawing from them.
Before you assume it’s the commercial feature verbatim
It’s a regional expansion of an existing capability, not a new one — treat it that way. But “GA in a sovereign region” and “identical to commercial” are not the same claim, and I’d not stake a migration plan on the assumption they are. In my own sovereign deployments over the years, these clouds have historically trailed on the edges: a portal blade a version behind, a CLI extension not yet published, an integration with an adjacent service that hasn’t lit up. I’m not asserting that’s true of IPAM here — I’m telling you it’s the pattern I’ve been bitten by, so verify against the Gov and China documentation for the pieces you depend on, and confirm the exact command surface in your own tenant rather than trusting a commercial tutorial. If a capability you need isn’t explicitly listed for your region, assume it isn’t there until proven otherwise.
And the thing the update doesn’t mention: I’ve seen nothing in the announcement about a bulk import path, and the commercial implementation doesn’t hand you one either. Don’t expect turning on IPAM to retroactively ingest your existing mess — there’s no button that reads IP_Ranges_FINAL_v7 and hands back a clean pool hierarchy. Onboarding VNets that already exist and already overlap is, based on how the commercial feature behaves, manual reconciliation work, and it’s exactly as tedious as it sounds. The tool prevents the next conflict. The ones you already shipped are still yours to untangle.
The next dated beat on this calendar is the one you set yourself: pick a maintenance window in the next quarter, stand up a pool hierarchy that reflects the address plan you wish you’d had on day one, and start onboarding VNets into it before the estate grows another fifty spokes. The spreadsheet isn’t going to get more accurate on its own.