Hello Cloud gurus. In today’s lesson, we’re gonna talk about one of GCPS network services, CLOUD NAT. Cloud NAT let’s you compute VM instances, and GKE container pods communicate with the internet using a shared public IP address. Cloud NAT offers several benefits over-provisioning VM or GKE nodes with public IP addresses. One is security. These servers can still access the internet for updates, patches, and some cases bootstrapping. The IP addresses for Cloud NAT can be whitelisted on your internet servers, allowing only connections to specific servers. Cloud NAT works as a managed service that provides high availability without an interaction or intervention. This is handled for both automatically allocated and manually allocated IP addresses. Cloud NAT is highly scalable. The network bandwidth available for each instance is not affected by the number of instances that use the Cloud NAT gateway. All instances have available bandwidth similar to instances with an external IP address.
Cloud NAT is a distributed, fully manage software-defined service, not an instance or application-based solution. Let’s talk about the Cloud NAT setup. We need a project, a VPC network. Cloud NAT is specific to one region, and only instances in that region can use a Cloud NAT. GCP requires a Cloud router be set up in the same region to support Cloud NAT configuration. Then we’ll need to select the subnet either all primary & secondary subnets, primary only, or selected subnets that limit Cloud NAT services to specific subnets in the VPC instance. Cloud NAT uses NAT gateway to manage those connections. A NAT gateway is region and VPC network specific. If you have VM instances in multiple regions, you will need to create a NAT gateway for each region. Let’s walk through a quick demo of what setting up a Cloud NAT looks like in GCP. We can click, Getting started, for our gateway name to set up Cloud NAT we’ll type VPC-demo1-cloudnat in UScentral1region.
We’ll select the demo1-network, we’ll select the US1-central region. For Cloud Router, we don’t have a Cloud Router created, so let’s set up a new one, and we’ll call that vpc-demo-1-router for nat. That way, we know what it is, the network and the region are already selected, and we can click Create. Scrolling down, here’s where we can choose our IP addresses for primary & secondary, primary only, or custom ranges. And we’ll choose all subnets. Next, we can choose the external net IP addresses that are used or shared by our VM instances. We can choose automatic or manual. If we choose manual, we can reserve multiple instances for our Cloud NAT to use. All right, we’re back at our diagram, and we’ve made it to the final column. The NAT IP addresses. We learned that we can allow GCP to automatically allocate external IPs to the NAT gateway as resources require them, allowing it to scale. Optionally, we can choose to manually manage and allocate external IPs. This is where the network admin reserves external IPs and must manage the number of connections using those IPs. Switching up the diagram, Cloud NAT implements an outbound NAT solution. It works with our default route to allow our instances to reach the internet. It does not implement inbound NAT, which means connections from the internet cannot reach internal instances. It does allow hosts outside of the VPC network to respond, to establish connections initiated by our instances. On our board, we draw it out for our project with one VPC, VPC-1. In the US-central region, we have one subnet called subnet-A, with a primary & secondary IP range assigned to a single VM instance called VM1. When Cloud NAT is enabled for the subnet allows our instance to use Cloud NATS external IP via the default route to connect to an update server on the internet.
If we create a new VM called VM2 on the same primary subnet, however, for VM2, we assign an external IP address. VM2 does not need to use the Cloud NAT services, even though it’s enabled for its primary subnet. VM2 sends traffic via the default route to access the internet directly. Let’s walk through this on a little bit different view. First, we have our internal instance with a 10.240.0.3 internal IP address. And it wants to send a packet to an update server on the internet. From the instance, the source IP and source port are recorded as is the destination IP of the update server and the destination port. Using NAT gateway, the source IP and source port are replaced with the Cloud NAT external IP address and an assign NAT port. For our instance, the destination IP and port remained the same. Winter update server replies the information is switched. The update server now becomes the source, and the destination is our Cloud NAT IP and port. GCP routes that request back to the original destination IP and port. Woo, that was a lot.
Now that we understand how that works let’s take a look at the bottom section of the Cloud NAT setup. We can enable logging for our instances. Logging facilitates troubleshooting for outgoing connections from our instances. We can select timeout for Nat connections for each of the different protocols that are allowed to use Cloud NAT. But the part that we wanna focus on is the minimum ports per VM is how many ports are allocated per VM instance. Unlike NAT proxy solutions, there are no NAT proxy instances in the path from RVM instance to the destination. Instead, each instance is allocated a globally unique set of net IPs and associated port ranges.
Each external IP supports up to 64,000 ports for each VM instance, located on the subnet where Cloud NAT is operating. Cloud NAT reviews its pool of external IPs, selects and assigned an IP address, and a range of ports to each VM instance. In our example, VM1 is assigned the only available IP address and 64 ports from 32,000 to 32063 to use for external communications. We can change the number of ports assigned to a VM instance and increase the number of connections available for outgoing requests. The Cloud NAT configuration is software-defined and pushed down to the host. Once this takes place, the host contains their configuration. It is available regardless of the NAT gateway state or status. As network specialists, we may have applications that run in containers that have short lifespans and are gonna initiate multiple connections to
Our BM1 instance needs more ports assigned to support the container workloads running on that instance. If we increase the number of ports from 64 to 1024, the number of VMs that we can support reduces from 1000 to approximately 64, because of the consumption rate of the IP port combinations allocated per VM. Keep this in mind when using NAT gateways so that you assign the correct amount of external IPS if you selected to assign them manually. CLOUD NAT also supports private GKE clusters, allowing private nodes, the ability to use Cloud NAT services while also supporting secondary ranges for the containers that run on those nodes. However, the external IP and port combination is only assigned per VM instance and must accommodate all containers or ports running on that instance. Ensure you assign enough ports to meet the business needs and ensure there is enough connection to support scalability in the future.
Let’s review the benefits of cloud NAT one more time. Security, we can provision instances without public IP addresses. We can still update and patch those instances using Cloud NAT. Cloud NATS high availability feature by pushing configuration to the instance. The instance always has the configuration available regardless of the state of Cloud NAT. And it’s fully scalable. All instances that use Cloud NAT have bandwidth similar to instances that have an external IP address. Thanks, and keep being awesome Cloud gurus.