VPC 리소스 할당량

할당량 및 한도

다음 섹션에서는 VPC 네트워크의 할당량 및 한도를 설명합니다. 할당량은 GCP Console에서 할당량 추가를 요청하기만 하면 변경할 수 있습니다. 다만 한도는 별도로 언급되어 있는 경우를 제외하고 늘릴 수 없습니다.

프로젝트별

이 표에서는 각 프로젝트의 VPC 리소스별로 중요한 글로벌 할당량을 보여줍니다. 기타 할당량에 관한 내용은 할당량 페이지를 참조하세요.

항목 할당량 참고
네트워크 할당량 이 항목에는 삭제할 수 있는 default 네트워크가 포함됩니다.
서브넷 할당량 프로젝트의 모든 네트워크에 있는 모든 서브넷에 적용됩니다.
할당된 IP 주소 범위 할당량 이 할당량은 비공개 서비스 액세스를 위해 할당할 수 있는 연속적인 내부 IP 주소 범위의 개수를 나타냅니다. 특정 VPC 네트워크나 리전이 아닌 프로젝트에 적용됩니다.
시스템 생성 및
커스텀 정적 경로
할당량 이 할당량에는 Cloud Router에서 학습한 커스텀 동적 경로가 포함되지 않습니다.
Cloud Router 할당량 이 할당량은 네트워크 및 리전에 상관없이 한 프로젝트 내에서 만들 수 있는 Cloud Router의 수를 나타냅니다. 네트워크에는 특정 리전의 Cloud Router 수에 대한 한도도 있습니다. 자세한 내용은 Cloud Router 할당량 및 한도를 참조하세요.
방화벽 규칙 할당량 이 할당량은 프로젝트의 모든 VPC 네트워크용으로 만들 수 있는 방화벽 규칙 수를 나타냅니다.
전달 규칙 할당량 이 할당량에는 내부 및 외부 전달 규칙 둘 다 포함되며 내부 전달 규칙에는 다른 한도가 적용됩니다. 자세한 내용은 네트워크당 내부 부하 분산기용 규칙 전달VPC 네트워크 피어링 한도를 참조하세요.

공유 VPC 프로젝트 한도

공유 VPC에 참여하는 프로젝트에는 다음과 같은 한도가 적용됩니다.

항목 한도 참고
호스트 프로젝트에 연결할 수 있는 서비스 프로젝트 수 최대 100 이 한도는 다를 수 있으며 100보다 낮을 수도 있습니다. 문의사항이 있거나 한도를 늘려야 할 경우 GCP 영업팀에 문의하세요.
단일 조직의 공유 VPC 호스트 프로젝트 수 100 이 한도를 늘려야 할 경우 GCP 영업팀에 문의하세요.
서비스 프로젝트를 연결할 수 있는 호스트 프로젝트 수 1 이 한도는 늘릴 수 없습니다.

네트워크별

VPC 네트워크에는 다음 한도가 적용됩니다. 별도로 명시되어 있지 않을 경우 GCP 영업팀에 문의해 한도를 늘릴 수 있습니다.

항목 한도 참고
네트워크당 VM 인스턴스 15,000 VPC 네트워크 피어링을 사용하여 네트워크를 다른 네트워크에 연결하면 네트워크당 만들 수 있는 인스턴스 수의 유효 한도가 줄어들 수 있습니다. 다음 섹션의 VPC 네트워크 피어링 한도를 참조하세요.
서브넷당 VM 인스턴스 별도의 제한이 없습니다.
할당된 별칭 IP 범위 15,000 별칭 IP는 VM의 네트워크 인터페이스에 할당된 단일 IP 주소(/32) 또는 CIDR 블록(예: /24 또는 /16)입니다. 별칭 IP 주소는 서브넷의 기본 또는 보조 IP 범위 중 하나에서 가져올 수 있습니다.
이러한 한도의 목적상 GCP는 별칭 범위의 크기(넷마스크)를 고려하지 않고 네트워크의 모든 VM에 할당된 별칭 IP(범위) 수만 반영합니다.

