VCF 9.1 VPC Networking: Distributed vs. Centralized Transit Gateway Designs

TL;DR

VCF 9.1 supports two distinct approaches for connecting Virtual Private Clouds to the physical data center network.

A Distributed Transit Gateway removes NSX Edge nodes, the Tier-0 gateway, and BGP from the north-south forwarding path. Traffic can leave directly from the ESXi host through a VLAN shared by every participating host. The design reduces architecture overhead and can eliminate an Edge forwarding hop, but it depends heavily on consistent Layer 2 reachability, physical gateway behavior, host uplink configuration, IP address management, and workload mobility convergence.

A Centralized Transit Gateway sends external traffic through NSX Edge nodes and a Tier-0 gateway. It requires more infrastructure and routing configuration, but it supports Layer 2 or Layer 3 physical topologies, dynamic routing, VPN services, centralized service insertion, and clearer provider-controlled routing boundaries.

The decision should be based on physical-network reachability, required network services, expected traffic patterns, scale boundaries, failure domains, and operational ownership. It should not be based only on whether the organization wants to avoid deploying Edge nodes.

Introduction

VCF 9.1 turns VPC external connectivity into a genuine architecture decision.

Traditional NSX designs generally assume that north-south traffic will eventually reach an NSX Edge node and a Tier-0 gateway. That model remains available, but it is no longer the only supported path for connecting VPC workloads to physical networks.

A Distributed Transit Gateway can connect workloads directly from ESXi hosts to a physical VLAN. A Centralized Transit Gateway retains the NSX Edge and Tier-0 service boundary. Both designs are valid, but they optimize different things.

Distributed connectivity optimizes for forwarding locality, reduced virtual-appliance dependency, and simpler integration with suitable Layer 2 environments. Centralized connectivity optimizes for routing flexibility, service availability, physical-fabric independence, and explicit operational boundaries.

The difference affects more than packet forwarding. It changes:

• Where north-south capacity is consumed
• Which failures can affect multiple workloads
• How existing VLAN networks are reached
• Where NAT, VPN, and other services run
• Which team owns routing and troubleshooting
• What must be validated before self-service access is enabled

This guide compares the two VCF 9.1 Transit Gateway designs through the decisions architects and operators must make before production deployment.

Why This Comparison Matters

A platform team could select distributed connectivity because it appears simpler. The deployment avoids NSX Edge virtual machines, Tier-0 configuration, and BGP peering.

That does not necessarily make the complete environment simpler.

The shared VLAN must still be available on every ESXi host that can run connected workloads. The physical gateway must support the traffic and adjacency scale. The switching fabric must converge correctly after workload mobility. The platform and network teams must agree on address ownership, failure handling, and monitoring.

The same problem appears in reverse with centralized connectivity.

A platform team could deploy an Edge cluster because it is the familiar NSX pattern. However, an undersized Edge tier can become a shared bottleneck, an unnecessary forwarding hop, or a concentration point for workloads that never required centralized services.

The correct question is not:

Which option has fewer components?

The correct question is:

Which option places forwarding, routing, services, failures, and ownership in the locations that best match the environment?

Scope and Assumptions

This comparison focuses on VCF 9.1 VPC connectivity from VPC workloads to physical data center networks.

It does not attempt to replace a complete NSX reference design, product release notes, or the VMware Configuration Maximums documentation. Exact component limits, supported service combinations, and sizing requirements should be validated against the installed VCF 9.1 build before design approval.

The article uses the following assumptions:

• The VCF 9.1 networking domain is healthy and correctly deployed.
• ESXi hosts are configured as NSX transport nodes.
• Overlay networking and host transport-node connectivity are operational.
• IP blocks and external address ranges are centrally managed.
• The physical network can provide the required VLAN or routed connectivity.
• Network services are sized and tested against the actual workload profile.
• Provider and tenant responsibilities are defined before self-service is enabled.

