직접 VPC 이그레스를 사용하는 경우 서브넷에 충분한 IP 주소가 있는지 확인합니다. 사용하는 IP 주소 수는 워크로드가 실행되는 인스턴스 수에 따라 다르므로 IP 주소 사용량을 모니터링하는 것이 좋습니다. 시간 경과에 따른 IP 사용량이 서브넷에서 지원하는 범위 내에 있는지 확인합니다.
IP 주소 사용량을 추정하려면 다음 안내를 따르세요.
Google Cloud 콘솔에서 Cloud Monitoring 측정항목 탐색기 페이지로 이동합니다.
Cloud Run 워크로드가 많은 경우 직접 VPC 이그레스와 함께 RFC 1918 비공개 IP 주소 공간을 사용하면 IP 소진 문제가 발생할 수 있습니다. 다음 전략은 대체 IP 주소 범위를 사용하여 IP 주소 소진을 관리하는 데 도움이 됩니다.
RFC 1918 이외의 IPv4 주소 사용
Cloud Run은 RFC 1918 IPv4 주소 범위 외에도 RFC 6598 및 클래스 E/RFC 5735 범위를 지원합니다. 모든Google Cloud 서비스와 기능은 VPC 네트워크, Cloud Load Balancing, Private Service Connect를 포함한 RFC 1918 이외의 범위에서 작동합니다.
최고의 호환성을 위해 RFC 6598(100.64.0.0/10) 범위로 시작하는 것이 좋습니다. 다른 곳에서 이미 이 범위를 사용하고 있으면 클래스 E/RFC 5735(240.0.0.0/4)를 사용하는 것이 좋습니다. 클래스 E는 IP 주소를 2억 6,800만 개 이상 사용할 수 있는 거대한 공간이므로 장기간 성장을 지원할 수 있습니다. 하지만 클래스 E에는 몇 가지 제한사항이 있습니다. 예를 들어 Windows 및 일부 온프레미스 하드웨어에서는 지원되지 않습니다. 클래스 E IPv4 주소 공간을 활용하여 GKE의 IPv4 소진 문제를 완화하는 방법을 알아보세요.
Cloud NAT 또는 Private Service Connect 사용
비RFC 1918 범위를 사용하는 Cloud Run 워크로드가 RFC 1918만 허용하는 온프레미스 대상에 도달해야 하는 경우 다음 솔루션 중 하나를 사용하세요.
Hybrid NAT를 사용하여 작은 RFC 1918 범위에서 주소 변환 및 이그레스를 실행합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],null,["# Best practices for Cloud Run networking\n\nThis page outlines the best practices for configuring networking options for\nCloud Run resources. Before you create your resources, we recommend\nthat you review all the sections on this page to understand the networking\noptions that Cloud Run supports, as well as their implications. \n**Best practices**:\n[Monitor IP address usage](#monitor-ip-usage). \n[Use non-RFC 1918 IP addresses](#non-rfc-1918). \n[Use IPv4 and IPv6 (dual-stack) subnets](#dual-stack-subnets). \n[Use connection pooling and reuse connections](#connection-pooling). \n[Faster external throughput to the internet](#external-throughput). \n[Faster internal throughput to a Google API](#internal-vpc-throughput). \n\nMonitor IP address usage\n------------------------\n\nIf you're using Direct VPC egress, [make sure that you have enough IP addresses\nfor your subnet](/run/docs/configuring/vpc-direct-vpc#before_you_begin). The\nnumber of IP addresses you use depends on the number of instances\nthat your workloads run, so we recommend monitoring your IP address usage. Be\nsure that your IP usage over time stays within the bounds supported by the\nsubnet.\n\nTo estimate your IP address usage:\n\n1. In the Google Cloud console, go to the Cloud Monitoring Metrics explorer page:\n\n [Go to Cloud Monitoring Metrics explorer](https://console.cloud.google.com/monitoring/metrics-explorer)\n2. Look up the number of instances in your project by using\n the metric type [`run.googleapis.com/container/instance_count`](/monitoring/api/metrics_gcp_p_z#gcp-run).\n Cloud Monitoring lets you view this metric's value over time.\n\n3. Multiply the instance count metric's value by 2 to get an estimate of the\n number of IP addresses in use.\n\nIP address exhaustion strategies\n--------------------------------\n\nHaving a large number of Cloud Run workloads can cause IP exhaustion\nchallenges when using the RFC 1918 private IP address space with Direct VPC\negress. The following strategies can help you manage IP address exhaustion by\nusing alternative IP address ranges.\n\n### Use non-RFC 1918 IPv4 addresses\n\nAside from the RFC 1918 IPv4 address ranges, Cloud Run also supports\n[RFC 6598](https://datatracker.ietf.org/doc/html/rfc6598#section-7) and\n[Class E/RFC 5735](https://tools.ietf.org/html/rfc5735) ranges. All\nGoogle Cloud services and features work with these non-RFC 1918 ranges,\nincluding VPC networks, Cloud Load Balancing, and\nPrivate Service Connect.\n\nFor the best compatibility, we recommend starting with the RFC 6598\n(100.64.0.0/10) range. If you're already using this range elsewhere,\nconsider using Class E/RFC 5735 (240.0.0.0/4). Class E is a huge space with over\n268 million IP addresses available, so it'll support your growth for a long\ntime. However, Class E has some limitations. For example, it's not supported on\nWindows and on some on-premises hardware. Read about\n[leveraging Class E IPv4 Address space to mitigate IPv4 exhaustion issues in GKE](https://cloud.google.com/blog/products/containers-kubernetes/how-class-e-addresses-solve-for-ip-address-exhaustion-in-gke).\n\n### Use Cloud NAT or Private Service Connect\n\nIf your Cloud Run workload using a non-RFC 1918 range needs to\nreach an on-premises destination that accepts only RFC 1918, use one of the\nfollowing solutions:\n\n- Use [Hybrid NAT](/nat/docs/private-nat) to perform address translation and egress using a small RFC 1918 range.\n- Expose the on-premises service as a [Private Service Connect](/vpc/docs/configure-private-service-connect-producer) hybrid service.\n\n### Use IPv4 and IPv6 (dual-stack) subnets\n\nAlthough it won't reduce IPv4 exhaustion, moving your apps to [IPv6](/vpc/docs/ipv6-support)\nis a good first step. [Set up dual-stack resources](/run/docs/configuring/vpc-dual-stack-subnet)\nto avoid IPv4 exhaustion problems in the future.\n\nPort exhaustion reduction strategies\n------------------------------------\n\nThe following section describes strategies for reducing port exhaustion with\nCloud Run.\n\n### Use connection pooling and reuse connections\n\nWhen sending a large number of requests to a single destination IP address,\nuse connection pooling to maintain and reuse connections to the destination.\nHigh connection rates to a single IP address can exhaust outbound ports and\ncause connection refused errors.\n\nPerformance and throughput strategies\n-------------------------------------\n\nThis section covers scalable options for improving network performance and\nthroughput towards the internet and Google services.\n\n### Use Direct VPC egress for faster network egress throughput\n\nTo achieve faster throughput across network egress connections, use Direct VPC\negress to route traffic through your VPC network.\n\n#### Example 1: External traffic to the internet\n\nIf you're sending external traffic to the public internet, route all traffic\nthrough the VPC network by setting\n[`--vpc-egress=all-traffic`](/sdk/gcloud/reference/run/deploy#--vpc-egress).\nWith this approach, you must set up Cloud NAT to reach the public internet.\n\nTo enable Cloud Run to use a Cloud NAT gateway for\nPublic NAT or Private NAT, see\n[Cloud NAT Direct VPC egress interactions](/nat/docs/nat-product-interactions#interactions-direct-vpc).\n\n#### Example 2: Internal traffic to a Google API\n\nIf you're using Direct VPC egress to send traffic to a Google API, such as\nCloud Storage, choose one of the following options:\n\n- Specify [`private-ranges-only`](/sdk/gcloud/reference/run/deploy#--vpc-egress) (default) with [Private Google Access](/vpc/docs/configure-private-google-access):\n 1. Set the flag `--vpc-egress=private-ranges-only`.\n 2. Enable Private Google Access.\n 3. [Configure DNS for Private Google Access](/vpc/docs/configure-private-google-access#config-domain). Make sure your target domain (such as `storage.googleapis.com`) maps to one of the following internal IP address ranges:\n - `199.36.153.8/30`\n - `199.36.153.4/30`\n- Specify [`all-traffic`](/sdk/gcloud/reference/run/deploy#--vpc-egress) with [Private Google Access](/vpc/docs/configure-private-google-access):\n 1. Set the flag `--vpc-egress=all-traffic`.\n 2. Enable Private Google Access.\n\nUse the default MTU setting for Cloud Run\n-----------------------------------------\n\nDon't change the [maximum transmission unit (MTU)](/vpc/docs/mtu) setting of a\nVPC network when using it with Cloud Run. Use the\ndefault MTU of 1,460 bytes instead.\n\nWhat's next\n-----------\n\n- [Compare Direct VPC egress and VPC connectors.](/run/docs/configuring/connecting-vpc)\n- [Use tags for testing, traffic migration and rollbacks.](/run/docs/rollouts-rollbacks-traffic-migration#tags)"]]
