Google CloudのVPCを徹底解説!(基本編)

記事タイトルとURLをコピーする

G-gen の杉村です。当記事では Google Cloud (旧称 GCP) の Virtual Private Cloud (VPC) について徹底解説します。なお当記事は VPC の基本機能に絞った 基本編 であり 応用編 も続けてご確認ください。

Virtual Private Cloud (VPC)

Virtual Private Cloud (VPC) とは

Virtual Private Cloud (VPC) とは Google Cloud に仮想ネットワークを構築するためのサービスです。構築された VPC は他の Google Cloud 利用者からは完全に独立したプライベートネットワークとなります。

VPC は サブネット と呼ばれる小分けしたネットワークに分割され、サブネットにはプライベート IP アドレス帯が割り当てられます。サブネット内には Compute Engine の仮想マシン (VM) を配置したり、 Google Kubernetes Engine (GKE) のクラスタを配置したり、 App Engine (Flexible) のアプリを配置することができます。

VPC は IPSec VPN (サービス名: Cloud VPN )や専用線 (サービス名: Cloud Interconnect ) を使ってオンプレミスのネットワークや、他のパブリッククラウドのネットワークと接続することもできます。

裏の仕組みを簡単に説明すると、 VPC は Andromeda という Google のネットワーク仮想化技術を使って実装されています。仮想的なネットワークのため、物理ネットワークで考慮が必要な「セグメントを小さく分けることでブロードキャストドメインを分割し、ネットワークの輻輳を軽減する」といった考慮は 必要ありません 。そのため、物理ネットワークとはネットワーク設計の勘所が異なる点に注意が必要です。

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

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

ネットワーク

Google Cloud の VPC の背景で「 ネットワーク 」という用語が出てきた場合、これは一つの VPC ネットワークのことを指しています。

ネットワークは グローバルリソース です。これは、ネットワークが リージョンをまたぐ存在 であることを示しています。

他のパブリッククラウド... Amazon Web Services (AWS) を例に取ると、 VPC はリージョンリソースであり、リージョンごとに VPC を作成する必要があります。これに対して Google Cloud の VPC はグローバルリソースであるため、作成時にリージョンを指定する必要がありません。ネットワークの中にサブネットを作成する際に、リージョンを指定します。

また VPC ネットワークは IP アドレス帯を 持ちません 。 VPC の中のサブネットが サブネットごとに IP アドレス帯を持ちます 。このことから VPC は「サブネットをまとめるグルーピングリソースである」と解釈することもできます。

ネットワークは中に「ルート」「ファイアウォールルール」などの子リソースを持ちます。これらもグローバルリソースです。

サブネット

サブネット (もしくはサブネットワーク) は VPC ネットワークの中に小分けされたネットワークです。

サブネットは リージョンリソース であるため、作成時にリージョンを指定します。また、作成時に IP アドレス帯 を CIDR 形式で指定します。

サブネットを作って初めて、その中に Compute Engine の VM (仮想サーバ) などを配置することができるようになります。

前述しましたが、 VPC ネットワークやサブネットは仮想的な存在のため「セグメントを小さく分けることでブロードキャストドメインを分割し、ネットワークの輻輳を軽減する」といった考慮は 必要ありません

また、セグメントを分けることは通信制御にはなりません。同一 VPC に所属するサブネット同士は自動的にルートが生成され 相互に通信することができます 。サブネット同士の通信制御を行いたいときは後述のファイアウォールルールにより行います。

「同一 VPC に所属するサブネット同士は通信できる」という原則は、リージョンが異なっても変わりません。違うリージョンのサブネット同士でも、同一 VPC に所属していれば相互に通信することができます。

サブネット作成モード

VPC 構築時にサブネットを作成する際、「 自動モード 」と「 カスタムモード 」が選択できます。

自動モードを選択すると、全リージョンに一つずつ、自動的にサブネットが作成されます。各サブネットの CIDR ブロックは 10.128.0.0/9 の範囲から 決まった CIDR が自動的に設定されます。このモードでは、不要なリージョンにも自動的にサブネットが作成されること、また CIDR が特定のものになってしまうことから、 検証目的等 でのみ使うべきです。

