VPC 네트워크 개요

Virtual Private Cloud(VPC) 네트워크는 데이터 센터 네트워크와 같은 실제 네트워크의 가상 버전입니다. VPC 네트워크는 Compute Engine 가상 머신(VM) 인스턴스, Google Kubernetes Engine(GKE) 클러스터, App Engine 가변형 환경 인스턴스, 프로젝트의 다른 리소스를 위한 연결을 제공합니다.

프로젝트에는 여러 VPC 네트워크가 포함될 수 있습니다. 이를 금지하는 조직 정책을 만들지 않는 한, 새 프로젝트는 각 리전에 하나의 서브네트워크(서브넷)가 있는 기본 네트워크(자동 모드 VPC 네트워크)로 시작됩니다.

사양

VPC 네트워크에는 다음과 같은 특징이 있습니다.

  • VPC 네트워크는 연결된 라우터와 방화벽 규칙을 포함하여 전역 리소스입니다. VPC 네트워크는 특정 리전 또는 영역과 연결되지 않습니다.

  • 서브넷은 리전 리소스입니다. 각 서브넷은 IP 주소 범위를 정의합니다.

  • 인스턴스에서 송수신되는 트래픽은 네트워크 방화벽 규칙으로 제어할 수 있습니다.

  • VPC 네트워크 내의 리소스는 관련 네트워크 방화벽 규칙에 따라 내부(비공개) IPv4 주소를 사용하여 서로 통신할 수 있습니다. 자세한 내용은 네트워크 내 통신을 참조하세요.

  • 내부 IP 주소가 있는 인스턴스는 Google API 및 서비스와 통신할 수 있습니다. 자세한 내용은 서비스 비공개 액세스 옵션을 참조하세요.

  • Cloud Identity and Access Management(Cloud IAM) 역할을 사용하여 네트워크 관리를 보호할 수 있습니다.

  • 조직에서는 공유 VPC를 사용하여 VPC 네트워크를 공용 호스트 프로젝트에 유지할 수 있습니다. 같은 조직의 다른 프로젝트에서 승인된 Cloud IAM 구성원은 공유 VPC 네트워크의 서브넷을 사용하는 리소스를 만들 수 있습니다.

  • VPC 네트워크 피어링을 사용하여 VPC 네트워크를 다른 프로젝트 또는 조직의 다른 VPC 네트워크에 연결할 수 있습니다.

  • Cloud VPN이나 Cloud Interconnect를 사용하여 하이브리드 환경에서 VPC 네트워크를 안전하게 연결할 수 있습니다.

  • VPC 네트워크는 IPv4 유니캐스트 트래픽만 지원합니다. 네트워크 브로드캐스트, 멀티캐스트 또는 IPv6 트래픽을 지원하지 않습니다. VPC 네트워크의 VM은 IPv4 대상으로만 보내고 IPv4 소스로부터는 트래픽을 받기만 합니다. 그러나 전역 부하 분산기에 IPv6 주소를 만들 수는 있습니다.

네트워크 및 서브넷 용어

용어 서브넷서브네트워크는 동의어입니다. Google Cloud Console, gcloud 명령어, API 문서에서는 서로 바꿔서 사용됩니다.

서브넷은 (VPC) 네트워크와 같지 않습니다. 네트워크 및 서브넷은 Google Cloud에서 서로 다른 객체 유형입니다.

네트워크 및 서브넷

각 VPC 네트워크는 서브넷이라는 하나 이상의 유용한 IP 범위 파티션으로 구성됩니다. 각 서브넷은 리전과 연결됩니다. VPC 네트워크에는 IP 주소 범위가 연결되어 있지 않습니다. IP 범위는 서브넷에 대해 정의됩니다.

네트워크를 사용하려면 네트워크에 한 개 이상의 서브넷이 있어야 합니다. 자동 모드 VPC 네트워크는 각 리전에 자동으로 서브넷을 만듭니다. 커스텀 모드 VPC 네트워크는 서브넷 없이 시작되므로 서브넷 만들기를 전적으로 제어할 수 있습니다. 한 리전에 두 개 이상의 서브넷을 만들 수 있습니다. 자동 모드와 커스텀 모드 VPC 네트워크의 차이점에 대한 자세한 내용은 VPC 네트워크 유형을 참조하세요.

