VPC ネットワーク

Virtual Private Cloud（VPC）ネットワークは、Andromeda を使用して Google の本番環境ネットワーク内に実装された物理ネットワークを仮想化したネットワークです。

VPC ネットワークは次のことを行います。

  • Compute Engine 仮想マシン（VM）インスタンス向けの接続を提供します。
  • ネイティブの内部パススルー ネットワーク ロードバランサと内部アプリケーション ロードバランサ用のプロキシ システムを提供します。
  • Cloud VPN トンネルと、Cloud Interconnect 用の VLAN アタッチメントを使用して、オンプレミス ネットワークに接続します。
  • Google Cloud の外部ロードバランサからバックエンドにトラフィックを分散します。

プロジェクトには複数の VPC ネットワークを設定できます。この設定を禁止する組織のポリシーを作成しない限り、新しいプロジェクトは、各リージョンに 1 つのサブネットワーク（サブネット）を持つデフォルトネットワーク（自動モード VPC ネットワーク）が設定された状態で開始されます。

ネットワークとサブネット

サブネットとサブネットワークという用語は同義語です。Google Cloud コンソール、gcloud コマンド、API ドキュメントでは同じ意味で使用されます。

サブネットは（VPC）ネットワークと同じではありません。Google Cloud では、ネットワークとサブネットは異なる種類のリソースです。

詳細については、サブネットをご覧ください。

仮想マシン インスタンス

Compute Engine 仮想マシン（VM）インスタンスは、Google のインフラストラクチャでホストされる仮想マシンです。Compute Engine インスタンス、VM インスタンス、VM は同じことを指す用語であり、Google Cloud コンソール、Google Cloud CLI リファレンス、API ドキュメントでは同じ意味で使用されます。

VM インスタンスには、Google Kubernetes Engine（GKE）クラスタ、App Engine フレキシブル環境インスタンス、Compute Engine VM 上に構築された他の Google Cloud プロダクトが含まれます。

詳細については、Compute Engine ドキュメントの仮想マシン インスタンスをご覧ください。

仕様

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 ネットワークを接続できます。

  • ハイブリッド環境の VPC ネットワークは、Cloud VPN または Cloud Interconnect を使用して安全に接続できます。

  • VPC ネットワークは GRE トラフィックをサポートします。これには、Cloud VPN と Cloud Interconnect 上のトラフィックも含まれます。VPC ネットワークでは、Cloud NAT で GRE がサポートされていません。また、ロード バランシングとプロトコル転送で転送ルールはサポートされません。GRE のサポートにより、インターネット（外部 IP アドレス）と Cloud VPN または Cloud Interconnect（内部 IP アドレス）から VM への GRE トラフィックを終了できます。カプセル化解除されたトラフィックは到達可能な宛先に転送できます。GRE を使用すると、セキュア アクセス サービスエッジ（SASE）や SD-WAN などのサービスを使用できます。

  • VPC ネットワークは、IPv4 と IPv6 のユニキャスト アドレスをサポートしています。VPC ネットワークは、ネットワーク内のブロードキャスト アドレスまたはマルチキャスト アドレスをサポートしません。

    IPv6 サブネット範囲の詳細については、サブネットをご覧ください。

VPC ネットワークの例

次の例では、2 つのリージョンに 3 つのサブネットがあるカスタムモード VPC ネットワークを示します。

VPC ネットワークの例。
VPC ネットワークの例（クリックして拡大）
  • subnet1 は、us-west1 リージョンで 10.240.0.0/24 として定義されています。
    • us-west1-a ゾーン内の 2 つの VM インスタンスはこのサブネットにあります。これらの IP アドレスは、subnet1 の使用可能なアドレス範囲から取得されます。
  • subnet2 は、us-east1 リージョンで 192.168.1.0/24 として定義されています。
    • us-east1-b ゾーン内の 2 つの VM インスタンスはこのサブネットにあります。これらの IP アドレスは、subnet2 の使用可能なアドレス範囲から取得されます。
  • subnet3 は、us-east1 リージョンで 10.2.0.0/16 として定義されています。
    • us-east1-b ゾーンの 1 つの VM インスタンスと us-east1-c ゾーンの 2 つ目のインスタンスは、subnet3 にあり、それぞれが使用可能な範囲から IP アドレスを受け取ります。サブネットはリージョン リソースであるため、インスタンスは、ゾーンを含む同じリージョンのサブネットに関連するネットワーク インターフェースを持つことができます。

