VPC 리소스 할당량

할당량 및 한도

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

프로젝트별

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

항목 할당량 참고
네트워크 할당량 이 항목에는 삭제할 수 있는 default 네트워크가 포함됩니다.
서브넷 할당량 프로젝트의 모든 네트워크에 있는 모든 서브넷에 적용됩니다.
할당된 IP 주소 범위 할당량 이 할당량은 비공개 서비스 액세스를 위해 할당할 수 있는 연속적인 내부 IP 주소 범위의 개수를 나타냅니다. 특정 VPC 네트워크나 리전이 아닌 프로젝트에 적용됩니다.
시스템 생성 및
커스텀 정적 경로
할당량 이 할당량에는 Cloud Router에서 학습한 커스텀 동적 경로가 포함되지 않습니다.
Cloud Router 할당량 이 할당량은 네트워크 및 리전에 상관없이 프로젝트 내에서 만들 수 있는 Cloud Router의 수를 나타냅니다. 네트워크에는 특정 리전의 Cloud Router 수에 대한 한도도 있습니다. 자세한 내용은 Cloud Router 할당량 및 한도를 참조하세요.
방화벽 규칙 할당량 이 할당량은 프로젝트의 모든 VPC 네트워크용으로 만들 수 있는 방화벽 규칙 수를 나타냅니다.
전달 규칙 할당량 이 할당량에는 내부 및 외부 전달 규칙 둘 다 포함되며 내부 전달 규칙에는 다른 한도가 적용됩니다. 자세한 내용은 네트워크당 내부 TCP/UDP 부하 분산용 전달 규칙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 범위 1 각 서브넷에는 기본 IP 범위(CIDR 블록)가 하나씩만 있어야 합니다. 이 범위가 VM 기본 내부 IP 주소, VM 별칭 IP 주소, 내부 TCP/UDP 부하 분산기의 IP 주소에 사용됩니다. 이 한도는 늘릴 수 없습니다.
서브넷당 보조 IP 범위 5 필요에 따라 서브넷당 최대 5개의 보조 CIDR 블록을 정의할 수 있습니다. 보조 IP 범위는 별칭 IP 주소에만 사용됩니다. 이 한도는 늘릴 수 없습니다.
방화벽 규칙당 최대 소스 태그 수 30 인그레스 방화벽 규칙을 만들 때 소스 태그로 지정할 수 있는 최대 네트워크 태그 수입니다. 이 한도는 늘릴 수 없습니다.
네트워크당 내부 TCP/UDP 부하 분산용 최대 전달 규칙 수 50 이 한도는 네트워크 내의 최대 내부 전달 규칙 수를 나타냅니다. VPC 네트워크 피어링을 사용하여 네트워크를 다른 네트워크에 연결하는 경우 VPC 네트워크 피어링 한도에서 중요한 추가 세부정보를 확인하세요.
Cloud Router 한도 라우터, BGP 피어, 커스텀 경로 공지, 학습된 경로의 총계에 관한 자세한 내용은 Cloud Router 할당량 및 한도를 참조하세요.

VPC 네트워크 피어링 한도

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

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

항목 한도 참고
단일 VPC 네트워크의 피어링 연결 수 25 이 한도는 피어링 그룹의 최대 네트워크 수를 나타내며 네트워크 자체는 포함되지 않습니다.
피어링 그룹의 총 VM 수 15,500 이 한도는 피어링 그룹의 직접 연결된 네트워크에서 사용할 수 있는 인스턴스의 총계를 나타냅니다.

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

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는 다음 방법을 사용하여 피어링 그룹에서 내부 TCP/UDP 부하 분산용 전달 규칙의 유효 개수를 계산합니다.

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

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

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

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

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와 피어링됩니다.

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

네트워크 특정 네트워크의 내부 TCP/UDP 부하 분산용 최대 전달 규칙 수 피어링 그룹의 내부 TCP/UDP 부하 분산용 전달 규칙 수
network-a 160 150
network-b 50 60
network-c 65 70
network-d 50 80

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

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

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

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

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

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

인스턴스별

VM 인스턴스에는 다음 한도가 적용되며 변경할 수 없습니다. VM과 관련된 할당량Compute Engine 할당량을 참조하세요.