Google Cloud에서 리소스를 만들 때 네트워크와 서브넷을 선택합니다. 인스턴스 템플릿 이외의 리소스를 만들 때는 영역 또는 리전도 선택합니다. 영역을 선택하면 상위 리전도 암시적으로 선택됩니다. 서브넷은 리전 객체이므로 리소스에 선택한 리전에 따라 리소스에서 사용할 수 있는 서브넷이 결정됩니다.

  • 인스턴스를 만드는 프로세스에는 영역, 네트워크, 서브넷을 선택하는 과정이 포함됩니다. 선택 가능한 서브넷은 선택된 리전의 서브넷으로 제한됩니다. Google Cloud는 서브넷의 사용 가능한 주소 범위에 있는 IP 주소 하나를 인스턴스에 할당합니다.

  • 관리형 인스턴스 그룹을 만드는 프로세스에는 그룹 유형에 따라 영역 또는 리전을 선택하고 인스턴스 템플릿을 선택하는 과정이 포함됩니다. 정의된 서브넷의 리전이 관리형 인스턴스 그룹에 선택된 리전과 동일한 인스턴스 템플릿만 선택할 수 있습니다.

    • 인스턴스 템플릿은 전역 리소스입니다. 인스턴스 템플릿을 만드는 프로세스에는 네트워크 및 서브넷을 선택하는 과정이 포함됩니다. 자동 모드 VPC 네트워크를 선택하면 자동 서브넷을 지정하여 템플릿을 사용할 관리형 인스턴스 그룹의 선택된 리전에서 사용 가능한 서브넷 선택이 연기되도록 할 수 있습니다. 자동 모드 VPC 네트워크는 정의에 따라 모든 리전에서 서브넷을 가집니다.
  • Kubernetes 컨테이너 클러스터를 만드는 프로세스에는 영역 또는 리전(클러스터 유형에 따름), 네트워크, 서브넷을 선택하는 과정이 포함됩니다. 선택 가능한 서브넷은 선택된 리전의 서브넷으로 제한됩니다.

서브넷 생성 모드

Google Cloud는 서브넷 생성 모드에 따라 결정되는 두 가지 유형의 VPC 네트워크를 제공합니다.

  • 자동 모드 VPC 네트워크가 만들어질 때 네트워크 내의 각 리전에서 하나의 서브넷이 자동으로 만들어집니다. 자동으로 생성되는 이러한 서브넷은 10.128.0.0/9 CIDR 블록에 속하는 사전 정의된 IP 범위 집합을 사용합니다. 새 Google Cloud 리전을 사용할 수 있게 되면 이 블록의 IP 범위를 사용하여 리전의 새 서브넷이 자동으로 자동 모드 VPC 네트워크에 추가됩니다. 자동으로 생성되는 서브넷 외에도, 자동 모드 VPC 네트워크의 선택한 리전에 10.128.0.0/9 이외의 IP 범위를 사용하여 수동으로 서브넷을 더 추가할 수 있습니다.

  • 커스텀 모드 VPC 네트워크가 만들어질 때는 서브넷이 자동으로 만들어지지 않습니다. 이 네트워크 유형에서는 개발자가 서브넷과 IP 범위를 완전히 제어할 수 있습니다. 직접 지정한 IP 범위를 사용하여 선택한 리전에 만들 서브넷을 결정합니다.

자동 모드에서 커스텀 모드로 VPC 네트워크를 전환할 수 있습니다. 이는 편도 변환입니다. 커스텀 모드 VPC 네트워크는 자동 모드 VPC 네트워크로 변경할 수 없습니다. 필요에 맞는 네트워크 유형을 결정하려면 자동 모드 VPC 네트워크에 대한 고려 사항을 참조하세요.

기본 네트워크

명시적으로 중지하지 않는 한, 각각의 새 프로젝트는 기본 네트워크로 시작합니다. 기본 네트워크는 방화벽 규칙이 사전 지정된 자동 모드 VPC 네트워크입니다.