이러한 할당량 외에 네트워크 인터페이스당 별칭 IP 범위 수에 대한 VM별 제한도 있습니다.
서브넷당 기본 IP 범위 1 각 서브넷에는 기본 IP 범위(CIDR 블록)가 하나씩만 있어야 합니다. 이 범위가 VM 기본 내부 IP 주소, VM 별칭 IP 주소, 내부 부하 분산기의 IP 주소에 사용됩니다. 이 한도는 늘릴 수 없습니다.
서브넷당 보조 IP 범위 30 필요에 따라 서브넷당 최대 30개의 보조 CIDR 블록을 정의할 수 있습니다. 보조 IP 범위는 별칭 IP 주소에만 사용됩니다. 이 한도는 늘릴 수 없습니다.
서브넷 IP 범위 수(기본 및 보조) 3,100 단일 VPC 네트워크에서 할당할 수 있는 기본 및 보조 서브넷 IP 범위의 총 수이며, 이 한도는 늘릴 수 없습니다.
방화벽 규칙당 최대 소스 태그 수 30 인그레스 방화벽 규칙을 만들 때 소스 태그로 지정할 수 있는 최대 네트워크 태그 수입니다. 이 한도는 늘릴 수 없습니다.
방화벽 규칙당 최대 대상 태그 수 70 이그레스 또는 인그레스 방화벽 규칙을 만들 때 대상 태그로 지정할 수 있는 최대 네트워크 태그 수입니다. 이 한도는 늘릴 수 없습니다.
방화벽 규칙당 최대 소스 서비스 계정 수 10 인그레스 방화벽 규칙을 만들 때 지정할 수 있는 최대 소스 서비스 계정 수입니다. 이 한도는 늘릴 수 없습니다.
방화벽 규칙당 최대 대상 서비스 계정 수 10 이그레스 또는 인그레스 방화벽 규칙을 만들 때 지정할 수 있는 최대 대상 서비스 계정 수입니다. 이 한도는 늘릴 수 없습니다.
네트워크당 최대 전달 규칙 수:
- 내부 TCP/UDP 부하 분산
- 내부 HTTP(S) 부하 분산
75 이 한도는 네트워크 내의 최대 내부 전달 규칙 수를 나타냅니다. VPC 네트워크 피어링을 사용하여 네트워크를 다른 네트워크에 연결하는 경우 VPC 네트워크 피어링 한도에서 중요한 추가 세부정보를 확인하세요.
Cloud Router 한도 라우터, BGP 피어, 커스텀 경로 공지, 학습된 경로의 총계에 관한 자세한 내용은 Cloud Router 할당량 및 한도를 참조하세요.

VPC 네트워크 피어링 한도

VPC 네트워크 피어링을 사용하여 연결된 VPC 네트워크에는 다음과 같은 한도가 적용됩니다. 각 한도는 서로 다이렉트 피어링된 VPC 네트워크 모음인 피어링 그룹에 적용됩니다. 특정 VPC 네트워크의 관점에서 볼 때 이 네트워크와 다른 모든 피어 네트워크는 한 피어링 그룹에 속합니다. 피어링 그룹에는 피어 네트워크의 피어가 포함되지 않습니다.

경우에 따라 한도를 늘릴 수 있습니다. 한도 증가에 대해 궁금한 점이 있으면 GCP 영업팀에 문의하세요.

항목 한도 참고
단일 VPC 네트워크의 피어링 연결 수 25 이 한도는 피어링 그룹의 최대 네트워크 수를 나타내며 네트워크 자체는 포함되지 않습니다.
피어링 그룹의 정적 경로 수 300 이 한도는 네트워크 관리자가 피어링 그룹의 모든 네트워크에서 만들 수 있는 정적 경로의 총 수를 나타냅니다. 네트워크에 대한 피어링 연결을 만들 경우 피어링 그룹이 이 한도를 초과하게 된다면 GCP가 네트워크에 대한 피어링 연결을 만들지 못하게 합니다.
피어링 그룹의 동적 경로 수 300

이 한도는 Cloud Router가 피어링 그룹의 모든 네트워크에 적용할 수 있는 동적 경로의 총 수를 나타냅니다. 동적 경로 수가 이 한도를 초과하면 GCP는 특정 네트워크의 동적 경로를 가져오는 방법을 조정합니다.

  • GCP는 피어링된 네트워크에서 가져온 동적 경로를 삭제합니다. GCP는 내부 알고리즘을 사용하여 동적 경로를 삭제하므로 최근에 추가된 경로뿐만 아니라 이전 경로도 삭제할 수 있습니다. 가져온 동적 경로 중 어떤 경로가 삭제될지 예측할 수 없습니다. 대신 피어링 그룹에서 동적 경로 수를 줄여야 합니다.
  • Cloud Router 한도에 따라 GCP는 로컬 네트워크에서 Cloud Router가 학습한 동적 경로를 절대 삭제하지 않습니다.
  • 피어링 연결로 인해 이 한도가 초과될 경우에도 GCP는 경고 없이 사용자가 피어링 연결을 만들도록 허용합니다.
