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

Monitor IP address usage

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

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 usingthe metric typerun.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 2 to get an estimate of thenumber of IP addresses in use.

IP address exhaustion strategies

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

Use non-RFC 1918 IPv4 addresses

Aside from the RFC 1918 IPv4 address ranges, Cloud Run also supportsRFC 6598 andClass E/RFC 5735 ranges. AllGoogle Cloud services and features work with these non-RFC 1918 ranges,including VPC networks, Cloud Load Balancing, andPrivate 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 over268 million IP addresses available, so it'll support your growth for a longtime. However, Class E has some limitations. For example, it's not supported onWindows and on some on-premises hardware. Read aboutleveraging Class E IPv4 Address space to mitigate IPv4 exhaustion issues in GKE.

Use Cloud NAT or Private Service Connect

If your Cloud Run workload using a non-RFC 1918 range needs toreach an on-premises destination that accepts only RFC 1918, use one of thefollowing solutions:

• UseHybrid NAT to perform address translation andegress using a small RFC 1918 range.
• Expose the on-premises service as aPrivate Service Connecthybrid service.

Use IPv4 and IPv6 (dual-stack) subnets

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

Port exhaustion reduction strategies

The following section describes strategies for reducing port exhaustion withCloud 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 andcause connection refused errors.

Performance and throughput strategies

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

Use the second generation execution environment

For the best networking performance for Cloud Run services, usethesecond generation execution environmentwhen routing traffic with Direct VPC egress. The second generation environmentprovides faster network performance, especially in the presence of packet loss.

You canselect the execution environmentusing the Google Cloud console, gcloud CLI, YAML, or Terraform.

Use Direct VPC egress for faster network egress throughput

To achieve faster throughput across network egress connections, use Direct VPCegress to route traffic through your VPC network. We recommendusing this in conjunction with the second generation execution environment asnoted previously.

Example 1: External traffic to the internet

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

To enable Cloud Run to use a Cloud NAT gateway forPublic NAT or Private NAT, seeCloud NAT Direct VPC egress interactions.

Example 2: Internal traffic to a Google API

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

• Specifyprivate-ranges-only(default) withPrivate Google Access:
  1. Set the flag--vpc-egress=private-ranges-only.
  2. Enable Private Google Access.
  3. Configure DNS for Private Google Access.Make sure your target domain (such asstorage.googleapis.com) mapsto one of the following internal IP address ranges:
     • 199.36.153.8/30
     • 199.36.153.4/30
• Specifyall-trafficwithPrivate Google Access:
  1. Set the flag--vpc-egress=all-traffic.
  2. Enable Private Google Access.

Use the default MTU setting for Cloud Run

Don't change themaximum transmission unit (MTU) setting of aVPC network when using it with Cloud Run. Use thedefault MTU of 1,460 bytes instead.

What's next

• Compare Direct VPC egress and VPC connectors.
• Use tags for testing, traffic migration and rollbacks.