compute.skipDefaultNetworkCreation 제약조건으로 조직 정책을 만들면 기본 네트워크 생성을 중지할 수 있습니다. 이 정책을 상속하는 프로젝트에는 기본 네트워크가 없습니다.

자동 모드 VPC 네트워크에 대한 고려사항

자동 모드 VPC 네트워크는 쉽게 설정하고 사용할 수 있으며 다음과 같은 속성을 가진 사용 사례에 적합합니다.

  • 각 리전에 서브넷이 자동 생성되는 편이 유용합니다.

  • 서브넷의 사전 정의된 IP 범위가 다른 용도로(예: 온프레미스 리소스를 위한 Cloud VPN 연결) 사용할 IP 범위와 겹치지 않습니다.

커스텀 모드 VPC 네트워크는 더 유연하고 프로덕션에 더 적합합니다. 다음 속성은 커스텀 모드 VPC 네트워크가 권장되거나 필요한 사용 사례를 나타냅니다.

  • 각 리전에 하나의 서브넷을 자동으로 만들 필요가 없습니다.

  • 새 리전을 사용할 수 있을 때 새 서브넷이 자동으로 만들어지면 수동으로 만들어진 서브넷 또는 정적 경로에 사용되는 IP 주소와 겹치거나 전체적인 네트워크 계획에 차질이 발생할 수 있습니다.

  • 사용되는 리전과 IP 주소 범위를 포함하여 VPC 네트워크에 만들어지는 서브넷의 모든 부분을 직접 제어해야 합니다.

  • VPC 네트워크 피어링 또는 Cloud VPN을 사용하여 VPC 네트워크에 연결할 계획입니다. 모든 자동 모드 VPC 네트워크의 서브넷은 동일한 사전 정의된 IP 주소 범위를 사용하므로 자동 모드 VPC 네트워크를 상호 연결할 수 없습니다.

서브넷 범위

서브넷을 만들 때 서브넷의 기본 IP 주소 범위를 정의해야 합니다. VM 인스턴스, 내부 부하 분산기, 내부 프로토콜 전달 등의 리소스에 대한 기본 내부 주소는 서브넷의 기본 범위에서 가져옵니다. 원하는 경우 별칭 IP 범위에서만 사용되는 보조 IP 주소 범위를 서브넷에 추가할 수 있습니다. 하지만 서브넷의 기본 또는 보조 범위에서 인스턴스의 별칭 IP 범위를 구성할 수 있습니다.

VPC 네트워크의 모든 서브넷에 대한 각 기본 또는 보조 IP 범위는 고유한 유효 CIDR 블록이어야 합니다. 정의할 수 있는 보조 IP 범위 수는 네트워크별 한도를 참조하세요.

서브넷에 사전 정의된 연속 CIDR 블록을 구성할 필요는 없지만 원하면 그렇게 할 수 있습니다. 예를 들어 자동 모드 VPC 네트워크는 사전 정의된 자동 모드 IP 범위에 속하는 서브넷을 만듭니다.

자세한 내용은 서브넷 작업을 참조하세요.

유효한 범위

서브넷의 기본 및 보조 IP 주소 범위는 리전별 내부 IP 주소입니다. 다음 표에서는 유효한 범위를 설명합니다.

범위 설명
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
비공개 IP 주소 RFC 1918
100.64.0.0/10 공유 주소 공간 RFC 6598
192.0.0.0/24 IETF 프로토콜 할당 RFC 6890
192.0.2.0/24 (TEST-NET-1)
198.51.100.0/24 (TEST-NET-2)
203.0.113.0/24 (TEST-NET-3)
문서 RFC 5737
192.88.99.0/24 IPv6-IPv4 릴레이(지원 중단됨) RFC 7526
198.18.0.0/15 벤치마크 테스트 RFC 2544
240.0.0.0/4 예약 RFC 1112
비공개적으로 재사용되는 공개 IP 주소 이 표에 나열된 RFC 범위에 속하지 않고 제한된 집합에 속하지 않는 IP 주소를 포함합니다. 이러한 주소를 서브넷 범위로 사용하면 Google Cloud가 이 범위로 트래픽을 공개적으로 라우팅하지 않습니다.

