はじめに
AWS VPC は「仮想ネットワーク」と説明される。
AWS を通常利用する範囲では、VPC、Subnet、Route Table、Security Group、NACL、NAT Gateway、Load Balancer、Transit Gateway などを理解すれば、多くのシステムは構築できる。
しかし、オンプレミスで VLAN、L2 セグメント、ブロードキャストドメイン、VRRP、透過 Firewall、SPAN、VLAN trunk などを設計してきた立場から見ると、AWS VPC には明確な違和感がある。
VPC はネットワークであるにもかかわらず、オンプレミスで当然のように扱っていた L2 の自由度が見えない。VLAN を切ることも、L2 透過で Firewall を挟むことも、ブロードキャストを前提に探索することも、VRRP で VIP を浮かせることも、オンプレミスと同じ形では成立しない。
この記事では、その違和感の正体を整理する。
結論は次の通りである。
AWS VPC において L2 は原理的に消えているのではない。L2 の自由度が、利用者の設計対象から外され、クラウド事業者のサービス境界内に封じ込められている。
この違いを理解しないままオンプレミスの設計思想を AWS に持ち込むと、構成上の齟齬が生じる。
オンプレミスで L2 が担っている役割
オンプレミスでは、ネットワークはかなり下位レイヤーから設計対象になる。
| 要素 | オンプレミスでの意味 |
|---|---|
| 物理 NIC | ホストやネットワーク機器の接続点 |
| スイッチ | L2 転送を行う装置 |
| VLAN | L2 セグメントを分離する単位 |
| VLAN trunk | 複数 VLAN を単一リンクに載せる仕組み |
| MAC 学習 | スイッチがフレーム転送先を決めるための情報 |
| ARP | IPv4 アドレスから MAC アドレスを解決する仕組み |
| ブロードキャスト | 同一 L2 セグメント内に広く届く通信 |
| STP / MLAG | L2 冗長化やループ防止の仕組み |
| LACP | 複数物理リンクを束ねる仕組み |
| VRRP / HSRP | L3 ゲートウェイ冗長化の仕組み |
| 透過 Firewall | L2 的に挟み込む Firewall 構成 |
| SPAN / ミラーポート | L2 トラフィックを観測する仕組み |
オンプレミスでは、これらを組み合わせてネットワークを構成する。
つまり、オンプレミスでは Ethernet を前提に IP ネットワークを作る。VLAN を切り、L2 セグメントを定義し、必要に応じて L3 境界を置き、Firewall、NAT、Load Balancer、VPN、IDS/IPS などを配置する。
この設計では、L2 は単なる下位実装ではない。利用者が直接扱う設計対象である。
AWS VPC が利用者に渡す抽象境界
AWS VPC で利用者に見える主な要素は、オンプレミスの L2 要素とは異なる。
| AWS 側の要素 | 主な意味 |
|---|---|
| VPC | 論理的に分離されたネットワーク空間 |
| Subnet | AZ に紐づく IP アドレス範囲 |
| ENI | EC2 などに接続される論理ネットワークインターフェース |
| Private IP | ENI に割り当てられる IP アドレス |
| Route Table | Subnet 単位などで適用される経路制御 |
| Security Group | ENI に紐づくステートフルな通信制御 |
| NACL | Subnet に紐づくステートレスな通信制御 |
| Internet Gateway | VPC とインターネット間の接続点 |
| NAT Gateway | Private Subnet から外部へ出るための NAT 機能 |
| Transit Gateway | VPC や VPN などを集約する L3 接続基盤 |
| Gateway Load Balancer | Firewall などのアプライアンス連携に使う仕組み |
| PrivateLink | サービス単位で閉域接続を提供する仕組み |
AWS VPC では、利用者が操作する中心は VLAN、MAC、ブロードキャストドメインではない。VPC、Subnet、ENI、Private IP、Route Table、Security Group、NACL が中心になる。
EC2 インスタンスには ENI が接続される。ENI には MAC アドレスも存在する。OS から見れば、ネットワークインターフェースがあり、IP アドレスがあり、通信が行われる。
その意味で、L2 的な要素が完全に存在しないわけではない。
ただし、ENI は自由な仮想 NIC ではない。VPC の制御プレーンに登録された論理インターフェースであり、そこに関連づく Private IP、Subnet、Security Group、Source/Destination Check などの制約の中で動作する。
AWS VPC は、利用者に仮想 Ethernet を自由に渡す仕組みではない。AWS が制御する IP 到達性モデルを、サービスとして提供する仕組みである。
なぜ AWS は L2 自由度を封じ込めるのか
AWS が L2 自由度を利用者に渡さないことには、設計上の理由がある。
マルチテナント性
クラウド基盤は、多数の利用者を同一の物理・論理基盤上で収容する。
利用者に自由な L2 挙動を許可すると、ブロードキャスト、MAC spoofing、ARP spoofing、flooding、未知ユニキャスト、ループなどが、他の利用者や基盤側の安定性に影響する可能性がある。
AWS VPC では、利用者が操作できる境界を ENI、IP、Security Group、NACL、Route Table などに限定することで、テナント間の分離と制御を成立させている。
スケール
L2 は小規模から中規模のネットワークでは扱いやすいが、大規模分散基盤では制御が難しくなる。
ブロードキャストドメイン、MAC 学習、flooding、L2 ループ、STP 的な収束は、巨大なクラウド基盤のスケール設計と相性が悪い。
クラウドでは、利用者が任意に L2 ドメインを広げるよりも、IP 到達性、経路、ポリシー、サービス単位の接続として抽象化した方が、制御プレーンとデータプレーンを大規模に管理しやすい。
障害ドメイン分離
L2 自由度は、障害の伝播範囲を広げやすい。
ブロードキャストストーム、ループ、誤った MAC 学習、冗長化設定の不整合などは、同一 L2 ドメイン内へ波及する。
AWS は AZ、Subnet、Route Table、Security Group、Load Balancer、Transit Gateway などの単位で障害境界を管理する。利用者に L2 を直接渡さないことは、障害ドメインをクラウド側で制御するための前提になる。
セキュリティ境界の明確化
オンプレミスの L2 では、同一セグメント内の通信が比較的自由になりやすい。
AWS VPC では、ENI、Private IP、Security Group、NACL、IAM、タグ、Route Table などを組み合わせて通信制御を行う。
利用者が操作する単位を L2 ではなく、クラウド制御プレーン上のオブジェクトに寄せることで、どの通信を誰が許可し、どの範囲まで到達できるのかを明確化しやすくなる。
運用自動化とサービス化
クラウドは、ネットワークを個別機器の設定集合としてではなく、API で操作可能なサービスとして提供する。
そのためには、利用者が直接扱う対象を、物理ポート、VLAN、MAC テーブル、STP 状態ではなく、VPC、Subnet、ENI、Route Table、Security Group のようなクラウドオブジェクトへ変換する必要がある。
L2 自由度の封じ込めは、クラウドネットワークを API 化し、マネージドサービスとして運用するための構造的条件である。
オンプレ設計を AWS に翻訳するときに変わる性質
オンプレミスの構成は、AWS の構成要素へ翻訳できることがある。
ただし、翻訳できることと、等価であることは別である。
ここで重要なのは、個別の製品や機能の対応関係ではない。オンプレミスで L2 が暗黙に提供していた性質が、AWS では別の責任境界へ移動することである。
AWS では、L2 が担っていた役割を、ENI、Route Table、Security Group、NACL、Load Balancer、Transit Gateway、Gateway Load Balancer、DNS、API などに分解して再構成する。
その結果として変わる性質は、主に以下である。
| 性質 | オンプレミスでの前提 | AWS での変化 |
|---|---|---|
| 到達性 | L2 隣接性や VLAN 内通信を前提にできる | ENI、Subnet、Route Table、SG、NACL によって明示的に定義される |
| 所有 | OS や機器側で IP / VIP / MAC の扱いを制御しやすい | ENI に登録された IP、AWS API、クラウド側の状態管理に従う |
| 収束 | VRRP、HSRP、STP、ルーティングプロトコルなどの収束に依存する | ヘルスチェック、API 更新、Route Table 更新、LB、DNS などの制御に依存する |
| 挿入 | L2 透過やインライン配置により経路上へ挟み込める | Route Table、GWLB、TGW などで明示的に通信を誘導する |
| 観測 | SPAN、TAP、ミラーポートでパケットを観測する | VPC Traffic Mirroring、Flow Logs、サービスログなどに分かれる |
| 発見 | ブロードキャスト、マルチキャスト、同一セグメント探索に依存できる | DNS、Service Discovery、API、Load Balancer へ寄せる |
| 責任境界 | 機器、OS、ネットワーク管理者の設定責任が大きい | AWS サービス仕様と利用者設定の境界に分割される |
つまり、AWS 的な部品に置き換えた時点で、通信の意味、障害時の振る舞い、運用手順、観測方法、責任境界が変わる。
「AWS ではこれで代替できる」と書く場合、その代替がどの性質を保持し、どの性質を失うのかを分けて考える必要がある。
置き換えはできるが等価ではない
前節では、AWS へ翻訳するときに変わる抽象的な性質を整理した。
ここでは、具体的な構成要素の対応関係として整理する。
| オンプレミスの構成 | AWS での主な代替 | 保持しやすい性質 | 変わる性質 |
|---|---|---|---|
| VRRP / HSRP | ENI 付け替え、Route Table 更新、Load Balancer、DNS フェイルオーバー | 単一の到達先を冗長化する目的 | 切替速度、検知方式、制御主体、障害時の操作点 |
| L2 透過 Firewall | Gateway Load Balancer、Routed Firewall、Transit Gateway 経由の集約 | 通信を検査・制御する目的 | L2 透過性、挿入方式、経路設計、戻り通信の扱い |
| SPAN / TAP | VPC Traffic Mirroring、Flow Logs、サービスログ | 通信や証跡を観測する目的 | 観測粒度、取得対象、保存形式、リアルタイム性 |
| VLAN trunk | 複数 ENI、複数 Subnet、ルーティング設計 | 複数ネットワークを扱う目的 | VM への L2 多重収容、タグ VLAN、L2 境界の自由度 |
| ブロードキャスト探索 | DNS、Service Discovery、API、Load Balancer | サービスを発見する目的 | 発見方式、依存先、明示設定の必要性 |
| 任意 IP の付与 | ENI に登録された Private IP、Secondary IP | 特定 IP で通信する目的 | OS 側だけで完結しない点、AWS 側の登録状態 |
| MAC ベース制御 | Security Group、NACL、IAM、タグ、ENI 単位の制御 | 通信主体を制限する目的 | 制御単位、識別子、ポリシー適用場所 |
| L2 延伸 | VPC Peering、Transit Gateway、VPN、Direct Connect | 離れたネットワーク間を接続する目的 | 同一 L2 セグメント性、ブロードキャスト到達性、障害伝播の扱い |
この表は「AWS ではこれを使えば同じことができる」という意味ではない。
保持しやすいのは、上位の目的である。たとえば、冗長化したい、通信を制御したい、観測したい、複数ネットワークを扱いたい、という目的は AWS 上でも実現できる。
一方で、その目的を実現していた下位の性質は変わる。L2 隣接性、透過性、VIP の扱い、観測方法、障害検知、制御主体は、AWS の到達性モデルに合わせて再定義される。
そのため、AWS 上で仮想 Firewall、IDS/IPS、VyOS、pfSense、FortiGate、Palo Alto、Kubernetes CNI、Active Directory、LDAP、Ceph、HA 構成などを考える場合、オンプレミスの構成をそのまま移植するのではなく、どの目的を維持し、どの性質が変わるのかを先に分解する必要がある。
設計翻訳の落とし穴
オンプレミスの設計経験があるほど、AWS VPC を既存の概念へ対応づけて理解しようとする。
その対応づけ自体は有効である。ただし、対応表を作った瞬間に「似ているもの」を「同じもの」として扱いやすくなる。
設計翻訳で起きる誤読は、技術要素の知識不足というより、オンプレミスで成立していた暗黙の前提を AWS 側にも持ち込むことで発生する。
1. Subnet を VLAN のクラウド版として読む
Subnet は、見た目として VLAN に近い。
どちらもアドレス範囲や分離単位として説明されるため、オンプレミス経験者は Subnet を VLAN のクラウド版として理解しやすい。
しかし、この読み方では、VLAN が暗黙に持っていた L2 隣接性、ブロードキャスト範囲、MAC ベースの挙動まで Subnet に重ねてしまう。
AWS の Subnet は、VPC 制御プレーン上の IP 到達性と配置の単位であり、L2 自由度の提供単位ではない。
2. Firewall を「通信経路上に置く箱」として考える
オンプレミスでは、Firewall はネットワーク境界に置く装置として考えやすい。
そのため、AWS でも「どこに Firewall を挟むか」という発想から始めると、Security Group、NACL、Gateway Load Balancer、Transit Gateway、Route Table の役割分担を誤読しやすい。
AWS では、通信制御は単一の箱に集約されるとは限らない。ENI 単位の Security Group、Subnet 単位の NACL、経路制御、サービス挿入、マネージド LB などに分散する。
オンプレミスの Firewall 配置図をそのまま AWS に移すと、制御点の分散という前提を見落とす。
3. HA を「VIP を浮かせる問題」として読む
オンプレミスでは、HA を考えるときに VRRP、HSRP、keepalived、VIP といった発想が出やすい。
これは、同一 L2 セグメント内で仮想 IP を共有できる前提があるためである。
AWS では、HA は VIP を浮かせる問題ではなく、AWS の制御プレーン上で到達先をどう切り替えるかという問題になる。
そのため、ENI 付け替え、Route Table 更新、Load Balancer、DNS フェイルオーバーなどが候補になるが、それぞれ検知方式、切替速度、責任境界が異なる。
4. 透過性を保ったまま挿入できると考える
オンプレミスでは、L2 透過 Firewall や IDS/IPS を既存経路に挟み込み、周辺の IP 設計を大きく変えずに導入できる場合がある。
この経験があると、AWS でも同じように「透過的に挿入する」構成を想像しやすい。
しかし、AWS では多くの場合、透過的に挟むのではなく、Route Table、Gateway Load Balancer、Transit Gateway などを使って、明示的に通信をサービスへ誘導する。
ここで必要になるのは L2 透過性の再現ではなく、どの通信をどの経路へ通すかという到達性の再設計である。
5. 自動探索をネットワークの性質として期待する
オンプレミスでは、同一 L2 セグメント内でブロードキャストやマルチキャストによる探索が成立することがある。
この経験があると、同一 Subnet 内でも同様の自動探索を期待しやすい。
AWS では、サービス発見を L2 の性質に依存させるべきではない。DNS、Service Discovery、API、Load Balancer、明示的なエンドポイント定義へ移す必要がある。
ここで変わるのは通信手段だけではない。サービスの存在を、ネットワーク上で発見するものから、制御プレーンや名前解決で定義するものへ変更することになる。
6. 観測を「全部見える場所を作る」問題として考える
オンプレミスでは、SPAN、TAP、ミラーポートによって、特定の場所を通るパケットを観測する設計ができる。
この発想のまま AWS を見ると、どこかにミラーポート相当の場所を作れば全体を観測できるように見える。
AWS では、観測もクラウド側の抽象に従う。VPC Traffic Mirroring、VPC Flow Logs、サービスログ、CloudWatch などを目的別に使い分ける必要がある。
そのため、観測設計も「どこをミラーするか」ではなく、「どのレイヤーの何を証跡として取得するか」に変わる。
AWS VPC は L2 の再現ではなく、到達性モデルである
AWS VPC を理解する上で重要なのは、クラウドネットワークをオンプレミス L2 の再現として見ないことである。
オンプレミスでは、ネットワークは L2 から構築する対象である。
AWS では、ネットワークは AWS が定義した到達性モデルを組み合わせる対象である。
この差分を整理すると、次のようになる。
| 観点 | オンプレミス | AWS VPC |
|---|---|---|
| 出発点 | 物理 / 仮想 L2 | VPC / Subnet / ENI |
| 分離単位 | VLAN / VRF | VPC / Subnet / Route Table / SG / NACL |
| 制御対象 | Port / VLAN / MAC / IP / Route | ENI / IP / Route Table / SG / NACL |
| 冗長化 | STP / MLAG / LACP / VRRP | AZ / ENI / Route / LB / DNS / TGW |
| 観測 | SPAN / TAP | VPC Traffic Mirroring / Flow Logs |
| サービス探索 | Broadcast / Multicast / DNS | DNS / API / Service Discovery / LB |
| Firewall | L2 透過 / L3 Routed | SG / NACL / Routed FW / GWLB |
AWS VPC は、オンプレミスの L2 自由度をそのまま再現する仕組みではない。
利用者に必要な到達性、分離、制御、観測の機能を、クラウド側が管理する抽象モデルとして提供している。
まとめ
AWS VPC において L2 が原理的に存在しないわけではない。
物理 NIC、仮想 NIC、MAC、転送プレーン、SDN 的な制御は当然存在する。しかし、それらは AWS の責任境界内に閉じられており、利用者が VLAN、ブロードキャストドメイン、MAC 学習、透過 Firewall、VRRP、VLAN trunk として自由に扱うものではない。
AWS が利用者に渡しているのは、自由な仮想 Ethernet ではない。VPC、Subnet、ENI、Private IP、Route Table、Security Group、NACL、Load Balancer、Transit Gateway、Gateway Load Balancer などによって構成される、クラウド側で制御された到達性モデルである。
オンプレミスの L2 概念は、AWS 上である程度翻訳できる。しかし、その翻訳は等価変換ではない。切替速度、検知方式、制御主体、観測範囲、障害時の責任境界、運用手順が変わる。
したがって、クラウドネットワーク設計で重要なのは、L2 を再現することではない。AWS が提供する抽象化された到達性モデルを理解し、その制約と責任境界の中で、必要な性質を再設計することである。
オンプレミスから AWS へのネットワーク設計の移行は、L2 構成の移植ではなく、必要な性質を AWS の到達性モデルへ翻訳する作業である。そして、その翻訳は等価変換ではない。
