AWS VPC に L2 はあるのか – VLAN / ARP / VIP をクラウドの到達性モデルへ翻訳する

AWS VPC は仮想ネットワークです。しかし、オンプレミスで VLAN、L2 セグメント、ARP、ブロードキャスト、VRRP、透過 Firewall、SPAN を扱ってきた目線で見ると、同じ「ネットワーク」という言葉でも、設計対象がかなり違います。

結論から言えば、AWS VPC において L2 が原理的に消えているわけではありません。EC2 には ENI があり、OS から見れば NIC があり、MAC アドレスもあります。ただし、利用者が VLAN やブロードキャストドメインを自由に設計する世界ではありません。

AWS VPC で利用者に渡されているのは、自由な仮想 Ethernet ではなく、VPC、Subnet、ENI、Private IP、Route Table、Security Group、NACL などで構成される クラウド側で制御された到達性モデル です。

まず結論

オンプレミスの L2 設計を AWS VPC に持ち込むときは、次のように考えると整理しやすいです。

オンプレミスでの発想	AWS VPC で見るべきもの	変わること
VLAN / L2 セグメント	Subnet / Route Table	L2 隣接性ではなく、IP 到達性と配置の単位として見る
物理 NIC / 仮想 NIC	ENI	OS 側の NIC だけでなく、AWS 制御プレーン上の論理インターフェースとして扱う
Firewall を経路上に置く	Security Group / NACL / GWLB	単一の箱ではなく、複数の制御点へ分散する
VIP を浮かせる	ENI / Route Table / Load Balancer / DNS	VRRP の再現ではなく、到達先の切替として設計する
SPAN / TAP で見る	Traffic Mirroring / Flow Logs	全部見える場所ではなく、目的別の観測に分ける
L2 延伸	Direct Connect / VPN / TGW	接続しても L2 が延長されるわけではない

つまり、AWS VPC は L2 の再現ではありません。オンプレミスで L2 が担っていた役割を、AWS のオブジェクトとサービスへ翻訳する必要があります。

オンプレミスでは L2 が設計対象になる

オンプレミスでは、ネットワーク設計はかなり下のレイヤーから始まります。VLAN を切り、trunk を設計し、MAC 学習や ARP、ブロードキャスト、STP、MLAG、LACP、VRRP、透過 Firewall、SPAN などを必要に応じて扱います。

この世界では、L2 は単なる下位実装ではありません。どの機器を同一セグメントに置くか、どこで L3 境界を作るか、どの経路に Firewall を挟むか、どこでパケットを観測するかという設計対象そのものです。

• VLAN は L2 セグメントを分ける単位になる
• VRRP / HSRP は同一 L2 セグメント上の gateway 冗長化として使われる
• 透過 Firewall は IP 設計を大きく変えずに経路上へ挟める
• SPAN / TAP は特定の場所を流れるパケットを観測できる
• ブロードキャストや ARP は同一セグメント内の通信前提として存在する

AWS VPC で利用者に見える境界

AWS VPC で利用者が直接扱う中心は、VLAN や MAC table ではありません。VPC、Subnet、ENI、Private IP、Route Table、Security Group、NACL、Internet Gateway、NAT Gateway、Transit Gateway、Gateway Load Balancer などです。

AWS 公式ドキュメントでも、Subnet は Availability Zone 内に存在する IP アドレス範囲として扱われ、Route Table は VPC 内外の通信先を制御する仕組みとして説明されています。Security Group はリソースに対する仮想 Firewall、NACL は Subnet レベルの通信制御です。

AWS の要素	オンプレミス風に誤読しやすい点	実際に見るべき点
VPC	大きな L2 ネットワーク	論理的に分離された IP ネットワーク空間
Subnet	VLAN のクラウド版	AZ に属する IP アドレス範囲と配置単位
ENI	仮想 NIC	AWS 制御プレーンに登録された論理ネットワークインターフェース
Route Table	ルータ設定の一部	Subnet や gateway に関連付く到達性制御
Security Group	Firewall 装置	ENI / リソースに関連付くステートフル制御
NACL	Subnet Firewall	Subnet に関連付くステートレス制御
GWLB	透過 Firewall の置き換え	仮想アプライアンスへ通信を誘導するためのサービス