VPC 네트워킹 피어링의 경우 공개 IP 주소에 대한 서브넷 경로가 자동으로 교환되지 않습니다. 서브넷 경로가 자동으로 내보내지지 않지만 이를 사용하기 위해서는 경로를 가져오도록 피어 네트워크가 명시적으로 구성되어 있어야 합니다.

서브넷 범위에는 다음과 같은 제약이 있습니다.

  • 서브넷 범위는 제한된 범위와 일치하거나, 이보다 좁거나 넓을 수 없습니다. 예를 들어 169.0.0.0/8은 제한된 범위인 링크-로컬 범위 169.254.0.0/16(RFC 3927)와 겹치기 때문에 유효한 서브넷 범위가 아닙니다.

  • 서브넷 범위는 RFC 범위(이전 표 설명 참조) 및 비공개적으로 사용되는 공개 IP 주소 범위를 포함할 수 없습니다. 예를 들어 172.16.0.0/10은 RFC 1918 및 공개 IP 주소와 겹치기 때문에 유효한 서브넷 범위가 아닙니다.

  • 서브넷 범위는 여러 RFC 범위를 포함할 수 없습니다. 예를 들어 192.0.0.0/8192.168.0.0/16(RFC 1918) 및 192.0.0.0/24(RFC 6890)를 모두 포함하기 때문에 유효한 서브넷 범위가 아닙니다. 하지만 192.0.0.0/16192.0.0.0/24가 각각 포함된 서로 다른 기본 범위를 포함하는 서브넷 2개를 만들 수 있습니다. 또는 둘 중 하나를 보조 범위로 만들 경우 동일 서브넷에서 두 범위를 모두 사용할 수 있습니다.

RFC 1918 제한 외부 범위

RFC 1918 범위 외부의 서브넷 범위를 선택할 때는 다음 제한 사항을 고려하세요.

  • Cloud DNS에는 비RFC 1918 IP 범위를 사용하는 서브넷 제한이 포함됩니다. 자세한 내용은 Cloud DNS 문서를 참조하세요.

제한된 범위

다음 표에 설명된 대로 제한된 범위에는 Google 공개 IP 주소 및 일반적으로 예약되는 RFC 범위가 포함됩니다. 이러한 범위는 서브넷 범위로 사용될 수 없습니다.

범위 설명
Google Cloud 넷블록을 포함한 Google API 및 서비스용 공개 IP 주소 이 IP 주소는 http://gstatic.com/ipranges/goog.txt에서 찾을 수 있습니다.
199.36.153.4/30199.36.153.8/30 비공개 Google 액세스 특정 가상 IP 주소
0.0.0.0/8 현재(로컬) 네트워크 RFC 1122
127.0.0.0/8 로컬 호스트 RFC 1122
169.254.0.0/16 링크-로컬 RFC 3927
224.0.0.0/4 멀티캐스트 RFC 5771
255.255.255.255/32 제한된 브로드캐스트 대상 주소 RFC 8190RFC 919

서브넷의 예약된 IP 주소

모든 서브넷은 기본 IP 범위에 4개의 예약된 IP 주소가 있습니다. 보조 IP 범위에는 예약된 IP 주소가 없습니다.

예약된 IP 주소 설명 예시
네트워크 서브넷의 기본 IP 범위에서 첫 번째 주소 10.1.2.0/2410.1.2.0
기본 게이트웨이 서브넷의 기본 IP 범위에서 두 번째 주소 10.1.2.0/2410.1.2.1
끝에서 두 번째 주소 나중에 사용할 수 있도록 Google Cloud가 예약한 서브넷의 기본 IP 범위에서 끝에서 두 번째 주소 10.1.2.0/2410.1.2.254
브로드캐스트 서브넷의 기본 IP 범위에서 마지막 주소 10.1.2.0/2410.1.2.255

자동 모드 IP 범위

