クラウドの仮想ネットワークは、どのように「成立」しているのか ── VPC・セキュリティグループ・PrivateLink・VPCピアリングの内部機構を、AWS・GCP・Azure の一次資料でたどる

この記事をお読みの皆様は、日々、AWSやGoogle Cloud、Azureなどのクラウド上で、VPCを作ったり、VPCピアリングでVPCどうしを通信経路でつないだり、PrivateLinkでセキュアな通信経路を確立させて、日々の仕事をなさっているのではないでしょうか？

しかし、VPCピアリングやPrivateLinkなどの通信は、どのような仕組みで成り立っているのでしょうか？

クラウドの通信の仕組みについては、ウェブ上でも、意外と多くは語られていない印象 があります。

そこにケーブルはなく、専用のネットワーク機器もありません。

あるのは、各サーバーの内部で動く ソフトウェア ── SDN（Software Defined Network） です。

かつて物理ネットワークを仕切っていた VLAN の思想は、いまどこへ行き、どう姿を変えて、この巨大なクラウドを支えているのか。

この記事は、AWS・GCP・Azure という大手クラウドで、VLANとSDNが実際にどう組み込まれ、動いているのかを正面から取り上げます。

VPC・セキュリティグループ・PrivateLink・VPCピアリングという「クラウド利用者に見える機能」の裏側を、各社が公開した一次資料をたどりながら、クラウド中級者以上の読者の皆様に向けて、解き明かしていきます。

TL;DR

• クラウドの VPC・セキュリティグループ・PrivateLink・VPCピアリングは、専用の物理配線でも、物理的なファイアウォール機器でも実現されていません。
  これらはすべて、各物理サーバーの内部で動作するホストSDN（仮想スイッチ、あるいは SmartNIC）が、ソフトウェアとして成立させているものです。
   
• その背景には、「VLANだけでは、ハイパースケールのクラウドは作れない」 という事情があります。 VLAN（$4,094$個の壁） $→$ VXLAN/Geneve（オーバーレイ） $→$ SDN → ホストSDN、という一本の進化史が、いまのクラウドを形づくっています。
   
• 設計原理は、コントロールプレーン（頭脳）とデータプレーン（手足）の分離、オーバーレイ（仮想の論理的なネットワーク）と基盤（物理的なネットワーク）の分離、そして両者を結ぶ マッピング（住所変換） の３点です。
   
• 各社のクラウド実装は公表されています。AWS は Nitro Card for VPC、GCP は Andromeda、Azure は VFP ＋ AccelNet。本記事は、これらの一次資料（査読論文・公式デック・公式ドキュメント）を逐一引用して解説します。
   
• AWS も Google Cloud も Azure も、SDN を用いるという考え方は同じです。
  しかし、その実装哲学は異なります。
  データプレーンをどこで実行するか（AWS＝専用HW / GCP＝SW主軸 / Azure＝FPGA）、制御プレーンをどのようにスケールさせるか（GCPのHoverboard等）という選択の違いが、３者の性能・拡張性・可用性・セキュリティといった実務的なパフォーマンスの差の背景にあります。この記事は、その差異を、表と図で整理します（第７章）。
   
• この仕組みは、「フローごとの個別認可（per-flow authorization）」 を土台とします。
  「デフォルトで拒否される」「なりすましができない」「テナントが完全に分離される」といった性質は、ここから演繹的に導かれます。
  セキュリティグループ・ピアリング・PrivateLinkの挙動も、すべてこの一点から説明できます。
   
• 大きな見取り図として、この記事は、「ネットワークの知能が、専用機器から、各サーバーへ移った」 という歴史的転換の記録でもあります。

想定読者

• AWS・GCP・Azure を日常的に運用し、VPC・サブネット・セキュリティグループ・PrivateLink・ピアリングを設定した経験がある方。
   
• それらが「動く」ことは知っているが、「どうやって成立しているのか」 を、公式の一次資料に基づいて理解したい方。
   
• SDN・オーバーレイ・SmartNIC・VXLAN といった語に、抵抗のない方。
   
• 設計レビューやセキュリティ監査の場で、「なぜこの構成が安全と言えるのか」を、根拠をもって説明したい方。

この記事を読む価値

クラウドのネットワークは、抽象化がよくできているために、内部機構を知らなくても運用できてしまいます。

しかし、クラウド利用者が技術的な仕組みを「知らなくてよい」状況は、いくつかの重要な場面で、確実に限界を迎えます。

1. セキュリティ設計の根拠を、自分の言葉で語れるようになる。
   セキュリティグループのステートフル性も、PrivateLinkの安全性も、内部機構を理解した上で説明できるようになります。監査や設計レビューの場で、効果を発揮します。
    
2. 障害・制約の理由が腑に落ちる。
   「なぜVPCピアリングは推移的でないのか」「なぜ重複CIDRだとピアリング不可でPrivateLinkなら可能か」── 仕組みを知れば、制約が生じる根拠も理解可能になります。
    
3. 一次資料の場所を押さえられる。
   各クラウド事業者が公表した査読論文や技術文書などの１次資料に基づいて、クラウドの仕組みをおさえることができます。この記事は、１次資料の 地図（全体像） を皆様にお届けします。
    
4. 知識が、そのまま設計判断に変わる。
   本記事の後半では、内部機構の理解を、具体的な設計判断（なぜSGを基本に据えるのか、なぜPrivateLinkで公開するのか、なぜPeeringを乱立させないのか）へと接続します。
    
5. ３社の設計思想が、どこで分かれるのかがわかる。
   VLAN/SDN の視点で見たとき、AWS・GCP・Azure の設計思想がどこで分かれ、それがセキュリティ・拡張性・可用性・性能のパフォーマンスの違いとして現れるのかを、表と図で解説します（第７章）。
   このあたりの理解は、マルチクラウドや移行の設計判断に直結します。

全体像 ── 結論を図で先取りする

最初に、この記事の結論を一枚の絵で示します。

皆様が設定する上位の抽象レイヤ（VPC・セキュリティグループ）は、下へ下へと翻訳され、最終的に各物理サーバーのSmartNIC/仮想スイッチで具体化・実体化される

── この縦の貫通が、すべての土台です。

それでは、最初の問いから始めましょう。

---

第１章：問い ──「配線」も「機器」もないのに、なぜ通信は成立するのか？

改めて考えてみましょう。

皆様が VPC を作り、その中に２台のインスタンスを起動し、セキュリティグループで 443 番ポートだけを許可したとします。

両者は通信できます。

しかし、このとき皆様は、ケーブルを一本も挿していません。
ファイアウォール機器も、一台も設置していません。
ルーターの設定ファイルも、一行も書いていません。

にもかかわらず、

• ２つのインスタンスは、プライベートIPで通信でき、
• 別のお客様のVPCからは、完全に隔離され、
• 許可していないポートは、確実に遮断され、
• 同じ物理ネットワーク上を流れているはずなのに、他人の通信を覗くことも、なりすますこともできません。

この「物理的な実体がないのに、堅牢に成立している」という事実こそ、クラウドネットワークの本質です。

このようなクラウドネットワークを成り立たせているのは、物理サーバーの内部で動くソフトウェア（ホストSDN） です。

---

第２章： ホストSDN、オーバーレイ、そしてマッピング

現代のクラウドは、ネットワークの仮想化を、ネットワーク機器ではなく、計算を行うサーバーそのものの内部で行います。

これを、 ホストSDN（host SDN） と呼びます。

各物理サーバーには、仮想スイッチ(virtual switch) や、ネットワーク処理専用の SmartNIC(スマートNIC) が備わっており、そこで、「どのパケットを、どこへ、通してよいか」という方針が強制的に執行されます。

