ネットワーク
本節では、クラウドにおいて初めに設計することになるインフラストラクチャである、ネットワークのデザイン パターンを解説します。
クラウド内のネットワークである VPC (Virtual Private Cloud) の効率的な設計パターンである共有 VPC を初めとして、今後は、インターネットからクラウド上のシステムへのアクセスするための方法や、オンプレミス環境から安全にクラウドへ接続する方法などをご紹介します。
デザイン パターン詳細
共有 VPC（Shared VPC）
解決する課題・使い所
最も単純なクラウド構成は、単一プロジェクトにおいて単一 VPC を全リージョンに展開する構成です。一方で、一般的に多くのエンタープライズ企業ではスケーリングや運用要件などの要因により、例えばチーム別に複数の独立したプロジェクトそれぞれで VPC を構成することがあります。組織内において異なる VPC 間での通信が必要な場合、以下のような課題があります。
VPC 同士は独立しているため、相互に通信するための追加の設定が必要となり、またそうすることでセキュリティや通信費への考慮が必要
ネットワーク ポリシーは各プロジェクトにて個別設定となるため、大量のプロジェクトを保持する場合は管理が煩雑化
共有 VPC は上記課題を解決するために、組織内においてプロジェクトを跨がる単一の VPC を構成する機能です。
アーキテクチャ
共有 VPC を構成する際に必要となる概念として、ホスト プロジェクトとサービス プロジェクトがあります。
ホスト プロジェクト
VPC を構成し管理するプロジェクト
複数の共有 VPC を保有することが可能
IP アロケーション、ルート、DNS、ファイアウォール、専用線接続、VPN、ログ出力設定といった共有のネットワーク リソースに対し統一ポリシーを適用
サービス プロジェクト
共有 VPC にアタッチされるクライアント プロジェクト
1 つのホスト プロジェクトのみにアタッチ可能
共有 VPC を利用して構成できるアーキテクチャ例を以下に示します。
単一ホスト プロジェクト、複数サービス プロジェクト、単一共有 VPC
共有 VPC を構成する際に基本となるアーキテクチャ
複数ホスト プロジェクト、複数サービス プロジェクト、複数共有 VPC
単一ホスト プロジェクトでは要件を満たせないような以下のケースで利用されるアーキテクチャ
必要とされるリソースを割り当て制限内で満たせない場合
VPC ネットワークごとに異なる管理ポリシーが必要な場合
利点
管理容易性
サブネット リソースに対しては IAM ベースのアクセス制御が可能
管理する VPC の数を削減できるため VPC 構成が単純化
ホスト プロジェクトにてネットワーク ポリシーの集中管理が可能
ホスト プロジェクトではネットワーク リソースを、サービス プロジェクトではその他のリソースを管理することで、チーム責任を明確に分離した状態でネットワーク リソース共有が可能
請求情報はサービス プロジェクト単位で分類可能（詳細はこちら）
注意事項
1 つのホスト プロジェクトに接続可能なサービス プロジェクト数は 1000 まで、単一組織におけるホスト プロジェクト数は 100 までという上限があります。申請により引き上げが可能です（最新情報はこちらをご確認ください）。
セキュリティや割り当てリソース上限の制約といった観点で、共有 VPC は本番環境、開発環境など用途別に分離することを推奨します。
既存プロジェクトをホスト プロジェクトに接続し、共有 VPC ネットワークを利用するには一部のリソースを再作成する必要があります。既存プロジェクトは自動では共有ネットワーク リソースを使用しません。
サービス プロジェクト内で複数のネットワーク インターフェースを持つ VM インスタンスは、最初のネットワーク インターフェース（ nic0 ）のみ共有 VPC 内のサブネットを参照できます。
複数 VPC ネットワークを接続する要件がある一方で、その他要件により共有 VPC を利用できない場合は、VPC ネットワーク ピアリングをご検討ください。
サンプル コンフィグ
共有 VPC 作成には組織が必要です。こちらを参考にまず組織を作成ください。
すでに組織なしのプロジェクトを保有している場合、こちらの手順で組織へプロジェクトを移行してください。
こちらの手順に沿ってホスト プロジェクトにおいて共有 VPC を作成し、サービス プロジェクトをマッピングします。
参考ドキュメント：組織なしのプロジェクトの移行共有 VPC 管理に必要な IAM ロールはこちらです。
このパターンで作成された事例
参照ドキュメント