Simplifying cloud networking for enterprises: announcing Cloud NAT and more

At Google Cloud, our goal is to meet you where you are and enable you to build what’s next. Today, we’re excited to announce several additions to our Google Cloud Platform (GCP) networking portfolio delivering the critical capabilities you have been asking for to help manage, secure and modernize your deployments. Here, we provide a glimpse of all these new capabilities. Stay tuned for deep dives into each of these offerings over the coming weeks.

Cloud NAT^Beta

Just because an application is running in the cloud, doesn’t mean you want it to be accessible to the outside world. With the beta release of Cloud NAT, our new Google-managed Network Address Translation service, you can provision your application instances without public IP addresses while also allowing them to access the internet—for updates, patching, config management, and more—in a controlled and efficient manner. Outside resources cannot directly access any of the private instances behind the Cloud NAT gateway, thereby helping to keep your Google Cloud VPCs isolated and secure.

Prior to Cloud NAT, building out a highly available NAT solution in Google Cloud involved a fair bit of toil. As a fully managed offering, Cloud NAT simplifies that process and delivers several unique features:

• Chokepoint-free design with high reliability, performance and scale, thanks to being a software-defined solution with no managed middle proxy

• Support for both Google Compute Engine virtual machines (VMs) and Google Kubernetes Engine (containers)

• Support for configuring multiple NAT IP addresses per NAT gateway

• Two modes of NAT IP allocation: Manual where you have full control in specifying IPs, and Auto where NAT IPs are automatically allocated to scale based on the number of instances

• Configurable NAT timeout timers

• Ability to provide NAT for all subnets in a VPC region with a single NAT gateway, irrespective of the number of instances in those subnets

• Regional high availability so that even if a zone is unavailable, the NAT gateway itself continues to be available

You can learn more about Cloud NAT here.

Firewall Rules Logging^Beta

What good are rules if you don’t know if they are being followed? Firewall Rules Logging, currently in beta, allows you audit, verify, and analyze the effects of your firewall rules. For example, it provides visibility into potential connection attempts that are blocked by a given firewall rule. Logging is also useful to determine that there weren't any unauthorized connections allowed into an application.

Firewall log records of allowed or denied connections are reported every five seconds, providing near real-time visibility into your environment. You can also leverage the rich set of annotations as described here. As with our other networking features, you can choose to export these logs to Stackdriver Logging, Cloud Pub/Sub, or BigQuery.

Firewall Rules Logging comes on the heels of several new telemetry capabilities introduced recently including VPC Flow Logs and Internal Load Balancing Monitoring. Learn more about Firewall Rules Logging here.

Managed TLS Certificates for HTTPS load balancers^Beta

Google is a big believer in using TLS wherever possible. That’s why we encourage load balancing customers to deploy HTTPS load balancers. However, manually managing TLS certificates for these load balancers can be a lot of work. We’re excited to announce the beta release of managed TLS certificates for HTTPS load balancers. With Managed Certs, we take care of provisioning root-trusted TLS certificates for you and manage their lifecycle including renewals and revocation.

Currently in beta, you can read more about Managed Certs here. Support for SSL proxy load balancers is coming soon.

New load balancing features

We invest significant resources to ensure Google Cloud remains the best place to run containerized workloads. We are excited to introduce container-native load balancing for applications running on Google Kubernetes Engine (GKE) and self-managed Kubernetes in Google Cloud. With this capability, you can program load balancers with network endpoints representing the containers and specified as IP and port pair(s) using a Google abstraction we call Network Endpoint Groups (NEGs). With NEGs, the load balancer now load balances directly to the containers, rather than to VMs, thereby avoiding one or more extra hops.

In addition to container-native load balancing, we’ve also introduced over a dozen other load balancing and CDN capabilities in the past few months, including:

• Google managed and custom TLS policies in GA, enabling you to control TLS versions and ciphers for meeting PCI and other compliance requirements

• QUIC support for HTTP(S) load balancers in GA, enabling you to lower latency and improve performance for your load balancers

• HTTP/2 and gRPC from load balancer to application instances in beta. We’ve already been supporting HTTP/2 from the client to the load balancer for a while and with this feature, you can deploy HTTP/2 and gRPC from the load balancer to your backends for improved performance

• User-defined request headers in beta, where the HTTP(S) load balancer inserts information such as client location, and Round Trip Time (RTT) into HTTP(S) requests and sends it to your backend application instances

• Content-based health checks in beta, enabling you to specify content to be matched against the body of HTTP health check response

• Network Tiers for Load Balancing in beta, so you can optimize the outbound traffic from your load balanced instances for performance or cost

• Cloud Armor, a DDoS and application defense service for HTTP(S) LB

• Cloud CDN Signed URLs in GA, enabling you to give clients temporary access to private cached content without requiring additional authorization

• Cloud CDN Large Objects support in GA, allowing you to cache and serve video and other content up to 5TB in size

We look forward to your feedback

In short, we’ve been busy. But we’re far from done. Let us know how you plan to use these new networking services, and what capabilities you’d like to have in the future. You can reach us at gcp-networking@google.com