VCF Automation 9.1 can provide several external connections through one Transit Gateway (TGW), but it can also provide several TGWs to the same organization. The two options serve different purposes.

Multiple external connections give one TGW more ways to reach networks outside the Virtual Private Cloud (VPC) environment. Multiple TGWs separate groups of VPCs and let each group use its own connectivity design. That difference affects how VPCs are grouped, how their external connectivity is arranged and how much of the network is shared.

One TGW with multiple external connections

A VPC connects to one TGW. Several VPCs can use that same TGW, and the TGW can have more than one external connection. The VPCs remain connected through the same TGW, while the external connections serve different destinations.

I use this when the VPCs belong together and should use the same TGW, but need more than one external path. Adding a second connection does not create another separation point between those VPCs. It adds another path to the existing design.

For example, one connection could provide access to an internal services network while another provides Internet egress. Remote Networks and the resulting routing determine which destinations use each connection. The TGW remains the common point for the attached VPCs.

The external connection model is chosen per organization. An organization uses either centralized or distributed external connections, so its TGWs do not mix the two connection types.

The forwarding table of the transit-gateway-default Distributed Router (DR) shows how the two external connections are reflected in the dataplane. The default route and the more specific 100.64.10.0/24 route use different next hops towards their respective upstream Tier-0 VRFs:

Multiple TGWs for different groups of VPCs

I use multiple TGWs when groups of VPCs need different connectivity. Each VPC still connects to one TGW at a time, but different VPCs can use different TGWs. The organization can therefore make several TGWs available without connecting every VPC to all of them.

One TGW could serve production VPCs while another serves a lab or development environment. Separate TGWs can also be useful when VPC groups need different external connectivity, need to span different parts of the infrastructure, or require different network services.

This gives the VPC groups a clearer separation than connecting them all to a single TGW. The trade-off is more TGW objects to configure and operate. That is only useful if the VPC groups actually need to be connected and operated independently.

Separate TGWs do not necessarily mean separate infrastructure. If two TGWs use the same Edge cluster, Tier-0 gateway, uplinks or physical network, they still share those dependencies. The separation exists at the VPC and TGW layer, but its practical value depends on what sits underneath it.

How I choose between the two

I start with the VPC grouping. If the VPCs are intended to share the same TGW and only need another external destination or path, I use one TGW with multiple same-type connections. The additional connection might, for example, provide internal connectivity or Internet egress.

If the VPCs need different connectivity, reachability, services or placement, I use separate TGWs. That makes the separation visible in the topology instead of hiding it behind additional connections on a shared TGW.

The one-TGW-per-VPC rule matters here. Providing several TGWs to an organization does not make a VPC connected to all of them. Its VPC Connectivity Profile selects the TGW it uses. Moving that VPC to another TGW is a network change that can affect routing, addressing and services; it is not just an inventory update.

You can also combine the two. An organization can have several TGWs, while an individual TGW can have several external connections. This is useful when separate VPC groups each require more than one external path. That also means more TGWs and connections to manage.

Closing thoughts

For me, the deciding factor is not the number of objects. It is whether the VPCs should share the same connectivity design.

Multiple external connections add paths to one TGW. The attached VPCs still share that TGW, and the connections follow the centralized or distributed connection model selected for the organization. Multiple TGWs separate groups of VPCs and allow those groups to use different connectivity designs, although they may still share infrastructure underneath.

I prefer the smallest setup that makes the intended connectivity clear. If one TGW can serve the VPC group and the only requirement is another external path, I add the connection there. If a group of VPCs needs its own connectivity design, network span or TGW services, I give it a separate TGW.