Terminology Guardrails

VPC Gateway

The VPC Gateway provides distributed routing for subnets inside a VPC. Workload routing between VPC subnets can remain on the ESXi transport nodes instead of being sent to an Edge node.

Transit Gateway

The Transit Gateway connects VPC Gateways and provides a path toward approved external connections.

External Connection

An External Connection represents a provider-defined connection between the VCF networking environment and the physical network. The provider exposes approved external connections to tenants without exposing the complete physical topology.

Distributed Transit Gateway Design

The Transit Gateway connects to a VLAN that is reachable from every participating ESXi host. An NSX Edge cluster and Tier-0 gateway are not required for the external forwarding path.

Centralized Transit Gateway Design

The Transit Gateway connects through NSX Edge service routers and a Tier-0 gateway. External connectivity is provided through Tier-0 uplinks using BGP or static routing.

Virtual Network Appliance Cluster

VCF 9.1 can deliver additional stateful network services to distributed connectivity through a Virtual Network Appliance cluster. This expands the available services, but it also introduces appliance placement, capacity, health, lifecycle, and recovery requirements.

The Architecture Decision at a Glance

The most important difference is where traffic crosses from the VPC networking environment into the physical network.

Both approaches keep VPC internal routing distributed. The architecture separates when traffic must leave the VPC environment.

In the distributed design, traffic reaches the external VLAN directly from the ESXi host running the workload.

In the centralized design, traffic is steered through an Edge service router and the Tier-0 gateway before reaching the physical network.

Distributed Transit Gateway Design

The distributed model removes the Edge cluster and Tier-0 gateway from the external forwarding path. The Transit Gateway is realized across the ESXi hosts and connects directly to an external VLAN.

This is a meaningful simplification when the physical environment already satisfies the design requirements. It is not a method for bypassing proper underlay planning.

Edge and Underlay Requirements

Distributed connectivity requires one critical physical-network condition:

Every ESXi host eligible to run the connected workloads must reach the same external Layer 2 network.

The requirement affects more than the NSX configuration. The VLAN must be:

• Permitted across every required host uplink
• Available on each participating rack and switch path
• Connected to the expected physical default gateway
• Configured consistently across the vSphere Distributed Switch and physical fabric
• Included in host maintenance, expansion, and compliance checks
• Sized for the required MAC and ARP behavior

The design team must also define which hosts are allowed to run the connected workloads. VCF 9.1 VPC span and workload-placement controls can help constrain that scope, but the host placement design and physical VLAN reachability must remain aligned.

A cluster expansion is not complete merely because the new hosts join vCenter and NSX. The distributed external VLAN must also be available before affected workloads are allowed to run on those hosts.

Distributed Packet Flow

For traffic between VPC subnets, routing occurs through the distributed VPC Gateway and remains in the overlay.

For traffic leaving the VPC, the Transit Gateway on the local ESXi host forwards the packet toward the external VLAN.

A private workload can receive an external IP that maps the internal workload address to an address from the externally reachable pool. The physical gateway then forwards return traffic across the shared VLAN toward the ESXi host currently representing that external address.

A public subnet can use address space intended to be reachable from the physical network without requiring the same one-to-one external IP workflow for every workload.

The exact address model must be designed before deployment. External IP blocks, public subnet ranges, private VPC ranges, Transit Gateway ranges, and existing physical subnets must not overlap.

Performance Characteristics

The principal performance benefit of the distributed model is path locality.

Traffic can leave from the ESXi host where the workload is running. It does not first need to cross the overlay to an Edge service router.

Depending on the environment, this can:

• Remove an Edge forwarding hop
• Reduce traffic hairpinning
• Distribute north-south forwarding across workload hosts
• Align capacity more directly with host uplink capacity
• Avoid concentrating all external traffic on a small Edge cluster

These are architectural advantages, not guaranteed benchmark results.

Performance can still be constrained by:

