3行まとめ
このテーマをもう少し広げて見るなら、VKS on VCF 9.1を設計前に確認する：3ゾーン、VPC/VDS、Antrea、LBの実務ポイント と VCF 9.1 Private AI Servicesを導入前に確認する：NSX/VDS、Supervisor、VCF Automationの実務ポイント も合わせて確認してください。VPC Network Spanのクラスタ範囲を、VKSのゾーン、VPC/VDS、ロードバランサ設計と合わせて確認できるため。
VPCサブネットをどのvCenterクラスタへ見せるかを、アプリ配置や専用クラスタの要件と合わせて決めます。
spanはTGWに適用されるため、VPC、TGW、default span、exclusive spanを同じ表で確認します。
Remote Networks、Private TGW IP Blocks、SNAT、providerとtenantの役割を後回しにしないことが重要です。
Network Spanだけで導入可否を決めず、クラスタ、TGW、外部接続、運用責任を同じ流れで確認します。
- VCF 9.1のVPC Network Spanは、VPCサブネットを見せるvCenterクラスタをTGW単位で絞り込むための設計ポイントです。VCF 9.0のように全クラスタへ広く見せる前提ではなく、アプリ配置、DMZ、専用クラスタ、物理ネットワークの伸長範囲を先に決める必要があります。
- Broadcom/VMwareの公式ブログは、Network Spanを「どのクラスタがVPCサブネットを見られるか」の制御として説明し、TechDocsはspanがTGWへ適用されること、default spanとexclusive spanの扱いを示しています。
- 導入前は、Network Spanだけで判断せず、TGW、外部接続、Remote Networks、Private TGW IP Blocks、provider-managed outbound SNAT、テナントとプロバイダの責任分界を同じ表で確認するのが安全です。
VCF 9.1のネットワーク更新で、VPC Network Spanは小さく見えて、実務上はかなり大きな変更点です。ポイントは、VPCサブネットを作れるようになったことではありません。どのクラスタへそのサブネットを見せるかを、明示的な設計項目として扱えるようになったことです。
2026年6月9日にVMware Cloud Foundation Blogが公開した記事では、VCF 9.1のVPC Network Spanを、VPCサブネットの可視範囲を特定のvCenterクラスタへ限定できる仕組みとして説明しています。VCF 9.0ではVPCサブネットが全vCenterクラスタで利用可能になるグローバルなモデルだったのに対し、VCF 9.1ではTGW、つまりTransit Gatewayのレベルで対象クラスタを絞れる、という整理です。
この記事では、その発表をニュースとして読むだけでなく、導入前チェックに変換します。すでに<a href="https://avgo-watch.blog.mo-gmo.com/avgo-21-vcf-91-vks-multi-network-check/">VKSのマルチネットワーク対応</a>や<a href="https://avgo-watch.blog.mo-gmo.com/avgo-32-vcf-operations-onprem-day2-efficiency-check/">VCF OperationsのDay 2運用</a>を見ている読者にとっても、VPC Network Spanは別の論点です。Kubernetesや運用可視化の前に、ネットワークをどのクラスタへ広げるかを決めなければならないからです。
なお、Broadcom Watch JapanはBroadcom Inc.およびVMware by Broadcomとは非提携の独立サイトです。本文は公式情報の確認と導入判断の整理を目的としており、製品購入、契約変更、投資判断の助言ではありません。
VPC Network Spanで何が変わるのか
可視範囲を狭めることはセキュリティポリシーそのものではなく、配置可能範囲を明確にする設計判断です。
VPC Network Spanを読む時は、「新しいネットワーク機能が追加された」とだけ捉えると少し浅くなります。実際の導入判断では、ネットワークの見える範囲を広げるのか、狭めるのか、狭めるなら誰が承認するのか、という運用設計まで含めて考える必要があります。
VPCサブネットの可視範囲をクラスタ単位で扱う
公式ブログは、Network Spanを「visibility」の問題として説明しています。つまり、VPCに紐づくサブネットを、どのvCenterクラスタが見られるかを指定する考え方です。VCF 9.1では、この範囲を特定クラスタへ限定できるため、アプリケーションを置ける場所をネットワーク側から絞り込めます。
TechDocsの「Configure Network Spans」では、Network Spanは管理者がVPCネットワークの可用性を特定のvSphereクラスタ集合へ制限する機能として説明されています。また、spanはTGWへ適用され、そのTGWに接続されたVPCサブネットが、spanに含まれるクラスタで利用可能になるという構造です。
根拠
- 公式ブログは、VCF 9.1でVPCサブネットを特定のvCenterクラスタに限定でき、この制御はTGWレベルで管理されると説明しています。
- TechDocsは、Network SpanをvSphereクラスタ集合に基づいて構成し、TGWへ適用すると説明しています。
- そのため、Network SpanはVPC単体のラベルではなく、TGW、VPCサブネット、クラスタ配置をつなぐ設計項目です。
VCF 9.0の全体可視モデルから、VCF 9.1の対象指定モデルへ
公式ブログは、VCF 9.0ではVPCサブネットが既定で全vCenterクラスタから利用可能だったと整理しています。これは柔軟ではありますが、アプリケーションごとにクラスタ境界を強く意識したい環境では、広すぎる場合があります。
VCF 9.1では、VPCサブネットを特定クラスタへ限定するモデルが加わります。たとえば、外部公開に近いDMZ用途のアプリを専用クラスタに寄せる、規制要件のある業務を特定クラスタだけに置く、物理ネットワークのバッキングを必要な場所だけに用意する、といった判断がしやすくなります。
注意点
Network Spanは、セキュリティポリシーやファイアウォールの代替ではありません。サブネットの可視範囲を限定できることと、通信をすべて許可または遮断できることは別です。DMZや専用クラスタの話をする場合も、Network Span、分散ファイアウォール、ルーティング、ロードバランサ、監査ログを分けて確認する必要があります。
TGWとSpanを同じ表で確認する
- 1Regionとconnectivity profile
TGWを作成する前に、対象regionと利用できるconnectivity profileを確認します。
- 2TGW
VPCを接続する中間点として、用途、接続VPC、外部接続、クラスタ範囲をまとめます。
- 3default span
何も指定しない時の可視範囲を、暫定設定ではなく設計上の選択として記録します。
- 4exclusive span
特定クラスタに限定したいVPCサブネットは、共有クラスタや退避先の扱いも合わせて確認します。
- 5VPCと外部接続
TGWにつながるVPC、external connections、経路の責任者を同じ台帳で管理します。
spanの設定だけではVPCの出口設計は決まりません。TGWの役割と外部接続を同じ単位で見ます。
VPC Network Spanを導入前に読むなら、最初にTGWを確認します。公式ブログでもTechDocsでも、spanはTGWに関係します。VPCごとに思いつきで範囲を変えるのではなく、TGWの役割、接続するVPC、外部接続、クラスタ範囲を一つの設計表にまとめるのが現実的です。
TGWはVPCと外部接続の中間にある
TechDocsの「Create a Transit Gateway in VCF Automation」は、Organization Administratorが組織内のTGWを作成、編集、削除でき、TGWをVPCへ接続すると説明しています。作成前には、組織に割り当てられたregion、利用可能なexternal connections、対象regionのconnectivity profileを確認する流れです。
ここで重要なのは、Network Spanの設定だけを見ても、VPCの出口設計は決まらないことです。TGWがどのVPCにつながるのか、どの外部接続を使うのか、どのregionで使うのか、connectivity profileが用意されているのかを先に確認しなければなりません。
確認項目
| 確認するもの | 見る理由 | 決めること |
|---|---|---|
| TGW名と用途 | どのVPC群を束ねるかを明確にする | 共有用、DMZ用、業務専用などの役割 |
| 対象region | 組織に割り当てられた範囲で作る必要がある | どのregionにTGWを置くか |
| external connections | 物理ネットワークや外部経路との接続点になる | 既存の接続を使うか、新規に用意するか |
| connectivity profile | VPC作成や接続の前提になる | 不足していれば作成手順を確認する |
| Network Span | VPCサブネットを見せるクラスタ範囲になる | default spanか、専用spanか |
default spanとexclusive spanを混同しない
TechDocsは、cluster-based spanをvSphereクラスタの集合として説明しています。TGW作成時には既定でdefault spanが関連付けられる、という扱いです。default spanは、exclusive spanに含まれるクラスタを除き、環境内のVTEP vCenterクラスタやstandalone hostを含むものとして説明されています。
一方で、exclusive spanは専用ワークロード向けに使う考え方です。通常、vCenterクラスタは複数spanで共有され得ますが、exclusive spanに含まれるクラスタは他のspanと共有または重複しない形で扱われます。
条件
default spanを使うか、exclusive spanを使うかは、次の条件で分けると判断しやすくなります。
| 条件 | default span寄り | exclusive span寄り |
|---|---|---|
| アプリの配置 | 複数クラスタへ広く配置してもよい | 特定クラスタだけに置きたい |
| セキュリティ境界 | 共有クラスタの前提で設計できる | DMZ、規制、専用運用などで分離したい |
| 物理ネットワーク | 多くのクラスタにバッキングを用意できる | 必要なクラスタだけに絞りたい |
| 運用変更 | 柔軟な移動を優先する | 承認済みの配置範囲を優先する |
| 障害時退避 | 広い候補を残したい | 退避先も限定しておきたい |
TGW作成時の「何も指定しない」を設計判断にする
TechDocsの分散VLAN接続の手順では、Transit Gatewayにspanを関連付ける項目があり、spanを指定しない場合はdefault spanが関連付けられると説明されています。その場合、exclusive spanに含まれるクラスタを除き、TGWに接続されたサブネットが広い範囲で利用可能になります。
これは便利な既定値ですが、導入前チェックでは「指定しなかった」ではなく「default spanでよいと判断した」と記録するべきです。特に、DMZ用途、外部公開アプリ、監査対象システム、専用GPUクラスタ、特定部門の閉じた環境では、既定値のままにしてよいかを確認する価値があります。
証跡
設計メモには、少なくとも次を残します。
- TGW名、対象VPC、対象サブネット、対象span。
- default spanを使う理由、またはexclusive spanを使う理由。
- spanに含めるクラスタ名と、含めないクラスタ名。
- クラスタ追加、削除、用途変更時の承認者。
- span変更後に確認する疎通、ファイアウォール、ロードバランサ、監視の項目。
配置、DMZ、DTGWを分けて読む
対象ワークロードが使うVPCサブネットと、配置先クラスタのCPU、メモリ、監視、DR条件をそろえます。
サブネットの可視範囲を限定しても、ファイアウォール、監査ログ、ロードバランサ、運用権限は別に設計します。
必要なクラスタだけにVLANや外部接続を寄せたい場合、物理ネットワークを伸ばす範囲として確認します。
Network Spanは配置候補を絞る材料です。DMZやDTGWの完成形は、接続、監査、運用の設計まで含めて判断します。
公式ブログは、VPC Network Spanの利点として、粒度の細かいアプリケーション配置、DMZのような専用セキュリティゾーン、DTGW最適化によるネットワーク効率を挙げています。ここは導入前の記事で一番誤解が出やすい部分です。三つの話はつながっていますが、同じものではありません。
アプリ配置は「クラスタに置けるか」まで見る
Network Spanを狭めると、VPCサブネットが見えるクラスタも狭まります。これは、アプリケーションを置ける候補を明示的に絞ることでもあります。
たとえば、ある業務アプリを専用クラスタだけに置きたい場合、Compute側の配置ルールだけでなく、そのアプリが使うVPCサブネットも同じクラスタ範囲に揃える必要があります。逆に、ネットワークだけを絞っても、アプリの移動、容量計画、DR設計、運用アラートが別々に動いていると、実際の運用では混乱します。
確認項目
- そのVPCサブネットを使うワークロードは、どのクラスタに配置される予定か。
- そのクラスタには必要なCPU、メモリ、ストレージ、GPU、NIC、ライセンス、監視がそろっているか。
- DRSや手動移動で、span外のクラスタへ移そうとする運用が起きないか。
- 障害時に一時退避するクラスタをspanに含めるのか、退避時だけ変更するのか。
- アプリチームが「ネットワークが見えない」状態を障害として扱わないよう、事前に説明できているか。
DMZはNetwork Spanだけで完成しない
公式ブログは、DMZ VPCを作り、Network Spanを特定の強化されたvCenterクラスタに制限する例を示しています。これは導入判断として分かりやすい一方、DMZという言葉だけが独り歩きしやすいところです。
Network Spanでできるのは、VPCサブネットの可視範囲をクラスタ単位で制限することです。外部公開の入口、ロードバランサ、NAT、分散ファイアウォール、WAF、ログ保全、脆弱性対応、変更承認まで自動で設計されるわけではありません。
注意点
DMZ用途で使うなら、Network Spanの表とは別に、通信制御の表を作ります。
| 領域 | Network Spanで見ること | 別途見ること |
|---|---|---|
| クラスタ境界 | どのクラスタにサブネットを見せるか | ホスト構成、物理分離、運用権限 |
| 通信制御 | 直接の代替ではない | DFW、ゲートウェイFW、NAT、ロードバランサ |
| 外部公開 | TGWや外部接続と関係する | 公開IP、証明書、WAF、Avi Load Balancer |
| 監査 | span変更の証跡を残す | ログ保存、変更管理、検知ルール |
| 障害時 | 退避先クラスタを決める | DNS、ルーティング、ロードバランサ切替 |
DTGWはVLANを伸ばす範囲の話として読む
公式ブログは、Distributed Transit Gateway、つまりDTGWとNetwork Spanを組み合わせることで、VLANをすべてのvCenterクラスタへ伸ばす必要を減らせると説明しています。必要なワークロードがいる場所にだけネットワークバッキングを用意する、という読み方です。
この点は、物理ネットワーク担当者にとって重要です。クラウドチームが「VPCサブネットを使える」と考えていても、実際には物理ファブリック、VLAN、外部接続、ルーティング、監視の準備が必要です。Network Spanを狭めることで、必要なクラスタだけにバッキングを寄せられる可能性があります。
評価基準
DTGWとNetwork Spanを組み合わせる場合は、次の観点で確認します。
- VLANや外部ネットワークを全クラスタへ伸ばしている理由が、今も残っているか。
- 特定クラスタだけにネットワークバッキングを置いた場合、移動、DR、メンテナンスに支障が出ないか。
- 中央集約型の接続と分散型の接続を混同していないか。
- 外部接続の作成、公開、テナントへの割り当てを誰が行うか。
- VNA cluster、Avi Load Balancer、stateful serviceなど、DTGWの周辺論点を本番設計でどう扱うか。
ここでの結論は、「VCF 9.1ならVLANを伸ばさなくてよい」ではありません。正しくは、「VPCサブネットを見せるクラスタ範囲を絞れるため、物理ネットワークをどこまで用意するかを再設計できる場合がある」です。
外部接続とルーティングを後回しにしない
- 1provider
Enterprise AdminがExternal Connectionsや物理ネットワーク側の接続条件を用意します。
- 2tenant
Project AdminやVPC AdminがTGW、VPC Gateway、subnetなど仮想ネットワーク層を扱います。
- 3Remote Networks
外部ネットワークやリモート接続先を、どのTGW経由で使うかを確認します。
- 4Private TGW IP Blocks
private subnetを扱う場合、TGW側のIPブロックと経路の割り当てを確認します。
- 5provider-managed outbound SNAT
外向き通信のSNATを誰が管理し、どの通信を対象にするかを明確にします。
アプリチームの配置希望だけでは完結しません。外部接続、経路、SNAT、変更権限を合わせて確認します。
Network Spanはクラスタ範囲の話ですが、TGWを使う以上、外部接続とルーティングの確認を後回しにはできません。VMware Cloud Foundation Blogの2026年5月12日記事は、VCF 9.1のTransit Gateway接続オプションとして、Remote Networks、Private TGW IP Blocks、provider-managed outbound SNATを整理しています。
providerとtenantの責任を分ける
同記事では、VCFの仮想ネットワーク責任をproviderとtenantに分けています。provider、つまりEnterprise Adminは、centralizedまたはdistributed VLAN/VXLAN connectivityのようなExternal Connectionsを定義します。tenant側のProject AdminやVPC Adminは、TGW、VPC Gateway、subnetなどの仮想ネットワーク層を扱います。
この分担は、Network Spanの記事でも非常に重要です。アプリチームが「このVPCをこのクラスタだけに置きたい」と考えても、外部接続や物理ネットワークの抽象化はprovider側が準備することが多いからです。
確認項目
| 役割 | 主に見るもの | Network Span導入前の確認 |
|---|---|---|
| Enterprise Admin | External Connections、物理ネットワーク、provider-managed SNAT | spanに含めるクラスタへ必要な外部接続を用意できるか |
| Organization Admin | TGW、組織内のregion、VPC接続 | default TGWでよいか、新しいTGWを作るか |
| Project Admin | プロジェクト内の接続、VPC運用 | アプリ配置とクラスタ範囲が合っているか |
| VPC Admin | VPC Gateway、subnet | subnetの用途とspanの範囲が合っているか |
| アプリ運用者 | VM、コンテナ、疎通、SLO | span外へ移動できないことを理解しているか |
Remote Networksは出口の選び方に効く
Transit Gateway Connectivity Optionsの記事では、VCF 9.1でtenantがTGWを複数のexternal connectionsへ接続でき、Remote Networksフィールドがどのトラフィックをどの外部接続へ流すかを決めると説明されています。remote networkを指定しない外部接続はdefault routeとして働き、追加の外部接続ではより具体的なrouteを指定する、という整理です。
Network Spanでクラスタ範囲を絞っても、出口経路が曖昧なら、本番設計としては不十分です。たとえば、あるVPCはインターネット向け、別のVPCは社内データセンター向け、さらに別のVPCは共有サービス向けという場合、Remote Networksの設計がTGW単位で必要になります。
注意点
- Network Spanは「どこに見えるか」を決める。
- Remote Networksは「どこへ出るか」を決める。
- External Connectionsは「どの物理または外部経路を使うか」を決める。
- NATやSNATは「どのアドレスとして出るか」を決める。
この四つを一つにまとめてしまうと、障害時の切り分けが難しくなります。導入前の設計表では、列を分けて書く方が後から効きます。
Private TGW IP BlocksとSNATは、private subnetの扱いを変える
Transit Gateway Connectivity Optionsの記事は、private TGW subnetは設計上TGW内に閉じ、external connections経由で通信できないと説明した上で、VCF 9.1ではproviderがPrivate IP Blocksを有効化することで、private TGW subnetをexternal connection経由で拡張できると説明しています。この場合、VMはnative private IP addressでデータセンターネットワークと通信できます。
ただし、同記事ではインターネット向けには引き続きSNATが必要になる例も示されています。さらに、provider-managed outbound SNATでは、tenantごとにSNATを構成させるのではなく、provider側がSNAT用IP blocksを定義し、tenant VMの外向き通信を集中的に制御できます。
評価基準
導入前には、次を分けて確認します。
| 論点 | 確認すること |
|---|---|
| private TGW subnet | TGW内に閉じる前提でよいか、外部接続へ拡張する必要があるか |
| Private IP Blocks | 有効化した場合、どのデータセンターネットワークとnative IPで通信するか |
| インターネット接続 | private subnetから外へ出る時にSNATが必要か |
| provider-managed SNAT | tenant任せではなくprovider側でSNATを集約するか |
| 監査 | どのIPで外へ出たかを、誰がどのログで追えるか |
導入前チェックリスト
PoCでは通信できることだけでなく、span外のクラスタで想定外に使えないことも確認します。
VPC Network Spanは、設定項目だけを追うと小さく見えます。しかし、実際にはクラスタ設計、TGW設計、外部接続、物理ネットワーク、運用責任をまたぐ変更です。PoC前には、少なくとも次の順で確認します。
まずクラスタ範囲を決める
最初に決めるのは、どのVPCサブネットをどのクラスタへ見せるかです。ここで「あとから変えればよい」と考えると、アプリ配置、監視、疎通試験、障害時退避のすべてが曖昧になります。
確認項目
- 対象ワークロードは、共有クラスタでよいのか、専用クラスタが必要なのか。
- DMZ、規制、データ所在地、性能、GPU、運用権限など、クラスタを分ける理由があるか。
- spanに含めないクラスタへ、将来移す可能性があるか。
- 移す可能性があるなら、Network Spanを広げるのか、別TGWを作るのか。
- クラスタを退役、追加、用途変更した時のspan見直し手順があるか。
TGWとVPCの対応表を作る
次に、TGWとVPCの対応を作ります。default TGWを使うのか、新しいTGWを作るのか、TGWごとにどのspanを使うのかを決めます。
設計表の例
| TGW | 用途 | 接続VPC | span | 外部接続 | 備考 |
|---|---|---|---|---|---|
| tgw-shared | 共有業務 | common-app-vpc | default span | internet, shared-services | 広い配置を許容 |
| tgw-dmz | 外部公開 | dmz-vpc | exclusive span | dmz-internet | 専用クラスタへ限定 |
| tgw-data | 社内連携 | data-vpc | data-cluster span | dc-connection | Remote Networksを明示 |
表は単純で構いません。重要なのは、TGW、VPC、span、外部接続を同じ行に置くことです。別々の資料に分かれていると、変更時にずれます。
外部接続と経路を確認する
Network Spanでクラスタ範囲を決めた後は、外部接続と経路を確認します。特にDTGWを使う場合、物理ネットワーク側の準備がどのクラスタに必要かを明確にします。
確認項目
- 対象spanに含まれるクラスタで、必要な外部接続が利用できるか。
- Remote Networksで、データセンター向け、インターネット向け、共有サービス向けの経路を分ける必要があるか。
- private TGW subnetを外部へ拡張する必要があるか。
- SNATをtenantが持つのか、provider-managed outbound SNATへ寄せるのか。
- ロードバランサやVNA clusterを使う場合、Network Spanの範囲と整合しているか。
変更時の承認とロールバックを決める
spanは一度決めて終わりではありません。アプリの移設、クラスタ増設、DR演習、物理ネットワーク変更、セキュリティ要件変更で見直しが必要になります。
注意点
- span変更は、アプリチーム、ネットワークチーム、セキュリティチーム、運用チームの境界にあります。
- 変更前後で、VMやコンテナの配置可能クラスタ、疎通、監視、バックアップ、DR手順が変わる可能性があります。
- ロールバックは、単に設定を戻すだけではなく、外部接続、経路、SNAT、ロードバランサ、DNS、監視の戻し方まで含めます。
PoCで見るべき成功条件
PoCでは、VPC Network Spanの画面操作だけを成功条件にしない方がよいです。成功条件は、クラスタ範囲を絞った時に、アプリ配置、疎通、監視、変更手順が想定どおり動くことです。
評価基準
- span内クラスタでは、対象VPCサブネットを使うワークロードを正常に配置できる。
- span外クラスタでは、意図せず対象サブネットを使えないことを確認できる。
- Remote Networksや外部接続の選択により、想定した出口へ通信できる。
- private subnet、SNAT、provider-managed SNATの動作を、ログで追跡できる。
- span変更時の影響範囲を、アプリ運用者へ説明できる。
- 障害時退避の候補クラスタが、span設計と矛盾していない。
使うべきケース、慎重に見るケース
単純な優劣ではなく、クラスタ固定の価値と運用の柔軟性のどちらを重く見るかで判断します。
VPC Network Spanは、すべての環境で必ず狭く使うべき機能ではありません。広い可視性が必要な環境もあります。大事なのは、広くするか狭くするかを既定値任せにしないことです。
使うべきケース
次のような場合は、Network Spanの導入効果を確認する価値があります。
- 外部公開アプリやDMZ用途を、特定クラスタへ寄せたい。
- 監査対象システムを、共有クラスタから分けたい。
- 物理ネットワークやVLANを、全クラスタへ伸ばしたくない。
- 部門、テナント、業務ごとにVPCサブネットの見える範囲を分けたい。
- アプリの配置可能範囲を、ネットワーク設計でも明確にしたい。
- DTGWを使い、必要なクラスタだけに外部接続を寄せたい。
慎重に見るケース
一方で、次のような場合は、狭めることが逆に運用負荷になる可能性があります。
- アプリが頻繁にクラスタ間を移動する。
- 障害時退避先を広く確保する必要がある。
- まだ業務ごとの配置ポリシーが決まっていない。
- アプリチームが、どのクラスタに置くかを意識しない運用になっている。
- 物理ネットワーク、外部接続、ロードバランサの担当が分かれており、変更調整に時間がかかる。
- 既存の監視や自動化が、全クラスタで同じネットワークが見える前提になっている。
判断の目安
本番前に「狭める理由」と「広げる理由」を両方書けるなら、Network Spanの設計に入る準備があります。片方しか書けない場合は、まだ要件が偏っている可能性があります。
導入判断のまとめ
- 1クラスタ範囲
どのVPCサブネットをどのクラスタへ見せるかを決めます。
- 2TGW
spanを適用するTGWと、接続するVPCを整理します。
- 3外部接続
External Connections、Remote Networks、物理ネットワークの伸長範囲を確認します。
- 4Private TGW IP BlocksとSNAT
private subnetや外向き通信の扱いを確認します。
- 5運用責任
変更承認、監視、DR、ロールバック、providerとtenantの役割を決めます。
Network Spanを先に設定すると、物理ネットワーク、ロードバランサ、DR、監視、変更承認の確認が後追いになりやすくなります。
VCF 9.1のVPC Network Spanは、ネットワークを狭く見せる機能というより、VPCサブネットの可視範囲をクラスタ設計の一部として扱うための機能です。TGWにspanを適用することで、どのクラスタがそのVPCサブネットを使えるかを明確にできます。
導入前に見るべき順番は、クラスタ範囲、TGW、外部接続、Remote Networks、Private TGW IP Blocks、SNAT、運用責任です。Network Spanだけを先に設定すると、後から物理ネットワーク、ロードバランサ、DR、監視、変更承認の話が追いつかなくなります。
すでにVCF 9.1への移行やパッチ適用を進めている場合は、<a href="https://avgo-watch.blog.mo-gmo.com/avgo-27-vcf-91-express-patch-0100-check/">VCF 9.1 Express Patch 01の確認ポイント</a>や<a href="https://avgo-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月の重要トピックまとめ</a>も合わせて確認すると、ネットワーク変更とライフサイクル管理を同じ時系列で見直しやすくなります。
次に読むなら
参照した主な情報源
- VMware Cloud Foundation Blog「VCF 9.1 Networking: Precision Workload Placement with VPC Network Span」
https://blogs.vmware.com/cloud-foundation/2026/06/09/vcf-9-1-networking-precision-workload-placement-with-vpc-network-span/ 確認日：2026年6月10日 JST
- Broadcom TechDocs「Configure Network Spans」
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/building-your-private-cloud-infrastructure/managing-virtual-private-clouds-in-vcenter/add-network-span.html 確認日：2026年6月10日 JST
- Broadcom TechDocs「Create a Transit Gateway in VCF Automation」
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/organization-management/adding-and-managing-virtual-private-clouds/create-a-transit-gateway-in-vcf-automation.html 確認日：2026年6月10日 JST
- Broadcom TechDocs「Add a Transit Gateway with a Distributed VLAN Connection」
https://techdocs.broadcom.com/jp/ja/vmware-cis/vcf/vcf-9-0-and-later/9-1/add-a-transit-gateway-with-distributed-external-connections.html 確認日：2026年6月10日 JST
- VMware Cloud Foundation Blog「Transit Gateway Connectivity Options in VCF 9.1」
https://blogs.vmware.com/cloud-foundation/2026/05/12/transit-gateway-connectivity-options-in-vcf-9-1/ 確認日：2026年6月10日 JST