Dr. Pranay Jha

Here is the myth: VCF 9 ships a load balancer in NSX, so I will just use that and skip the extra moving parts. Here is the reality: the NSX native load balancer is on its way out, and building anything new on it in 2026 is building on a deprecated component. The real decision is not Avi or NSX native, it is how fast you move to Avi and what you do with the NSX LBs you already have.

The state of load balancing in VCF 9

Two technologies have lived in the stack for years. The NSX native load balancer is built into NSX and handles basic L4 and L7 traffic for workloads behind Tier-1 gateways. Avi Load Balancer, which you will still see called NSX Advanced Load Balancer, is a full software application delivery controller with a separate control plane and a distributed data plane. Broadcom has been clear on direction: the native NSX load balancer is deprecated and will be removed in a future release, with equivalent or more advanced function delivered through Avi. In VCF 9 that direction is the design assumption. Avi is what SDDC Manager deploys and lifecycle-manages, it backs the vSphere Supervisor and VKS, and the new VPC model from Part 10 is built to consume it.

Avi versus NSX native: the comparison

Architecture and the licensing reality

The footprint difference is the most common objection to Avi, so be honest about it. NSX native LB needs no extra virtual machines because it runs on the Tier-1 gateway you already have. Avi is a real distributed system: SDDC Manager deploys a three-node Avi Controller cluster into the management domain for control-plane HA, paired one-to-one with each NSX Manager, and the traffic is handled by Service Engines, lightweight data-plane VMs the controller places and scales. Controllers and Service Engines talk over HTTP/2 on port 8443. For lab use you can run a single controller (VCF 9.0 added a workaround, 9.1 exposes a simpler single-node path), but do not carry that into production where controller HA matters. Plan management-domain capacity for the controllers up front, alongside the sizing in the reference architecture.

The licensing change is the part teams miss. General-purpose load balancing is no longer inside the VCF entitlement, so Avi is a line item you budget separately. That is the single biggest reason to stop treating just turn on the NSX LB as free: the free option is going away, and the capable option has a cost. Decide it on purpose, not at cutover, and see the licensing breakdown for what is and is not entitled.

Where each one still fits

Choose Avi when you are deploying anything new, when you need WAF, GSLB, or per-request analytics, when you are running the vSphere Supervisor or VKS and need Kubernetes ingress, or when you are adopting the VPC model. That covers the overwhelming majority of VCF 9 designs. The only place NSX native LB still makes sense is narrow: an existing, simple L4 or basic L7 config already running on it, where you want to avoid touching anything until a planned migration window. Treat that as a bridge, not a destination. Broadcom provides a migration path and tooling to move existing configurations onto Avi.

Sizing the Service Engines

The controllers are the brain, but the Service Engines are where throughput actually lives, and they are the part teams forget to size. Service Engines are lightweight data-plane VMs that the controller places and scales, and Avi can autoscale them predictively as virtual service load grows. The design questions are how many Service Engines per workload domain, how you group virtual services onto them, and whether you run them in a dedicated or shared placement. For a first deployment, let the controller manage placement and start conservative, then watch the per-request analytics Avi gives you and scale from real data rather than a guess. The point that matters for capacity planning: Service Engines consume host resources in the workload domain, separate from the controller footprint in the management domain, so they belong in both halves of your sizing model.

Migrating off the native NSX LB

If you have existing NSX native load balancer configurations, do not rip them out on a deadline. Broadcom provides a migration path and tooling to move configurations onto Avi, so the sane sequence is to stand up the Avi controllers, recreate or migrate one simple virtual service onto Avi, validate it against the per-request analytics, and then move services in waves on a window you control. Confirm the Avi version supports your networking model first, because the VPC model needs Avi 31.1 or later, and back up both NSX and Avi configuration before you cut over. The goal is to leave nothing production sitting on the deprecated component, but to get there on your schedule rather than a removal date set by someone else.

The Verdict

The verdict is not close. In VCF 9, Avi Load Balancer is the choice for every new design: strategic, integrated, fully featured, and where Broadcom is investing. NSX native load balancing is deprecated and should be used only as a temporary bridge for simple existing configs you have a plan to migrate. Yes, Avi costs more in controllers, Service Engines, and licensing, but you are paying for the platform that is not being removed, plus WAF, GSLB, and Kubernetes ingress you would otherwise bolt on later. Budget for it, size the controllers into the management domain, and migrate the stragglers on your schedule rather than a deprecation deadline. What is your current split between NSX native and Avi, and is a migration window booked?

References

• Broadcom TechDocs: Deploying Avi Load Balancer in VCF 9
• VMware: Native NSX Load Balancing is Going Away, Migrate to Avi
• William Lam: Single-Node Avi Load Balancer with VCF 9.0 and 9.1

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts