NSX Public Cloud Gateway: Architecture and Modes of Deployment

The NSX Public Cloud Gateway (PCG) provides north-south connectivity between the public cloud and the on-prem management components of NSX.

Familiarize yourself with the following terminology explaining the PCG's architecture and deployment modes for workload VM-management.

Note: The PCG is deployed in a single default size for each supported public cloud:

Public Cloud	PCG instance type
AWS	c5.xlarge. Some regions might not support this instance type. Refer to AWS documentation for details. Note: If you see high CPU usage alerts with this instance type, resize PCG instances to c5.2xlarge. If you have a high availability pair of PCG instances, resize the standby PCG first by stopping, resizing and restarting it. Stop the currently active PCG next and wait until the standby PCG becomes active. Resize and restart this PCG and it should become active. See AWS documentation for details on resizing instance types.
Microsoft Azure	Standard DS3 v.2

Public Cloud

PCG instance type

AWS

c5.xlarge.

Some regions might not support this instance type. Refer to AWS documentation for details.

Note: If you see high CPU usage alerts with this instance type, resize PCG instances to c5.2xlarge.

If you have a high availability pair of PCG instances, resize the standby PCG first by stopping, resizing and restarting it. Stop the currently active PCG next and wait until the standby PCG becomes active. Resize and restart this PCG and it should become active.

See AWS documentation for details on resizing instance types.

Microsoft Azure

Standard DS3 v.2

Architecture

The PCG can either be a standalone gateway appliance or shared between your public cloud VPCs or VNets to achieve a hub and spoke topology.

Modes of Deployment

Self-managed VPC/VNet: When you deploy the PCG in a VPC or VNet, it qualifies the VPC or VNet as self-managed, that is, you can bring VMs hosted in this VPC or VNet under NSX management.

Transit VPC/VNet: A self-managed VPC/VNet becomes a Transit VPC/VNet when you link Compute VPCs/VNets to it.

Compute VPC/VNet: VPCs/VNets that do not have the PCG deployed on them but link to a Transit VPC/VNet are called Compute VPCs/VNets.

AWS Transit Gateway with PCG: Starting in NSX 3.1.1, you can use AWS Transit Gateway to connect a Transit VPC with Compute VPCs. See Using PCG with AWS Transit Gateway for details.

Subnets Required in Your VPC/VNet to deploy PCG

The PCG uses the following subnets that you set up in your VPC/VNet. See Connect Microsoft Azure with On-prem NSX or Connect AWS with On-prem NSX.

Management subnet: This subnet is used for management traffic between on-prem NSX and PCG. Example range: /28.
Uplink subnet: This subnet is used for north-south internet traffic. Example range: /24.
Downlink subnet: This subnet encompasses the workload VM's IP address range. Size this subnet bearing in mind that you might need additional interfaces on the workload VMs for debugging.

PCG deployment aligns with your network addressing plan with FQDNs for the NSX components and a DNS server that can resolve these FQDNs.

Note: It is not recommended to use IP addresses for connecting the public cloud with NSX using PCG, but if you do, you must not change your IP addresses.

Impact of on-prem and public cloud connectivity mode on PCG's discovery of CSM

After PCG is deployed in your public cloud, it must interact with CSM as the management interface for your public cloud inventory. To ensure that PCG can reach the IP address of CSM, follow these guidelines:

For PCG deployed in Private IP mode (VGW): PCG discovers CSM with either the actual CSM IP address or with one of the IP addresses in the subnet range provided.

Figure 1. NSX Public Cloud Gateway Architecture with VGW Connectivity
For PCG deployed in Public IP mode (IGW): PCG can discover CSM using CSM's NAT-translated IP address that allows access to the real IP address or subnet range for CSM.

Figure 2. NSX Public Cloud Gateway Architecture with IGW Connectivity

Modes of VM-management

NSX Enforced Mode: In this mode, workload VMs are brought under NSX management by installing NSX Tools on each workload VM to which you apply the tag nsx.network=default in your public cloud.

Native Cloud Enforced Mode: In this mode, your workload VMs can be brought under NSX management without the use of NSX Tools.

Quarantine Policy

Quarantine Policy: NSX Cloud's threat detection feature that works with your public cloud security groups.

In the NSX Enforced Mode, you can enable or disable Quarantine Policy. As a best practice, disable Quarantine Policy and add all your VMs to the User Managed list when onboarding workload VMs.
In the Native Cloud Enforced Mode Quarantine Policy is always enabled and cannot be disabled.

Design Options

Regardless of the mode you deploy the PCG in, you can link a Compute VPC/VNet to it in either mode.

Table 1. Design Options with PCG Deployment Modes
PCG Deployment Mode in Transit VPC/VNet	Supported Modes when linking Compute VPCs/VNets to this Transit VPC/VNet
NSX Enforced Mode	NSX Enforced Mode Native Cloud Enforced Mode
Native Cloud Enforced Mode	NSX Enforced Mode Native Cloud Enforced Mode

Note:

Once a mode is selected for a Transit or Compute VPC/VNet, you cannot change the mode. If you want to switch modes, you must undeploy the PCG and redeploy it in the desired mode.