G-genの小林です。
今回のブログでは Google Cloud (旧称 GCP) の VPC の基本機能をご紹介します。
VPCはGoogle CloudのGoogle Compute EngineやGoogle Kubernetes Engineといったサービスを使う上で重要なネットワークになります。
VPCに所属するサービスのセキュアに使用するためには、VPC設計が非常に重要になりますので、基本的なVPCの機能を覚えていきましょう!
また、今回のブログでは、Google CloudとAWSで同等の概念を並べて、もしくは、比較して記載しております。
AWSのVPCはわかるけど、Google CloudのVPCがわからない方は是非ご参考にして見てください。
なお、AWSとGoogle Cloudのどちらが良いといった観点で比較する投稿ではないのでその点ご了承ください!
VPC
まず、 VPC はプライベートな仮想ネットワーク群になります。
Google CloudのVPCの最大の特徴としては、 リージョンに跨ったグローバルで管理するネットワーク であること。 一般的なクラウドサービスのVPCでは単一のリージョンにVPCを作成する形になりますが、 Google CloudのVPCはGoogle Cloudが提供するリージョン全てに跨るVPCを作成する形になります。
合わせて、AWSではVPC作成時にVPCのIP範囲 (CIDR) を指定しますが、Google CloudではVPC作成時にIP指定することがないのも特徴です。
IP アドレスはサブネットに紐づくためです。
サブネット
続いて、リソースを配置するネットワーク単位である サブネット 。 Google Cloudのサブネットはリージョン管理のリソースになります。 そのため、サブネット作成時にリージョンの選択をします。 なお、ゾーンの選択は、サブネット作成時は選択せず、インスタンス作成時にのみ選択します。
VPCとサブネットの情報をまとめると以下のようになります。
わかりやすいようにAWSと同等のリソースを並べて書きましたが、ネットワークのパーツが大きく異なることがわかるかと思います..!
また、Google Cloudのサブネットには作成モードとして、オートサブネットモードとカスタムサブネットモードの2つがあります。
オートサブネットモード は自動的にサブネットが作成される機能になります。 Google Cloudが提供する全リージョンに固定のIP範囲のサブネットが作成されます。 一部ファイアウォールも自動で作成されるため、IP範囲を指定する必要がない検証用途での利用に最適です。
一方、 カスタムサブネットモード は、ユーザーでリージョン、IP範囲を定義してサブネットを作成します。 ファイアウォールもユーザーで定義する必要があります。 本番利用の場合やCIDRの重複を避ける必要がある場合はこちらを利用します。
VPCルート
Google CloudのVPCルートはサブネットごとの設定ではなく、VPCごとの設定になります。 そのため、VPCルートで設定したルートはVPCない全てのインスタンスが参照します。
インスタンスごとにルートを指定したい場合、特定のタグがついているインスタンスのみルート適用という設定が可能です。
なお、サブネットを作成すると、VPCルートはデフォルトで作成したサブネット範囲でのルートとインターネットへのデフォルトルートが登録されます。 そのほかのルートはユーザー自身で登録する必要があります。
また、それぞれのルートにはプライオリティを設定する必要があります。 このプライオリティの数字の小さいルートから優先的にルーティングされるような仕組みになっています。
Cloud NAT
外部IPを持たないインスタンスがインターネットへのアクセスをするために利用する Cloud NAT 。
NAT作成時、 NATマッピング という機能でどの送信元IPをNATするか指定できます。 例えば、特定のサブネットに所属するインスタンスのみCloud NAT経由の外部アクセスを可能とする、といった設定で使用します。
なお、NATマッピングが すべてのサブネットとプライマリとセカンダリ範囲
と設定した上で外部IPをもつインスタンスがインターネットへのアクセスをした場合はインスタンスがもつ外部IPが送信元として優先されます。
また、AWSの場合はNAT Gateway作成後ルートテーブルのターゲットとして設定する必要がありますが、Google Cloudの場合はNAT Gateway作成のみでNATマッピングに応じてNATされます。
参考:Cloud NAT の概要 | Google Cloud
VPCネットワークピアリング
2つのVPC同士を接続し内部IPアドレスでの接続を可能にする機能になります。
AWS同様、ピアリングは 1:1の関係 になります。 そのため、以下のようなピアリングしていないVPCへのアクセスをすることはできません。
そのほかにも、ピアリングしたVPCは内部IPアドレスで通信するために、以下のような制約があります。
- ピアリングするVPCとIP範囲が重複しているサブネットがないこと
- VPC A(サブネット10.0.1.0/24) とVPC B(サブネット10.0.1.0/24)はピアリングできない
- すでにピアリングしているCIDRと新規でピアリングするCIDRで直複してはならないこと
- VPC A(サブネット10.0.1.0/24) とVPC B(サブネット10.0.2.0/24)がピアリングしている場合、VPC A(サブネット10.0.1.0/24) とVPC C(サブネット10.0.2.0/24)はピアリングできない
参考:VPC ネットワーク ピアリングの概要 | Google Cloud
共有VPC
Google Cloudはプロジェクトというリソースを格納するための階層があります。 AWSではアカウントにあたります。
通常VPCはプロジェクトごとにそのプロジェクトだけで使用できるように作成をしますが、 特定のVPCを現在所属しているプロジェクト以外のプロジェクトにも割り当てすることができる機能が 共有VPC になります。
ユースケースとしては、複数システムのVMを管理する(環境別のみVPCで分ける)場合ですね。この場合、以下のような要件が考えられます。
- ルート、ファイアウォール、VPN等のリソースは共通で使用したい
- 複数システムが同じVPCに配置するけれども、AシステムのVMはAシステムの運用者のみ、BシステムのVMはBシステムの運用者のみと権限設計を厳格にしたい
この時、共有VPCを使うことで、セキュアな権限設計やネットワークの一元管理の実現が可能です。
その他 VPC の詳細
以下の当社記事で Google Cloud (GCP) の VPC の基本的な仕組みを詳細に解説しています。
応用編の記事は以下です。複雑なルーティングの仕組みなどについては、以下の記事で解説しています。
小林 あゆみ (記事一覧)
クラウドソリューション部 営業チーム
AWSエンジニアからGoogle Cloud営業に転向
福井からリモートワーク中
趣味はMonkey125でツーリング、Netflix鑑賞、旅行