VPC 네트워크 개요

Virtual Private Cloud(VPC) 네트워크는 Andromeda를 사용하여 Google의 프로덕션 네트워크 내에서 구현되는 물리적 네트워크의 가상 버전입니다. VPC 네트워크는 다음을 제공합니다.

  • Compute Engine 가상 머신(VM) 인스턴스에 대한 연결을 제공하며 여기에는 Google Kubernetes Engine(GKE) 클러스터, App Engine 가변형 환경 인스턴스 및 Compute Engine VM에 내장된 기타 Google Cloud 제품이 포함됩니다.
  • 내부 HTTP(S) 부하 분산을 위한 기본 내부 TCP/UDP 부하 분산 및 프록시 시스템을 제공합니다.
  • Cloud VPN 터널 및 Cloud Interconnect 연결을 사용하여 온프레미스 네트워크에 연결합니다.
  • Google Cloud 외부 부하 분산기에서 백엔드로 트래픽을 배포합니다.

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

네트워크 및 서브넷

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

서브넷은 (VPC) 네트워크와 같지 않습니다. 네트워크와 서브넷은 Google Cloud에서 서로 다른 유형의 리소스입니다.

서브넷에 대한 자세한 내용은 서브넷 개요를 참조하세요.

사양

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

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

  • 서브넷은 리전 리소스입니다.

  • 각 서브넷은 IPv4 주소 범위를 정의합니다. 커스텀 모드 VPC 네트워크의 서브넷에는 IPv6 주소 범위도 포함될 수 있습니다.

  • 인스턴스에서 송수신되는 트래픽은 네트워크 방화벽 규칙으로 제어할 수 있습니다. 규칙은 VM 자체에서 구현되므로 VM에서 나가거나 도착할 때만 트래픽을 제어하고 로깅할 수 있습니다.

  • VPC 네트워크 내 리소스는 내부 IPv4 주소, 내부 IPv6 주소 또는 외부 IPv6 주소를 사용하여 서로 통신할 수 있으며 해당 네트워크 방화벽 규칙이 적용됩니다. 자세한 내용은 네트워크 내 통신을 참조하세요.

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

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

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

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

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

  • VPC 네트워크는 Cloud VPN 및 Cloud Interconnect의 트래픽을 포함하여 GRE 트래픽을 지원합니다. VPC 네트워크는 부하 분산프로토콜 전달을 위한 전달 규칙 또는 Cloud NAT를 위한 GRE를 지원하지 않습니다. GRE 지원을 이용하면 인터넷(외부 IP 주소) 및 Cloud VPN 또는 Cloud Interconnect(내부 IP 주소)로부터 VM에서 GRE 트래픽을 종료할 수 있습니다. 그런 다음 캡슐화 해제된 트래픽을 연결 가능한 대상으로 전달할 수 있습니다. GRE를 통해 SASE(Secure Access Service Edge) 및 SD-WAN과 같은 서비스를 사용할 수 있습니다.

  • VPC 네트워크에서는 IPv4 및 IPv6 유니캐스트 주소를 지원합니다. VPC 네트워크에서는 네트워크 브로드캐스트 주소나 멀티캐스트 주소를 지원하지 않습니다.

    IPv6에 대한 자세한 내용은 서브넷 개요를 참조하세요.

조직 정책 제약조건

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

  • 조직 정책을 사용하여 다음 IPv6 구성을 제어할 수 있습니다.

    • VPC 외부 IPv6 사용 중지: true로 설정하면 constraints/compute.disableVpcExternalIpv6 제약조건으로 인해 외부 IPv6 범위가 있는 이중 스택 서브넷을 구성할 수 없습니다.

    • VPC 내부 IPv6 사용 중지: true로 설정하면 constraints/compute.disableVpcInternalIpv6 제약조건으로 인해 내부 IPv6 범위가 있는 이중 스택 서브넷을 구성할 수 없습니다.

    • 모든 IPv6 사용 중지: true로 설정하면 constraints/compute.disableAllIpv6 제약조건은 IPv6 사용과 관련된 리소스 생성이나 업데이트를 중지합니다.