一方のカスタムモードでは、自動的にサブネットが作成されることはなく、サブネット作成先のリージョンや CIDR は自分で指定します。 VPC ネットワークを作成すると、サブネットのない空のネットワークができあがるため、「東京リージョンに 192.168.0.0/24 でサブネットを作成」のように個別にサブネットを作成していきます。 本番用途等ではこちらのカスタムモードを利用します

VPC 間接続

異なる VPC 間同士は VPC ネットワーク ピアリング (VPC ピアリング) 機能で接続することができます。当機能では、異なる Google Cloud プロジェクトにいる VPC とも接続させることが可能です。

条件として、サブネットの IP アドレス範囲が重複していないことがあります。また 推移的ピアリングはできない (いわゆる 2 ホップ制限) などの制限もあります。

また Cloud VPN を使って VPC 間を接続することもよく用いられます。 Cloud VPN では推移的な接続ができるが料金がかかる、というのが VPC ピアリングとの違いです。

詳細は、応用編の記事で紹介します。

オンプレミスや他のクラウドとの接続

VPC は Cloud VPN と呼ばれる IPSec VPN の仕組みや、 Cloud Interconnect という専用線サービスを使うことで、オンプレミスの既存ネットワークや、他のパブリッククラウドのネットワークと接続することが可能です。

これによりインターネットを介さず、プライベート IP を用いて他のネットワークから Google Cloud の VPC 内のリソースにアクセスすることができます。

他のネットワークと VPC の接続においては、原則として接続される他のネットワークと VPC (サブネット) の IP アドレス帯が 重複していないこと が条件です。ルーティングの設定によっては一部重複していても通信が可能になる場合がありますが、シンプルなルート設計のためには、 VPC 設計の際に他のネットワークとの接続の可能性は十分考慮に入れる ことが推奨となります。

当記事では Cloud VPN や Cloud Interconnect については詳述しないため、以下のドキュメントをご参照ください。

また Cloud VPN については以下の記事もご参照ください。

blog.g-gen.co.jp

ルート

ルート は VPC ネットワーク単位で設定します。

注意すべきなのは、ルートは「 VPC ネットワークの 中から外へ パケットが到達するための経路を指定する」ものである点です。逆方向、つまり VPC の 外から各サブネット方向への 経路は 自動的に生成され、削除することができません

ルートには、最初から Google Cloud により生成される システム生成ルート とユーザーが自分で定義する カスタムルート があります。インターネットへ通信するためのデフォルトゲートや、同一 VPC 内のサブネット同士のルートは自動的に生成されます (前者は削除/置換できますが、後者は削除や変更ができません) 。

前述の通り同一 VPC 内のサブネット同士の通信は自動的にできるようになりますので、特に追加の設定は必要ありません。また VPN や専用線で VPC を他のネットワークと接続する際も、仕様上多くの場合で BGP による動的ルート交換が行われるため、手動でのルート追加を行うことは稀です。ルートの追加設定が必要になるのは、以下のような限られた場面です。

  • 特定ネットワークへのパケットを VM 上の仮想アプライアンス、またはその手前のロードバランサーへルーティングしたい場合
  • Cloud VPN の Classic VPN 機能を使っており静的ルートの追加が必要な場合

このように、ルートを手動で編集する機会は少ないと言えます。むしろ VPN 、専用線、 VPC Peering 等で他ネットワークへ接続する際にルート交換が正常に行われているかを確認する際などに参照する方が多いでしょう。

ファイアウォール

ファイアウォールルール

基本

ファイアウォールルール は VPC 内のトラフィックに対し 「接続元ノード・接続先ノード・プロトコル・ポート番号」による通信制御を提供します。いわゆる L3 ・ L4 レベルのトラフィック制御を行うファイアウォールと理解することができます。

なおファイアウォールルールは 無料 で利用できます。