이 표에서는 자동 모드 VPC 네트워크에서 자동으로 만들어진 서브넷의 IP 범위를 확인할 수 있습니다. 이러한 서브넷의 IP 범위는 10.128.0.0/9 CIDR 블록 내에 포함됩니다. 자동 모드 VPC 네트워크는 만들어지는 시점에 리전당 하나의 서브넷으로 구축되며 새 리전에서 자동으로 새 서브넷을 받습니다. 따라서 10.128.0.0/9의 미사용 부분은 이후 Google Cloud에서 사용할 수 있도록 예약됩니다.

리전 IP 범위(CIDR) 기본 게이트웨이 사용 가능한 주소(포함)
asia-east1 10.140.0.0/20 10.140.0.1 10.140.0.2 ~ 10.140.15.253
asia-east2 10.170.0.0/20 10.170.0.1 10.170.0.2 ~ 10.170.15.253
asia-northeast1 10.146.0.0/20 10.146.0.1 10.146.0.2 ~ 10.146.15.253
asia-northeast2 10.174.0.0/20 10.174.0.1 10.174.0.2 ~ 10.174.15.253
asia-northeast3 10.178.0.0/20 10.178.0.1 10.178.0.2 to 10.178.15.253
asia-south1 10.160.0.0/20 10.160.0.1 10.160.0.2 ~ 10.160.15.253
asia-southeast1 10.148.0.0/20 10.148.0.1 10.148.0.2 ~ 10.148.15.253
australia-southeast1 10.152.0.0/20 10.152.0.1 10.152.0.2 ~ 10.152.15.253
europe-north1 10.166.0.0/20 10.166.0.1 10.166.0.2 ~ 10.166.15.253
europe-west1 10.132.0.0/20 10.132.0.1 10.132.0.2 ~ 10.132.15.253
europe-west2 10.154.0.0/20 10.154.0.1 10.154.0.2 ~ 10.154.15.253
europe-west3 10.156.0.0/20 10.156.0.1 10.156.0.2 ~ 10.156.15.253
europe-west4 10.164.0.0/20 10.164.0.1 10.164.0.2 ~ 10.164.15.253
europe-west6 10.172.0.0/20 10.172.0.1 10.172.0.2 ~ 10.172.15.253
northamerica-northeast1 10.162.0.0/20 10.162.0.1 10.162.0.2 ~ 10.162.15.253
southamerica-east1 10.158.0.0/20 10.158.0.1 10.158.0.2 ~ 10.158.15.253
us-central1 10.128.0.0/20 10.128.0.1 10.128.0.2 ~ 10.128.15.253
us-east1 10.142.0.0/20 10.142.0.1 10.142.0.2 ~ 10.142.15.253
us-east4 10.150.0.0/20 10.150.0.1 10.150.0.2 ~ 10.150.15.253
us-west1 10.138.0.0/20 10.138.0.1 10.138.0.2 ~ 10.138.15.253
us-west2 10.168.0.0/20 10.168.0.1 10.168.0.2 ~ 10.168.15.253
us-west3 10.180.0.0/20 10.180.0.1 10.180.0.2 ~ 10.180.15.253
us-west4 10.182.0.0/20 10.182.0.1 10.182.0.2 ~ 10.182.15.253

경로 및 방화벽 규칙

경로

경로란 인스턴스에서 나가는 패킷(이그레스 트래픽)의 경로를 나타냅니다. Google Cloud의 경로는 시스템 생성 경로와 커스텀 경로라는 두 가지 카테고리로 나뉩니다.

모든 새로운 네트워크는 두 가지 유형의 시스템 생성 경로로 시작합니다.

  • 기본 경로는 트래픽이 VPC 네트워크에서 나가는 경로를 정의합니다. 이 경로는 인터넷 액세스 요구사항을 충족하는 VM에 일반적인 인터넷 액세스 기능을 제공합니다. 또한 비공개 Google 액세스의 일반적인 경로도 제공합니다.

  • 서브넷과 연결된 각 IP 범위에 대해 서브넷 경로가 하나씩 생성됩니다. 모든 서브넷에는 기본 IP 범위에 대한 서브넷 경로가 하나 이상 있으며, 서브넷에 보조 IP 범위를 추가하면 서브넷에 대한 추가 서브넷 경로가 생성됩니다. 서브넷 경로는 트래픽이 서브넷을 사용하는 VM에 도달하는 경로를 정의합니다. 서브넷 경로는 수동으로 삭제할 수 없습니다.