まず、SDNの定義を、少し厳密に見てみましょう。

SDN とは、ネットワークの制御を中央に集約し、各転送装置（スイッチ/NIC）は、その制御結果だけを実行する、という設計思想である。

言い換えれば、「何を、どう通すか」を決める制御（コントロールプレーン）と、「実際に運ぶ」転送（データプレーン）を分離することです。この定義を軸に、原理を３つの層で整理します。

1. コントロールプレーンとデータプレーンの分離。
   頭脳を中央のソフトウェアに集約し、手足を各ホストへと分散させます。
    
2. オーバーレイ（論理的なネットワーク）と物理基盤（アンダーレイ）の分離。
   クラウド利用者の目に見える仮想ネットワーク（VPC）は、物理ネットワークの上に重ねられた論理的な仮想の層（オーバーレイ）です。
   パケットは物理網を渡るときカプセル化（encapsulation）され、宛先ホストで復元されます。
    
3. マッピング（住所変換）。
   「この仮想IPは、物理的にどのサーバーか」を解決するマッピングサービスが、論理の世界と物理の世界を結びます。
   解決時に送信元・宛先の双方が正当かを検証します ── これが後述するセキュリティの要です。

上図：
制御（コントロールプレーン）が方針（ポリシー）を決め、転送（データプレーン）が実際にパケットを運ぶ。オーバーレイの仮想IPは、マッピングによって物理サーバーへ解決され、送信元・宛先の検証を経て、カプセル化されて基盤（substrate）を渡る。

歴史的補足（この設計思想の起点、OpenFlow）。

この 「制御と転送の分離」という設計思想 が広く注目されたのは、2010年前後の OpenFlow でした。

当時は、中央コントローラが各スイッチのフロー表を、直接書き換える形が理想とされました。

しかし、ハイパースケールの現実の前に、現在の大規模クラウドは OpenFlow そのものではなく、同じ思想を各社独自の実装（後述の Nitro / Andromeda / VFP）へと発展させていきました。

この 「集中制御の理想が、なぜ分散オフロードへ着地したのか」という変遷史そのもの は、稿を改めて別の記事で論じる予定です。

これら３点を、AWS・GCP・Azure は、それぞれ独自の方式で実装しています。

以下、各社から公表された１次資料に基づいて見ていきますが、その前に、そもそもなぜこの方式が必要になったのか ── VLAN の限界から確認します。

---

第３章：VLANはどこへ行ったのか？ ──「4094の壁」と、オーバーレイへの進化

「クラウドのネットワークは、結局 VLAN でできているのか？」
── これは、経験のある技術者ほど抱く、自然な問いです。

答えは明確です。

利用者に見える仮想ネットワークの分離は、VLANではありません。
このあたりの歴史的な事情を紐解いていきます。

VLAN とは？

VLAN（IEEE 802.1Q）は、物理的な $L2$ ネットワークを論理的に分割する技術 です。

イーサネットフレームに付与される VLAN ID は 12 ビット。
したがって、識別できるセグメントは 最大 $4,094$ 個（0 と 4095 は予約） に限られます。

4,094個では、足りない？

ハイパースケールのクラウドが扱うのは、数百万のVM、数十万のテナント/VPC、そしてIPレンジが重複する多数の顧客です。

$4,094$という数字は、この規模にはまったく届きません。

加えて、VLAN は $L2$ の技術であり、$L3$ で結ばれた広大なデータセンターをまたぐのにも適していません。

VLANは、同じ建物（セグメント）の中に閉じる $L2$ の技術です。
その一方で、クラウドのデータセンターは、$L3$ で結ばれた広域に広がります。

だからこそ、$L2$ に閉じる VLAN では、データセンターをまたぐことができないのです。

だから、オーバーレイへと進化した。

この限界を超えるために生まれたのが、オーバーレイ・カプセル化です。

代表的なものが VXLAN (RFC 7348)で、$L2$ フレームを $L3$ の UDP/IP パケットに包み、24 ビットの VNI によって 約 1,600 万 （$2^{24}$） のセグメントを扱えます。

さらに拡張性を高めた後継が Geneve（RFC 8926）です。

VXLANのヘッダが固定的で、運べる制御情報が限られていたのに対し、Geneveは、可変長のオプション領域を備えます。

これにより、カプセル化のヘッダに、後から必要になったメタデータ（テナントの識別情報や、転送・セキュリティ処理のためのタグなど）を、仕様を作り直すことなく柔軟に追加することが可能となります。

ネットワーク仮想化が扱う情報は年々増えていきますが、Geneve は、その将来の拡張を、あらかじめ設計に織り込んでいるのです。

そして、ハイパースケーラは、しばしば独自のカプセル化を採ります。

AWS は、既存の VXLAN や MPLS が自社の規模では通用しないため、独自方式を用いると公表しています（第４章）。

VLAN は「消えた」のではなく、「下層へ追いやられた」。

クラウド事業者の物理ネットワーク内部では、VLAN が使われることは依然としてあります。

しかし、皆様（クラウド利用者）が設計する仮想ネットワークの分離を担っているのは、VLAN ではなく、オーバーレイとホストSDNです。

VLAN は、いわばクラウドを理解するための出発点であって、その役割は、より上位のソフトウェア層へと引き継がれた のです。

一本の流れとして描くと、こうなります

── VLAN → VXLAN / Geneve（オーバーレイ） $→$ SDN（制御と転送の分離） $→$ ホストSDN（各ホストでの強制）。

各社の実装を比べるときの「比較の軸」

この記事の第４章から６章で、各社の実装の解説に深く入り込む前に、比較の軸を先にお示しいたします。

• AWS ── 専用ハードウェアへのオフロード。 VPC のデータプレーンを、専用のNitro Cardに逃がす。
• GCP ── ソフトウェア主軸＋賢いスケーリング。 高性能なソフトウェアデータパスと、Hoverboard モデルで数百万VMへ。
• Azure ── プログラム可能な仮想スイッチを、FPGAへ。 多層マッチ・アクション表（VFP）を、FPGA SmartNIC（AccelNet） へオフロード。

いくつか、耳慣れない固有名詞が出てきますので、用語の意味を補足しておきます。

• Nitro Card とは、AWS のサーバーに搭載された、ネットワーク処理専用のハードウェアカードです。本来 CPU が行う通信の仕事を、この専用カードが肩代わりします。
   
• Hoverboard とは、GCP が用いる制御の仕組みの名前です。すべての通信を細かく管理するのではなく、通信量の多い「重要な通信」だけを選び出して手厚く処理する、という賢いスケーリングの方式を指します。
   
• 多層マッチ・アクション表（VFP） とは、Azure のサーバー上で動く、プログラム可能な仮想スイッチです。「この条件に一致したら（マッチ）、こう処理する（アクション）」という規則を何層も重ねることで、仮想化・NAT・アクセス制御などを一貫して表現します。
   
• FPGA SmartNIC（AccelNet） とは、その仮想スイッチの処理を肩代わりさせる、書き換え可能なハードウェアチップ（FPGA）を載せた高機能なネットワークカードです。ソフトウェアの柔軟さを保ちながら、ハードウェアに近い速度を実現します。

上図：
各社の設計アプローチを並べて比較しました。

AWS は、VPC のデータプレーンを、CPU から専用ハードウェア（Nitro Card）へ逃がします。
GCP は、高性能なソフトウェアデータパスと Hoverboard モデルで、数百万VMへスケールさせます。
Azure は、多層マッチ・アクション表（VFP）を、FPGA SmartNIC（AccelNet）へオフロードします。