VPC のファイアウォールは ステートフルインスペクション 形式です。これは、通信の行きと戻りをファイアウォールが紐づけて理解することを意味しています。例えば「自社オフィスの固定 IP アドレス "xx.xx.xx.xx" から VM (A) に対する SSH ログインの通信を許可したい」場合は、ファイアウォールルールとして「方向は Ingress (上り) 」「接続元は "xx.xx.xx.xx" 」「ターゲットは VM (A) 」「プロトコルは TCP 、ポート番号は 22 」「アクションは "許可" 」を一つだけ作ればいいのです。 TCP 通信は必ず "行き" と "戻り" がありますが、ステートフルインスペクションのファイアウォールは行きのパケットと戻りのパケットを自動的に紐づけて評価してくれるので、戻りのパケットを許可するルールを作る必要がないのです。

ルールの仕様

Google Cloud では VPC ごとにファイアウォールルールのテーブルを持って います。そこで定義した内容が VPC 内の全ての VM に適用されます。

ルールテーブルは例えば以下のようになります。

ルール名 タイプ ターゲット フィルタ プロトコル:ポート アクション 優先度
allow-icmp Ingress 全インスタンス IP ranges: 0.0.0.0/0 icmp Allow 1000
allow-rdp-from-myoffice Ingress 全インスタンス IP ranges: a.b.c.0/24 tcp:3389, udp:3389 Allow 1000
allow-ssh-from-partneroffice Ingress 全インスタンス IP ranges: x.y.z.0/23 tcp:22 Allow 1000
deny-internet-from-prod Egress tags: prod IP ranges: 0.0.0.0/0 全プロトコル Deny 500

ルールには 上り (Ingress) と 下り (Egress) の タイプ があります。 VM 側を上 (Internal) と見て、そこから外に出ていく通信を下り (Egress) と呼び、その逆を上り (Ingress) と呼びます。

ターゲット はルールが適用される VM です。「IP アドレス帯」「ネットワークタグ」「サービスアカウント」などの方法でルールの対象とする VM を限定できます。ここでの条件から外れる VM から / へのトラフィックはファイアウォールルールの対象となりません。少々分かりづらいのですが、パケットの観点だと、上り (Ingress) ルールではターゲットは 接続先 であり、下り (Egress) ルールでは 接続元 を指すことになります。

フィルタ はルール適用対象のパケットをフィルタする設定です。これも分かりづらいですが、パケットの観点だと、上り (Ingress) ルールではフィルタは 接続元 であり、下り (Egress) ルールでは 接続先 を意味します。ターゲットの反対と理解すればよいでしょう。

ターゲットやフィルタに VPC 上の VM インスタンスを指定する際は、 IP アドレス帯 (CIDR 形式) での指定のほか VM の ネットワークタグサービスアカウント で指定することができます。

プロトコル・ポート は読んで字のごとくです。「 TCP: 443」「 UDP:53 」「 ICMP 」のように指定ができます。

ルールには 許可 (Allow) または 拒否 (Deny) の アクション があります。パケットがルールに合致するとこのアクションが適用されます。

そしてルールには 優先度 があります。 0 から 65535 の整数で指定し、より小さい数字が先に評価されます。パケットがいずれかのルールに合致して Allow または Deny されるとそれ以降の優先度のルールは無視されます。

暗黙のルール

重要な留意点として、明示的にファイアウォールルールを作成していなくても必ず適用され、ルールを一覧表示しても表示されない 暗黙のルール存在します 。それは、以下の 2 つです。

  1. 暗黙の下り (Egress) 許可
  2. 暗黙の上り (Inress) 拒否

1. は方向が 下り (Egress) 、 宛先が 0.0.0.0/0 、優先度が 65535 、アクションが allow のルールです。つまり、どのファイアウォールルールにも合致しなかった下り (Egress) パケットは 自動的に許可 されます。これは、例えば VM からインターネット上のソフトウェアレポジトリへ通信するパケットなどが自動的に許可されることを意味しています。これを防ぎたい場合は、明示的に拒否ルールを追加する必要があります。

2. は方向が 上り (Egress) 、 送信元が 0.0.0.0/0 、優先度が 65535 、アクションが deny のルールです。つまり、どのファイアウォールルールにも合致しなかった上り (Inress) パケットは 自動的に拒否 されます。これは、インターネット上からいかなる VM へのパケットも拒否することを意味しています。つまり、デフォルトでは VM への HTTPS 通信や SSH 通信も到達しません。明示的に許可ルールを追加することでこれを許可します。