• ESXi physical NIC throughput
• Host uplink teaming
• Switch-port oversubscription
• The external VLAN
• Physical gateway throughput
• MAC and ARP table capacity
• Workload packet size and packet rate
• VNA service capacity
• Security and load-balancing services enabled on the path

A distributed design should be tested using the complete production service chain. Testing only basic routing does not prove the performance of a design that will also use NAT, load balancing, firewall enforcement, or other stateful services.

Scale Boundaries

The distributed model spreads forwarding across hosts, but it also expands the Layer 2 operational boundary.

As more hosts, clusters, and racks participate, the environment must maintain:

• Consistent VLAN trunking
• Predictable first-hop gateway behavior
• Adequate physical uplink capacity
• Fast convergence after workload mobility
• Accurate address ownership
• Correct filtering and security policy
• Consistent monitoring across virtual and physical layers

The design becomes less attractive when a VLAN must be stretched across a large failure domain solely to avoid deploying Edge nodes.

The question is not whether the VLAN can technically reach every host. The question is whether the organization wants that Layer 2 dependency to become part of the private-cloud service boundary.

Workload Mobility

Workload mobility changes which ESXi host must receive traffic for the external address.

The physical switching environment must update its forwarding information quickly enough to follow the workload. The design should validate:

• vMotion between hosts in the same rack
• vMotion between racks
• MAC-table convergence
• ARP and neighbor updates
• Physical gateway behavior
• Security controls tied to ports or MAC addresses
• Return-path behavior during convergence
• Recovery after host or uplink failure

A successful ping after migration is not sufficient. The test should measure packet loss, convergence time, session behavior, and application recovery.

Existing VLAN Connectivity

Distributed connectivity is a strong fit when VPC workloads need direct access to systems already attached to an existing data center VLAN.

Examples include:

• Physical database servers
• Storage systems
• Network appliances
• Legacy virtual machines
• Backup targets
• Monitoring systems
• Application dependencies that cannot be moved into an overlay network

The VPC can retain isolated overlay subnets internally while using the distributed Transit Gateway to reach the established physical network.

However, a routed connection to an existing VLAN is not the same as extending that VLAN into the VPC. The application requirement must distinguish between:

• Layer 3 reachability
• Layer 2 adjacency
• Preserved workload IP addresses
• Broadcast or multicast dependency
• A temporary migration requirement
• A permanent operating model

Using a broad Layer 2 domain to solve an application discovery or migration problem can create a long-term network liability.

Centralized Transit Gateway Design

The centralized design retains the NSX Edge and Tier-0 architecture for external connectivity.

Traffic leaving a VPC is sent through a centralized service-router path on the Edge cluster. The Tier-0 gateway then connects to the physical routers through BGP or static routes.

Edge and Routing Requirements

A production centralized design normally requires:

• At least two NSX Edge nodes
• An NSX Edge cluster
• Tier-0 service routers
• Redundant Edge uplinks
• Physical-router connectivity
• BGP or static routing
• MTU alignment
• Edge placement and anti-affinity
• Reserved compute capacity
• Tested failure headroom

The Edge cluster becomes a shared platform service. It should not be treated as a group of ordinary infrastructure virtual machines.

The architecture must account for:

• Edge node form factor
• CPU and memory reservations
• Physical NIC and uplink capacity
• Fast-path interface placement
• NUMA and host-placement considerations
• Edge failure capacity
• Maintenance capacity
• BGP and BFD timer behavior
• Route filtering and summarization
• Stateful-service placement

Centralized Packet Flow

The centralized packet path introduces a deliberate service boundary.

This additional path can be valuable when the organization needs a consistent point for:

• Dynamic routing
• VPN termination
• Centralized NAT
• Gateway security services
• Prefix filtering
• Multi-site routing
• Partner connectivity
• Internet connectivity
• Shared north-south observability

The Edge tier becomes both a service location and an operational boundary.