커스텀 경로는 직접 만든 정적 경로 또는 하나 이상의 Cloud Router에서 자동으로 관리하는 동적 경로입니다. 자세한 내용은 커스텀 경로를 참조하세요.

Google Cloud의 라우팅에 대한 자세한 내용은 경로 개요를 참조하세요.

동적 라우팅 모드

각 VPC 네트워크에는 연결된 동적 라우팅 모드가 있으며, 이 모드는 모든 Cloud Router의 동작을 제어합니다. Cloud Router는 VPC 네트워크로 가는 경로를 공유하고, 사용자가 Cloud VPN 터널(동적 라우팅 사용), Dedicated Interconnect 또는 Partner Interconnect를 사용하여 VPC 네트워크를 다른 네트워크에 연결할 때 연결된 네트워크에서 커스텀 동적 경로를 학습합니다.

  • 리전별 동적 라우팅은 기본값입니다. 이 모드에서 VPC 네트워크의 지정된 Cloud Router에 의해 학습된 온프레미스 리소스 경로는 Cloud Router와 동일한 리전의 서브넷에만 적용됩니다. 커스텀 공지로 수정하지 않는 한, 각 Cloud Router는 리전의 서브넷 경로를 온프레미스 대응 라우터와만 공유합니다.

  • 전역 동적 라우팅은 네트워크의 모든 Cloud Router의 동작을 변경하여 온프레미스 리소스로 연결되는 학습된 경로를 리전에 관계없이 VPC 네트워크의 모든 서브넷에서 사용할 수 있도록 합니다. 커스텀 공지로 수정하지 않는 한, 각 Cloud Router는 VPC 네트워크의 모든 서브넷 경로를 온프레미스 대응 라우터와 공유합니다.

Cloud Router가 공유하는 경로 집합을 커스텀할 수 있는 방법은 커스텀 공지를 참조하세요.

동적 라우팅 모드는 VPC 네트워크를 만들거나 수정할 때 설정할 수 있습니다. 동적 라우팅 모드를 리전에서 전역으로, 또는 그 반대로 제한 없이 변경할 수 있습니다. 자세한 내용은 동적 라우팅 모드 변경을 참조하세요.

방화벽 규칙

방화벽 규칙은 네트워크에서 나가는(이그레스) 트래픽과 들어오는(인그레스) 트래픽 모두에 적용됩니다. 방화벽 규칙은 VM 인스턴스 간의 통신을 포함하여 전적으로 네트워크 내에서 이루어지는 트래픽도 제어합니다.

모든 VPC 네트워크에는 두 가지 묵시적인 방화벽 규칙이 있습니다. 하나는 모든 이그레스 트래픽을 허용하는 묵시적 규칙이고, 다른 하나는 모든 인그레스 트래픽을 거부하는 묵시적 규칙입니다. 묵시적 규칙은 삭제할 수는 없지만 직접 재정의할 수는 있습니다. Google Cloud는 방화벽 규칙에 관계없이 항상 일부 트래픽을 차단합니다. 자세한 내용은 차단된 트래픽을 참조하세요.

어떤 방화벽 규칙이 특정 연결을 허용하거나 거부하는지를 모니터링하려면 방화벽 규칙 로깅을 참조하세요.

커뮤니케이션 및 액세스

네트워크 내 통신

시스템 생성 서브넷 경로는 내부(비공개) IP 주소를 사용하여 네트워크 내의 인스턴스 간에 트래픽을 전송하기 위한 경로를 정의합니다. 모든 네트워크에는 인그레스 트래픽에 적용되는 묵시적 거부 방화벽 규칙이 있으므로 인스턴스 간 통신을 위해서는 적절한 방화벽 규칙도 구성해야 합니다.