피어링 그룹의 총 VM 인스턴스 수 15,500 이 한도는 피어링 그룹의 직접 연결된 네트워크에서 사용할 수 있는 인스턴스의 총계를 나타냅니다.

이 한도를 명확히 보여주는 예는 이 표 아래의 VPC 네트워크 피어링 및 최대 VM 수를 참조하세요.
서브넷 IP 범위 수(기본 및 보조) 3,200 피어링 그룹의 모든 네트워크에 할당할 수 있는 기본 및 보조 서브넷 IP 범위의 총 수입니다.
특정 네트워크의 최대 전달 규칙 수:
- 내부 TCP/UDP 부하 분산
- 내부 HTTP(S) 부하 분산
75 다음 조건을 모두 충족하면 GCP를 통해 특정 VPC 네트워크에서 새 내부 전달 규칙을 만들 수 있습니다.
  • 특정 네트워크의 프로젝트에서 내부 전달 규칙뿐 아니라 모든 전달 규칙의 총계가 프로젝트당 전달 규칙 할당량 미만입니다.
  • 특정 네트워크의 내부 전달 규칙 수는 특정 네트워크의 내부 부하 분산기당 최대 전달 규칙 수보다 적습니다.
  • 피어링 그룹의 내부 전달 규칙 수는 피어링 그룹의 내부 부하 분산기용 전달 규칙의 유효 개수보다 적습니다. 유효 개수는 VPC 네트워크 피어링 및 내부 전달 규칙의 설명대로 계산됩니다.
다음에 대한 피어링 그룹의 전달 규칙 수:
- 내부 TCP/UDP 부하 분산
- 내부 HTTP(S) 부하 분산
175

VPC 네트워크 피어링 및 최대 VM 수

피어링 그룹의 여러 네트워크 간에 최대 15,500개의 VM 인스턴스가 허용됩니다. 예를 들어 network-bnetwork-anetwork-c라는 2개의 다른 네트워크와 피어링된다고 가정해 보겠습니다.

  • network-b에 VM이 5,000개 있으면 network-anetwork-c 모두 합산해서 만들 수 있는 총 VM 수가 10,500개 이하여야 합니다.
  • network-b에 VM이 500개 있으면 network-anetwork-c 모두 합산해서 만들 수 있는 총 VM 수가 15,000개 이하여야 합니다.

VPC 네트워크 피어링 및 내부 전달 규칙

특정 VPC 네트워크의 관점에서 볼 때 GCP는 다음 방법을 사용하여 피어링 그룹에서 내부 부하 분산기용 전달 규칙의 유효 개수를 계산합니다.

  • 1단계: 특정 네트워크에서 다음 두 한도 중 더 큰 한도를 찾습니다.

    • 특정 네트워크의 내부 부하 분산기용 최대 전달 규칙 수
    • 피어링 그룹의 내부 부하 분산기용 전달 규칙 수
  • 2단계: 피어링 그룹의 나머지 네트워크 각각에서 다음 두 한도 중 더 큰 한도를 찾습니다.

    • 피어 네트워크의 내부 부하 분산기용 최대 전달 규칙 수
    • 피어링 그룹의 내부 부하 분산기용 전달 규칙 수
  • 3단계: 2단계에서 만든 목록에서 가장 작은 값을 찾습니다.

  • 4단계: 1단계와 3단계의 두 숫자 중에서 더 큰 숫자를 취합니다. 이 숫자가 특정 네트워크의 관점에서 피어링 그룹에 만들 수 있는 내부 부하 분산기용 전달 규칙의 유효 개수입니다.

network-a, network-b, network-c, network-d라는 4개의 VPC 네트워크가 있다고 가정해 보겠습니다.

  • network-anetwork-b와, network-bnetwork-a와 피어링됩니다.
  • network-anetwork-c와, network-cnetwork-a와 피어링됩니다.
  • network-cnetwork-d와, network-dnetwork-c와 피어링됩니다.