インスタンス指定方法

前述のようにファイアウォールルールでは、接続元/接続先 VM を指定する際に「IP アドレス帯」「ネットワークタグ」「サービスアカウント」が選択可能と記載しました。

ネットワークタグ は VM に設定可能なタグです。文字列として指定可能で、一つの VM に複数のネットワークタグを設定することができます。

例として AP サーバーに app というネットワークタグを指定し、 DB サーバーに db というタグを指定したうえで、以下のようなルールを作成することで AP ・ DB 間の通信を許可することができます。

ルール名 タイプ ターゲット フィルタ プロトコル:ポート アクション 優先度
allow-ap-db-access Ingress network tag: db network tag: app tcp: 5432 Allow 1000

サービスアカウント は VM にアタッチ可能な IAM リソースです。本来 VM 内で動作するプログラムからの認証・認可に利用されますが、ファイアウォールでも利用可能です。

詳細は Compute Engine の 公式ドキュメント および以下の当社記事をご参照ください。

blog.g-gen.co.jp

ファイアウォールポリシー

ファイアウォールポリシー (階層型ファイアウォールポリシーとも呼称) は VPC ファイアウォールを組織全体で一貫して管理するための仕組みです。プロジェクト横断で、複数 VPC ネットワークにポリシーを適用することができます。

詳細は応用編の記事で解説いたします。

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

VM とインターネット間の通信

VPC ネットワーク (サブネット) 内からインターネットへ接続することも可能です。

VPC には デフォルトインターネットゲートウェイ (default-internet-gateway) が存在し、サブネット内の VM はこれを通じてインターネットと通信することができます。 VM がインターネットと通信するには以下の条件を 全て 満たしている必要があります。

  1. VPC のルートにデフォルトインターネットゲートウェイへの経路が存在している
  2. VM が External IP (外部 IP 、いわゆる Public IP) を持っている
  3. VM とインターネット上のノード間の通信がファイアウォールルール/ポリシーで許可されている

VPC が作成されると、いくつかのルートがシステムよって自動生成されます ( システム生成のデフォルトルート ) 。その中には 0.0.0.0/0 をデフォルトインターネットゲートウェイへ向けるルートも存在しているため 1. に関して、追加の手順は必要ありません。

2. について、全ての VM は Internal IP (Privete IP) を持ちますが、インターネットと通信するための External IP (いわゆる Public IP) については VM の構築時に持たせるかどうかを選択できます。 VM 構築後でも、 VM 停止時であれば Public IP の有無を変更できます。

3. については、ファイアウォールにて VM とインターネット上のノードの間の通信が許可されている必要があります。 VM から 始まる 通信であれば下り (Egress) ルールで、 外部から始まる 通信であれば上り (Ingress) ルールで許可されている必要があります。ファイアウォールルールの項で解説したように、デフォルトでは下り (Egress) ルールは 0.0.0.0/0 に対し許可、上り (Ingress) では 0.0.0.0/0 からを拒否しているので、上り通信を許可するには明示的にルール追加する必要があります。

Cloud NAT

Cloud NAT はフルマネージドな NAT 機器です。 External IP を持っていない VM でもインターネットへの通信 (VM から開始しインターネットへ到達する方向の通信) が可能になります。

"フルマネージド" とは、このサービスの基盤が Google Cloud によって完全に管理されていることを意味しています。我々利用者は、一度 Cloud NAT を使用する設定を追加しさえすれば「障害対応」「パッチ適用」「性能監視・スケーリング」などをほとんど行う必要がありません。 Cloud NAT のバックエンドは仮想化・分散アーキテクチャになっており、スケーラビリティ・可用性・パフォーマンスが確保されています。

Cloud NAT を VPC に追加すれば、 External IP を持たない VM でもインターネットへ通信することができます。逆にインターネットから開始して VM へ到達する方向の通信は許可されません。これにより例えば「パッチ配信サーバからのファイルダウンロード」「インターネット上のソースコードレポジトリからのソースコード取得」「SaaS サービスの HTTP API 呼び出し」などがセキュアに可能になります。

以下の条件を 全て 満たすと、 VM は Cloud NAT を利用してインターネットへ出ていくことができます。

  1. VM の所属するサブネットが Cloud NAT を利用するよう紐付けられている
  2. VM に External IP (外部 IP) が割り振られていない
  3. VPC のルートにて 0.0.0.0/0 のネクストホップがデフォルトインターネットゲートウェイになっているルートが存在している
  4. ファイアウォールの下り (Egress) ルールで許可されている

Cloud NAT はフルマネージドであるため多くの場合で簡単に利用できますが、様々な機能や仕様を持っています。詳細は Cloud NAT のドキュメント をご参照ください。

インターネットとの通信を防ぐ方法

セキュリティ上の理由で VPC 内の VM とインターネットの接続をさせないようにするには、以下のような方法があります。

  1. VPC のルートを編集しデフォルトインターネットゲートウェイへのルートを削除する
  2. VM に External IP を持たせない
  3. ファイアウォールルール・ポリシーにて制御する

1. のようにルートを削除してしまえば、 VPC 内の全ての VM はインターネットと通信できなくなります。 影響範囲は VPC 全体 となるので、もし同一 VPC 内にインターネットとの通信要件の異なる複数の VM がある場合は、この方法は取れません。 AWS を例に取ると「パブリックサブネット」「プライベートサブネット」のように通信要件ごとにネットワークセグメントを分けるケースがありますが、 Google Cloud においてはこれは実現できません。実現する場合は VPC ごと分割することになります。

2. は読んで字のごとく、 VM に External IP を持たせないことでルート設定等に関係なくそもそも通信できなくさせてしまう方法です。ただし前述の Cloud NAT が設定されていると External IP を持たない VM はインターネットへ 出ていく ことは可能となってしまいます。これを防ぐには 3. を実施します。

3. はファイアウォールにてブロックする方法です。前述のように VPC を分割すると管理面で煩雑になる場合があるため、 Google Cloud の場合は ファイアウォールにてインターネットとの通信可否を制御することが多い と言えます。なお前述の通りファイアウォールの 上り (Ingress) はデフォルトで 拒否 (Deny) のため、インターネット から の通信は明示的に許可しなければ到達しません。逆に下り通信はデフォルトで許可 (Allow) のため、明示的に拒否ルールを追加しなければ VM から外部方向への通信は可能なままです。

プレミアムティアとスタンダードティア

VPC 内の VM とインターネット間の通信では料金の異なる ネットワークティア を VM やロードバランサーごとに選択することができます。

プレミアムティアスタンダードティア の 2 種類があり、前者は Google の持つ高品質な専用バックボーンネットワークを利用し、後者はコストパフォーマンスに優れた通常のインターネットを利用するティアです。デフォルトでは前者が利用されるようになっており、また Google の推奨は前者です。

前者は高品質・高パフォーマンスであり、特にグローバルに利用されるシステムでの利用が推奨されています。一方で後者は、単一の地域で利用されるシステムで、かつコスト最適化が望まれる場合に利用されます。

前述の通り料金は 下り方向のパケットのデータ量 に応じて課金されます。具体的な料金は、以下のページから確認できます。

Google Cloud サービスへのプライベートサービスアクセス

いくつかの Google Cloud サービスは、リソース配置に専用の VPC とサブネットを使います。例えば以下のようなサービスです。

  • Cloud SQL
  • Memorystore
  • Cloud Build
  • Vertex AI

上記のサービスではリソースを作成すると サービスプロデューサーネットワーク と呼ばれる専用ネットワークに配置されます。例として AWS の Amazon RDS ではユーザーの VPC ・サブネット内にインスタンスが配置されますが、 Google Cloud の Cloud SQL では、ユーザーの VPC の 外に 専用ネットワークができ、そこにインスタンスが配置されます。

そしてユーザーの VPC とサービスプロデューサーネットワークは VPC ピアリングで接続され ユーザーの VM とはピアリング経由で接続するのです。