기본 네트워크를 제외하고 인스턴스 간 통신을 허용하려면 우선순위가 더 높은 인그레스 방화벽 규칙을 명시적으로 만들어야 합니다. 기본 네트워크에는 네트워크 내에서 인스턴스 간 통신을 허용하는 default-allow-internal 규칙을 포함하여 묵시적 규칙 외에도 여러 가지 방화벽 규칙이 포함되어 있습니다. 기본 네트워크에는 RDP 및 SSH와 같은 프로토콜을 허용하는 인그레스 규칙도 있습니다.

기본 네트워크에 제공되는 규칙은 Cloud Console을 사용하여 만드는 새 자동 모드 VPC 네트워크에 적용할 수 있는 옵션으로도 제공됩니다.

인터넷 액세스 요구사항

인스턴스에서 발신 인터넷 액세스 권한을 가지려면 다음 기준을 충족해야 합니다.

  • 네트워크에 대상 IP 범위가 최대한 포괄적인(0.0.0.0/0) 유효한 커스텀 경로나 기본 인터넷 게이트웨이 경로가 있어야 합니다. 이 경로는 인터넷 경로를 정의합니다. 자세한 내용은 경로를 참조하세요.

  • 방화벽 규칙이 인스턴스의 이그레스 트래픽을 허용해야 합니다. 우선순위가 더 높은 규칙에 의해 재정의되지 않는 한 이그레스 트래픽에 적용되는 묵시적 허용 규칙은 모든 인스턴스에서 발신되는 트래픽을 허용합니다.

  • 다음 중 하나에 해당해야 합니다.

    • 인스턴스에 외부 IP 주소가 있어야 합니다. 인스턴스를 만들 때 또는 인스턴스를 만든 후 인스턴스에 외부 IP 주소를 할당할 수 있습니다.

    • 인스턴스는 정적 0.0.0.0/0 경로의 대상인 Cloud NAT 또는 인스턴스 기반 프록시를 사용할 수 있어야 합니다.

App Engine용 통신 및 액세스

VPC 방화벽 규칙은 Compute Engine VM과 같이 VPC 네트워크에서 실행하는 리소스에 적용됩니다. App Engine 인스턴스의 경우 방화벽 규칙은 다음과 같이 작동합니다.

  • App Engine 표준 환경: App Engine 방화벽 규칙만 인그레스 트래픽에 적용됩니다. App Engine 표준 환경 인스턴스는 VPC 네트워크 내에서 실행되지 않으므로 VPC 방화벽 규칙이 적용되지 않습니다.

  • App Engine 가변형 환경: App Engine 및 VPC 방화벽 규칙이 인그레스 트래픽에 적용됩니다. 인바운드 트래픽은 두 유형의 방화벽 규칙 모두에서 허용되는 경우에만 허용됩니다. 아웃바운드 트래픽의 경우 VPC 방화벽 규칙이 적용됩니다.

App Engine 인스턴스에 대한 액세스를 제어하는 방법에 대한 자세한 내용은 앱 보안을 참조하세요.

외부 IP 주소에 대한 Traceroute

내부적인 이유로 Google Cloud는 Google 네트워크에서 다음 홉을 통과하는 패킷의 TTL 카운터를 증가시킵니다. 일부 홉에서는 TTL이 만료되지 않으므로 traceroutemtr 같은 도구에서 불완전한 결과를 제공할 수 있습니다. 다음과 같은 경우 Google 네트워크 내부와 외부에 있는 홉이 숨겨질 수 있습니다.

  • Compute Engine 인스턴스에서 다른 Google Cloud 리소스의 외부 IP 주소나 인터넷의 목적지를 포함한 외부 IP 주소로 패킷을 보낼 때

  • Compute Engine 인스턴스 또는 다른 Google Cloud 리소스와 연결된 외부 IP 주소로 패킷을 보낼 때

숨겨진 홉 수는 인스턴스의 네트워크 서비스 등급, 리전, 기타 요인에 따라 다릅니다. 몇 개의 홉만 있는 경우에는 모두 숨겨져 있을 수 있습니다. traceroute 또는 mtr 결과에서 홉이 누락되었다고 아웃바운드 트래픽이 삭제된 것은 아닙니다.