組織ポリシーの制約

  • 新しいプロジェクトは、デフォルトの 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 では、サブネット作成モードで決定される 2 種類の VPC ネットワークを提供します。

  • 自動モード VPC ネットワークを作成すると、各リージョンから 1 つのサブネットがネットワーク内に自動的に作成されます。このような自動作成されたサブネットでは、一連の事前定義された IPv4 範囲（10.128.0.0/9 CIDR ブロック）が使用されます。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 ネットワークが推奨される、または必須とされるユースケースを示しています。

  • 各リージョンに 1 つのサブネットを自動的に作成する必要がない場合

  • 新しいリージョンが利用可能になるときに新しいサブネットを自動的に作成すると、手動で作成したサブネットや静的ルートによって使用される IP アドレスと重複したり、ネットワーク計画全体に影響したりする可能性がある場合

  • 使用するリージョンや IP アドレス範囲など、VPC ネットワーク内で作成されるサブネットを完全に制御する必要がある場合

  • VPC ネットワークを別のネットワークに接続する予定がある場合:

    • すべての自動モードの VPC ネットワークのサブネットは事前定義の同じ IP アドレス範囲を使用するため、VPC ネットワーク ピアリングまたは Cloud VPN を使用して自動モードの VPC ネットワークを相互に接続できません。

    • 自動モードの 10.128.0.0/9 CIDR 範囲は、一般的に使用される RFC 1918 アドレス空間の一部であるため、Google Cloud の外部のネットワークでは、重複する CIDR 範囲が使用される可能性があります。

  • IPv6 範囲のサブネットを作成する必要がある場合。自動モードの VPC ネットワークはデュアル スタックのサブネットをサポートしていません。

IPv4 サブネット範囲

各サブネットには、プライマリ IPv4 アドレス範囲があります。VM インスタンス、内部ロードバランサ、内部プロトコル転送の各リソースのプライマリ内部アドレスは、サブネットのプライマリ範囲から取得されます。必要に応じて、エイリアス IP 範囲でのみ使用されるセカンダリ IP アドレス範囲をサブネットに追加します。ただし、インスタンスのエイリアス IP 範囲は、サブネットのプライマリ範囲またはセカンダリ範囲のいずれでも構成できます。

VPC ネットワーク内のすべてのサブネットの各プライマリまたはセカンダリ IPv4 範囲は、一意の有効な CIDR ブロックである必要があります。定義できるセカンダリ IP 範囲の数については、ネットワークごとの上限をご覧ください。

IPv4 サブネットが、事前定義された連続した CIDR ブロックを形成する必要はありませんが、必要に応じて連続させることができます。たとえば、自動モード VPC ネットワークでは事前定義された自動モード IP 範囲に収まるサブネットが作成されます。

カスタムモード VPC ネットワークでサブネットを作成するときに、使用する IPv4 範囲を選択します。詳細については、有効な範囲、禁止されたサブネット範囲、IPv4 サブネット範囲の制限をご覧ください。

すべてのプライマリ IPv4 サブネット範囲には 4 つの使用できない IP アドレスがあります。詳細については、IPv4 サブネット範囲で使用できないアドレスをご覧ください。

自動モード VPC ネットワークはリージョンごとに 1 つのサブネットで作成され、新しいリージョンで新しいサブネットを自動的に受信します。サブネットには 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 アドレス

VPC ネットワーク内では次の IP アドレスがアドバタイズされます。

VPC ネットワーク ピアリングを使用して VPC ネットワークを接続すると、プライベート IPv4 アドレスを使用するサブネット範囲が常に交換されます。プライベートで使用されるパブリック IPv4 アドレスを使用してサブネット範囲を交換するかどうかを制御できます。グローバル内部 IPv4 アドレスがピアリングで交換されることはありません。詳細については、VPC ネットワーク ピアリングのドキュメントをご覧ください。

