VCF Private AI Services networking looks like an installer choice until you follow the consequences downstream.
At first glance, the decision appears simple: deploy the vSphere Supervisor with traditional VDS networking and Foundation Load Balancer, or deploy it with VCF Networking using VPCs. Both can support Private AI Services. Both can get a Supervisor online. Both can put AI platform services in front of developers.
But they do not create the same operating model.
This is the architecture fork.
The VDS + Foundation Load Balancer path is closer to a traditional vSphere operational model. It fits environments that want to move quickly, reuse familiar VLAN-backed networking, and keep the first deployment narrow. The VPC networking path is closer to a cloud consumption model. It is designed around self-service networks, multi-tenancy, policy, automation, and NSX-backed network services.
VMware’s current Private AI Services guidance calls out both Supervisor networking options: VCF Networking with VPC and VDS. VMware also notes that the choice affects consumption, scalability, and the ability to use VCF Automation as the infrastructure consumption layer.
The practical question is not simply, “Which load balancer should I use?”
The better question is:
Are you deploying Private AI Services as a controlled platform service, or are you building an AI consumption platform?
Scope and Assumptions
This article is focused on VCF Private AI Services networking in a VCF 9.x context, with emphasis on the design fork between:
- VDS + Foundation Load Balancer
- VCF Networking with VPC, commonly discussed by many architects as the NSX-backed or NSX-T path
A terminology note is important here. VMware’s current language uses VCF Networking with VPC and VCF Networking (NSX). Many practitioners still say “NSX-T” when they mean the NSX-backed networking model. In this article, NSX-T is used as practitioner shorthand for the NSX-backed VPC architecture path, not as a third separate design.
This article assumes:
- You are deploying or planning VCF Private AI Services.
- You are using a vSphere Supervisor as part of that design.
- You care about the long-term operating model, not only initial deployment.
- You may need to support model endpoints, GPU-backed workloads, namespaces, developer access, IPAM, load balancing, and governance.
- You are making a design decision before production standardization.
VMware describes Private AI Services as built into VCF and including capabilities such as Model Gallery, Model Runtime, Agent Builder, Data Indexing for RAG, API Gateway, and MCP Tools Registry. VMware also describes the Supervisor as the Kubernetes control plane layer where these services are activated and consumed.
What Is Actually Being Compared?
This comparison is not only about packets.
It is about the relationship between networking, platform consumption, and operational ownership.
Option 1: VDS + Foundation Load Balancer
This path uses traditional vSphere Distributed Switch networking with VLAN-backed port groups. Foundation Load Balancer provides a native, lightweight Layer 4 load balancer option for the Supervisor. VMware describes FLB as simple and lightweight, running as one or two VMs in an active/passive model, but also notes that it is limited compared to Avi Load Balancer.
This path generally aligns with environments where the virtualization team owns most of the deployment workflow and the network team provides VLANs, IP ranges, routing, DNS, and firewall rules through existing processes.
Option 2: VPC Networking
This path uses VCF Networking with VPCs. It is NSX-backed and exposes a more cloud-like networking model with self-service VPCs, subnets, NAT, load balancing, distributed firewalling, IPAM integration, and connectivity policy options. VMware positions this path as the one required for VCF Automation infrastructure consumption use cases.
This path generally aligns with environments where Private AI Services are part of a governed internal platform, not just a manually operated cluster service.
Decision Path at a Glance
The diagram below is intentionally simple. The important part is not the packet path. The important part is the operating model that follows each networking decision.
What to notice: both paths start with the Supervisor, but they diverge in how teams consume networking, how platform services are exposed, how tenants are isolated, and how much automation the environment can support.
VMware explicitly notes that moving from a VDS-based Supervisor model to a VPC-based model is not a simple configuration switch. It requires planned redeployment because the underlying network fabrics differ.
Networking Comparison Table
| Decision Area | VDS + Foundation Load Balancer | VPC Networking / NSX-T Path | Architecture Implication |
|---|---|---|---|
| Primary model | Traditional vSphere networking with VLAN-backed port groups | Cloud-style VPC networking backed by VCF Networking / NSX | VDS feels familiar; VPC changes the consumption model |
| Load balancing | Foundation Load Balancer for basic Layer 4 load balancing | Native NSX load balancing or Avi integration, depending on design | FLB is simpler; VPC gives broader service design options |
| Supervisor deployment style | Faster for teams already standardized on VDS and VLAN operations | More involved upfront because NSX/VPC design must be ready | VDS can accelerate first deployment; VPC requires stronger architecture preparation |
| Consumption model | Platform/admin-driven | Self-service and automation-friendly | VPC is better aligned to platform engineering and internal cloud patterns |
| VCF Automation support | Not the preferred path for VCF Automation infrastructure consumption | Required for VCF Automation-based consumption workflows | This is one of the biggest decision points |
| Tenant isolation | Primarily namespace, VLAN, firewall, and operational process boundaries | VPCs, subnets, policy, firewalling, and connectivity controls | VPC provides cleaner tenant and project boundaries |
| Network services | More dependent on external or manually provided services | NAT, load balancing, IPAM, routing, and security policy are more integrated | VPC reduces handoffs when properly designed |
| IPAM | Often handled through existing enterprise IPAM and manual allocation | Can integrate with native IPAM or third-party IPAM such as Infoblox | VPC supports a more automated address lifecycle |
| Security policy | Usually enforced through existing network/firewall process plus vSphere/namespace controls | Supports NSX-backed security and distributed policy patterns | VPC gives security teams better platform-native policy hooks |
| Operational complexity | Lower initial complexity, but more manual process over time | Higher initial architecture complexity, but better scaling model | VDS is simpler to start; VPC is cleaner to scale |
| Best fit | Lab, pilot, tightly controlled Private AI deployment, smaller scope | Production platform, multi-team AI services, developer self-service, governed consumption | Match the model to the platform ambition |
| Migration posture | Future move to VPC generally means planned redeployment | Better long-term target if VCF Automation and self-service are expected | Avoid treating VDS as a harmless temporary choice if VPC is the real target |
VMware’s VCF 9.1 networking materials also describe VPC network services such as switching, routing, IP management, NAT, and load balancing, with different design modes for distributed and centralized services.
Option 1: VDS + Foundation Load Balancer
The VDS + Foundation Load Balancer path is the pragmatic starting point for teams that want to stand up Private AI Services without redesigning the entire network operating model first.
That does not make it a weak option.
It makes it a scoped option.
In many enterprise environments, the virtualization team already has a well-understood VDS model. VLANs are documented. Uplinks are known. Firewall processes exist. IPAM may be handled outside of VCF. DNS is probably centralized. Change control already knows how to approve these requests.
That familiarity matters when a team is trying to get its first Private AI deployment off the ground.
Foundation Load Balancer strengthens that story because it gives the Supervisor a native lightweight Layer 4 load balancing option without requiring a full Avi Load Balancer deployment on day one. VMware describes it as simple and lightweight, while also making clear that it is limited compared to Avi.
Where VDS + FLB Works Well
VDS + FLB is a good fit when the environment looks like this:
- The deployment is a proof of concept, pilot, or limited production service.
- A small platform team will manage Private AI Services directly.
- Network provisioning is already handled through established VLAN workflows.
- There is no immediate requirement for VCF Automation as the developer-facing consumption layer.
- Tenant isolation requirements are modest or handled through existing firewall and operational processes.
- The priority is reducing initial platform friction.
This path is especially attractive when the organization is still validating the Private AI use case. For example, a platform team may want to expose a curated model runtime to one or two internal engineering groups before building a full self-service AI platform.
In that case, VDS + FLB can be the right first move.
The Tradeoff
The tradeoff is that the simplicity is front-loaded.
As more teams consume the platform, manual network coordination becomes harder to sustain. Every new project, namespace, model endpoint, routing requirement, IP allocation, firewall exception, or exposure model may require a ticket-driven workflow. That may be acceptable for a controlled deployment. It becomes painful when the environment is expected to behave like an internal cloud.
VMware’s own comparison notes that the VDS path is simpler and faster for existing VLAN-based networks, but it lacks the same on-demand networking, micro-segmentation, and VCF Automation integration that the VPC path provides.
The risk is not that VDS + FLB cannot work.
The risk is that it works well enough to become the accidental production standard.
Option 2: VPC Networking / NSX-T Path
The VPC networking path is the better fit when Private AI Services are intended to become a platform capability.
This matters because AI platform consumption is rarely static. The first deployment may involve one model and one internal team. The second phase usually introduces more namespaces, more users, more model endpoints, more data indexing workflows, more security reviews, and more questions about who can expose what to whom.
That is where VPC networking becomes more than an NSX feature.
It becomes the control surface for consumption.
VMware describes VPC networking as supporting self-service VPCs, networks, NAT, load balancing, distributed firewalling, and richer automation patterns. VMware also notes that VCF Automation requires a Supervisor deployed with VPC networking for its consumption model.
Where VPC Networking Works Well
VPC networking is a better fit when the environment looks like this:
- Multiple teams will consume Private AI Services.
- Developers or platform consumers need self-service access.
- VCF Automation is part of the operating model.
- Tenants need clearer isolation boundaries.
- Network services should be provisioned through policy and automation.
- IPAM, NAT, load balancing, and firewall rules need to scale without ticket-heavy workflows.
- Security teams need a more platform-native enforcement model.
This path aligns better to an internal AI platform where users request services, deploy workloads, consume models, and operate inside governed boundaries.
The Operational Reality
VPC networking is not free.
It requires a mature VCF Networking / NSX design. That includes external connectivity, IP blocks, VPC planning, routing, security policy, naming standards, tenant boundaries, and operational ownership. The network team and platform team need to agree on where self-service starts and where central guardrails remain.
VCF 9.1 adds important networking improvements, including distributed connectivity options, multiple external connection models, transit gateways, and better VPC planning and assessment capabilities. VMware also describes distributed VLAN connections that can reduce reliance on dedicated edge nodes for some designs, while centralized designs still provide broader service flexibility.
The design decision still has to be intentional. Distributed mode, centralized mode, VNA clusters, edge placement, IPAM, and connectivity policy all need to be planned. VMware’s VPC service guidance also notes that distributed mode has topology constraints, while centralized mode supports a broader set of services and physical network layouts.
VPC is the stronger long-term architecture for a private AI platform.
It is also the architecture that requires more discipline before deployment.
VCF Automation Is the Line in the Sand
One of the clearest decision points is VCF Automation.
If the Private AI Services environment is expected to be consumed through VCF Automation, the VPC path becomes the architectural center of gravity. VMware states that VCF Automation requires a Supervisor deployed with VPC networking because VCF Automation depends on the VPC model for IPAM and multiple VPCs.
That changes the conversation.
Without VCF Automation, the VDS path can still support Private AI Services, but the operating model leans more heavily on manual activation, CLI/YAML workflows, kubectl, and direct platform administration. VMware notes that without VCF Automation in the VDS model, Private AI Services can still be activated and endpoints can be deployed manually, while the Private AI Services UI remains available for the application layer.
That distinction is easy to miss.
The Private AI Services UI and VCF Automation are not the same thing. The first helps with AI service consumption at the application layer. The second changes the infrastructure consumption model.
For a small controlled deployment, that may be fine.
For a platform team trying to deliver governed self-service AI infrastructure, it is a major limitation.
Common Misunderstandings
“Foundation Load Balancer means the simple path is always the best path.”
Foundation Load Balancer is useful because it lowers the barrier to entry. It is not a replacement for a complete load balancing architecture in every production scenario. VMware positions FLB as lightweight Layer 4 load balancing and contrasts it with Avi Load Balancer for richer enterprise-grade use cases.
The right question is not whether FLB works.
The right question is whether FLB matches the expected service exposure, scale, resiliency, and operational requirements.
“VPC networking is just an NSX preference.”
VPC networking is not just a network team preference. It changes how infrastructure is consumed.
A VPC-based design supports a more cloud-like model where networks, policies, IPAM, NAT, load balancing, and tenant boundaries can be handled closer to the platform. VMware’s VPC networking materials describe network services that include IP management, NAT, load balancing, and centralized or distributed service models.
That makes the VPC path a platform design decision, not just an NSX deployment choice.
“We can start with VDS and flip to VPC later.”
This is the assumption to challenge early.
VMware notes that transitioning from VDS to VPC in VCF 9.1 requires planned Supervisor redeployment because the underlying fabrics are different.
That does not mean VDS is wrong. It means VDS should not be selected casually when the known target state is VPC-based consumption.
“Connectivity policy is automatic in every VPC design.”
VCF 9.1 introduces VPC Connectivity Policy for controlling communication between VPCs, including policy models such as community, promiscuous, and isolated. VMware also notes that this capability is available through the Advanced Cyber Compliance add-on.
That detail matters for architecture reviews. Do not build a security design around a feature until the entitlement, licensing, and version requirements are confirmed.
Where Each Option Fits
Choose VDS + Foundation Load Balancer When
Use VDS + FLB when the goal is controlled adoption.
This path makes sense when you need to validate Private AI Services, support a limited audience, and keep the network design close to existing vSphere operations. It is also reasonable when the organization has not yet standardized VCF Automation or is not ready to operate VPC networking as a platform service.
Good fit scenarios include:
- First Private AI Services proof of concept
- Small platform team with direct operational ownership
- Limited namespace count
- Existing VLAN-based network model
- No immediate developer self-service requirement
- No near-term dependency on VCF Automation
- Conservative rollout where manual control is preferred
The design principle is simple:
Use VDS + FLB when Private AI Services are being introduced as a managed platform capability with limited scope.
Choose VPC Networking When
Use VPC networking when the goal is platform scale.
This path makes sense when Private AI Services are part of a broader internal platform strategy. It is the better fit when multiple teams will consume services, when automation matters, when network isolation must be repeatable, and when VCF Automation is expected to provide the front door for infrastructure consumption.
Good fit scenarios include:
- Production Private AI Services platform
- Multiple business units, tenants, or developer teams
- VCF Automation-based catalog or request workflows
- Stronger network isolation and policy requirements
- Integrated IPAM and repeatable network lifecycle
- Platform engineering operating model
- Long-term expansion of AI services and model endpoints
The design principle is also simple:
Use VPC networking when Private AI Services are becoming an internal AI cloud platform.
Decision Checklist
Operational Checks Before You Commit
Before selecting the networking path, validate these items with the platform, network, security, and automation teams.
Supervisor Lifecycle
Confirm whether the selected Supervisor networking model is intended to be long-lived. If the expected future state is VPC, do not treat VDS as a harmless temporary step unless the team accepts a planned redeployment later.
Load Balancer Requirements
Decide whether Foundation Load Balancer is enough for the environment or whether Avi Load Balancer or another enterprise load balancing pattern is required. Consider scale, resiliency, operational visibility, service exposure, and future application requirements.
VCF Automation Dependency
Confirm whether VCF Automation is in scope. If it is, VPC networking should be treated as a core requirement, not an optional enhancement. VMware’s guidance is clear that VCF Automation infrastructure consumption depends on the VPC networking model.
IPAM and DNS Ownership
Document who owns IP allocation, DNS registration, certificate naming, endpoint exposure, and cleanup. Manual IPAM may work for a pilot. It usually becomes a bottleneck as more namespaces and model endpoints appear.
Security Boundary Model
Define the boundary between tenants, namespaces, model endpoints, data indexing services, and shared services. With VDS, much of that boundary may live in existing firewall and process controls. With VPC, more of it can be represented as platform-native networking and security policy.
NSX / VCF Networking Readiness
For the VPC path, validate NSX operational readiness. That includes monitoring, backup, troubleshooting, routing ownership, connectivity policy, IPAM integration, and escalation paths. VPC networking gives the platform more power, but it also requires the organization to operate that power responsibly.
Automation and API Strategy
VCF 9.1 continues to expand programmable infrastructure capabilities, including API and SDK coverage for VCF components and VPC-related automation. If the team wants repeatable platform operations, automation should be part of the networking decision rather than an afterthought.
Practical Recommendation
For most organizations, the decision comes down to ambition and readiness.
Use VDS + Foundation Load Balancer when the goal is to deploy Private AI Services quickly, validate the service, and keep the operational surface area small. This is a reasonable path for pilots, controlled rollouts, and environments where platform self-service is not yet required.
Use VPC Networking when Private AI Services are expected to become a shared, governed, multi-tenant platform. This is the better long-term path for VCF Automation, stronger isolation, integrated network services, automated IPAM, and a cloud-like consumption model.
The mistake is not choosing VDS.
The mistake is choosing VDS while pretending it is neutral.
It is not neutral. It commits the deployment to a more traditional operating model. That may be exactly what the organization needs for phase one, but it should be documented as an intentional architecture decision.
The VPC path is more complex upfront, but it aligns better with where enterprise Private AI Services are likely heading: governed consumption, repeatable network lifecycle, policy-driven access, and platform automation.
Conclusion
VCF Private AI Services networking should be treated as an architecture fork, not an installer detail.
VDS + Foundation Load Balancer gives teams a faster and more familiar starting point. It is practical, especially when the environment is small, controlled, and still validating the use case.
VPC Networking gives teams the better platform foundation. It supports the operating model that most enterprises eventually want from Private AI Services: self-service, governance, tenant isolation, automated networking, and VCF Automation alignment.
The cleanest design decision is to be honest about the target state.
If Private AI Services are a controlled service owned by a small platform team, VDS + FLB may be enough.
If Private AI Services are the beginning of an internal AI platform, VPC networking should be treated as the default architecture path.
