Cloud NAT: deep dive into our new network address translation service

Among all the network services that you rely on when running your applications, Network Address Translation (NAT) is key. It allows your applications to access the internet, while keeping your deployments private. A few days ago, we announced the beta of our fully managed Cloud NAT service at Google Cloud Next ‘18 in London. Today, let’s take a closer look at it.

The benefits of Cloud NAT

When you put an application behind a Cloud NAT gateway, it can access the internet—for updates, patching, config management, and more—in a controlled and efficient manner, but outside resources cannot directly access those instances. This helps keep your Google Cloud VPCs isolated and secure.

Cloud NAT offers a number of advantages when compared to other NAT offerings:

• As a software-defined solution with no managed middle proxy, Cloud NAT offers a chokepoint-free design that is highly reliable, performant and scalable.

• Cloud NAT supports both Google Compute Engine virtual machines (VMs) and Google Kubernetes Engine (containers).

• The ability to configure multiple NAT IP addresses per NAT gateway allows you to scale based on the size of your network without having to add or manage another NAT gateway.

• Manual and Auto  modes for  NAT IP allocation allow you to choose based on your specific requirements.Manual provides full control when specifying IPs, and Auto enables the NAT IPs to be allocated and scaled automatically based on the number of instances.

• Adjust timer values with configurable NAT timeout timers.

• NAT all subnets in a VPC for a region via a single NAT gateway,  irrespective of the number of instances in those subnets.

• Regional high availability even if a zone is unavailable.

Early adopters of Cloud NAT are successfully implementing the functionality within their existing Google Cloud deployments.

"I configured Cloud NAT to see how it would handle our existing Google Cloud deployment, and everything worked out of the box, and exactly as specified." said Wietse Muizelaar, Lead System Engineer, bol.com

Chokepoint-free, software-defined NAT

Cloud NAT is a fully managed, software-defined service, not an instance or appliance-based solution. This differs from traditional NAT proxy solutions because there are no NAT middle proxies in the path from the instance to the destination. Instead, each instance is allocated a NAT IP along with a slice of the associated port range. This allocated IP and port range is programmed by our Andromeda network virtualization stack into the instance and then used by the instance to perform NAT.

In effect, our Cloud NAT implementation, similar to our firewalls, is distributed without any choke points in the path between your internal instance and external destination. This approach delivers higher scalability, performance, throughput and availability for Cloud NAT.

NAT IP allocation modes

When we were designing Cloud NAT’s IP allocation model, our customers told us that being able to configure static, manually specified NAT IP(s) is essential, so that they can open firewalls for these NAT IPs on the external servers. At the same time, customers familiar with Google Cloud Load Balancing and other Google services told us they hoped they’d be able to autoscale Cloud NAT IPs like they do our load balancers.

That’s why we decided to offer two options for NAT IP allocation:

• Configure auto-allocation of IPs by a NAT gateway: GCP auto-allocates NAT IPs and autoscales them based on the number of VMs. This is the best way to ensure that enough IPs are available for NAT. Note that with this method, whitelisting IPs on the receiving side is more challenging because some IPs are released when they are no longer required.

• Configure specific NAT IP(s) to be used by a NAT gateway: In this case, you manually specify one or more NAT IPs to be used by the NAT gateway. These IPs must be reserved and static, and no auto-allocation of IPs is performed. This mode is preferred if you need to whitelist NAT IPs on the receiving side. Note that if there aren’t enough NAT IPs to perform NAT for all required instances, then some of these instances will not be able to use NAT. You will receive a log message when more NAT IPs are required.

Launching NAT gateway(s) in your VPC

Now you’re ready to set up a NAT gateway in your environment. Let’s take a look at an example.

Let’s say you have a GCP network containing three subnets in two regions:

• Us-east1

• subnet 1 (10.240.0.0/16) and subnet 2 (172.16.0.0/16)

• europe-west1

• subnet 3 (192.168.1.0/24)

The VMs in subnet 1 (10.240.0.0/16) and subnet 3 (192.168.1.0/24) do not have external IP addresses, but need to fetch periodic updates from an external server at 203.0.113.1. The VMs in subnet 2 (172.16.0.0/16) do not need to get these updates and should not be allowed to connect to the internet at all, even with NAT.

To achieve this setup, first configure one NAT gateway per region, per network:

1. Configure NAT-GW-US-EAST for subnet 1 (10.240.0.0/16).

2. Configure NAT-GW-EU for subnet 3 (192.168.1.0/24).

3. Configure each NAT gateway with the subnetwork(s) for which it should translate traffic:

• subnet 1 (10.240.0.0/16) for NAT-GW-US-EAST

• subnet 3 (192.168.1.0/24) for NAT-GW-EU

4. Do not configure NAT for subnet 2. This isolates it from the internet, as this example requires.

For detailed information about setting up Cloud NAT, you can view Cloud NAT configurations for Google Compute Engine and Google Kubernetes Engine here.

Cloud NAT for GKE

You can use Cloud NAT for Google Kubernetes Engine (GKE) containers by configuring Cloud NAT to NAT-translate all ranges in the subnet.

Both Nodes and Pods can use Cloud NAT. If you do not want Pods to be able to use NAT, you can create a Cluster Network Policy to prevent it.

In the example above, you want your containers to be NAT-translated. To enable NAT for all the containers and the GKE Node, you must choose all the IP ranges of subnet 1 as the NAT candidates. It is not possible to use NAT for only container1 or container2.

Pricing and availability

Cloud NAT is available in all Google Cloud regions, and during the beta period, we offer it free of charge. Once Cloud NAT becomes generally available (GA), each gateway is priced as follows:

• Starting at $0.045 per NAT gateway hour

• NAT data processing charges

In addition, outbound transfer costs to move data between a GCP instance and the internet remain unchanged. For more information, read about Cloud NAT pricing here.

Try Cloud NAT today

We’ve been busy delivering capabilities like Cloud NAT to make your Google Cloud workloads and services easy to deploy and manage. Visit the Cloud NAT online documentation and get started with a sample deployment using our Cloud NAT example. We’d also love your feedback—you can reach us at gcp-networking@google.com.