---

第４章： AWS ── Nitro Card for VPC と、マッピングサービス

この章の要点

• 実装の中心： Nitro Card for VPC （専用ハードウェアへのデータプレーンのオフロード化）
• 最大の特徴：カプセル化・セキュリティグループ・ルーティングを、CPUではなく専用カードで処理
• 他社との違い：徹底したハードウェア専用化。独自カプセル化とマッピングサービスで大規模に対応

AWS のネットワーク仮想化は、Nitro システムの一部として実装されています。

要点は、VPC のデータプレーン処理を、ホストCPUから、専用ハードウェアである「Nitro Card for VPC」へオフロードしていることです。

AWS が re:Invent で公表した Nitro の技術デック（CMP303, "Powering next-gen Amazon EC2: Deep dive into the Nitro system", 公式スライドPDF）には、Nitro Card for VPC の責務として、明確に次の点が挙げられています
── VPCデータプレーン、カプセル化（Encapsulation）、セキュリティグループ〔S6〕。

つまり、皆様が設定するセキュリティグループは、ソフトウェア的な概念であると同時に、各インスタンスのNitroカード上で強制される実体を持っています。

Nitro の設計思想については、Nitro System 製品ページ、およびNitro System のセキュリティ設計ホワイトペーパー(AWS Security Blog)が一次資料です。

ネットワークに関しては、Nitroカードが 転送中パケットの透過的な暗号化（AES）をハードウェアで担う点も公表されています〔S4〕〔S6〕。

「この仮想IPは、物理的にどこか」を解決するのが マッピングサービス（mapping service） です。

AWS re:Invent のネットワーク系ディープダイブセッション（いわゆる "A Day in the Life of a Billion Packets" 系の講演群）で、次のアーキテクチャが公表されてきました。

• マッピングサービス ── 仮想アドレスを物理アドレスへ変換する分散した「住所台帳」。
   
• カスタムなカプセル化プロトコル ── VXLAN や MPLS は AWSの規模では通用しないため、独自方式を採用。
   
• Blackfoot エッジデバイス ── VPCを外部へ接続する際のカプセル化を理解する境界装置。
   
• Hyperplane ── NATゲートウェイやネットワークロードバランサー（NLB）など、ステートフルなフロー処理をテラビット規模で担う分散基盤〔S10〕。

そして最も重要なのが、VPC 公式ドキュメント と Logical Separation on AWS ホワイトペーパーが述べる論理的分離の保証です。

すべてのトラフィックは VPC 識別子で紐づけられ、パケットフローは個別に認可され、たとえIPレンジが重複していても、あるVPCのトラフィックが別のVPCへ漏れることはありません〔S3〕〔S5〕。

**つまり、AWSでは、VPC も セキュリティグループ も、最終的には Nitro Card for VPC上で実体化されている、ということです。

---

第５章：GCP ── Andromeda と Hoverboard モデル

この章の要点

• 実装の中心：Andromeda（高性能なソフトウェアデータパス）
• 最大の特徴：Hoverboardモデルで、制御状態を最小化しつつ数百万VMへスケール
• 他社との違い： ハードウェア専用化に依存せず、ソフトウェアの柔軟性・機能追加速度を優先

Google Cloud のネットワーク仮想化スタックは Andromeda（アンドロメダ） と呼ばれます。

その設計内容は、査読付き論文として全文公開されています。

── Dalton et al., "Andromeda: Performance, Isolation, and Velocity at Scale in Cloud Network Virtualization", NSDI '18 (USENIX)。

上記に加えて、Google Cloud 公式ブログの Andromeda 解説が実務的な一次資料です。

Andromeda が際立つのは、ハードウェアへの処理のオフロード化に全面依存せず、高性能なソフトウェアデータパスを主軸に置いた点です。

論文は、その理由を「ソフトウェアによって、柔軟で高速な機能追加（velocity）を可能にするため」と明言しています。

