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 AreaVDS + Foundation Load BalancerVPC Networking / NSX-T PathArchitecture ImplicationPrimary modelTraditional vSphere networking with VLAN-backed port groupsCloud-style VPC networking backed by VCF Networking / NSXVDS feels familiar; VPC changes the consumption modelLoad balancingFoundation Load Balancer for basic Layer 4 load balancingNative NSX load balancing or Avi integration, depending on designFLB is simpler; VPC gives broader service design optionsSupervisor deployment styleFaster for teams already standardized on VDS and VLAN operationsMore involved upfront because NSX/VPC design must be readyVDS can accelerate first deployment; VPC requires stronger architecture preparationConsumption modelPlatform/admin-drivenSelf-service and automation-friendlyVPC is better aligned to platform engineering and internal cloud patternsVCF Automation supportNot the preferred path for VCF Automation infrastructure consumptionRequired for VCF Automation-based consumption workflowsThis is one of the biggest decision pointsTenant isolationPrimarily namespace, VLAN, firewall, and operational process boundariesVPCs, subnets, policy, firewalling, and connectivity controlsVPC provides cleaner tenant and project boundariesNetwork servicesMore dependent on external or manually provided servicesNAT, load balancing, IPAM, routing, and security policy are more integratedVPC reduces handoffs when properly designedIPAMOften handled through existing enterprise IPAM and manual allocationCan integrate with native IPAM or third-party IPAM such as InfobloxVPC supports a more automated address lifecycleSecurity policyUsually enforced through existing network/firewall process plus vSphere/namespace controlsSupports NSX-backed security and distributed policy patternsVPC gives security teams better platform-native policy hooksOperational complexityLower initial complexity, but more manual process over timeHigher initial architecture complexity, but better scaling modelVDS is simpler to start; VPC is cleaner to scaleBest fitLab, pilot, tightly controlled Private AI deployment, smaller scopeProduction platform, multi-team AI services, developer self-service, governed consumptionMatch the model to the platform ambitionMigration postureFuture move to VPC generally means planned redeploymentBetter long-term target if VCF Automation and self-service are expectedAvoid 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.
External Sources
VMware Cloud Foundation Blog: Deploying VMware Cloud Foundation Private AI Services, Navigating the Supervisor Networking Stackhttps://blogs.vmware.com/cloud-foundation/2026/06/11/deploying-vmware-cloud-foundation-private-ai-services-navigating-supervisor-networking-stack/
VMware Cloud Foundation Blog: VCF Networking 9.1, Exploring Network Services for Virtual Private Cloudshttps://blogs.vmware.com/cloud-foundation/2026/05/15/vcf-networking-9-1-exploring-network-services-for-virtual-private-clouds/
VMware Cloud Foundation Blog: Simplify Workload Connectivity and Enhance Network Scale and Performance with VCF 9.1https://blogs.vmware.com/cloud-foundation/2026/05/05/simplify-workload-connectivity-and-enhance-network-scale-and-performance-with-vcf-9-1/
VMware Cloud Foundation Blog: VCF Networking 9.1, Simpler VPC Connectivity Controlhttps://blogs.vmware.com/cloud-foundation/2026/05/15/vcf-networking-9-1-simpler-vpc-connectivity-control/
VMware Cloud Foundation Blog: Unlocking the Full Potential of Programmable Infrastructure with VMware Cloud Foundation 9.1https://blogs.vmware.com/cloud-foundation/2026/05/25/unlocking-the-full-potential-of-programmable-infrastructure-with-vmware-cloud-foundation-9-1-new-features-and-capabilities/
AI Agents Are the New Control Plane: Governing Identity, Tool Access, and Observability Across Azure, AWS, Google Cloud, and VCF
Introduction The first article in this series focused on multicloud control-plane sprawl. Azure, AWS, Google Cloud, and VMware Cloud Foundation each bring…
The post VCF Private AI Services Networking: VDS + Foundation Load Balancer vs VPC Networking appeared first on Digital Thought Disruption.