OS から見れば EC2 には NIC があり、通信も通常の IP 通信に見えます。しかし、その NIC は AWS 上では ENI として管理され、Private IP、Security Group、Source/Destination Check などの制御対象になります。

Subnet は VLAN と等価ではない

AWS VPC の Subnet は、見た目として VLAN に似ています。アドレス範囲を持ち、リソースを配置する単位にもなります。そのため、オンプレミス経験者は Subnet を VLAN のクラウド版として読みたくなります。

ただし、Subnet は L2 自由度を提供する単位ではありません。AWS 公式ドキュメントでは、Subnet は 1 つの Availability Zone 内に完全に収まる必要があり、複数 AZ にまたがることはできません。さらに、Subnet は Route Table に関連付けられ、その Route Table が通信先を制御します。

つまり、Subnet は VLAN のように L2 を自由に切る単位というより、配置、アドレス範囲、経路制御、可用性境界を結びつける単位として見る方が自然です。

Firewall は箱ではなく制御点に分解される

オンプレミスでは、Firewall は通信経路上に置く箱として考えやすいです。物理的または仮想的にインラインへ挟み、そこを通る通信を制御する発想です。

AWS では、この発想をそのまま持ち込むと誤解しやすくなります。Security Group はリソースに関連付くステートフルな制御であり、NACL は Subnet に関連付くステートレスな制御です。さらに、仮想アプライアンスを挿入したい場合は、Route Table、Gateway Load Balancer、Transit Gateway などを組み合わせて通信を誘導します。

目的	オンプレミスでの典型	AWS での考え方
インスタンス単位の通信制御	ホスト Firewall / 境界 Firewall	Security Group をリソースに関連付ける
Subnet 境界の補助制御	セグメント境界 ACL	NACL を Subnet に関連付ける
仮想アプライアンス挿入	L2 透過または Routed Firewall	GWLB、Route Table、TGW で通信を誘導する
広域集約	コア Firewall / 集約 Firewall	Transit Gateway と Security VPC の設計として扱う

したがって、AWS で Firewall を考える場合は、どこに箱を置くかだけではなく、どの通信をどの制御点へ通すのかを設計する必要があります。

VIP / HA は VRRP の再現ではない

オンプレミスでは、gateway や appliance の冗長化で VRRP / HSRP / keepalived / VIP を使うことがあります。これは、同一 L2 セグメント上で仮想 IP を共有できる前提があるからです。

AWS では、HA を単純に VIP を浮かせる問題として扱うと詰まりやすくなります。ENI の付け替え、Secondary Private IP、Route Table 更新、Load Balancer、DNS failover など、AWS の制御プレーン上で到達先を切り替える設計になります。

この違いは運用にも効きます。VRRP のような L2 近傍の収束ではなく、AWS API、ヘルスチェック、Route Table、Load Balancer、DNS などの制御に依存するため、切替速度、失敗時の見え方、責任境界が変わります。

Direct Connect でつないでも L2 は延長されない

AWS Direct Connect を使うと、オンプレミスと AWS を専用線で接続できます。しかし、Direct Connect はオンプレミスの L2 セグメントを AWS VPC へそのまま延長する仕組みではありません。

Direct Connect で重要なのは、Connection、VIF、DXGW、VGW、TGW、BGP の関係です。接続後に扱うのは、L2 延伸ではなく、経路広告、到達性、gateway association、責任分界です。

つまり、オンプレミス側で VLAN や L2 セグメントを設計していても、AWS 側では Subnet、Route Table、Security Group、NACL、TGW などのモデルへ翻訳して考える必要があります。Direct Connect は物理的・論理的な接続手段であり、オンプレミス L2 の自由度を AWS へ持ち込む魔法ではありません。

観測も SPAN からログとミラーリングへ変わる

オンプレミスでは、SPAN、TAP、ミラーポートによって、特定の場所を流れるパケットを観測する設計ができます。AWS では、観測もクラウド側の抽象に従います。

VPC Traffic Mirroring は ENI からネットワークトラフィックをコピーし、監視・解析用のターゲットへ送る機能です。一方、VPC Flow Logs は VPC 内の network interface などを流れる IP traffic の情報をログとして取得する機能です。