이 동작에 대한 해결 방법은 없습니다. VM과 연결된 외부 IP 주소에 연결되는 타사 모니터링을 구성하는 경우 이 점을 고려해야 합니다.

이그레스 처리량 한도

네트워크 처리량 정보는 네트워크 대역폭 섹션에서 확인할 수 있습니다.

VPC 네트워크 예시

다음 예시에서는 두 리전에 3개의 서브넷이 있는 커스텀 모드 VPC 네트워크를 보여줍니다.

VPC 네트워크 예시(확대하려면 클릭)
VPC 네트워크 예시(확대하려면 클릭)
  • Subnet1은 us-west1 리전에서 10.240.0.0/24로 정의됩니다.
    • us-west1-a 영역의 두 개 VM 인스턴스가 이 서브넷에 있습니다. 두 개의 IP 주소는 모두 subnet1의 가용 주소 범위에 속합니다.
  • Subnet2는 us-east1 리전에서 192.168.1.0/24로 정의됩니다.
    • us-east1-a 영역의 두 개 VM 인스턴스가 이 서브넷에 있습니다. 두 개의 IP 주소는 모두 subnet2의 가용 주소 범위에 속합니다.
  • Subnet3도 us-east1 리전에서 10.2.0.0/16으로 정의됩니다.
    • us-east1-a 영역의 VM 인스턴스 하나와 us-east1-b 영역의 두 번째 인스턴스는 각각 subnet3에 있으며 사용 가능한 범위에서 IP 주소를 수신합니다. 서브넷은 리전 리소스이므로 인스턴스는 네트워크 인터페이스가 각자의 영역이 포함된 동일한 리전의 서브넷과 연결되도록 할 수 있습니다.

네트워크 성능

지연 시간

Google Cloud 네트워크에서 측정된 리전 간 지연 시간은 라이브 대시보드에서 확인할 수 있습니다. 대시보드는 PerfKit Benchmarker를 사용하여 이러한 결과를 재현하기 위해 Google Cloud의 리전 간 지연 시간 중앙값과 처리량 성능 측정항목 및 방법론을 보여줍니다.

Google Cloud는 일반적으로 50번째 백분위수에서 55μs 미만의 왕복 지연 시간과 동일한 영역에 있는 c2-standard-4 VM 인스턴스 간의 99번째 백분위수에서 80μs 미만의 꼬리 지연 시간을 측정합니다.

Google Cloud는 일반적으로 50번째 백분위수에서 45μs 미만의 왕복 지연 시간과 지연 시간이 짧은 동일한 네트워크에 있는 c2-standard-4 VM 인스턴스 간의 99번째 백분위수에서 60μs 미만의 꼬리 지연 시간을 측정합니다('압축' 배치 정책). 압축 배치 정책은 VM이 지연 시간이 짧은 동일한 네트워크 내에 실제로 위치하도록 하여 네트워크 지연 시간을 줄여줍니다.

방법론: 영역 내 지연 시간은 모든 영역 c2 인스턴스에서 한 쌍의 c2-type VM 간에 netperf TCP_RR 벤치마크를 지속적으로 실행하는 블랙박스 프로버를 통해 모니터링됩니다. 압축 배치 정책을 사용하거나 사용하지 않고 설정할 수 있도록 P50 및 P99 결과를 수집합니다. TCP_RR 벤치마크는 트랜잭션 요율을 측정하여 요청/응답 성능을 측정합니다. 애플리케이션에 가능한 최대 지연 시간이 필요한 경우 c2 인스턴스를 사용하는 것이 좋습니다.

패킷 손실

Google Cloud는 모든 리전 간 왕복 손실을 주기적으로 측정하여 리전 간 패킷 손실을 추적합니다. Google은 이러한 측정의 글로벌 평균을 0.01% 미만으로 설정합니다.

방법론: 블랙박스 VM-VM 프로브는 핑을 사용하여 모든 영역 쌍의 패킷 손실을 모니터링하고 결과를 하나의 전역 손실 측정항목으로 집계합니다. 이 측정항목은 1일 기간으로 추적됩니다.

다음 단계