VPCアーキテクチャパターン:AWS・GCPのスタンドアロン型と集中型を比較

スタンドアロンVPCは、クラウドアカウントやプロジェクト内で独立して動作する分離型のネットワーク環境です。各VPCは独自のネットワーク構成、セキュリティルール、ルーティングポリシーを保持するため、厳格な分離が求められるケースや、シンプルなネットワーク要件のユースケースに適しています。

主な特徴

スタンドアロンVPCは他のVPCから完全に分離されており、専用のネットワークリソースを備えた自己完結型の環境として機能します。ルーティングテーブルやアクセス制御といったネットワーク構成は個別に管理されるため、workloadsごとの要件に合わせてポリシーを柔軟にカスタマイズできます。

スタンドアロンVPCは接続要件に応じてピアリングで接続され、フルサービスメッシュ(すべてのVPCを相互接続した構成)まで拡張できます

スタンドアロン型VPCアーキテクチャは、ネットワーク要件がシンプルで、ネットワーク間の広範な通信を必要としないアプリケーションを抱える組織に特に向いています。環境間の干渉を防ぐために分離が欠かせない開発・テスト環境では、その強みが際立ちます。コンプライアンス上の要件から、機密性の高いworkloadsを完全にネットワーク分離したい組織にもよく選ばれています。クラウドリソースが限られ、構成もシンプルな小規模組織であれば、スタンドアロンVPCのわかりやすさと明確な境界線の恩恵を享受できます。

デメリット

スタンドアロンVPCは独立性が高い分、環境ごとにリソースが重複しやすく、運用コストや保守の負担が増えがちです。複数のVPC間で接続を確立しようとすると構成は一気に複雑化し、入り組んだピアリング設定や複数の接続ポイント、さらにはCIDRの重複を解消するためのNATソリューションが必要になることもあります。組織が拡大するほど、複数のスタンドアロンVPCの管理は難しくなり、特に環境横断で一貫したポリシーを徹底するハードルが高くなります。集中管理の仕組みがないため、標準化されたセキュリティポリシーやネットワーク構成を複数のVPCで維持することは容易ではありません。

Google Cloudの共有VPC、およびAWSのVPC Sharingは、複数のプロジェクト(AWSの場合はアカウント)から共通のネットワークインフラを利用できるようにする仕組みです。このアプローチにより、プロジェクト単位の分離とセキュリティを保ちながら、ネットワークの集中管理を実現できます。

主な構成要素

共有VPCアーキテクチャは、共有VPCのネットワークインフラを保有・管理するホストプロジェクトを中心に構成されます。サービスプロジェクトはこの共有ネットワークを利用しつつ、自身のリソース管理とアクセス制御を維持します。サブネットは特定のプロジェクトに対して選択的に共有でき、ネットワークリソースの割り当てをきめ細かくコントロールできます。ファイアウォールルールは中央で一元管理されますが、必要に応じてサービスプロジェクトごとに個別設定することも可能です。

VPCはひとつのプロジェクトで作成され、他のプロジェクトから利用されます

名称も似ており、クラウドプロジェクト間でネットワークリソースを共有するという中核機能は両者に共通していますが、Google Cloudの共有VPCはハイブリッド接続(例:オンプレミスホストへの接続)を標準でサポートしている点が特徴です。ホストプロジェクト側にハイブリッドリンク(例:オンプレミス環境へのCloud VPNトンネル)を構築すれば、各サービスプロジェクトからリモート拠点へのアクセス権を付与できます。一方、AWSのVPC Sharingでは、追加のネットワークコンポーネントを別途デプロイする必要があります。その代表例が、次に紹介するAWS Transit Gatewayです。

AWSのVPC Sharingが単一VPCのサブネットをアカウント間で共有することに主眼を置いているのに対し、Transit Gatewayは複数のVPC、VPN、Direct Connectゲートウェイ間の接続を仲介します。複雑なマルチVPC構成やハイブリッドクラウドアーキテクチャに適した仕組みです。

各AWSアカウントは1つ以上のVPCを持つことができ、それらをすべてTransit Gateway経由で接続できます

本記事が、複雑に絡み合うネットワークアーキテクチャを読み解く一助となれば幸いです。DoiTの専門領域については、https://www.doit.com/services/ もぜひご覧ください。

• Google Cloud 共有VPC
• AWS VPC Sharing
• AWS Transit Gateway