コントロールプレーンのスケーリング問題への解が、有名な `Hoverboard（ホバーボード）モデル*です。

論文では、制御方式が以下の３つに整理されています。

• 事前プログラム型
  ── すべてのVMの間の通信規則を、あらかじめ全ノードへ配布しておく方式です。しかし、VMがN台あれば、その間の組み合わせの数は、 $N×(N−1)/2$、つまり、$N$の2乗のオーダーで増えていきます。VMが10倍になれば、管理すべき規則はおよそ100倍。数百万台規模のクラウドでは、この量が現実的な限界を超え、破綻します。
   
• オンデマンド型
  ── 初回パケットを制御機へ。初回遅延・制御機への依存・リクエスト殺到への脆弱性。つまり、最初のパケットを制御機に送るため、初回に遅延が生じ、制御機が止まると全体が止まり、リクエストが殺到すると過負荷でパンクしやすい。
   
• ゲートウェイ型（Hoverboard）
  ── まず少数のゲートウェイ（gateway）に通し、そのうち、通信量が突出して多い一部のフロー（hot flow / elephant flow）だけを、ゲートウェイを経由せず、ホスト間を直結する経路（direct host-to-host path）へ動的にオフロード（offload） する。大多数を占める通信量の少ないフロー（mice flow）はゲートウェイに任せられるため、制御状態を最小化しつつ数百万VMへスケールできる〔S11〕〔S12〕。

なお、GCPのVPCはグローバル（全リージョンにまたがる） という、AWS・Azureにはない設計を採ります（Google Cloud VPC ドキュメント）。

サブネットはリージョン単位です。

このことが意味するのは、複数のリージョンにまたがるVMどうしが、VPCピアリングを挟むことなく、ひとつのプライベートネットワークとして直接つながるということです。

AWS・Azureでは、リージョンごとにVPC／VNetを作り、それらをピアリングやハブで結ぶ必要があります。

GCPでは、ネットワークそのものが最初から全世界で一枚であり、マルチリージョン構成の出発点が根本的に異なります。

つまり、GCPではAndromeda のソフトウェアデータパスが、各ホストで通信を成立させている ということです。

---

第６章： Azure ── VFP と AccelNet （FPGA SmartNIC）

この章の要点

• 実装の中心： VFP（プログラム可能な仮想スイッチ）＋ AccelNet（FPGAオフロード）
• 最大の特徴： 多層マッチ・アクション表という統一モデルで、仮想化・NAT・ACL・QoSを表現
• 他社との違い： CPUコアを顧客に明け渡すため、処理を FPGA SmartNIC へ逃がす設計思想

Microsoft Azure のホストSDNは、VFP（Virtual Filtering Platform） と、そのハードウェアオフロードである AccelNet（Accelerated Networking） の２本柱です。

いずれも査読論文として公開されています。

• VFP ── Firestone, "VFP: A Virtual Switch Platform for Host SDN in the Public Cloud", NSDI '17（USENIX）。
  各ホスト上で動作するプログラム可能な仮想スイッチで、多層のマッチ・アクション表（layered match-action tables） という設計を採ります。
  ネットワーク仮想化、ステートフルなNAT・ステートフルなACL、メータリング、QoS を、この一貫したモデルで表現・強制します。
  皆様が設定する ネットワークセキュリティグループ（NSG） は、このVFPの層として実現されています。

〔S15〕VFP 論文（"A Virtual Switch Platform for Host SDN in the Public Cloud", NSDI '17, USENIX）

 

• AccelNet ── Firestone et al., "Azure Accelerated Networking: SmartNICs in the Public Cloud", NSDI '18 (PDF)。
  VFPの処理を FPGAベースの Azure SmartNIC へオフロードし、仮想化環境でありながらネイティブに近い性能を実現します。

論文は、AccelNet 適用によりVM間レイテンシが平均50µsから17µsへ改善した実測値まで公開しています。

設計思想はGoogleと対照的です。

Googleが、「ホストのCPUコアを使ってでもソフトウェアの柔軟性を採る」のに対し、Microsoftは、「CPUコアを顧客に明け渡すため、処理をFPGAへ逃がす」判断を採りました。

両論文が同じ NSDI '18 で並んだことで、この対比はしばしば教材として引用されます。

つまり Azure では、VFP という仮想スイッチが FPGA SmartNIC へオフロードされ、そこで通信が成立している、ということです。

---

第７章：　３社の設計思想の違いがもたらすもの ── セキュリティ・拡張性・可用性・性能

ここまでで、AWS・GCP・Azureの設計思想（実装戦略）の差異（第４〜６章）を見てきました。

ここで、VLAN/SDNという視点で３社を並べたとき、各社の設計思想はどう違い、それがセキュリティ・拡張性・可用性・性能に、どんな実務差を生むのかを、表と図で整理してみます。

まず押さえるべきは、３社とも同じ原理に立脚しているということです。

• 制御と転送の分離
• オーバーレイとマッピング
• フローごとの個別認可

── この原理のレベルでは、本質的な差はありません。

各社に違いが出るのは、次の２つの選択です。

• ① データプレーンを、どこで実行するか（オフロード哲学）。
• ② 制御プレーンを、どうスケールさせるか。

この２つの選択が、実務上のパフォーマンス差を生みます。

設計思想の３類型

軸	AWS	GCP	Azure
データプレーンの実行場所	専用ハードウェア（Nitro Card、機能特化のシリコン）	ソフトウェア主軸（OSバイパスの高速データパス／専用に約1コアを確保）	FPGA SmartNIC（再構成可能なHW／NICとToRの間の"bump-in-the-wire"）
制御プレーンのスケール戦略	マッピングサービス＋Hyperplane（セル型・シャッフルシャーディング）	Hoverboard（通信量の少ないフローはゲートウェイ任せ、通信量の多い一部のフローだけホスト間を直結）	集中コントローラがVFP各層へマッチ・アクション表を配布
仮想NWのスコープ	VPC＝リージョン	VPC＝グローバル	VNet＝リージョン
フィルタの表現	SG（許可のみ）＋NACL（許可/拒否）	ファイアウォールルール（階層的ポリシー）	NSG（許可/拒否）＋ASG

結果として生じる実務的パフォーマンス差

観点	AWS（専用HW）	GCP（SW主軸）	Azure（FPGA）
性能	◎ 全コアを顧客へ／HW暗号化	○ HWとほぼ同等（約1コア消費）	◎ 低遅延（50→17µs）／CPU解放
拡張性	◎ 大規模接続に強い（セル型）	◎ 数万VMを数秒／制御面を一桁改善	○ ホスト単位で底上げ
可用性	○ マルチAZ／障害の波及を限定	◎ 制御面が落ちても転送継続（fail static）	○ 接続を切らずにNIC保守・障害対応
セキュリティの効き所	HW暗号化＋SG/NACLの二層	グローバルVPCで均一なポリシー	持ち出し防御（インスタンス単位）
機能追加の速度	△ HW更新サイクルに依存	◎ 最速（SW主軸）	○ FPGA再構成で比較的柔軟

各主張の根拠は、第4〜6章で引用した各社の一次資料にあります

• AWS：〔S4〕〔S6〕
• GCP：〔S11〕〔S12〕
• Azure：〔S15〕〔S16〕

（可用性の fail static・RACP/GACP、Hoverboard の分布統計は〔S11〕、AccelNet の 50→17µs は〔S16〕）。

各番号の詳細は、この記事の末尾に掲げた 「主張 $→$ 根拠 対照表」 をご参照ください。

この比較の読み方 ── 優劣ではなく、設計思想のトレードオフ

この表は、「どのクラウドが一番か」を示すものでは ありません。

３社はいずれも、自社のワークロード分布と運用体制に合わせて、異なる軸を最適化しています。

AWSは、専用ハードウェアで性能の一貫性とコア解放を、
GCPは、ソフトウェア主軸で可用性（fail static）と機能追加の速度を、
Azureは、FPGAで柔軟性と無停止のサービシングを、

それぞれ重視しています。

「どれが優れているか」ではなく、「どの軸を重視した設計なのか」を読み取っていただくのが、最も実利的です。

なお、掲載した数値（例：$50 → 17µs$) は、各資料の公表時点のものです。

---

第８章： 「セキュリティグループ」は、物理的に何なのか？

ここまでの理解を踏まえると、クラウド利用者が設定する構成要素の「正体」が見えてきます。

セキュリティグループは、ファイアウォール機器ではありません。

それは、各ホストのデータプレーン（AWSならNitroカード、AzureならVFP/SmartNIC、GCPならAndromedaのデータパス）に配布・強制される、マッチ・アクション規則です。

コンソールで設定した「443を許可」という指示は、コントロールプレーンによって翻訳され、そのインスタンスが載っている物理サーバーのSDN層に適用されます。

この理解から、AWS の設計上の性質がすべて演繹的に導き出されてきます（Amazon VPC ドキュメント）。

• セキュリティグループはインスタンス（ENI）単位・ステートフル・許可ルールのみ。
  ステートフルなのは、VFPやNitroがフローの状態を保持しているからです。
  その結果、戻りの通信は自動的に許可されます。

• ネットワークACL（NACL）はサブネット単位・ステートレス・許可と拒否の両方。
  状態を持たないため、戻り通信も明示的に許可が必要です。
  なお、NACLが物理的にどのコンポーネントで強制されるかは、セキュリティグループ（Nitro Card for VPC が担うと公表されている〔S6〕）ほど詳細には公開されていません。
  確かなのは、いずれも専用のファイアウォール機器ではなく、ホストSDNの層として、サブネット単位という異なる粒度で適用される論理的なフィルタである、という点です。
   
• GCP のファイアウォールのルールや Azure のNSGも同じです。これらは、物理的なネットワーク機器によって担われるのではなく、各ホスト上のソフトウェア（ホストSDN）によって担われています。

「機器ではなく、各ホストで強制される分散ポリシー」
── この一点が、クラウドのセキュリティがスケールしても均質に効く理由です。

---

第９章：「VPCピアリング」は、どう成立するのか？

VPCピアリングは、しばしば「２つのVPCの間にトンネルを張る」と説明されますが、内部機構はもう少し精妙です。

実体は、両VPCのマッピング情報とルーティングを相互に解決可能にすること
── すなわち、オーバーレイの解決範囲を、相手のVPCまで拡張することです。

物理的なケーブルが新設されるわけではありません。

この理解から、ピアリングの有名な性質がすべて自然に導かれます。

• 推移的でない(non-transitive)。
  $A–B$ と $A–C$ をピアリングしても、$B–C$ は通信できません。
  マッピング/ルートの相互解決は 対ごと（pairwise） であり、$A$ を経由して $B$ と $C$ が結ばれることはないからです。
   
• 全面的・双方向の$L3$接続。
  ピアリングは両VPCのCIDR全体を相互到達可能にします（その分、開放範囲が広い）。
   
• 重複CIDRは不可。
  マッピングは仮想IPで宛先を解決するため、両VPCで同じIPレンジが使われていると宛先が一意に定まらず、成立しません。

規模が増すと、対ごとのピアリングは組合せ的に増大します
（$N$個のVPCの全結合は、$N(N−1)/2$ 本）。

そのため、中央ハブ型の AWS Transit Gateway が用いられます。

詳細な設計指針は、AWS の「Building a Scalable and Secure Multi-VPC AWS Network Infrastructure」ホワイトペーパーにまとまっています。

---

第１０章：「PrivateLink」は、なぜ本質的に安全なのか？

PrivateLink(AWS)、Private Service Connect（GCP）、Private Link（Azure） は、ピアリングやTransit Gatewayとは、モデルが根本的に異なります。

ピアリングが「ネットワークどうしを、まるごとつなげる」のに対し、
PrivateLink は「相手のサービスへの入り口だけを、自分のVPCの中に置く」のです。

AWS の一次資料(AWS PrivateLink 製品ページ、VPC 接続オプション・ホワイトペーパー)に基づく機構は、次のとおりです。

• 提供側は、サービスを ネットワークロードバランサー（NLB） の背後に置き、エンドポイントサービスとして公開。
   
• 利用側のVPCにはインターフェースエンドポイントが作られる。実体は、利用側VPCのサブネット内に置かれた、プライベートIPを持つ ENI。
   
• 結果として、利用側から見ると、相手のサービスは「自分のVPCの中にある、ひとつのプライベートIPアドレス」として現れます。そして、相手のネットワークは、一切見えません。 ピアリングと違い、両者のネットワークは経路としてつながっていないからです。
  利用側に置かれるのは、あくまで「そのサービスへの入り口」ひとつだけであり、その入り口の先が相手のネットワークのどこにどうつながっているかは、利用側からは辿れません。
  つながっているのはネットワークではなく、サービスへの一点だけ
  ── だから、相手のネットワーク全体は、見えようがないのです。

ここから、PrivateLinkの安全性 が導き出されます。

• サービス単位・一方向。
  ネットワーク結合が生じないため、開放範囲が最小化されます。
   
• セキュリティグループで制御可能。
  エンドポイントは利用側VPCのENIなので、利用側のSGで制御できます。
   
• 重複CIDRでも成立。
  ルーティングではなくエンドポイント注入で成立するため。
   
• トラフィックはバックボーン内に留まり、インターネットに出ません。
  攻撃対象領域(attack surface)が構造的に縮小します。

PrivateLink は、Hyperplane という土台の上に立っています。

第4章で少し触れた Hyperplane を、ここで思い出してください。

これは、AWS内部の**巨大な「通信処理の分散基盤」**とでも言うべき仕組みです。

正式には「ネットワーク機能仮想化（NFV）基盤」と呼ばれ、複数のアベイラビリティゾーンにまたがって冗長化された、多数のサーバーの集まりです。皆様が直接目にすることはありませんが、その上で数々のAWSサービスが動いています。

PrivateLink のエンドポイントには、多数の利用者からの通信が集まります。

このとき、「どの通信が、どのサービスと、どうつながっているか」という情報（接続の状態）を、１件ずつ覚えて管理しなければなりません。

これを、１台の中継サーバーで担おうとすれば、通信が増えた瞬間に詰まり、そのサーバーが落ちれば全体が止まってしまいます。

そこで AWS は、この「接続の状態を覚えて捌く」仕事を、多数のサーバーに分担させる巨大な基盤 ── Hyperplane に任せる設計を採用しました。

膨大な通信量（テラビット規模）を、大勢で手分けして処理するので、詰まらず、一部が壊れても全体は止まりません。

PrivateLink だけでなく、NAT Gateway や Network Load Balancer も、同じ Hyperplane の上で動いています。

AWS 公式の Amazon Builders' Library も、これらのサービスの背後にある内部システムが Hyperplane であると明言しています〔S10〕。

「下層のメカニズム」が「上位のマネージドサービス」を可能にしている
── その構造が、ここで一つにつながります。

GCP の場合
── Private Service Connect は Andromeda 上で直接処理される。

３社の比較として、GCP の Private Service Connect（PSC） にも触れておきます。

PSC は中間プロキシを挟まず、Andromeda のデータパス上で、宛先ホストが直接 NAT(SNAT/DNAT)を行うため、追加のプロキシによるボトルネックを持ちません。

（GCP 公式ドキュメント Private Service Connect architecture and performance が、「データプレーンは完全に分散され、中間のプロキシやアプライアンスに中央集約的なボトルネックがない」と述べています）〔S14〕。

第５章の Andromeda が、ここでも効いています。

「家全体の合鍵を渡すピアリング」に対し、「玄関に受け取り口だけを設置するPrivateLink」
── この比喩は、内部機構（ネットワーク結合 対 サービス注入）を正確に言い当てています。

なお、Azure のプライベート接続（Private Endpoint / Private Link） は、AWS や GCP とはかなり異なる独自の設計を採っており、しかも運用でつまずきやすい（特にDNS周りの設定でトラブルが起きやすい）領域です。

そのため、次章で独立して詳しく扱います。

---

第１１章：Azure のプライベート接続 ── 設計と実装（VNet Peering・Private Endpoint・Hub-and-Spoke）

Azure のホストSDN（VFP/AccelNet）は、第６章で見ました。

本章では、その上に構築される 「プライベート接続の設計・実装」 を、Azure 固有の設計思想とともに掘り下げます。

Azure には、AWS/GCP とは明確に異なる判断がいくつも埋め込まれています。

VNet と VNet Peering、そして Hub-and-Spoke

Azure の仮想ネットワークは VNet（リージョン単位） です。

VNet Peering は、２つの VNet を、Microsoft が自前で保有する基幹ネットワーク（バックボーン）を通じて直接つなぎます。

通信はインターネット（公道）を経由せず、Microsoft 社内の閉じた高速な網の中だけを流れるため、速く、安全です。

性質は AWS のピアリングとほぼ対応し、双方向・アドレス空間の重複不可で、リージョン内（regional）・リージョン間（global）の両方に対応します。

規模を扱う定石は Hub-and-Spoke です。

ハブVNet に、ファイアウォール・VPN/ExpressRoute ゲートウェイ・共有DNS といった共有サービスを集約し、スポーク VNet を peering で束ねます。

ゲートウェイ推移（gateway transit） により、オンプレ接続をスポーク間で共有できます。

さらに多数拠点・大規模を一元管理するには、マネージドなハブである Virtual WAN(AWS Transit Gateway に相当)を用います。

Private Endpoint / Private Link ── Azure の設計上の差別化点

Azure のサービス単位のプライベート接続は、Private Link と、その実体である Private Endpoint で構成されます（Azure Private Link 概要, Microsoft Learn、Private Endpoint とは, Microsoft Learn）。

• Private Endpoint は、自分のサブネット内に置かれる NIC（プライベートIP） です。
  対象のサービスを「自分の VNet の中へ持ち込む」構図で、AWS の Interface Endpoint(ENI) と同じ発想です。
   
• 一方向。 接続はクライアント $→$ サービスの向きにのみ確立でき、サービス側からは戻せません。
   
• 重複アドレス空間でも成立。
  ルーティングではなく、エンドポイント・マッピングで成立するため、ピアリングと違い、両者のIPレンジが重複していても機能します(Azure Private Link 発表ブログ, Microsoft Azure Blog)。

 

• NSG・UDR・ASG(ネットワークポリシー)で制御可能。
  エンドポイントは自分のサブネットのNICなので、通常のネットワーク制御が効きます。

そして、Azure 最大の差別化点がこれです。

Azure Private Link は、「サービス全体」ではなく「特定のリソース"インスタンス"」に private endpoint を対応づける。

その結果、同じエンドポイントを悪用して別のアカウントのデータへ持ち出そうとしても失敗する
── これを Microsoft は データ持ち出し（exfiltration）防御 と呼び、他社との明確な違いとして位置づけて います〔S19〕(Azure Private Link 発表ブログ)。

自前のサービスを提供する側は、サービスを Standard Load Balancer の背後に置いて Private Link Service として公開します。

別VNet・別サブスクリプション・別 Microsoft Entra テナントの利用者に対して、承認フロー(approval) 付きで提供できます。

実装上の最重要ポイント ── DNS

Azure のプライベート接続で、最も事故が多いのが DNS です。

Private Endpoint は、サービスの FQDN をプライベートIPへ解決させる必要があり、そのために Private DNS Zone の設計が要になります。

ここを誤ると、「エンドポイントは作ったのに、名前が公開IPへ解決されてしまいつながらない」という典型的な障害に陥ります。

Azure のプライベート接続は、「NIC を置く」よりも「DNS を正しく解く」ことのほうが、設計の主戦場だと言っても過言ではありません（Private Endpoint DNS 構成, Microsoft Learn）。

オンプレミス接続

オンプレミスとの接続は、ExpressRoute（専用線・private peering）と VPN Gateway（暗号トンネル）です。

重要なのは、Private Endpoint が、ExpressRoute private peering や peered VNet を経由して、オンプレミスからも私設到達できる点です。

これにより、オンプレの端末から Azure PaaS(例：SQL Database、Storage)へ、インターネットを一切経由せずアクセスする経路が組めます（Azure Private Link 概要）。

まとめ ── Azure のプライベート接続の設計思想

つまり Azure のプライベート接続は、

① リソース"インスタンス"単位のマッピングによる持ち出し防御、
② Hub-and-Spoke／Virtual WAN による集約、
③ DNS（Private DNS Zone）を主戦場とする実装、

という３点が、設計の肝 です。

そしてそのすべてが、第6章で見た VFP/AccelNet のホストSDN の上に構築されています。

---

第１２章：サイバーセキュリティ上の含意 ── すべては「フローごとの個別認可」から演繹される

ここまでの内部機構は、セキュリティの観点では一つの原理に収束します
── フローごとの個別認可(per-flow authorization)。

すべての通信は、ホストSDNのデータプレーンで、送信元・宛先・ポリシーが個別に検証されてから通されます。

ここから、クラウドネットワークのセキュリティ特性 が体系的に導かれます。

• ① デフォルト拒否。 何も許可しなければ何も通りません。「つなげば通る」旧来の前提は成り立ちません。
   
• ② なりすまし・盗聴の不能。 送信元は基盤側で検証され、なりすましは成立しません。テナントが見えるのはオーバーレイのみで、基盤の生トラフィックは覗けません(AWS Nitro セキュリティ設計ホワイトペーパー)。
   
• ③ テナント完全分離（IP重複下でも）。 VPC識別子による論理分離で、IPが重複しても越境しません(Amazon VPC ドキュメント)。
   
• ④ 攻撃対象領域の最小化。 PrivateLink や専用線で、通信がインターネットに出ず、到達可能性そのものを断てます。
   
• ⑤ マイクロセグメンテーションとブラストラディウスの縮小。 区画化で、一箇所の侵害の延焼を止めます。
   
• ⑥ 転送中の暗号化。 新世代インフラでは、インスタンス間トラフィックが透過的にハードウェア暗号化されます(AWS Nitro)。
   
• ⑦ ゼロトラストの自然な土台。 「フローごとに検証する」というホストSDNの原理は、ゼロトラストの思想とそのまま整合します。

機械学習基盤にとって、これらは抽象論ではありません。

学習データ・推論API・モデルの重みを、インターネットに晒さず、テナント分離のもとで最小権限で扱うための土台が、まさにこのSDNなのです。

---

第１３章： だから、設計判断が変わる ── 実務への接続

内部機構の理解は、そのまま設計判断の根拠になります。ここまでの話を、実務の問いに接続します。

• なぜ、セキュリティグループを設計の基本に置くのか。
  SGはENI単位・ステートフル・各ホストで強制されます。つまり、リソースの最も近くで、最小権限を最小の労力で実現できる制御です。まずSGで締め、必要に応じてNACLで補うのが定石です。
   
• なぜ、PrivateLink が推奨されるのか。
  サービス注入モデルにより、ネットワークを結合せず、サービス単位・一方向で公開できます。学習データや推論APIなど機密性の高い通信を、インターネットに出さず、攻撃面を最小化して扱えます。別勘定・別組織・重複CIDRとも相性が良い。
   
• なぜ、VPCピアリングを乱立させないのか。
  非推移かつ $N(N−1)/2$ で増える上、CIDR管理と広い開放範囲が負債になります。
  少数なら可、増えるならハブ(Transit Gateway)へ、が原則です。
   
• なぜ、Transit Gateway を使うのか。
  多数のVPCとオンプレミスを中央ハブで集約し、推移的ルーティングと一元管理を得るためです。
  規模とガバナンスが要求水準を超えたら、これが解になります。
   
• なぜ、ゼロトラストと親和するのか。
  クラウドSDNは、そもそもフローごとの個別認可を前提に設計されています。
  ゼロトラスト（暗黙の信頼を置かない）は、この土台の上に自然に乗ります。
  突然現れた概念ではなく、既存の内部機構の延長線上にあるのです。

内部機構を知る者は、これらの判断を「ベストプラクティスだから」ではなく、「仕組みからそう導かれるから」と述べられます。

この差は、設計レビューの説得力に、そのまま現れます。

---

第１４章： ３社の対応と設計上の非対称性

役割で見ると対応がとれますが、設計思想の非対称こそが、マルチクラウドで効きます。

観点	AWS	GCP	Azure
ホストSDN実装	Nitro Card for VPC（専用HWオフロード）	Andromeda(SW主軸＋Hoverboard)	VFP＋AccelNet(FPGA SmartNICオフロード)
一次資料	re:Invent Nitroデック / Nitroホワイトペーパー	NSDI '18 Andromeda論文 / GCP公式ブログ	NSDI '17 VFP / NSDI '18 AccelNet論文
仮想ネットワーク	VPC(リージョン単位)	VPC（グローバル）	仮想ネットワーク VNet(リージョン単位)
通信フィルタ	セキュリティグループ（ENI単位/ステートフル/許可のみ）＋NACL（サブネット/ステートレス/許可・拒否）	ファイアウォールルール	ネットワークセキュリティグループ(NSG)
VPC間結合	VPCピアリング	VPCネットワークピアリング	VNetピアリング
多数VPCの集約	Transit Gateway	Network Connectivity Center	Virtual WAN
サービス単位の限定公開	PrivateLink	Private Service Connect	Private Link
オンプレ暗号トンネル	Site-to-Site VPN	Cloud VPN	VPN Gateway
オンプレ専用線	Direct Connect	Cloud Interconnect	ExpressRoute

特に押さえるべき非対称性を、要点だけ挙げます（実務差の詳細は第7章をご参照ください）。

• VPCの広がり。
  GCPのVPCはグローバルで、リージョンをまたいでサブネットを持てます。
  AWS/AzureはリージョンごとにVPC/VNetを作り、リージョン間はピアリングやハブで結びます。
  マルチリージョン設計の出発点が異なります。
   
• フィルタの表現力。
  AWSはSG（許可のみ）とNACL（許可・拒否）を分業させ、
  AzureのNSGは許可・拒否を一体で扱います。
  「拒否ルール」を書く場所が違います。
   
• オフロード哲学。 AWS/AzureはハードウェアオフロードでCPUを解放し、GCPはソフトウェア主軸で柔軟性を採る。性能特性と機能追加速度に、思想差が現れます。

---

第15章： 複数の設計が「可能」であることの意味 ── そして、米国外の選択肢

ここまで見てきた3社の違いは、単なる実装の差ではありません。

より深い事実を示しています
── それは、ホストSDNの設計には、技術的に複数の正解が存在しうる、ということです。

「唯一の最適解」は、存在しない

AWS・GCP・Azure は、いずれも「数百万台規模で、テナントを分離し、高性能に通信させる」という同じ問題を解いています。

にもかかわらず、専用ハードウェア（Nitro）・ソフトウェア主軸（Andromeda）・FPGA（AccelNet）という、異なる答えにたどり着きました。

これが意味するのは、次のことです。

• SDNの設計は、物理法則のように一意に決まるものではない。
  各社の答えは、そのワークロードの分布、既存資産、運用体制、そして「何を最も重視するか」という価値判断の関数です。
• したがって、「どれが正しいか」という問いは、そもそも設定を誤っています。
  正しい問いは、「どの制約のもとで、何を優先した設計か」です。
• そして、制約と優先順位が変われば、まだ見ぬ第4・第5の設計もありうる。
  この地図は、まだ描き終わっていないのです。

この視点を持つと、米国外の大規模事業者が公開している情報が、俄然、興味深く見えてきます。

彼らは、また別の制約のもとで、別の答えを出しているから です。

米国外の選択肢 ── Alibaba Cloud の場合

米国外で、技術情報を比較的よく公開している大規模事業者が、Alibaba Cloud です。

同社のクラウドネットワークは Luoshen（洛神） と呼ばれ、その一部は査読論文（SIGCOMM）としても公表されています〔S20〕〔S21〕。

Alibaba の設計を、これまでの3社の軸で読み解くと、興味深い 混成（ハイブリッド） が見えてきます。

• プログラマブルスイッチという第3のハードウェア。
  Alibaba は、ゲートウェイ処理を担う XGW という、自社開発のプログラマブルスイッチを用います〔S20〕。これは、AWS/Azure が採った「サーバーに挿すNIC/カード」でも、GCP が採った「サーバーのソフトウェア」でもなく、ネットワーク側のプログラマブルなスイッチへ処理を寄せる、という第３の場所の選択です（今後、公開予定のQiita記事で取り上げるP4言語の系譜と地続きです）。
   
• SmartNIC/DPU も併用。
  一方でホスト側には、X-Dragon（神龍）と呼ばれる SmartNIC、そして後継の CIPU（Cloud Infrastructure Processing Unit） があり、ネットワーク・ストレージ・セキュリティの処理をホストCPUから逃がします〔S21〕。これは AWS Nitro に対応する位置づけです。
   
• つまり、「専用スイッチ」＋「SmartNIC/DPU」＋「SDNコントローラ」の３点を組み合わせる設計です。
  米国の３大クラウド事業者のいずれとも異なり、処理をネットワーク側とホスト側の両方に分散させています。

ここから読み取れるのは、「ホストか、NICか、専用ハードか」という選択が、二者択一ではなく、組み合わせの問題でもある、ということです。

Alibabaの答え は、３社の軸を、また別の形で組み替えた一例なのです。

情報公開の非対称という、重要な留保

ただし、ここには慎重な留保が必要です。

• 米国3社（特に GCP の Andromeda、Azure の VFP/AccelNet）は、査読論文として設計の内部を詳細に公表しています。一方、米国外の多くの事業者は、公開情報が限定的か、英語では手に入りにくいことが少なくありません。Alibaba は比較的公開している方ですが、それでも AWS/GCP/Azure ほど内部機構が精密に検証できるわけではありません。
   
• したがって本章の記述は、「公表されている範囲で読み取れること」 に限定されます。「公開されていない ＝ 技術的に劣る」では決してありません。見えないことと、無いことは、違います。
   
• Huawei Cloud、Tencent Cloud なども大規模なホストSDNを運用しているはずですが、本記事では、英語の一次資料で内部設計を十分に裏づけられなかったため、踏み込んだ記述は控えます。この空白は、本記事の限界であり、各社の技術の限界ではありません。

この章の含意

複数の設計が技術的に可能であること
── これは、SDNという分野が、まだ成熟しきって固定化してはいないことの証です。

「正解が一つに収束していない」からこそ、各社は自社の制約に最適化した答えを出し続けており、そして DPU/IPU という新しい選択肢が、いままさに地図を書き換えつつあります。

皆様がもし、この分野の設計判断に関わることがあれば、「業界標準はこうだから」ではなく、「自分たちの制約のもとで、何を優先するか」から出発できる
── それが、複数の正解が併存するこの分野の、面白さでもあります。

---

まとめ ── ネットワークの知能は、機器からサーバーへ移った

• クラウドの VPC・セキュリティグループ・PrivateLink・ピアリングは、各物理サーバー内部のホストSDNが成立させています。専用配線でも、専用機器でもありません。
   
• その必然は、「VLANの4094の壁」 にありました。
  $VLAN → VXLAN/Geneve → SDN → ホストSDN$ という進化が、いまのクラウドを形づくっています。
   
• 共通原理は、制御と転送の分離／オーバーレイと基盤の分離／マッピングによる住所解決。各社の実装（Nitro / Andromeda / VFP＋AccelNet）は、いずれも査読論文や公式デックとして公表されています。
   
• セキュリティグループの挙動も、ピアリングの非推移性も、PrivateLinkの安全性も、すべて 「フローごとの個別認可」から演繹的に導出すること ができて、そのまま設計判断の根拠になります。

最後に、この記事全体を貫く一つのメッセージ をお伝えさせていただきます。

従来のデータセンターでは、ネットワークの知能は、スイッチやルーターにありました。

クラウドでは、その知能は、各サーバーのホストSDNへ移りました。

VLAN・ACL・ルーティング・ファイアウォール・ロードバランサーといった、かつて専用機器が担っていた機能は、いまやサーバー側のソフトウェアと SmartNIC へと移されています。

「ネットワーク機器中心」から「サーバー中心」へ
── これこそが、クラウドネットワークの本質的な転換でした。

そして、この「ネットワーク・セキュリティ処理をハードウェアへオフロードする」という思想
── AWS Nitro や Azure AccelNet が切り拓いた道
── は、2026年現在、DPU（Data Processing Unit）や IPU（Infrastructure Processing Unit） という、独立したコンポーネント分野へと結実しつつあります。

SmartNIC の延長線上にあるこの潮流は、いまや、パブリッククラウドの枠を越え、オンプレミスや GPU クラスタといった AI基盤にも広がりつつあります。

この**「SmartNIC から DPU/IPU へ」という展望** は、今後、連載記事（３つの記事を予定）で改めて論じる予定です。

皆様が、次にクラウドのコンソール画面と向き合い、「セキュリティグループ」を設定された内容が、世界中の物理サーバーの中のSDNへと配布され、フローごとに強制されていく様を、思い浮かべていただけましたら幸いです。

---

一次資料 及び 各主張の根拠

本記事の主要な主張が、どの一次資料に基づくかを確認できるよう、対照表を用意しました。本文中の〔S番号〕は、下の「一次資料一覧」の番号に対応します。

主張 → 根拠 対照表

主な主張	該当章	根拠
VLAN は12ビットで最大4094、VXLAN は24ビットVNIで約1600万、Geneve は拡張型の後継	第3章	〔S1〕〔S2〕
AWS は Nitro Card for VPC が VPCデータプレーン(カプセル化・セキュリティグループ・ルーティング)を担う	第4・7章	〔S6〕〔S4〕
Nitro は転送中トラフィックを透過的にハードウェア暗号化する	第4・7・12章	〔S4〕〔S6〕
AWS はフローごとに個別認可し、IP重複下でもVPC間を分離する	第4・12章	〔S3〕〔S5〕
Hyperplane が NLB・NAT Gateway・PrivateLink の背後にある内部NFV基盤	第4・10章	〔S10〕
AWS PrivateLink はインターフェースエンドポイント(ENI)＋NLBで、サービス単位・一方向・重複CIDR可	第10章	〔S7〕〔S8〕
多数VPCの接続設計(Transit Gateway 等)の指針	第9章	〔S9〕
GCP Andromeda はSW主軸のデータパス＋Hoverboard(閑散フローはゲートウェイ、象フローのみホスト設置)で数万VMを数秒で設定	第5・7章	〔S11〕〔S12〕
GCP は "fail static"／RACP・GACP による地域間の障害隔離で可用性を確保	第7章	〔S11〕
GCP VPC はグローバル(サブネットはリージョン)	第5・7・14章	〔S13〕
GCP PSC は Andromeda 上で宿主ホストが直接NAT(SNAT/DNAT)し、プロキシのボトルネックを持たない	第10章	〔S14〕
Azure VFP は多層マッチ・アクション表で仮想化・ステートフルNAT/ACL・QoS を強制	第6章	〔S15〕
Azure AccelNet は VFP を FPGA SmartNIC へオフロード(平均50→17µs、制御面はハイパーバイザ)	第6・7章	〔S16〕
Azure Private Endpoint はサブネット内のNIC(プライベートIP)、一方向、重複アドレス空間可、DNS(Private DNS Zone)が要	第11章	〔S18〕〔S17〕
Azure Private Link はリソース"インスタンス"単位マッピング＝データ持ち出し防御	第7・11章	〔S19〕〔S17〕
Azure はオンプレから ExpressRoute/VPN 経由で Private Endpoint に私設到達できる	第11章	〔S17〕
Alibaba Cloud はプログラマブルスイッチ(XGW)＋SmartNIC/DPU(X-Dragon/CIPU)＋SDNコントローラの混成設計を採る	第15章	〔S20〕〔S21〕

一次資料一覧(番号つき)

標準(オーバーレイ)

• 〔S1〕VXLAN：RFC 7348 — https://www.rfc-editor.org/rfc/rfc7348
• 〔S2〕Geneve：RFC 8926 — https://www.rfc-editor.org/rfc/rfc8926

AWS

• 〔S3〕Amazon VPC 公式ドキュメント：https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html
• 〔S4〕AWS Nitro System(製品ページ)：https://aws.amazon.com/ec2/nitro/
• 〔S5〕Nitro System のセキュリティ設計ホワイトペーパー(AWS Security Blog)：https://aws.amazon.com/blogs/security/introducing-the-security-design-of-the-aws-nitro-system-whitepaper/
• 〔S6〕re:Invent CMP303「Deep dive into the Nitro system」公式スライド：https://d1.awsstatic.com/events/reinvent/2019/REPEAT_2_Powering_next-gen_Amazon_EC2_Deep_dive_into_the_Nitro_system_CMP303-R2.pdf
• 〔S7〕AWS PrivateLink(製品ページ)：https://aws.amazon.com/privatelink/
• 〔S8〕VPC 接続オプション・ホワイトペーパー(PrivateLink)：https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/aws-privatelink.html
• 〔S9〕Building a Scalable and Secure Multi-VPC AWS Network Infrastructure(ホワイトペーパー)：https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/
• 〔S10〕Amazon Builders' Library(Hyperplane が NLB・NAT Gateway・PrivateLink の背後にある内部NFV基盤である旨)：https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/

GCP

• 〔S11〕Andromeda 論文(NSDI '18, USENIX)：https://www.usenix.org/conference/nsdi18/presentation/dalton
• 〔S12〕Google Cloud 公式ブログ(Andromeda 2.2)：https://cloud.google.com/blog/products/networking/google-cloud-networking-in-depth-how-andromeda-2-2-enables-high-throughput-vms
• 〔S13〕Google Cloud VPC ドキュメント：https://cloud.google.com/vpc/docs
• 〔S14〕Private Service Connect architecture and performance(PSC が Andromeda 上で直接NAT処理される旨)：https://docs.cloud.google.com/vpc/docs/private-service-connect-architecture

Azure

• 〔S15〕VFP 論文(NSDI '17, Microsoft Research)：https://www.microsoft.com/en-us/research/publication/vfp-virtual-filtering-platform-host-sdn-public-cloud/
• 〔S16〕AccelNet / Azure SmartNIC 論文(NSDI '18, PDF)：https://www.microsoft.com/en-us/research/wp-content/uploads/2018/03/Azure_SmartNIC_NSDI_2018.pdf
• 〔S17〕Azure Private Link 概要(Microsoft Learn)：https://learn.microsoft.com/en-us/azure/private-link/private-link-overview
• 〔S18〕Private Endpoint とは(Microsoft Learn)：https://learn.microsoft.com/en-us/azure/private-link/private-endpoint-overview
• 〔S19〕Azure Private Link 発表ブログ(リソース単位マッピングによるデータ持ち出し防御の旨, Microsoft Azure Blog)：https://azure.microsoft.com/en-us/blog/announcing-azure-private-link/

米国外の事業者（参考・公開情報の範囲）

• 〔S20〕Alibaba Cloud "Sailfish: Accelerating Cloud-Scale Multi-Tenant Multi-Service Gateways with Programmable Switches"（SIGCOMM 2021）／Luoshen・XGW 解説（Alibaba Cloud Community）：https://www.alibabacloud.com/blog/alibaba-clouds-paper-on-luoshen-cloud-network-management-has-entered-sigcomm-again_597878
• 〔S21〕Alibaba Cloud CIPU / X-Dragon SmartNIC 解説（Alibaba Cloud Community）：https://www.alibabacloud.com/blog/a-detailed-explanation-about-alibaba-cloud-cipu_599183

注記(この記事の立ち位置と限界)

1. クラウド各社の内部実装には、公表されていない詳細が数多く存在します。本記事は、各社が自ら公開した査読論文・技術デック・公式ドキュメントから言える範囲に記述を限定しています。
    
2. 引用した論文・デックには、公表時点の情報が含まれます(Andromeda・VFP・AccelNet は 2017〜2018 年、Nitro デックは 2019 年)。設計は継続的に更新されているため、最新の詳細は各社の最新資料をご確認ください。
    
3. 各サービスの正確な仕様・制約・料金は、必ず各クラウドの公式ドキュメントでご確認ください。本記事は機構の理解を助けることを目的とし、設定手順や保証を提供するものではありません。
    
4. 「マッピングサービス」「Blackfoot」「Hyperplane」等の名称・構成は、AWS の re:Invent セッション等で公表されてきたものですが、詳細は変化しうる点にご留意ください。
    
5. 「集中制御(OpenFlow)から分散オフロードへ」という変遷史、SDNの「約束と現実」の答え合わせ、そして「SmartNIC から DPU/IPU へ」という展望については、稿を改めて論じる予定です(三部作)。本記事は、その三部作における「現在の定点」に位置づけられます。
    
6. 第15章で触れた米国外の事業者（Alibaba Cloud 等）については、英語で検証可能な公開情報の範囲に記述を限定しています。Huawei Cloud・Tencent Cloud 等も大規模なホストSDNを運用していますが、内部設計を十分に裏づけられる一次資料を確認できなかったため、踏み込んだ記述は控えました。情報が公開されていないことは、技術的な優劣とは無関係である点を、改めて申し添えます。

---