観測手段	向いていること	注意点
VPC Traffic Mirroring	パケット内容に近い観測、IDS / NDR / トラブルシュート	対象 ENI、フィルタ、ターゲット、コスト、対応インスタンスを確認する
VPC Flow Logs	通信の許可・拒否、送信元・宛先・ポート・バイト数などの証跡	パケット内容そのものではなくフローログとして扱う
サービスログ	ALB、NLB、DNS、CloudTrail などサービス単位の証跡	ネットワーク機器のミラーポートとは粒度が違う

AWS での観測設計は、どこかに全部見えるポートを作ることではありません。何を証跡として残したいのか、どのレイヤーを見たいのか、どのサービスログを組み合わせるのかを決める作業です。

L2 が封じ込められる理由

AWS が利用者に L2 自由度を渡さないことには、クラウド基盤としての理由があります。マルチテナント性、スケール、障害ドメイン分離、セキュリティ境界、API による運用自動化を考えると、利用者が任意に L2 ドメインを広げる設計は扱いにくくなります。

• ブロードキャストや未知ユニキャストを利用者が自由に広げると、スケールと分離の問題が出る
• MAC spoofing、ARP spoofing、ループ、flooding などの L2 的な事故をサービス境界内に閉じたい
• AZ、Subnet、Route Table、Security Group などの単位で障害境界と責任境界を制御したい
• ネットワークを物理機器設定ではなく API で扱えるサービスとして提供したい

このため、AWS VPC では L2 がなくなったというより、L2 の自由度が AWS 側の責任境界に閉じ込められていると考える方が正確です。

オンプレ設計を AWS へ翻訳するときの確認軸

オンプレミスの設計を AWS へ持っていく時は、構成要素をそのまま対応付けるより、何の性質を維持したいのかから分解した方が安全です。

確認軸	問い
到達性	どの送信元から、どの宛先へ、どの経路で到達させたいのか
分離	VPC、Subnet、Route Table、Security Group、NACL のどこで分離するのか
冗長化	Load Balancer、DNS、ENI、Route Table、Multi-AZ のどれで切り替えるのか
検査	Security Group / NACL で足りるのか、GWLB や仮想 Firewall が必要なのか
観測	Flow Logs、Traffic Mirroring、サービスログのどれを使うのか
責任分界	AWS、利用者、Direct Connect Partner、仮想アプライアンス製品のどこを見るのか

この確認軸にすると、VLAN を Subnet に置き換える、Firewall を EC2 に置く、VIP を浮かせる、といった単純移植から離れやすくなります。

まとめ

AWS VPC に L2 が原理的に存在しないわけではありません。ENI、MAC、転送プレーン、AWS 内部の SDN 的な仕組みは当然存在します。ただし、それらは AWS のサービス境界内にあり、利用者が VLAN、ブロードキャスト、MAC 学習、VRRP、SPAN のように自由に設計する対象ではありません。

AWS VPC が利用者に渡しているのは、自由な仮想 Ethernet ではなく、VPC、Subnet、ENI、Private IP、Route Table、Security Group、NACL、Load Balancer、Transit Gateway、Gateway Load Balancer などで構成される到達性モデルです。

オンプレミスから AWS へのネットワーク設計の移行は、L2 構成の移植ではありません。オンプレミスで L2 が担っていた性質を分解し、AWS の到達性モデルへ翻訳する作業です。そして、その翻訳は等価変換ではありません。

参考資料

• How Amazon VPC works
• Subnets for your VPC
• Configure route tables
• Control traffic to your AWS resources using security groups
• Control subnet traffic with network access control lists
• Elastic network interfaces
• What is Traffic Mirroring?
• VPC Flow Logs
• What is a Gateway Load Balancer?

関連記事

• AWS Direct Connect は何を接続するのか – Connection / VIF / DXGW / TGW の責務分界
• AWS Outposts の本質は「オンプレ AWS」ではなく、責任分界を変えるインフラである
• AWS Outposts racks と Outposts servers は別物として評価すべき
• AWS EC2 のネットワーク帯域をどう読むか – baseline / burst / flow 制約と NFV 設計
• パブリッククラウド上で NFV 型ネットワーク機能は成立するのか
• クラウドという言葉の本質 – 場所ではなく運用モデルと責任分界で考える