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

Virtual Private Cloud (VPC) とは
ネットワークとサブネット
オンプレミスや他のクラウドとの接続
ルート
ファイアウォール
インターネットとのアクセス
Google Cloud サービスへのプライベートサービスアクセス
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 に所属していれば相互に通信することができます。

サブネットの IP アドレス

サブネットには CIDR 形式 で IP アドレス範囲を指定します。サブネットには IPv4 または IPv6 範囲を割り当てることが可能です。

IPv4 では 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 すなわち RFC 1918 のプライベート IP アドレス範囲の中から割り当て可能なほか、いくつかの範囲が利用可能です。

最小のサブネットサイズは /29 です (IP アドレス数が 8 個。後述の予約アドレスを除くと利用可能は 4 個のみ) 。

参考 : 有効な IPv4 範囲

なおサブネットの IP アドレスの第4オクテットが最初の2つと最後の2つの IP アドレスは Google Cloud によって予約されているため、ユーザーは利用することができません。

例えば 10.1.2.0/24 というサブネットであれば 10.1.2.0, 10.1.2.1, 10.1.2.254, 10.1.2.255 には VM インスタンス等を配置することができないことになります。

サブネット作成モード

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 等で他ネットワークへ接続する際にルート交換が正常に行われているかを確認する際などに参照する方が多いでしょう。

ファイアウォール

Google Cloud の VPC には備え付きのファイアウォール機能があり Cloud Firewall と呼ばれます。

Cloud Firewall はフルマネージドの分散システムであり、一般的なファイアウォールアプライアンスのようなイメージではなく、VPC 内の通信に対して透過的に制御をかけます。ユーザは、Google Cloud コンソールや gcloud コマンドラインでルールを追加するだけでよく、インフラの管理などを考える必要がありません。

当機能は Amazon Web Services (AWS) における「セキュリティグループ」に相当しています。

詳細は以下の記事で解説しています。ただし、以下の記事は Cloud Firewall の全体像を解説しており長大なので、基本的な理解だけをしたい人は、まずは以下記事の「概要」「VPC ファイアウォールルール」だけを読むのも良いでしょう。

blog.g-gen.co.jp

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

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

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

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

VPC のルートにデフォルトインターネットゲートウェイへの経路が存在している
VM が External IP (外部 IP 、いわゆる Public IP) を持っている
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 を利用してインターネットへ出ていくことができます。

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

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

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

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

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

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 の推奨は前者です。

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

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

Network Service Tiers の料金

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 によって送受信されたトラフィック記録のサンプルをログとして保存する仕組みです。利用目的としては以下が挙げられます。

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

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

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

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

意図通りにファイアウォールルールが許可/拒否しているか確認
特定のルールが何台の 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 の料金は、以下の課金対象があります。

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

なお、 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 」がありますが、どちらも同様に課金されます。