각 네트워크의 한도는 다음과 같습니다.

네트워크 특정 네트워크의 내부 부하 분산기용 최대 전달 규칙 수 피어링 그룹의 내부 부하 분산기용 전달 규칙 수
network-a 160 150
network-b 75 80
network-c 75 75
network-d 75 95

각 VPC 네트워크의 관점에서 볼 때 GCP는 피어링 그룹에서 내부 부하 분산기용 전달 규칙의 유효 개수를 다음과 같이 계산합니다.

  • network-a의 관점에서 볼 때 피어링 그룹에 network-a, network-b, network-c가 포함되어 있습니다. 피어링 그룹에서 내부 부하 분산기용 전달 규칙의 유효 개수는 다음과 같이 계산됩니다.

    1. network-a: max(160,150) = 160
    2. 나머지 피어 네트워크:
      • network-b: max(75,80) = 80
      • network-c: max(75,75) = 75
    3. min(80,75) = 75
    4. max(160,75) = 160
      • network-a의 관점에서 피어링 그룹당 내부 부하 분산기용 전달 규칙의 유효 개수: 160
  • network-b의 관점에서 볼 때 피어링 그룹에 network-b, network-a가 포함되어 있습니다. 피어링 그룹에서 내부 부하 분산기용 전달 규칙의 유효 개수는 다음과 같이 계산됩니다.

    1. network-b: max(75,80) = 80
    2. 나머지 피어 네트워크:
      • network-a: max(160,150) = 160
    3. min(160) = 160
    4. max(80,160) = 160
      • network-b의 관점에서 피어링 그룹당 내부 부하 분산기용 전달 규칙의 유효 개수: 160
  • network-c의 관점에서 볼 때 피어링 그룹에 network-c, network-a, network-d가 포함되어 있습니다. 피어링 그룹에서 내부 부하 분산기용 전달 규칙의 유효 개수는 다음과 같이 계산됩니다.

    1. network-c: max(75,75) = 75
    2. 나머지 피어 네트워크:
      • network-a: max(160,150) = 160
      • network-d: max(75,95) = 95
    3. min(160,95) = 95
    4. max(75,95) = 95
      • network-c의 관점에서 피어링 그룹당 내부 부하 분산기용 전달 규칙의 유효 개수: 95
  • network-d의 관점에서 볼 때 피어링 그룹에 network-d, network-c가 포함되어 있습니다. 피어링 그룹에서 내부 부하 분산기용 전달 규칙의 유효 개수는 다음과 같이 계산됩니다.

    1. network-d: max(75,95) = 95
    2. 나머지 피어 네트워크:
      • network-c: max(75,75) = 75
    3. min(75) = 75
    4. max(95,75) = 95
      • network-d의 관점에서 피어링 그룹당 내부 부하 분산기용 전달 규칙의 유효 개수: 95

인스턴스별

VM 인스턴스에는 다음 한도가 적용되며 별도로 명시되지 않는 한 이 한도를 늘릴 수 없습니다. VM과 관련된 할당량Compute Engine 할당량을 참조하세요.

항목 한도 참고
최대 전송 단위(MTU) 1,460바이트 더 큰 MTU 크기를 사용하는 인스턴스에서는 패킷이 손실될 수 있습니다. 이 MTU 값은 늘릴 수 없습니다.
네트워크 인터페이스의 최대 개수 8 네트워크 인터페이스는 인스턴스를 만들 때 정의되며 이후에 인스턴스를 수정하여 변경할 수 없습니다.
네트워크 인터페이스당 최대 별칭 IP 범위 수 10 VPC 네트워크에서 할당된 별칭 IP 범위의 총 수에 대한 할당량을 초과하지 않는 한 네트워크 인터페이스에 할당할 수 있는 별칭 IP 범위 수

