Best practices for Cloud Run networking

This page outlines the best practices for configuring networking options for Cloud Run resources. Before you create your resources, we recommend that you review all the sections on this page to understand the networking options that Cloud Run supports, as well as their implications.

Best practices:

Monitor IP address usage.
Use non-RFC 1918 IP addresses.
Use IPv4 and IPv6 (dual-stack) subnets.
Use connection pooling and reuse connections.
Faster external throughput to the internet.
Faster internal throughput to a Google API.

Monitor IP address usage

If you're using Direct VPC egress, make sure that you have enough IP addresses for your subnet. The number of IP addresses you use depends on the number of instances that your workloads run, so we recommend monitoring your IP address usage. Be sure that your IP usage over time stays within the bounds supported by the subnet.

To estimate your IP address usage:

  1. In the Google Cloud console, go to the Cloud Monitoring Metrics explorer page:

    Go to Cloud Monitoring Metrics explorer

  2. Look up the number of instances in your project by using the metric type run.googleapis.com/container/instance_count. Cloud Monitoring lets you view this metric's value over time.

  3. Multiply the instance count metric's value by 4 to get an estimate of the number of IP addresses in use.

IP address exhaustion strategies

Having a large number of Cloud Run workloads can cause IP exhaustion challenges when using the RFC 1918 private IP address space with Direct VPC egress. The following strategies can help you manage IP address exhaustion by using alternative IP address ranges.

Use non-RFC 1918 IPv4 addresses

Aside from the RFC 1918 IPv4 address ranges, Cloud Run also supports RFC 6598 and Class E/RFC 5735 ranges. All Google Cloud services and features work with these non-RFC 1918 ranges, including VPC networks, Cloud Load Balancing, and Private Service Connect.

For the best compatibility, we recommend starting with the RFC 6598 (100.64.0.0/10) range. If you're already using this range elsewhere, consider using Class E/RFC 5735 (240.0.0.0/4). Class E is a huge space with over 268 million IP addresses available, so it'll support your growth for a long time. However, Class E has some limitations. For example, it's not supported on Windows and on some on-premises hardware. Read about leveraging Class E IPv4 Address space to mitigate IPv4 exhaustion issues in GKE.

Use IPv4 and IPv6 (dual-stack) subnets

Although it won't reduce IPv4 exhaustion, moving your apps to IPv6 is a good first step. Set up dual-stack resources to avoid IPv4 exhaustion problems in the future.

Port exhaustion reduction strategies

The following section describes strategies for reducing port exhaustion with Cloud Run.

Use connection pooling and reuse connections

When sending a large number of requests to a single destination IP address, use connection pooling to maintain and reuse connections to the destination. High connection rates to a single IP address can exhaust outbound ports and cause connection refused errors.

Performance and throughput strategies

This section covers scalable options for improving network performance and throughput towards the internet and Google services.

Use Direct VPC egress for faster network egress throughput

To achieve faster throughput across network egress connections, use Direct VPC egress to route traffic through your VPC network.

Example 1: External traffic to the internet

If you're sending external traffic to the public internet, route all traffic through the VPC network by setting --vpc-egress=all-traffic. With this approach, you must set up Cloud NAT to reach the public internet. Note that Cloud NAT is a paid product.

Example 2: Internal traffic to a Google API

If you're using Direct VPC egress to send traffic to a Google API, such as Cloud Storage, choose one of the following options:

What's next