このサービスプロデューサーネットワークの IP レンジ (CIDR) は、ユーザー側で指定できます。ユーザーの VPC と重複しない CIDR を指定して、そこにサービスプロデューサーネットワークを作成し、その中に Cloud SQL インスタンス等を配置するイメージです。

一度サービスプロデューサーネットワークを作成すれば、その中に複数の Cloud SQL インスタンスや Memorystore インスタンスを配置することが可能です。

プライベートサービスへのアクセス

Virtual Private Cloud (VPC) の運用

VPC フローログ

VPC フローログ (VPC Flow Logs) は VM によって送受信されたトラフィック記録のサンプルをログとして保存する仕組みです。利用目的としては以下が挙げられます。

  1. ネットワークモニタリング
  2. トラブルシューティング
  3. 費用最適化
  4. セキュリティ (フォレンジック・リアルタイム分析)

VPC フローログにはいわゆる 5 タプル (送信元 IP 、送信元ポート番号、送信先 IP 、送信先ポート番号、プロトコル番号) が含まれる他、時刻、バイト数、 TCP の ACK のレイテンシなどが含まれます。こういった パケットの関連情報 が記録されるのであり、 パケットそのものがキャプチャされるのではありません

さらに メタデータ の記録を有効化すると、ログのサイズは大きくなってしまいますが、通信を行った VM や VPC に関する追加情報も記録されるようになります。

また当機能では全てのトラフィックが記録対象となるわけではなく、事前に指定するサンプリングレート (%) に基づいた割合のトラフィックのログだけが記録されます。また「特定の VM のみ」「特定送信元 IP のトラフィックのみ」といったように記録する対象トラフィックをフィルタすることもできます。

なお当機能は VPC の仮想化基盤に組み込まれている機能であり、 VPC フローログを有効化してもパフォーマンス遅延等は発生しません。

当機能で記録されたログは Cloud Logging の機能を使って、デフォルトではログバケットに保管されます。 Cloud Logging の詳細や料金については以下をご参照ください。

blog.g-gen.co.jp

デフォルトのログバケットであれば 30 日間保存であり、この範囲内であれば保存料金は無料です。ただし保存料金とは別に取り込み量に応じた料金が発生します。 2022 年 4 月現在では $0.50 / GiB ですが、月ごとに最初の 50 GiB は無料です。これを超えるようなログ取り込みをプロジェクト全体で行う場合には、料金を考慮して VPC フローログの有効化有無を検討したほうが良いでしょう。

VPC フローログの有効化有無やサンプリングレート等の設定は サブネットごと に決めます。サブネット作成時に決定するほか、あとからでも変更可能です。

ファイアウォールルールのログ

ファイアウォールルールのログ は、各 VPC のファイアウォールルールの監査・検証・分析のために用いるログです。以下のような目的で利用されます。

  • 意図通りにファイアウォールルールが許可/拒否しているか確認
  • 特定のルールが何台の VM に影響を与えているか調査
  • トラブル時に通信にファイアウォールが影響しているかの確認

特徴として、ファイアウォールルールのロギングはファイアウォールの ルールごと に設定します。VPC (ルールテーブル) ごと、ではありません。 1 行のルールごとに「ロギングの有効/無効」と「メタデータを含むか否か」を設定します。

ログには以下のような内容が記載されます (詳細)。

  • 日時
  • いわゆる 5 タプル (送信元 IP 、送信元ポート番号、送信先 IP 、送信先ポート番号、プロトコル番号)
  • 許可されたか拒否されたか
  • 該当するファイアウォールルールの詳細

また メタデータ の記録も有効化すると、 VPC や VM の詳細など追加情報が記録されます。

なお当ロギング機能は VPC のファイアウォールルールと階層型ファイアウォールポリシーの両方で使用可能です。

VPC ネットワークの監査ログ

ネットワーク関連設定が作成・変更・削除された記録は監査ログとして自動的に記録されるようになっています。逆に、これを無効化することはできません。