제약조건에 대한 자세한 내용은 조직 정책 제약조건을 참조하세요.

서브넷 생성 모드

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

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

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

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

기본 네트워크

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

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

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

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

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

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

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

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

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

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

  • IPv6 범위가 있는 서브넷을 만들려고 합니다. 자동 모드 VPC 네트워크에서는 이중 스택 서브넷을 지원하지 않습니다.

IPv4 서브넷 범위

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

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

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

커스텀 모드 VPC 네트워크에서 서브넷을 만들 때 사용할 IPv4 범위를 선택합니다. 자세한 내용은 유효한 범위, 제한된 서브넷 범위, 서브넷 작업을 참조하세요.

모든 기본 IPv4 서브넷 범위에는 사용할 수 없는 IP 주소 4개가 있습니다. 자세한 내용은 서브넷에 예약된 IP 주소를 참조하세요.

자동 모드 VPC 네트워크는 생성 시점에 리전당 서브넷 하나로 생성되며 자동으로 새 리전에서 새 서브넷을 받습니다. 서브넷에는 IPv4 범위만 있으며 모든 서브넷 범위는 10.128.0.0/9 CIDR 블록 내에 포함됩니다. 따라서 10.128.0.0/9의 미사용 부분은 이후 Google Cloud에서 사용할 수 있도록 예약됩니다. 어떤 리전에서 어떤 IPv4 범위를 사용하는지에 대한 자세한 내용은 자동 모드 IPv4 서브넷 범위를 참조하세요.

IPv6 서브넷 범위

커스텀 모드 VPC 네트워크에서 이중 스택 서브넷을 만들 때 서브넷이 내부 IPv6 서브넷 범위로 구성되는지 아니면 외부 IPv6 서브넷 범위로 구성되는지 여부를 선택합니다.

  • 내부 IPv6 서브넷 범위는 고유한 로컬 주소(ULA)를 사용합니다.

    • ULA는 VPC 네트워크 내 VM 간 통신에 사용됩니다. IPv6의 ULA는 IPv4의 RFC 1918 주소와 유사합니다. ULA는 인터넷에서 연결될 수 없으며 공개적으로 라우팅될 수 없습니다.
  • 외부 IPv6 서브넷 범위는 전역 유니캐스트 주소(GUA)를 사용합니다.

    • GUA는 VPC 네트워크 내에서 VM 간 통신에 사용될 수 있으며 인터넷에서 라우팅될 수도 있습니다.

IPv6 서브넷 범위에 대한 자세한 내용은 서브넷 개요를 참조하세요.

이중 스택 서브넷을 지원하는 네트워크

커스텀 모드 VPC 네트워크에서 이중 스택 서브넷을 만들 수 있습니다.

이중 스택 서브넷은 기본 네트워크를 포함하여 자동 모드 VPC 네트워크에서 지원되지 않습니다. 레거시 네트워크에서는 이중 스택 서브넷이 지원되지 않습니다.

이중 스택 서브넷을 추가할 자동 모드 VPC 네트워크가 있으면 다음을 수행할 수 있습니다.

  1. 자동 모드 네트워크를 커스텀 모드로 변환

  2. 새 이중 스택 서브넷을 만들거나 기존 서브넷을 이중 스택으로 변환합니다.

경로 및 방화벽 규칙

경로

경로란 인스턴스에서 나가는 패킷(송신 트래픽)의 경로를 나타냅니다. Google Cloud 경로 유형에 대한 자세한 내용은 경로 개요를 참조하세요.

동적 라우팅 모드

각 VPC 네트워크에는 연결된 동적 라우팅 모드가 있으며, 이 모드는 모든 Cloud Router의 동작을 제어합니다. Cloud Router는 Google Cloud 연결 제품의 BGP 세션을 관리합니다.

동적 라우팅 모드 옵션에 대한 설명은 Cloud Router 문서의 동적 라우팅 모드의 영향을 참조하세요.

경로 공지 및 내부 IP 주소

