TL;DR · Key Takeaways
- NSX 9 removed the Manager API for logical networking and security. The Policy API is the supported automation surface, and it is declarative: you describe the desired state, NSX realizes it.
- Declarative beats imperative for infrastructure. You stop scripting the sequence of create-this-then-that and start describing the end state, which makes your automation idempotent and far easier to reason about.
- The hierarchical Policy API lets you build a whole topology, segments, gateways, groups, and firewall rules, in a single PATCH to the infra tree. One call, one consistent transaction, instead of dozens of ordered requests.
- On top of the Policy API sit the real tools: the NSX Terraform provider (now covering Transit Gateway and VPCs), Ansible, VCF Automation, and PowerCLI. Pick by team and use case, not by fashion.
- Treat NSX as code. Version your intent, review it, and let the declarative model converge the live state to the repo. Click-ops in NSX Manager is the thing your automation is meant to replace, not supplement.
If you wrote NSX automation against the Manager API, NSX 9 just broke it, and that is a good thing. The Manager API for logical networking and security is gone, and the Policy API is the only supported path forward. Teams treat this as a migration chore, but it is really a forced upgrade in how you think about automating the network. The Manager API encouraged imperative scripting: do this, then that, in the right order, and handle every failure between steps. The Policy API is declarative. You describe what you want the network to look like and let NSX figure out how to get there. Once that clicks, you stop writing fragile sequences and start managing the network like code.
Declarative beats imperative, and the API now enforces it
The difference is not cosmetic. With an imperative API you own the orchestration: create the segment, wait, create the Tier-1, attach it, then the group, then the rule, and if step three fails you are responsible for cleaning up steps one and two. Every script becomes a little state machine, and every state machine is a place for bugs to live. With the declarative Policy API you submit the desired end state and NSX reconciles the live configuration to match it. Run the same definition twice and the second run is a no-op, because the state already matches. That property, idempotency, is what makes infrastructure-as-code trustworthy. You can apply your network definition on a schedule and know it will converge, not drift.
This is also why the realized-state thinking from the micro-segmentation Part matters here. The Policy API separates your intent from its realization: you declare intent, NSX realizes it, and you can query whether realization succeeded. Automation that checks realized state rather than just trusting a 200 response is automation that catches problems before users do.
The hierarchical API: a whole topology in one call
The Policy API has a feature that pays for the whole migration on its own: the hierarchical API. Instead of creating each object with its own request, you submit one PATCH to the infra tree containing a nested structure of everything you want, and NSX applies it as a single consistent transaction. A segment, the Tier-1 it attaches to, a security group, and the firewall rules that reference the group can all land together, in order, without you writing the order. If part of it is invalid, the whole intent is rejected cleanly rather than leaving you with a half-built topology.
# One PATCH builds a whole branch of the infra tree
PATCH https://NSX-MGR/policy/api/v1/infra
{
"resource_type": "Infra",
"children": [
{ "resource_type": "ChildSegment",
"Segment": { "id": "web-seg", "subnets": [ ... ] } },
{ "resource_type": "ChildGroup",
"Group": { "id": "web-grp", "expression": [ ... ] } },
{ "resource_type": "ChildSecurityPolicy",
"SecurityPolicy": { "id": "web-policy", "rules": [ ... ] } }
]
}
# All applied as one transaction. Invalid input rejects the whole tree.The tools that sit on top
You rarely hit the Policy API raw in production. You drive it through a tool, and the right tool depends on your team and your use case. The NSX Terraform provider is my default for declarative infrastructure-as-code, and in NSX 9 it has been extended to cover the new constructs, including Transit Gateway and VPCs, so the multi-tenancy model from Part 22 is now automatable end to end. Terraform fits naturally because it is itself declarative, mapping cleanly onto the Policy API’s intent model.
# NSX Terraform provider: declare a segment as code
resource "nsxt_policy_segment" "web" {
display_name = "web-seg"
transport_zone_path = data.nsxt_policy_transport_zone.overlay.path
subnet { cidr = "10.10.10.1/24" }
}
# terraform plan shows the diff, terraform apply reconciles NSX to itAnsible suits teams that already live in Ansible and want procedural playbooks alongside their server automation. VCF Automation is the right layer when you want self-service catalog items and governance on top, tying NSX provisioning into broader cloud workflows. And PowerCLI, with its low-level cmdlets for the NSX Policy REST API, is the pragmatic choice for Windows-centric operations teams and quick administrative scripting. None of these is wrong; they sit at different points on the spectrum from infrastructure-as-code to self-service portal to ad-hoc scripting.
| Tool | Best for | Style |
|---|---|---|
| Terraform provider | Infrastructure-as-code, VPC/TGW | Declarative |
| Ansible | Teams already in Ansible | Procedural playbooks |
| VCF Automation | Self-service catalog, governance | Workflow / templating |
| PowerCLI | Windows ops, quick scripting | Imperative cmdlets |
| Raw Policy API | Custom integrations, the hierarchical tree | Declarative REST |
Worked example
A team manages 200 micro-segmentation rules across 30 applications. Hand-maintained in the UI, that is a drift machine: nobody knows which rules are current, and audits take days. Moved to the Terraform provider, the 200 rules live in version control, every change is a reviewed pull request, and terraform plan shows exactly what will change before it does. The same definition applied to a DR site reproduces the policy identically. The win is not speed of the first apply; it is that the network now has a single source of truth you can review, diff, and reproduce.
My Take
The removal of the Manager API is the best thing to happen to NSX automation, even if it broke your scripts. It forces everyone onto the declarative Policy API, which is the model that actually scales: describe the network you want, version it, review it, and let NSX reconcile the live state to your repo. Reach for the hierarchical API when you want a whole topology applied as one clean transaction, and lean on the Terraform provider, now covering VPCs and Transit Gateway, for everyday infrastructure-as-code. Pick Ansible, VCF Automation, or PowerCLI where they fit your team, but treat the Policy API as the one surface underneath them all. The trap to avoid is using automation to speed up click-ops while still treating NSX Manager as the source of truth. Make the repo the source of truth, let the declarative model converge to it, and check realized state rather than trusting the response code. Do that and your network finally behaves like the rest of your infrastructure-as-code. Is your NSX config in a repo, or scattered across a UI nobody fully trusts?
Operating NSX as code, not just deploying it
Getting your NSX config into Terraform is the start, not the finish. The operational habits around state, secrets and testing are what separate a repo that genuinely runs your network from a repo that drifts into fiction within a quarter.
Two states have to agree: Terraform and realized
There are two sources of truth you must keep aligned. Terraform has its state file, which records what it believes it created, and NSX has its realized state, which records what is actually enforced. They drift apart the moment someone makes a change in the NSX UI that Terraform does not know about, or when an apply half-succeeds. Good NSX automation does not just run terraform apply and trust the exit code; it queries realized state afterward to confirm the intent actually landed. Make a clean plan with no unexpected diffs a precondition for every change, and investigate any drift before you apply over it, because applying over drift is how you silently revert someone else’s emergency fix.
The pipeline needs its own identity and its own guardrails
Automation runs as a principal, and that principal needs the least privilege that lets it do its job and no more. Give the pipeline its own NSX role scoped to what it manages, store its credentials in a real secret store rather than in the repo, and rotate them like any other credential. The same RBAC and Project boundaries from the multi-tenancy design apply here: a pipeline that provisions tenant networking should be scoped to that tenant, so a bad plan cannot reach across the platform. Infrastructure as code removes the human from the keyboard, which is exactly why the guardrails have to move into the code and the access model instead.
Test changes where they cannot hurt anyone
The declarative model makes testing tractable in a way the old imperative scripts never allowed. Run the same definition against a non-production NSX, inspect the plan, apply it, and confirm realized state before the change ever touches production. Because the definition is idempotent, the production apply becomes a known quantity rather than a leap of faith. This is the real payoff of the Policy API being declarative: not that the first apply is faster, but that every subsequent apply is predictable, reviewable and reproducible across environments. A firewall rule set you can stand up identically in a lab, a DR site and production is a firewall rule set you can actually trust.
Worked example
A team manages 200 micro-segmentation rules across 30 applications in Terraform. An engineer hand-edits one rule in the NSX UI during an incident and forgets to tell anyone. The next routine pipeline run plans to revert that rule, because the repo is still the old version, and without a realized-state check the apply would quietly undo the emergency fix at 3 a.m. The team that gates applies on a clean plan catches the unexpected diff, reconciles the change back into the repo first, and only then applies. The repo stays the source of truth, the incident fix is preserved, and nobody gets paged twice for the same problem.
Version the network and review the diffs
The deepest shift the Policy API and Terraform enable is cultural, not technical: the network becomes something you review before you change, the same way you review code. When the NSX configuration lives in a repository, a change to a firewall rule or a segment is a pull request, and the plan diff is the artifact your reviewer actually reads. That diff is worth more than any change-advisory-board form, because it shows precisely what will change in terms NSX understands, before a single packet is affected. A reviewer who can see that a change adds one allow rule and modifies a group, and nothing else, can approve with confidence instead of hope.
Around that review habit sit the supporting practices that keep the repository honest. Store the definitions in version control with real history, gate merges on a clean plan, and run drift detection so the repository and the live NSX never silently diverge. When they do diverge, because someone made an emergency change in the UI, you reconcile it back into the repository rather than letting the two stories drift apart. Done this way, the network gets the same auditability, reproducibility and peer review that the rest of your infrastructure already enjoys, and the question what changed and who approved it always has a precise answer.
References
- Terraform Registry: VMware NSX-T Provider Documentation
- Broadcom TechDocs: Managing the NSX Policy API with PowerCLI
- Broadcom TechDocs: What’s New in NSX (VCF 9)
About The Author