これは Cloud Audit Logs の機能で実現されており 「誰が、いつ、どこで、何をしたか」 の形で記録されます。 Cloud Audit Logs については、以下の記事をご参照ください。

blog.g-gen.co.jp

設定の作成・変更・削除された記録は 管理アクティビティ監査ログ と呼ばれ、前述のように必ず有効化されており無効化することはできません。

前述の Cloud Audit Logs の記事にあるように、デフォルトではログは 400日間保存され、デフォルトで有効化されている管理アクティビティ監査ログについては料金は発生しません。

一方で設定の読み取りや一覧表示に関する履歴は データアクセス監査ログ と呼ばれ、ログサイズが膨大になりがちなことからデフォルトでは無効化されています。前述の記事にある通りデータアクセス監査ログは有償のため、有効化の際は、ログの料金を意識する必要があります。

料金

課金対象

VPC の料金は、以下の課金対象があります。

  1. 下り (Egress) トラフィックのデータ量
  2. 確保した External IP (外部 IP) アドレスの利用時間
  3. その他、階層型ファイアウォールポリシーなど利用機能に応じた課金

なお、 VPC を単純に作成するのみであれば無償です。

トラフィック量への課金

1. は、 VPC 内を通るトラフィックの量に応じた課金です。特徴的なのは、パケットの通信方向によって課金の有無が異なります。 VPC 側 (= VM 側) を上側/Internal 側とみなし、インターネットやオンプレミス側を下側/External 側としたときに、上り (Ingress) パケットは課金 されません 。反対に下り (Egress) パケットは 課金されます

例えば VPC 内の VM に Web サーバーを置いた時、ユーザーからの HTTP リクエストやデータのアップロードには課金されませんが、反対にユーザーがデータをダウンロードした際にはデータ量に応じて課金されます。これは他の多くのパブリッククラウドのネットワーク課金体系と類似していると言えるでしょう。

例として 2022 年 4 月現在の東京リージョンから日本国内へのインターネットへの通信は GB あたり $0.14 ドルです。月に 100 GB の外向き通信が発生するとして、概ね¥ 1,680 円程度の課金が発生することになります。なおこの料金は通信先の地域や、月間の総データ量によっても変化します (後述のドキュメント参照) 。

またインターネットに対する通信だけではなく VPC 内の VM 同士の通信であっても、 異なるゾーンや異なるリージョン同士 の通信には課金が 発生します 。こちらも同一リージョン内の異ゾーンとの通信なのか、リージョン間であればどのリージョンへの通信なのか、によって料金が変動します。

IP アドレスへの課金

2. は VPC に配置する VM (Compute Engine の仮想マシン) に付与するための IP アドレスに対する課金です。 Internal IP (内部 IP 。いわゆる Private IP) には課金 されません が、インターネットとの通信に必要な External IP (外部 IP 。いわゆる Public IP) には割り当て時間に応じた課金が発生します。 External IP には VM を停止すると解放される「エフェメラル IP 」と固定的に確保できる「静的 IP 」がありますが、どちらも同様に課金されます。

その他機能への課金

3. は「階層型ファイアウォールポリシー」「 Private Service Connect 」「 Packet Mirroring 」など他のさまざまな VPC 機能に関する課金です。

VPC の課金体系は複雑なため、詳細は以下の公式ドキュメントをご参照ください。

応用編へのリンク

当記事は VPC の基本機能に絞った基本編でした。応用編の記事では以下の機能を扱っていますので、ご参照ください。

  • VPC 間・サブネット間の通信
  • VPC ネットワークピアリング
  • Cloud VPN による推移的な通信 (カスタムルート広報)
  • 共有 VPC
  • 階層型ファイアウォールポリシー
  • サーバーレス VPC アクセス
  • 限定公開の Google アクセス / Private Service Connect
  • Packet Mirroring

blog.g-gen.co.jp

杉村 勇馬 (記事一覧) (Facebook)

クラウドソリューション部 部長

元・警察官という経歴を持つ現・エンジニア。クラウド管理運用やネットワークに知見。AWS 12冠、Google Cloud認定資格10冠。

2022年5月現在、ハマっているものはモンスターエナジーウルトラ。