Physical-Network Flexibility

The centralized design does not require the same external VLAN to reach every compute host.

The workload overlay can span the compute environment while the Edge cluster provides the handoff to the physical fabric. The Edge nodes can connect to dedicated uplink VLANs and peer with physical routers.

This makes centralized connectivity a stronger fit for:

• Routed leaf-spine fabrics
• Environments that limit Layer 2 domains
• Multi-rack or multi-zone deployments
• Networks with formal routing policy
• Data centers using dedicated border or services layers
• Designs where network teams must control advertised prefixes
• Environments requiring separate internet, partner, or shared-services routes

Centralized Performance and Scale

Centralized does not mean that all traffic must depend on a single Edge node.

Tier-0 gateways can use active-active service-router designs across multiple Edge nodes. VCF 9.1 supports scale-out active-active Tier-0 configurations across as many as eight Edge nodes for applicable designs.

The practical throughput still depends on:

• Edge node size
• Number of active service routers
• Physical placement
• Edge host uplinks
• Tier-0 uplink design
• ECMP path availability
• Enabled stateful services
• Packet size and packet rate
• Failure and maintenance headroom

The advantage of centralized capacity is that it can be modeled as a distinct platform tier.

The platform team can monitor:

• Throughput per Edge node
• Uplink utilization
• Packet drops
• CPU and memory pressure
• Service-router placement
• BGP state
• Route count
• Connection-table utilization
• Failover capacity

The disadvantage is concentration. An undersized Edge cluster can become a bottleneck for multiple VPCs, projects, and business services simultaneously.

Existing VLAN and Routed Network Connectivity

Centralized connectivity is usually a better fit when existing VLAN networks remain behind physical routers.

The Tier-0 advertises or learns the required prefixes, while the physical routers continue to provide reachability toward the existing VLANs. The VLANs do not need to be stretched to every VCF compute host.

This preserves a familiar responsibility model:

• The physical network team owns routing outside VCF.
• The VCF networking team owns the Edge cluster and Tier-0.
• Project administrators consume approved Transit Gateway connectivity.
• VPC administrators create subnets and attach workloads.
• Application teams consume networking without managing BGP.

The model requires coordination around route ownership, route filtering, NAT, failure behavior, change control, and incident escalation.

What VCF 9.1 Changes

VCF 9.1 reduces some of the historical feature differences between the two designs, but it does not make them architecturally equivalent.

The practical outcome is that an enterprise does not need to select one connectivity model for every workload.

Distributed and centralized designs can coexist when each is attached to a clearly defined use case, support boundary, and ownership model.

Operational Ownership Is Part of the Architecture

The Transit Gateway design changes which teams must respond when a packet stops moving.

Distributed connectivity does not eliminate network operations. It shifts more responsibility toward host networking, VLAN consistency, physical gateway behavior, and virtual-to-physical convergence.

Centralized connectivity creates a more explicit NSX service boundary, but it also introduces Edge capacity, Tier-0 routing, and BGP operations.

The design should identify an accountable owner for every row before implementation begins.

A Practical Decision Framework

Start with the physical topology, then evaluate services, traffic behavior, and operational ownership.

Choose Distributed Connectivity When

Distributed connectivity is a strong candidate when:

• Every eligible host intentionally reaches the same external VLAN.
• Direct host-to-fabric forwarding provides measurable value.
• The physical gateway can support the expected scale.
• The Layer 2 failure domain is acceptable.
• VPN is not required on the path.
• Dynamic routing through Tier-0 is unnecessary.
• The organization can operate host networking and physical-fabric dependencies as one service.
• Required VNA services have been sized and validated.
• Workload mobility has been tested across the complete placement scope.

Choose Centralized Connectivity When

Centralized connectivity is the stronger candidate when:

• The physical fabric is routed.
• The same external VLAN should not span every compute host.
• The design requires BGP or controlled static routing.
• VPN services are required.
• Multiple external paths or remote network policies are required.
• Centralized service insertion is operationally important.
• The organization needs an explicit boundary between tenant networking and physical routing.
• Edge capacity can be sized, monitored, and protected with failure headroom.
• Multi-site, partner, internet, or regulated-zone connectivity is required.

Use Both Patterns When

Large environments should not force every workload into one connectivity model.

A practical service catalog can include:

Distributed brownfield pattern

Use for workload domains that must reach an established VLAN and can meet the shared Layer 2 requirement.

Distributed high-throughput pattern

Use for workloads that benefit from direct host-to-fabric forwarding and do not require centralized VPN or Tier-0 routing.

Centralized enterprise pattern

Use for general-purpose application connectivity through a routed data center fabric.

Centralized VPN pattern

Use for encrypted site, tenant, partner, or external connectivity.

Centralized multi-path pattern

Use when different destination prefixes must use different provider-defined external connections.

Each pattern should define prerequisites, address ownership, service limits, monitoring, escalation paths, and exception criteria.

Design and Validation Sequence

A Transit Gateway design should be validated with a production-representative pilot before it is exposed as a self-service service.

Map the Physical Topology

Document:

• Eligible ESXi clusters and hosts
• Host uplinks and physical NICs
• VLAN reachability
• Layer 2 and Layer 3 boundaries
• Physical gateways
• Edge uplinks
• MTU
• Oversubscription points
• Rack and switch failure domains
• Routing and first-hop redundancy

For distributed connectivity, verify the external VLAN on every eligible host.

For centralized connectivity, verify redundant Edge uplinks and routing paths.

Build the Address and Route Model

Create one authoritative register for:

• VPC private address blocks
• External IP blocks
• Public subnet ranges
• Transit Gateway address blocks
• NAT pools
• Existing data center prefixes
• Remote Networks
• Default routes
• Route summaries
• Route exclusions
• Advertised and non-advertised networks

Overlapping addresses or unclear prefix ownership should stop the design review.

Validate Representative Traffic Flows

Test:

• Subnet-to-subnet traffic inside a VPC
• VPC-to-VPC traffic through a Transit Gateway
• VPC-to-existing-VLAN traffic
• Existing-VLAN-to-VPC traffic
• Access through an external IP
• Access from a public subnet
• Shared-services connectivity
• Internet or partner connectivity
• Traffic after vMotion
• Traffic after host failure
• Traffic after Edge failure
• Traffic after uplink failure
• Traffic after physical-router failure

Validate the Complete Service Chain

Do not validate routing in isolation when production will also use:

• NAT
• Load balancing
• Distributed firewalling
• Gateway firewalling
• VPN
• VNA services
• Route filtering
• Multiple external connections

Measure:

• Throughput
• Packet rate
• Latency
• Connection count
• Packet loss
• Failover time
• Session recovery
• Resource utilization
• Application recovery time

Validate Operations

Run failure exercises with the teams that will support the platform.

Success is not simply that a ping returns.

Success means the expected packet path, services, telemetry, failure response, and ownership model are all visible and repeatable.

Common Architecture Mistakes

Choosing Distributed Only to Avoid Edge Nodes

Avoiding Edge deployment can reduce virtual-appliance overhead. It can also transfer complexity into the physical Layer 2 fabric.

If the external VLAN must be stretched across racks, clusters, or sites only to support the distributed design, the organization may be creating a larger failure domain than the Edge tier would have introduced.

Treating Centralized Connectivity as Automatically Slow

Centralized traffic follows an additional service path, but that does not prove that the design will be slow.

A properly sized active-active Edge cluster can provide substantial throughput while preserving dynamic routing and service flexibility. Compare measured production paths rather than relying on topology diagrams alone.

Ignoring the VNA Dependency

VCF 9.1 makes distributed connectivity more capable through Virtual Network Appliance services.