항목 한도 참고
최대 전송 단위(MTU) 1,460바이트 더 큰 MTU 크기를 사용하는 인스턴스에서는 패킷이 손실될 수 있습니다. 이 MTU 값은 늘릴 수 없습니다.
네트워크 인터페이스의 최대 개수 8 네트워크 인터페이스는 인스턴스를 만들 때 정의되며 이후에 인스턴스를 수정하여 변경할 수 없습니다.
VPC 네트워크당 네트워크 인터페이스 1 각 네트워크 인터페이스는 고유한 VPC 네트워크에 연결되어야 합니다. 하나의 인스턴스는 특정 VPC 네트워크에서 하나의 네트워크 인터페이스만 포함할 수 있습니다.
최대 유휴 TCP 연결 기간 10분 VPC 네트워크는 10분이 지나면 유휴 TCP 연결을 자동으로 중단합니다. 이 한도를 변경할 수는 없지만 TCP 연결 유지를 사용하여 인스턴스 연결이 유휴 상태가 되는 것을 방지할 수 있습니다. 자세한 내용은 Compute Engine 도움말 및 문제해결 페이지를 참조하세요.
최대 인그레스 데이터 속도 머신 유형에 따라 다름 GCP는 인그레스에 대역폭 제한을 적용하지 않습니다. VM에서 처리할 수 있는 트래픽 양은 머신 유형과 운영체제에 따라 다릅니다. 인그레스 데이터 속도는 VM에 있는 네트워크 인터페이스 수 또는 VM에서 사용하는 별칭 IP 주소 수의 영향을 받지 않습니다.
최대 이그레스 데이터 속도 vCPU당 2Gbps
최대 16Gbps
GCP는 vCPU가 8개 이하인 머신 유형이그레스를 vCPU당 2Gbps로 제한합니다. vCPU가 8개가 넘는 머신 유형은 16Gbps로 제한되고 공유 코어 머신 유형은 1Gbps로 제한됩니다. 실제 이그레스 속도는 다른 요인에 따라 달라집니다. 자세한 내용은 이 페이지를 참조하세요. 이그레스 속도는 영구 디스크에 대한 데이터 전송 속도를 포함합니다.

개요

Virtual Private Cloud는 다양한 이유로 리소스 사용량에 할당량을 적용합니다. 예를 들어 할당량은 사용량이 예기치 않게 급증하는 것을 방지하여 Google Cloud Platform 사용자 커뮤니티를 보호합니다. 또한 할당량은 무료 등급으로 GCP 제품을 둘러보는 사용자가 계속해서 평가판을 사용할 수 있도록 해줍니다.

모든 프로젝트는 동일한 할당량으로 시작하며, 추가 할당량을 요청하여 할당량을 변경할 수 있습니다. 제품 사용에 따라 일부 할당량은 자동으로 증가할 수 있습니다.

권한

할당량을 보거나 할당량 증가를 요청하려면 IAM 구성원에게 다음 역할 중 하나가 필요합니다.

작업 필요한 역할
프로젝트의 할당량 확인 프로젝트 소유자나 편집자 또는 할당량 뷰어
할당량 수정, 추가 할당량 요청 프로젝트 소유자나 편집자, 할당량 관리자 또는 serviceusage.quotas.update 권한이 있는 커스텀 역할

할당량 확인

GCP Console에서 할당량 페이지로 이동합니다.

gcloud 명령줄 도구를 사용하는 경우에는 다음 명령어를 실행하여 할당량을 확인합니다. 여기서 [PROJECT_ID]는 프로젝트 ID로 바꿉니다.

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

리전에서 사용한 할당량을 확인하려면 다음 명령어를 실행합니다.

    gcloud compute regions describe example-region

할당량 초과 시 오류

gcloud 명령어 사용 시 할당량을 초과하면 gcloud에서 quota exceeded라는 오류 메시지를 출력하고 종료 코드 1을 반환합니다.

API 요청 시 할당량을 초과하면 GCP에서 HTTP 상태 코드 HTTP 413 Request Entity Too Large를 반환합니다.

추가 할당량 요청

GCP Console의 할당량 페이지에서 추가 할당량을 요청합니다. 할당량 요청이 처리되는 데는 24~48 시간이 소요됩니다.

  1. 할당량 페이지로 이동합니다.

    할당량 페이지로 이동

  2. 할당량 페이지에서 변경할 할당량을 선택합니다.
  3. 페이지 상단의 할당량 수정 버튼을 클릭합니다.
  4. 이름, 이메일, 전화번호를 입력하고 다음을 클릭합니다.
  5. 할당량 요청을 작성하고 다음을 클릭합니다.
  6. 요청을 제출합니다.

리소스 가용성

각 할당량은 특정 유형의 리소스를 사용할 수 있는 경우 생성 가능한 해당 유형의 리소스에 대한 최대 개수를 나타냅니다. 할당량이 리소스 가용성을 보장하지는 않는다는 점에 유의해야 합니다. 사용 가능한 할당량이 있더라도 리소스를 사용할 수 없으면 새 리소스를 만들 수 없습니다. 예를 들어 us-central1 지역에 새로운 지역 외부 IP 주소를 만들 수 있는 할당량이 충분히 있더라도 이 지역에 사용 가능한 외부 IP 주소가 없으면 해당 작업을 수행할 수 없습니다. 또한 지역별 리소스 가용성은 새 리소스를 만들 수 있는지 여부에도 영향을 줄 수 있습니다.

전체 지역에서 리소스를 사용할 수 없는 경우는 거의 없습니다. 하지만 영역 내의 리소스는 일반적으로 해당 리소스 유형의 SLA에 영향을 미치지 않으면서 수시로 고갈될 수 있습니다. 자세한 내용은 리소스의 관련 서비스수준계약(SLA)을 참조하세요.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...