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

AWS VPC は仮想ネットワークですが、オンプレミスの VLAN、L2 セグメント、ARP、ブロードキャスト、VRRP、透過 Firewall、SPAN をそのまま再現する場所ではありません。OS から見れば EC2 には ENI があり、MAC アドレスもありますが、利用者が自由な Ethernet segment を設計する世界ではありません。

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

この記事では、オンプレミスの L2 設計を AWS VPC へそのまま移植するのではなく、どの要素へ翻訳して考えるかを確認します。

この記事の結論

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

オンプレミスのネットワークでは、VLAN、STP、ARP、VRRP、HSRP、LAG、SPAN、firewall の inline / transparent mode など、L2 を直接設計対象にする場面が多くあります。機器の配置、port、VLAN、trunk、tag、MAC learning、broadcast domain を図に描いて制御します。

この感覚で AWS VPC を見ると、Subnet を VLAN のように扱いたくなります。しかし、AWS VPC の Subnet は、利用者が自由に L2 動作を作るための VLAN ではありません。IP 到達性、route table、ENI、security group などの組み合わせとして扱う方が現実に合います。

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

AWS VPC で利用者が主に扱うのは、VPC CIDR、Subnet、Route Table、ENI、Private IP、Security Group、NACL、Internet Gateway、NAT Gateway、Transit Gateway、Gateway Load Balancer などです。これらは L2 の自由な再現ではなく、クラウド側で制御された到達性を設定するための部品です。

Subnet は VLAN と等価ではない

Subnet は VLAN に似た粒度で語られることがありますが、等価ではありません。Subnet は AZ に属し、route table を関連付け、IP address range を切る単位です。broadcast domain や L2 adjacency を自由に作るための単位ではありません。

そのため、オンプレミスで VLAN を分けていた理由を、そのまま AWS の Subnet 分割へ移す前に、何を分離したいのかを確認します。route、security、AZ、運用境界、障害範囲、IP 管理のどれを分けたいのかで Subnet 設計は変わります。

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

オンプレミスでは、Firewall を物理または仮想の箱として経路上に置く設計が分かりやすいです。AWS では、Security Group、NACL、route table、Gateway Load Balancer、AWS Network Firewall、third-party appliance など、制御点が分散します。

重要なのは、どこに Firewall を置くかだけではなく、どの traffic をどの制御点で止めるのか、どの logging をどこで見るのか、障害時にどの経路へ切り戻すのかです。

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

オンプレミスでは、VRRP や HSRP によって VIP を持たせ、active / standby の gateway を切り替える設計があります。AWS VPC では、gratuitous ARP や L2 adjacency を前提に同じ動きを再現する考え方は合いません。

AWS では、ENI の付け替え、secondary private IP、Route Table の target 変更、NLB、GWLB、managed service の冗長化など、クラウド側の仕組みで HA を設計します。ここでも、L2 の再現ではなく到達性の切り替えとして見ることが重要です。

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

Direct Connect は、オンプレミスと AWS を閉域で接続する強力な手段です。しかし、Direct Connect を使っても、オンプレミスの VLAN や broadcast domain が AWS VPC へそのまま延長されるわけではありません。

Direct Connect では、Connection、VIF、DXGW、VGW、TGW、BGP を通じて IP reachability を構成します。L2 延伸ではなく、route advertisement と責任分界を設計するものとして見る必要があります。

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

オンプレミスでは、SPAN / mirror port で traffic を観測する設計がよくあります。AWS では、VPC Flow Logs、Traffic Mirroring、CloudWatch metrics、appliance logs、load balancer logs などを組み合わせます。

Traffic Mirroring は強力ですが、物理 switch の SPAN と完全に同じではありません。対象 ENI、filter、session、collector、packet volume、cost、privacy の観点を合わせて設計します。

L2 が封じ込められる理由

AWS VPC で L2 を自由に扱えないことは制約ですが、同時にクラウドのスケールと安全性の前提でもあります。利用者ごとに自由な broadcast domain や L2 loop を許すと、クラウド全体の分離と制御が難しくなります。

その代わり、利用者は IP reachability、route table、security group、managed gateway、load balancer などを使って設計します。つまり、L2 の自由度を減らす代わりに、クラウド側の抽象化された制御点を使うモデルです。

AWS CLI で確認すること

VPC の到達性を確認するときは、Subnet だけでなく route table、ENI、security group、NACL を合わせて確認します。

aws ec2 describe-vpcs
aws ec2 describe-subnets
aws ec2 describe-route-tables
aws ec2 describe-network-interfaces
aws ec2 describe-security-groups
aws ec2 describe-network-acls

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

まとめ

AWS VPC に L2 がまったく存在しないわけではありません。EC2 には ENI があり、OS から見れば NIC や MAC address も見えます。しかし、利用者が VLAN、ARP、broadcast、VRRP、SPAN を自由に設計するオンプレミスの L2 とは違います。

AWS VPC では、L2 の発想をそのまま持ち込むのではなく、VPC、Subnet、ENI、Route Table、Security Group、NACL、GWLB、Traffic Mirroring へ翻訳して考えます。この翻訳ができると、オンプレミスの設計意図を保ったまま、クラウドの到達性モデルに合わせやすくなります。

関連記事

AWS Outposts の本質は「オンプレ AWS」ではなく、責任分界を変えるインフラである AWS EC2 のネットワーク帯域をどう読むか – baseline / burst / single-flow と NFV 設計 AWS Direct Connect は何を接続するのか – Connection / VIF / DXGW / TGW の責務分界 AWS Outposts racks と Outposts servers は別物として評価すべき