A distributed design using those services should not be described as appliance-free. It removes NSX Edge nodes and the Tier-0 gateway from the external forwarding path, but VNA health and capacity still matter.

Mixing Address Ownership

External IP blocks, existing VLAN ranges, public subnets, VPC private ranges, NAT pools, and Transit Gateway address blocks must have named owners.

Address overlap can create failures where both the VPC configuration and physical network appear individually correct.

Skipping Mobility Testing

Distributed connectivity depends on the physical network following workload mobility.

Centralized connectivity depends on overlay reachability and Edge service availability.

Both paths must be tested during movement and failure, not only in steady state.

Hiding Infrastructure Complexity from the Provider Team

Tenant administrators should not need to configure physical VLANs, Edge uplinks, BGP peers, or routing policy.

The provider team still needs complete visibility into those dependencies. Abstraction should simplify tenant consumption without hiding infrastructure risk from platform operators.

Recommended Default Positions

For a compact single-site environment with a controlled VLAN available on every eligible host, simple external routing, and a strong reason to minimize Edge infrastructure, begin the design review with distributed connectivity.

For a large enterprise data center with routed fabrics, multiple network zones, dynamic routing, VPN, shared north-south services, or formal network-team control, begin with centralized connectivity.

For a mixed estate, define both as approved provider patterns.

Use distributed connectivity where direct host-to-fabric forwarding and existing VLAN integration provide clear value.

Use centralized connectivity where routing control, service flexibility, multi-site reachability, and explicit operational boundaries matter more than removing an Edge hop.

The default should follow the operating model and physical topology, not a preference for one product construct.

Conclusion

VCF 9.1 gives architects a meaningful choice in where VPC external connectivity is implemented.

A Distributed Transit Gateway moves the external forwarding boundary onto the ESXi hosts. It can reduce forwarding hops and simplify integration with suitable VLAN environments, but it depends on consistent Layer 2 reachability, physical gateway behavior, host uplink capacity, address discipline, workload mobility convergence, and VNA capacity when stateful services are used.

A Centralized Transit Gateway preserves the NSX Edge and Tier-0 service tier. It requires more infrastructure and routing coordination, but it supports Layer 2 or Layer 3 fabrics, dynamic routing, VPN, centralized services, multiple external paths, and a clear provider-controlled network boundary.

Neither design is universally simpler.

The stronger architecture is the one that makes four things obvious:

• The packet path
• The capacity bottleneck
• The failure domain
• The operational owner

When those answers are clear, the Transit Gateway becomes a repeatable private-cloud service. When they are unclear, self-service networking only makes an unresolved infrastructure problem easier to consume.

External References

• VMware Cloud Foundation Blog: VCF 9.1 Networking: Exploring Network Services for Virtual Private Clouds
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/15/vcf-networking-9-1-exploring-network-services-for-virtual-private-clouds/
• VMware Cloud Foundation Blog: Transit Gateway Connectivity Options in VCF 9.1
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/12/transit-gateway-connectivity-options-in-vcf-9-1/
• VMware Cloud Foundation Blog: Simplify Workload Connectivity and Enhance Network Scale and Performance with VCF 9.1
  Canonical URL: https://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: VPC Distributed Network Connectivity – No NSX Edge VMs
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2025/06/25/vpc-distributed-network-connectivity-no-nsx-edge-vms/
• VMware Cloud Foundation Blog: VPC Centralized Network Connectivity – With Guided Edge Deployment
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2025/06/25/vpc-centralized-network-connectivity-with-guided-edge-deployment/
• VMware Cloud Foundation Blog: Self-service Networking with Virtual Private Clouds
  Canonical URL: https://blogs.vmware.com/cloud-foundation/2025/06/25/self-service-networking-with-virtual-private-clouds/

The post VCF 9.1 VPC Networking: Distributed vs. Centralized Transit Gateway Designs appeared first on Digital Thought Disruption.