Pick the load balancer for your vSphere Supervisor and you have made a decision you cannot take back. Once the Supervisor is activated, the engine it publishes services on is fixed for the life of that Supervisor, and swapping it means tearing the Supervisor down and building it again. Last part we prepared VCF 9 and enabled the Supervisor. This part we make the two choices that sit under it, the workload network model and the load balancer, and we make them in that order because the first choice narrows the second.

Three platform load balancers and one irreversible pick

Three engines can sit under a Supervisor, and each was built for a different operating model. Foundation LB is the load balancer VCF ships in the box, a Layer 4 service that publishes an IP and port with no extra licensing beyond your VVF or VCF entitlement, and it carries the smallest footprint of the three. NSX-LB is the NSX load balancer, also Layer 4, included with VCF for estates already running NSX networking. Avi, the NSX Advanced Load Balancer, is the Enterprise-grade option, adding Layer 7 routing, a web application firewall, real health monitoring, analytics and global server load balancing, and it wants its own Avi Enterprise license and a set of Service Engines to run on.

All three give Supervisor-managed workloads Layer 4 connectivity, which on VKS means the VKS cluster control planes, any VM Service virtual machines, and the LoadBalancer-type services your applications expose. Management sizing is small and identical whichever you pick, the Supervisor control plane wants five consecutive IPs on its management network and a minimum of two Edge nodes for its Edge cluster. What differs is everything above Layer 4, and that difference is exactly what a migration off NSX-T tends to need.

Avi is not free in footprint terms, and that cost belongs in the decision. Where Foundation LB and NSX-LB run as platform services with nothing extra to stand up, Avi wants an Avi Controller and a set of Service Engines, virtual machines that carry the data plane and consume CPU, memory and IPs of their own. On a small estate that overhead can outweigh a Layer 7 feature nobody uses, which is a fair argument for Foundation LB on a genuinely simple cluster. On an estate carrying real Layer 7 policy off NSX-T, that same overhead buys back behaviour your applications already depend on, so it reads as continuity rather than cost.

One relief before the pressure: the platform load balancer you choose for the Supervisor does not cap what your teams run inside a VKS cluster. Because VKS clusters are upstream-conformant Kubernetes, an application team can still bring Contour, Istio, the Gateway API or MetalLB inside the cluster for their own ingress, regardless of what the Supervisor publishes on. That in-cluster ingress story sits in the VKS Series. That platform choice governs the front door, not every room behind it, and that distinction keeps the immutable pick from feeling like a life sentence for developers.

Network model decides the shortlist

You do not get a free choice among all three. Your workload network model, the decision from Part 7, sets which load balancers are even offered when you activate the Supervisor. Match the two wrong and the activation wizard simply will not present the engine you had in mind. Here is the mapping, small enough to memorise and worth memorising.

Here is a genuine seam in the documentation worth flagging before you design around it. VCF team guidance from July 2026 maps NSX VPC to Avi only, while the Supervisor VPC architecture reference still reads that a VPC can use the NSX load balancer or Avi. My reading is that Avi is the safe and supported engine for an NSX VPC on VCF 9, and I would not design a production migration around NSX-LB on a VPC until that combination is confirmed for your build [VERIFY]. If you want the cloud-consumption model that VPC networking unlocks, plan for Avi and move on. Our reference estate lands on NSX VPC, so this narrows its shortlist to one before any feature debate even starts.

Why does a VPC push you to Avi at all? NSX VPC is the workload network VCF recommends for the full cloud-consumption model, the self-service subnets and tenant projects that VCF Automation drives, and Avi is the load balancer wired into that model. Choosing VPC is therefore a commitment to a way of consuming the platform, not just a subnet layout, and the load balancer follows from it. On a migration that intends to hand application teams self-service namespaces later, that commitment is usually the one you want, so Avi arrives as a consequence of a larger design decision rather than a standalone pick.

flowchart TD
  Q1[Workload network model] --> V[VDS]
  Q1 --> S[NSX segment]
  Q1 --> P[NSX VPC]
  V --> V2{Need L7 WAF or GSLB}
  V2 -->|yes| VA[Avi]
  V2 -->|no| VF[Foundation LB]
  S --> S2{Need L7 WAF or GSLB}
  S2 -->|yes| SA[Avi]
  S2 -->|no| SN[NSX LB]
  P --> PA[Avi]

Load balancer selection matrix

Keep the table below. It is the reference artifact of this part, a capability-by-capability comparison of the three engines with the best-fit call spelled out on the last row. When someone argues the free built-in load balancer is obviously the right default, this is the answer that shows why free is not the same as fit.

