ネットワーク

デザイン パターン詳細

共有 VPC（Shared VPC）

解決する課題、使い所

最も単純なクラウド構成は、単一プロジェクトにおいて単一 VPC を全リージョンに展開する構成です。一方で、一般的に多くのエンタープライズ企業ではスケーリングや運用要件などの要因により、例えばチーム別に複数の独立したプロジェクトそれぞれで VPC を構成することがあります。組織内において異なる VPC 間での通信が必要な場合、以下のような課題があります。

  • VPC 同士は独立しているため、相互に通信するための追加の設定が必要となり、またそうすることでセキュリティや通信費への考慮が必要
  • ネットワーク ポリシーは各プロジェクトにて個別設定となるため、大量のプロジェクトを保持する場合は管理が煩雑化 

共有 VPC は上記課題を解決するために、組織内においてプロジェクトを跨がる単一の VPC を構成する機能です。

アーキテクチャ

共有 VPC を構成する際に必要となる概念として、ホスト プロジェクトとサービス プロジェクトがあります。

  • ホスト プロジェクト
    • VPC を構成し管理するプロジェクト
    • 複数の共有 VPC を保有することが可能
    • IP アロケーション、ルート、DNS、ファイアウォール、専用線接続、VPN、ログ出力設定といった共有のネットワーク リソースに対し統一ポリシーを適用
  • サービス プロジェクト
    • 共有 VPC にアタッチされるクライアント プロジェクト
    • 1 つのホスト プロジェクトのみにアタッチ可能 

共有 VPC を利用して構成できるアーキテクチャ例を以下に示します。

shared-vpc
  • 複数ホスト プロジェクト、複数サービス プロジェクト、複数共有 VPC
    • 単一ホスト プロジェクトでは要件を満たせないような以下のケースで利用されるアーキテクチャ
      • 必要とされるリソースを割り当て制限内で満たせない場合
      • VPC ネットワークごとに異なる管理ポリシーが必要な場合 
shared-vpc-2

利点

  • 管理容易性
    • サブネット リソースに対しては IAM ベースのアクセス制御が可能
    • 管理する VPC の数を削減できるため VPC 構成が単純化
    • ホスト プロジェクトにてネットワーク ポリシーの集中管理が可能
    • ホスト プロジェクトではネットワーク リソースを、サービス プロジェクトではその他のリソースを管理することで、チーム責任を明確に分離した状態でネットワーク リソース共有が可能
    • 請求情報はサービス プロジェクト単位で分類可能（詳細はこちら）

注意事項

  • 1 つのホスト プロジェクトに接続可能なサービス プロジェクト数は 1000 まで、単一組織におけるホスト プロジェクト数は 100 までという上限があります。申請により引き上げが可能です（最新情報はこちらをご確認ください）。
  • セキュリティや割り当てリソース上限の制約といった観点で、共有 VPC は本番環境、開発環境など用途別に分離することを推奨します。
  • 既存プロジェクトをホスト プロジェクトに接続し、共有 VPC ネットワークを利用するには一部のリソースを再作成する必要があります。既存プロジェクトは自動では共有ネットワーク リソースを使用しません。
  • サービス プロジェクト内で複数のネットワーク インターフェースを持つ VM インスタンスは、最初のネットワーク インターフェース（ nic0 ）のみ共有 VPC 内のサブネットを参照できます。
  • 複数 VPC ネットワークを接続する要件がある一方で、その他要件により共有 VPC を利用できない場合は、VPC ネットワーク ピアリングをご検討ください。 

サンプル コンフィグ

  • 共有 VPC 作成には組織が必要です。こちらを参考にまず組織を作成ください。
  • すでに組織なしのプロジェクトを保有している場合、こちらの手順で組織へプロジェクトを移行してください。
  • こちらの手順に沿ってホスト プロジェクトにおいて共有 VPC を作成し、サービス プロジェクトをマッピングします。
    参考ドキュメント：組織なしのプロジェクトの移行
  • 共有 VPC 管理に必要な IAM ロールはこちらです。

このパターンで作成された事例

関係するデザイン パターン

参照文献