A Deep Dive into Virtual Private Cloud’s Subnet Access Modes

When designing your private cloud environment, one of the most fundamental decisions revolves around network architecture. A well-designed network provides not only connectivity but also inherent security and segmentation. With VMware’s Virtual Private Cloud (VPC), administrators are given powerful tools to build multi-tenant environments, and at the heart of this capability lies the VPC Subnet.

A subnet’s Access Mode, defined at its creation, dictates its connectivity scope and routing behavior. This feature provides powerful, built-in network segmentation, establishing isolation without needing complex firewall policies or additional licensing for distributed firewalling.

Let’s explore the three available access modes — Private-VPC, Private-Transit-Gateway, and Public — to understand how you can build a secure and efficient network from the ground up.

1. Private-VPC

The Private-VPC access mode is the most restrictive and isolated option, designed for workloads that should not be directly accessible from outside their local VPC environment.

• Scope: The networking scope is strictly limited to the VPC in which the subnet resides.
• Connectivity: Virtual machines (VMs) on a Private-VPC subnet can communicate freely with other VMs on any other subnet within the same VPC.
• IP Source: IP addresses for these subnets are assigned from the Private-VPC IP CIDRs defined specifically for each VPC, which allows for overlapping IP address spaces between different VPCs.
• Routing: The key to this isolation lies in route advertisement. The IP ranges of Private-VPC subnets are never advertised beyond the VPC’s own internal gateway. They remain completely hidden from the Transit Gateway and the broader datacenter network, creating a secure “island” for your application tiers.
• Use Case: This mode is ideal for the backend tiers of a standard three-tier application, such as database and application servers, which should only be accessed by the web servers within the same VPC.

2. Private-Transit-Gateway (TGW)

The Private-TGW access mode enables communication for workloads both within their own VPC and between other VPCs that are connected to the same Transit Gateway.

• Scope: Connectivity is limited to all the VPCs attached to the same Transit Gateway (TGW), typically within the same NSX Project.
• Connectivity: Allows workloads to communicate with other resources within their own VPC and with workloads on Private-TGW or Public subnets in other VPCs connected to the same TGW.
• IP Source: IPs are sourced from the project-level Private-Transit Gateway IP Blocks. This is a shared pool of non-overlapping IP ranges used by all VPCs connected to that TGW.
• Routing: The routes for Private-TGW subnets are advertised to the Transit Gateway, which acts as a central routing hub. These routes are not advertised further, keeping the traffic contained within the group of connected VPCs. This architecture is common for a shared services model.
• Use Case: Excellent for a dedicated “Shared Services VPC” that hosts common resources like Active Directory, DNS servers, or CI/CD tools. Other “Application VPCs” can then access these services across the TGW.

3. Public

The Public access mode is designed for workloads that require direct connectivity from other networks within the datacenter. In the context of a VPC, the term “Public” does not necessarily mean “Internet-facing.” Instead, think of it as being public to your internal datacenter network.

• Scope: Accessible from within the VPC and from outside the VPC across the wider datacenter or from specific VLANs.
• Connectivity: Provides direct, non-NAT’d connectivity from other parts of your organization’s network. Private RFC 1918 IP addresses (like 10.0.0.0/8) are typically used.
• IP Source: IP addresses are assigned from the project’s External IP Blocks, which are unique, routable IP ranges within your datacenter.
• Routing: The CIDRs of Public subnets are advertised from the VPC Gateway up to the NSX T0 Gateway or directly to the physical network fabric via VLANs. This makes the subnet directly accessible from other networks, even those in different transit gateways.
• Use Case: Perfect for hosting bastion hosts, jump boxes, or front-end web servers that need to be directly reached from the corporate network for management or user access.

A Note on NAT: Providing External Access to Private Subnets

While Private-VPC and Private-TGW subnets are designed for isolation, they are not entirely cut off from the outside world. VMware’s VPC provides powerful Network Address Translation (NAT) options to grant these private subnets controlled access when required.

These options are available for both Private-VPC and Private-TGW subnets and allow you to:

• Access external resources using auto-outbound NAT, which lets VMs on a private subnet initiate connections to other external networks.
• Receive inbound connections through carefully configured External IPs or a dedicated 1:1 NAT mapping. This allows you to selectively expose specific services (like a web server API) to external users without placing the VM on a public subnet.

This flexibility means you can maintain a secure-by-default posture, keeping workloads isolated while still enabling necessary communication patterns.

The Proof is in the Routing Table

This network-level isolation isn’t just theoretical. We can see it clearly by examining the forwarding tables of the VPC’s gateway and the Transit Gateway.

 In the screenshot above, we have two routing tables (below is the same forwarding table in text):

The top table is from the Transit Gateway. Look closely:

• The route for the Public subnet (30.30.0.64/26) is present.
• The route for the Private-TGW subnet (10.150.0.0/26) is present.
• The route for the Private-VPC subnet (10.151.0.0/28) is conspicuously absent.

The bottom table is from the VPC Gateway. Notice it has routes for all its connected subnets, including the Private-VPC subnet (10.151.0.0/28), the Private-TGW subnet (10.150.0.0/26), and the Public subnet (30.30.0.64/26).

This demonstrates the core principle: the Transit Gateway is completely unaware of the Private-VPC subnet, enforcing isolation at the routing level.

Summary

Access Mode	IP Source	Route Advertisement	Best For…
Private-VPC	Private VPC CIDRs	Not advertised outside the VPC	Secure application backends, databases and Cookie cutter deployment reusing same IPs – like Labs
Private-TGW	Private TGW IP Blocks	Advertised only to the Transit Gateway	Shared services (DNS, AD, etc.). When required communication between applications in different VPCs
Public	External IP Blocks	Advertised to Outside from the Transit Gateway	Jump boxes, front-ends needing direct corporate access. Environments without NAT

By understanding and utilizing these three distinct access modes, network and cloud architects can design VPC environments that are not only functional but also inherently secure, scalable, and perfectly aligned with application requirements.

---

Related Posts:

Virtual Private Cloud in VMware Cloud Foundation 9.0
Why NSX for VMware Cloud Foundation
Virtual Private Clouds (VPCs) in vCenter
Self-service networking with Virtual Private Clouds
VPC Distributed Network Connectivity – No NSX Edge VMs
VPC Centralized Network Connectivity – With Guided Edge Deployment
Hands On Lab – What’s New in VMware Cloud Foundation 9.0

---