The NSX Public Cloud Gateway (PCG) provides north-south connectivity between the public cloud and the on-prem management components of NSX-T Data Center.
|Public Cloud||PCG instance type|
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|
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-T Data Center 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
- Management subnet: This subnet is used for management traffic between on-prem NSX-T Data Center 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-T Data Center components and a DNS server that can resolve these FQDNs.
Impact of on-prem and public cloud connectivity mode on PCG's discovery of CSM
- 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.
- 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.
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.
- 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.
Regardless of the mode you deploy the PCG in, you can link a Compute VPC/VNet to it in either mode.
|PCG Deployment Mode in Transit VPC/VNet||Supported Modes when linking Compute VPCs/VNets to this Transit VPC/VNet|
|NSX Enforced Mode||
|Native Cloud Enforced Mode||
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.