Cloud VPN、Cloud Interconnect、ルーター アプライアンスなどの Google Cloud 接続プロダクトを使用して、VPC ネットワークを別のネットワーク（オンプレミス ネットワークなど）に接続する場合:

  • VPC ネットワークの内部 IP アドレスを別のネットワーク（オンプレミス ネットワークなど）にアドバタイズできます。
  • VPC ネットワークと別のネットワーク（オンプレミス ネットワークなど）間の接続では、Google Cloud 接続プロダクトによって提供されるプライベート ルーティングを使用できますが、他のネットワークの IP アドレスは一般公開されたルーティングが可能です。オンプレミス ネットワークで一般公開されたルーティングが可能な IP アドレスを使用する場合は、この点に注意してください。
  • VPC ネットワーク内で、プライベートで使用されるパブリック IP アドレスを含むサブネット範囲の VM インスタンスは、同じパブリック IP アドレスを使用する外部リソースに接続できません。
  • プライベートで使用されるパブリック IP アドレスを別のネットワーク（オンプレミス ネットワークなど）にアドバタイズする場合は慎重に行ってください。特に、他のネットワークがパブリック IP アドレスをインターネットにアドバタイズできる場合は注意が必要です。

ファイアウォール ルール

階層型ファイアウォール ポリシーと VPC ファイアウォール ルールは、VM インスタンスや VM に依存するリソース（Google Kubernetes Engine ノードなど）間で送受信されるパケットに適用されます。同じ VPC ネットワーク内の VM 間であっても、両方のタイプのファイアウォールでトラフィックが制御されます。

どのファイアウォール ルールが特定の接続を許可または拒否したかを確認するには、ファイアウォール ルールのロギングをご覧ください。

通信とアクセス

ネットワーク内の通信

システム生成のサブネット ルートは、内部 IP アドレスを使用して、ネットワーク内のインスタンス間でトラフィックを送信するためのパスを定義します。どのネットワークにも上り（内向き）トラフィックに対する暗黙の拒否ファイアウォール ルールが構成されているため、インスタンス間で通信を行う場合は、適切なファイアウォール ルールを構成する必要があります。

デフォルト ネットワークを除いて、インスタンスが相互に通信できるように、優先度がより高い上り（内向き）ファイアウォール ルールを明示的に作成する必要があります。デフォルト ネットワークには、暗黙的なルールに加えて、ネットワーク内でのインスタンス間の通信を許可する default-allow-internal ルールなど複数のファイアウォール ルールが含まれています。また、RDP や SSH などのプロトコルを許可する上り（内向き）ルールも含まれています。

デフォルト ネットワークに含まれるルールは、Google Cloud コンソールを使用して作成する新しい自動モード VPC ネットワークに適用するためのオプションとしても表示されます。

インターネット アクセスの要件

インスタンスにインターネットへの送信を許可するには、次の条件を満たす必要があります。

  • ネットワークには、有効なデフォルト インターネット ゲートウェイ ルート、または宛先 IP 範囲が最も一般的なカスタムルート（0.0.0.0/0）が必要です。このルートは、インターネットへのパスを定義します。詳細については、ルートをご覧ください。

  • ファイアウォール ルールでは、インスタンスからの下りトラフィックを許可する必要があります。優先度の高いルールでオーバーライドされない限り、下り（外向き）トラフィックの暗黙的に許可されたルールによって、すべてのインスタンスからの発信トラフィックが許可されます。

  • 以下のいずれかの条件を満たす必要があります。

    • インスタンスに外部 IP アドレスが必要です。外部 IP アドレスは、インスタンスの作成時または作成後にインスタンスに割り当てることができます。

    • インスタンスで、Cloud NAT または静的 0.0.0.0/0 ルートのターゲットであるインスタンス ベースのプロキシを使用できる必要があります。

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 カウンタが増加します。traceroute や mtr などのツールでは、一部のホップで TTL が期限切れにならないため、結果が不完全になることがあります。Compute Engine インスタンスからインターネット上の宛先にパケットを送信すると、Google のネットワーク内に存在するホップが非表示になることがあります。