다음 IP 주소는 VPC 네트워크 내에서 공지됩니다.

VPC 네트워크 피어링을 사용하여 VPC 네트워크를 연결하면 비공개 IPv4 주소를 사용하는 서브넷 범위가 항상 교환됩니다. 비공개로 사용되는 공개 IPv4 주소를 사용하는 서브넷 범위를 교환할지 여부를 제어할 수 있습니다. 전역 내부 IPv4 주소는 피어링을 통해 교환되지 않습니다. 자세한 내용은 VPC 네트워크 피어링 문서를 참조하세요.

Cloud VPN, Cloud Interconnect, 또는 Router 어플라이언스와 같은 Google Cloud 연결 제품을 사용하여 VPC 네트워크를 온프레미스 네트워크와 같은 다른 네트워크에 연결하는 경우:

  • VPC 네트워크의 내부 IP 주소를 다른 네트워크(예: 온프레미스 네트워크)에 공지할 수 있습니다.
  • VPC 네트워크와 다른 네트워크(예: 온프레미스 네트워크) 간의 연결은 Google Cloud 연결 제품에서 제공하는 비공개 라우팅을 사용할 수 있지만 다른 네트워크의 IP 주소도 공개적으로 라우팅할 수 있습니다. 온프레미스 네트워크에서 공개적으로 라우팅 가능한 IP 주소를 사용하는 경우 이 점을 염두에 두어야 합니다.
  • 비공개로 사용되는 공개 IP 주소가 있는 서브넷 범위가 포함된 VPC 네트워크의 VM 인스턴스는 동일한 공개 IP 주소를 사용하는 외부 리소스에 연결할 수 없습니다.
  • 비공개로 사용되는 공개 IP 주소를 온프레미스 네트워크 등의 다른 네트워크에 공지할 때, 특히 다른 네트워크가 공개 IP 주소를 인터넷에 공지할 때 특히 주의하세요.

방화벽 규칙

계층식 방화벽 정책VPC 방화벽 규칙은 VM 인스턴스(및 Google Kubernetes Engine 노드와 같이 VM에 의존하는 리소스)와 주고받는 패킷에 적용됩니다. 두 가지 방화벽 유형 모두 같은 VPC 네트워크의 VM 사이에 있더라도 트래픽을 제어합니다.

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

커뮤니케이션 및 액세스

네트워크 내 통신

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

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

기본 네트워크에 제공되는 규칙은 콘솔을 사용하여 만드는 새 자동 모드 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 같은 도구에서 불완전한 결과를 제공할 수 있습니다. Compute Engine 인스턴스에서 인터넷의 대상으로 패킷을 전송할 때 Google 네트워크 내부의 홉이 숨겨질 수 있습니다.

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

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

이그레스 처리량 한도

네트워크 처리량 정보는 Compute Engine 문서의 네트워크 대역폭 페이지에서 확인할 수 있습니다.

패킷 크기

패킷 크기에 대한 정보는 최대 전송 단위 개요에 있습니다.

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 주소를 수신합니다. 서브넷은 리전 리소스이므로 인스턴스는 네트워크 인터페이스가 각자의 영역이 포함된 동일한 리전의 서브넷과 연결되도록 할 수 있습니다.

최대 전송 단위

VPC 네트워크와 연결된 VM의 최대 전송 단위(MTU) 설정에 대한 자세한 내용은 최대 전송 단위 개요를 참조하세요.

VPC 네트워크의 MTU 변경이나 MTU 설정이 다른 VPC 네트워크 간에 VM 마이그레이션은 VPC 네트워크의 MTU 설정 변경을 참조하세요.

네트워크 성능

지연 시간

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일 기간으로 추적됩니다.

다음 단계

직접 사용해 보기

Google Cloud를 처음 사용하는 경우 계정을 만들어 실제 시나리오에서 VPC의 성능을 평가할 수 있습니다. 신규 고객에게는 워크로드를 실행, 테스트, 배포할 수 있는 무료 크레딧 $300가 제공됩니다.

VPC 무료로 사용해 보기