このブログでは、VMware Cloud Foundation® 9 （VCF 9）の新機能である VMware Cloud Foundation® Automation（VCF Automation） を複数回のテーマに分けてご紹介していきたいと思います。
第3部では、VCF 9 が「3つの管理者ロール」による職務分離（SoD）に基づき、いかに効率的かつ安全な「次世代テナント管理」を実現するかを、導入・運用フローと共に詳細に解説しました。
第4部では、そのテナント分離技術である「VPC（Virtual Private Cloud）」の概念と、それを支える VCF 9 の次世代ネットワークアーキテクチャについて、VMware NSX® のコンポーネントと関連付けながら詳細に掘り下げます。
プライベートクラウドへの「VPC」の必要性
従来のプライベートクラウドのマルチテナントは、多くの場合、vSphere の「リソースプール」や IAM（Identity and Access Management）による「論理分離」に依存していました。
🛑 従来の単一テナントモデル（限界）
ハードウェアと VCF 基盤を全社で共有し、プロジェクトは IAM によってアクセス制御されるだけでした。これでは、リソースの競合は防げても、ネットワークレベルの分離は担保されません。
ネットワーク分離（VLANなど）は、ITインフラ管理者が手動で行う必要があり、これが第1部で述べた「スピードのボトルネック」と「人的ミス」を多く誘発する要因となっていました。
🚀 VCF 9 マルチテナントモデル（次世代）
VCF 9 は、パブリッククラウド（AWS, Azure, GCP）で標準となっている「VPC」の概念を導入しています。
各テナントは、プロバイダーポータルが管理する VCF 基盤上で、ネットワークレベルで完全に分離された専用のプライベートクラウド（VPC）を持つことができます。VPC は、独立したルーティングテーブル、サブネット、FWルール、NAT、ロードバランサ、VPN などを持つ、隔離された仮想ネットワーク空間です。
この VPC によるインフラ分離により、テナント間の不正アクセスを原理的に防止しつつ（ゼロトラストの実現）、リソース消費の一元管理していくことができるようになります。例えば、「GPU 搭載ホスト」を「AI 開発テナント」専用のリージョンとして割り当て、他のテナントからは完全に隔離するといった柔軟な構成を設けることができるようになります。
VCF 9 アーキテクチャを構成する4つの要素
VCF 9 の強力なマルチテナント・アーキテクチャは、主に4つの構成要素で成り立っており、これらは NSX の主要コンポーネントと密接に関連しています。
1. 🌍 リージョン (Region)
- プロバイダー管理者（ITインフラ）が定義する「物理リソースの単位」
- 地理的なドメイン（東京DC、大阪DC）や、特定のハードウェア（GPU クラスタ）を指します
- 技術的背景: VCF 9 では、1つのリージョンは1つの NSXドメイン に相当します
2. 🏢 テナント (Tenant / Org)
- 企業の事業部門（営業本部、開発本部）やクライアント組織に相当する「論理的な管理単位」
- プロバイダーによって作成され、複数のリージョンにまたがってリソースを持つことができます
3. ☁️ VPC (Virtual Private Cloud)
- テナント管理者が作成する「ネットワーク的に分離された空間」
- 用途（開発用、本番用、PCI-DSS 準拠用など）に応じて、テナントが複数の VPC を自由に作成できます
4. 📦 名前空間 (Namespace)
- アプリケーション管理者（開発者）がアプリ（VMやPod）をデプロイする「K8s ベースのワークスペース」
- 必ず特定の VPC に紐づく（Namespace内の VM が vNIC ごとに異なる VPC に接続する構成も可）
- 1つの VPC 内で複数の名前空間がリソースを共有可能
VCF 9 ネットワークの内部構造：TGW と VPC GW
このアーキテクチャは、VCF Automation と NSX の高度なルーティング機能が連携することで実現されています。
🌐 トランジットゲートウェイ (TGW)
各テナントはリージョンごとに独立した TGW を持ちます（NSX Tier-0 VRF 相当）
これがテナントの外部接続とのゲートウェイとなり、外部ネットワークとの接続（North-South 通信）を担う
テナント A と B の TGW はL3 VRF レベルで完全に分離される
テナント内で複数のTGWを作成することもでき、TGWは複数の外部接続を持たせるようなマルチホーム構成をとることもできる
TGWは、NAT や IPsec VPN 、GWFW（L4FWルール）といったネットワークサービスにも対応
VCF 9 では、この操作がテナント管理者や開発者にセルフサービスとして開放
🛡️ VPCゲートウェイ (VPC GW)
各 VPC は専用の VPC GW を持つ（NSX Tier-1 Gateway 相当）
これが VPC 内部の「ルーター」となり、サブネット間の通信（East-West）や TGW 経由の外部通信を制御する
ここで VPC FW （L4FWルール）や NAT といったネットワークサービスにも対応
VCF 9 では、この操作がテナント管理者や開発者にセルフサービスとして開放
🕸️ サブネット (Subnet)
名前空間にひも付くネットワークセグメント（NSX Segment）
VCF 9 では、この操作がテナント管理者や開発者にセルフサービスとして開放
開発者に移譲されるネットワーク権限 (セルフサービス)
このアーキテクチャの最大のメリットは、「権限移譲/セルフサービス」です。従来はITインフラ管理者に集中していたネットワーク操作権限が、安全な形で下位の管理者に移譲されます。
テナント管理者は、VPCを自由に作成・削除や、特定のトラフィック制御や仮想アプライアンス(VNFなど）へのルーティングするためのスタティックルートの設定も可能
アプリケーション管理者（開発者/Project Admin）は、以下の高度な機能をセルフサービスで利用
- 仮想 IP (VIP): ロードバランサと連携し、VM や Pod を外部公開するためのIPを即座に取得
- サブネット（オートスケール対応）: 必要に応じて動的にネットワークを割り当て
- IPAM: DHCP だけでなく、特定の VM への「静的 IP 割り当て」
- Avi ロードバランサ: Avi ロードバランサと連携し、VM や Pod を外部公開したり、LB負荷監視やトランザクションのログ分析をセルフサービスで実施
これにより、開発者は様々なネットワーク設定変更のために IT 部門にチケットを起票し、数日待つ必要がなくなり、俊敏性の向上に寄与する活用を可能にします。
次回、第5部では、この強力な基盤の上で、アプリケーション管理者（開発者）がどのような「セルフサービス IaaS 体験」を得られるのかを、具体的な UI 画面と共に詳しくご紹介します。
VCF 9 詳細ブログシリーズ
- 第1部：プライベートクラウドのジレンマと「運用の行き詰まり」
- 第2部：VCF 9 が提示する解決策「プライベートクラウドポータル」
- 第3部：VCF 9 の「次世代テナント管理」
- 第4部：プライベートクラウドへの「VPC」の必要性とネットワークアーキテクチャ（本記事）
- 第5部：アプリ開発者向け「セルフサービス IaaS」 体験
- 第6部：「App Stack Formation」が実現するガバナンスとスピードの両立