이 한도를 늘려야 할 경우 GCP 영업팀에 문의하세요.
VPC 네트워크당 네트워크 인터페이스 1 각 네트워크 인터페이스는 고유한 VPC 네트워크에 연결되어야 합니다. 하나의 인스턴스는 특정 VPC 네트워크에서 하나의 네트워크 인터페이스만 포함할 수 있습니다.
최대 유휴 TCP 연결 기간 10분 VPC 네트워크는 10분이 지나면 유휴 TCP 연결을 자동으로 중단합니다. 이 한도를 변경할 수는 없지만 TCP 연결 유지를 사용하여 인스턴스 연결이 유휴 상태가 되는 것을 방지할 수 있습니다. 자세한 내용은 Compute Engine 도움말 및 문제해결 페이지를 참조하세요.
최대 인그레스 데이터 속도 머신 유형에 따라 다름 GCP는 VM 인스턴스의 인바운드 또는 인그레스 트래픽을 인위적으로 제한하지 않습니다. VM은 리소스 및 네트워크 조건으로 허용되는 한도까지 트래픽을 수신할 수 있습니다. 용량 계획을 위해서는 각 VM 인스턴스가 외부 인터넷 트래픽을 최대 10Gbps까지 처리할 수 있다고 가정해야 합니다. 이러한 값은 대략적인 값이며 SLA로 지원되지 않고, 변경될 수 있습니다. VM에 별칭 IP 주소 또는 여러 네트워크 인터페이스를 추가해도 인그레스 용량이 늘어나지 않습니다.
최대 이그레스 데이터 속도 VM의 머신 유형에 따라 다릅니다.
  • 모든 공유 코어 머신 유형은 1Gbps로 제한됩니다.
  • vCPU가 16개 이상인 Skylake 이상의 CPU 플랫폼을 사용하는 머신 유형의 경우 vCPU당 2Gbps, VM당 최대 32Gbps입니다. 이 이그레스 속도는 ultramem 머신 유형에도 사용할 수 있습니다.
  • vCPU가 8개 이상인 다른 모든 머신 유형의 경우 vCPU당 2Gbps, VM당 최대 16Gbps입니다.
이그레스 트래픽은 VM의 모든 네트워크 인터페이스에서 공유되는 총 발신 대역폭입니다. 여기에는 VM에 연결된 영구 디스크로의 데이터 전송이 포함됩니다.

실제 이그레스 속도는 다른 요인에 따라 달라집니다. 자세한 내용은 이 페이지를 참조하세요.

Overview

Virtual Private Cloud enforces quotas on resource usage for a variety of reasons. For example, quotas protect the community of Google Cloud Platform users by preventing unforeseen spikes in usage. Quotas also help users who are exploring GCP with the free tier to stay within their trial.

All projects start with the same quotas, which you can change by requesting additional quota. Some quotas may increase automatically, based on your use of a product.

Permissions

To view quotas or request quota increases, IAM members need one of the following roles.

Task Required Role
Check quotas for a project Project owner or editor or Quota Viewer
Modify quotas, request additional quota Project owner or editor, Quota Admin, or custom role with the serviceusage.quotas.update permission

Checking your quota

In the GCP Console, go to the Quotas page.

Using the gcloud command-line tool, run the following command to check your quotas. Replace [PROJECT_ID] with your own project ID.

    gcloud compute project-info describe --project [PROJECT_ID]

To check your used quota in a region, run:

    gcloud compute regions describe example-region

Errors when exceeding your quota

If you exceed a quota with a gcloud command, gcloud outputs a quota exceeded error message and returns with the exit code 1.

If you exceed a quota with an API request, Google Cloud returns the following HTTP status code: HTTP 413 Request Entity Too Large.

Requesting additional quota

Request additional quota from the Quotas page in the GCP Console. Quota requests take 24 to 48 hours to process.

  1. Go to the Quotas page.

    Go to the Quotas page

  2. In the Quotas page, select the quotas you want to change.
  3. Click the Edit Quotas button at the top of the page.
  4. Fill out your name, email, and phone number and click Next.
  5. Fill in your quota request and click Next.
  6. Submit your request.

Resource availability

Each quota represents a maximum number for a particular type of resource that you can create, provided that resource is available. It's important to note that quotas do not guarantee resource availability. Even if you have available quota, you won't be able to create a new resource if it is not available. For example, you might have sufficient quota to create new regional, external IP address in the us-central1 region, but that would not be possible if there were no available external IP addresses in that region. Zonal resource availability can also affect your ability to create a new resource.

Situations where resources are unavailable in an entire region are rare; however, resources within a zone can be depleted from time to time, typically without impact to the SLA for the type of resource. For more information, review the relevant Service Level Agreement (SLA) for the resource.