非表示のホップ数は、インスタンスの Network Service Tiers、リージョンなどの要素によって異なります。ホップ数が少ない場合は、すべて非表示にできます。traceroute または mtr の結果からホップが欠落していても、送信トラフィックが破棄されるわけではありません。

この動作の回避策はありません。VM に関連付けられた外部 IP アドレスに接続するサードパーティのモニタリングを構成する場合は、このことを考慮する必要があります。

下り（外向き）スループットの上限

ネットワーク スループットに関する情報については、Compute Engine ドキュメントのネットワーク帯域幅のページをご覧ください。

パケットサイズ

パケットサイズに関する情報は、最大伝送単位をご覧ください。

最大伝送単位

VPC ネットワークとその接続された VM の最大転送単位（MTU）設定の詳細については、最大伝送単位をご覧ください。

VPC ネットワークの MTU の変更や、MTU 設定が異なる VPC ネットワーク間の VM の移行については、VPC ネットワークの MTU の設定を変更するをご覧ください。

サポートされているプロトコル

Google Cloud では、次のプロトコルと拡張ヘッダーのみがサポートされます。

  • VM 間の IPv4 データパケット: すべての IPv4 プロトコル。
  • VM とインターネット間の IPv4 データパケット: ICMP、IPIP、TCP、UDP、GRE、ESP、AH、SCTP プロトコル。
  • VM 間および VM とインターネット間の IPv6 データパケット: AH、ESP、GRE、ICMP、ICMPv6、IPIP、SCTP、TCP、UDP プロトコル、宛先オプションとフラグメント拡張ヘッダー。ただし、IPv6 データパケットのフラグメント ヘッダーの後に宛先オプション ヘッダーを配置することはできません。
  • プロトコル転送: AH、ESP、GRE、ICMP、ICMPv6、SCTP、TCP、UDP プロトコル

サポートされているプロトコルのデータパケットを許可するには、要件に基づいてファイアウォール ルールまたはプロトコル転送ルールを構成する必要があります。

ネットワーク パフォーマンス

レイテンシ

Google Cloud ネットワークで測定されたリージョン間のレイテンシは、ライブ ダッシュボードで確認できます。ダッシュボードには、Google Cloud のリージョン間レイテンシとスループットのパフォーマンス指標の中央値が表示されます。これらの結果は PerfKit Benchmarker を使用して再現できます。

Google Cloud は通常、同じゾーン内の c2-standard-4 VM インスタンス間では 50 パーセンタイルで 55 マイクロ秒未満の往復のレイテンシを測定し、99 パーセンタイルで 80 マイクロ秒未満のテール レイテンシを測定します。

Google Cloud は通常、同じ低レイテンシ ネットワーク内の c2-standard-4 VM インスタンス間で、50 パーセンタイルで 45 マイクロ秒未満の往復のレイテンシと、99 パーセンタイルで 60 マイクロ秒未満のテール レイテンシを測定します（コンパクト プレースメント ポリシー）。コンパクト プレースメント ポリシーでは、VM が物理的に同じ低レイテンシ ネットワーク内に配置されるため、ネットワーク レイテンシが短縮されます。

手法: ゾーン内レイテンシは、C2 インスタンスが有効なすべてのゾーンの C2 タイプの VM 間で netperf TCP_RR ベンチマークを常に実行するブラックボックス プローバーでモニタリングされます。コンパクト プレースメント ポリシーの有無にかかわらず、P50 と P99 の結果を収集します。TCP_RR ベンチマークは、トランザクション レートを測定してリクエスト / レスポンスのパフォーマンスを測定します。アプリケーションに最適なレイテンシが必要な場合は、C2 インスタンスをおすすめします。

パケットロス

Google Cloud は、すべてのリージョン間での定期的な往復ロスを測定することで、リージョン間のパケットロスを追跡します。Google では、これらの測定値の世界平均を 0.01% 以下にすることを目標としています。

手法: VM 間のブラックボックス プローバーは、ping を使用してすべてのゾーンペアのパケットロスをモニタリングし、その結果を 1 つのグローバルな損失指標に集約します。この指標は 1 日間トラッキングされます。

次のステップ

使ってみる

Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの VPC のパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

VPC 無料トライアル