Read the last three rows together and the migration story writes itself. Every engine is a rebuild if you change your mind, so the cost of a wrong pick is identical and high. Only Avi maps closely to how an NSX-T load balancer behaved, with real health monitors and Layer 7 rules, which matters the instant your old estate has any application that depended on those. For the build detail behind that row, the NSX Series walks the Avi registration against NSX Manager.

Numbers from the reference estate

Capability rows tell you what is possible. Numbers tell you what the decision actually costs on the ground. These are the figures that moved the load balancer call on the reference estate, three TKGI clusters landing on VKS with NSX VPC networking.

Sit with the 47 for a moment, because it sets the real project size. Forty seven virtual servers is forty seven separate re-authoring tasks, each with a pool, a health monitor and often a persistence rule to reproduce, and none of it copies across. At even fifteen minutes for a clean one, that is most of a working day before anything unusual appears, and unusual always appears. Sizing the load balancer migration off that count, rather than off a vague sense that services will just move, is what keeps the cutover schedule honest.

One row invites a wrong conclusion, so let me pull it out. Foundation LB programs a fresh VIP fastest in the lab, and it is tempting to read that speed as the tiebreaker. It is not. A one-time VIP publish measured in seconds is noise against a service that runs for years, and the chart below shows the gap is real but small. Let latency at provision time decide a permanent, immutable choice and you have optimised the wrong variable.

NSX-T load balancer inventory and the no import reality

Now the part of the decision that a feature table hides. On TKGI, the NSX-T load balancer held a real inventory built over years, virtual servers, server pools, health monitors and persistence profiles, all expressed in NSX-T terms. None of that exports into a Supervisor load balancer. There is no configuration import, on Avi, NSX-LB or Foundation LB. You re-express the intent, one virtual server at a time, in the target engine, which is why the count of what you carry, 47 virtual servers on the reference estate, matters more than any single feature checkbox. A closer map between target and source behaviour means fewer surprises during that re-authoring, and Avi is the closest map.

Categorising the inventory is less obvious than it sounds, so give it a rule. Any virtual server doing plain IP and port forwarding is L4 and moves cleanly to any of the three engines. A virtual server doing host or path routing, TLS termination, header rewriting or content switching is L7, and only Avi reproduces it at the platform. Persistence is the quiet trap, because a source IP stickiness rule looks like L4 but pins you to an engine that supports the same persistence type, and Foundation LB does not. Tag each row for both dimensions, routing layer and persistence, before you total the Avi column.

That is the contradiction to the common advice, said plainly. Tutorials and quick-start guides reach for Foundation LB because it is built in and free, and for a greenfield lab that is the right reflex. On a migration, free plus immutable is a trap. Add one application on that Supervisor with L7 policy, or land on NSX VPC networking, and the built-in default strands you against a wall you cannot move without a rebuild. A safe default for a TKGI migration flips the other way, assume Avi unless you can prove every service on the cluster is pure L4 and will stay that way.

Avi for the reference estate, Foundation LB at the edge

My verdict for the reference estate is Avi, on two grounds that reinforce each other. It is the supported engine for the NSX VPC networking these clusters land on, so the network model already points there, and it is the closest behavioural match to the NSX-T load balancer inventory those clusters are leaving, so the 47 virtual servers re-author with the fewest surprises. Choose Foundation LB only where the cluster is genuinely simple L4, runs on VDS rather than a VPC, carries no L7 policy today, and no roadmap item will add one. A pick to avoid is reaching for Foundation LB because it is free and in the box on a cluster that carries any L7 requirement, since that saving evaporates the first time you have to rebuild a Supervisor to correct it.

One more framing helps a change board sign off. Present the load balancer choice as a per-cluster decision, not an estate-wide standard, because the two are not the same thing. A batch of pure L4 clusters on VDS can sit on Foundation LB while your policy-heavy clusters on VPC sit on Avi, and nothing about VKS forces one engine across the whole fleet. Standardising for its own sake here can push a simple cluster onto Avi footprint it does not need, or push a policy-heavy cluster onto Foundation LB it cannot support. Decide per Supervisor, record the reason, and move on.

Next part builds the first VKS cluster on the network and load balancer you just chose, with vSphere Namespaces, cluster classes and node pools. Bring the load balancer decision per cluster, because the cluster build assumes the Supervisor underneath it is already committed to one.

References

• VMware Cloud Foundation Blog, Load Balancing in vSphere 9.0+ and VCF 9.0+, July 2026
• Broadcom TechDocs, Supervisor Architecture with VCF Networking with VPC, VCF 9
• Broadcom TechDocs, Deploying vSphere Supervisor with NSX and Avi Load Balancer, VCF 9

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