← → キー / クリックで進む・O で一覧

パケットの気持ちで巡る
AWSネットワーク

Shota SHIRATORI(NW-JAWS)
@whitebird_sp #NW_JAWS
※本資料に記載の内容は2026年8月4日12:00(JST)時点のものとなります
※本資料の見解・知見については所属する組織を代表するものではありません

自己紹介

白鳥 翔太
しらとり　しょうた
白鳥 翔太
ネクストモード・NTT東日本
経歴
2009年入社(NTT東日本)/ネットワークエンジニア〜セールス〜サービス開発/2025年ネクストモード出向
好きなAWSサービス
Amazon VPC
好きな言葉
Knowledge is Power. / Insist on the Highest Standards.
Any sufficiently advanced technology is indistinguishable from magic.

保有資格(レベル別)

Practitioner Cloud PractitionerAI Practitioner
Associate Solutions ArchitectDeveloperSysOps AdministratorData EngineerMachine Learning Engineer
Professional Solutions Architect ProDevOps Engineer ProGenerative AI Developer Pro
Specialty Advanced NetworkingSecurityMachine Learning
その他 G検定IPA ネットワークスペシャリストIPA 情報セキュリティスペシャリスト

実績

  • 2020-2022 APN AWS Top Engineers / 2023-2026 Japan AWS Top Engineers
  • 2023-2026 Japan AWS All Certifications Engineers
  • 2024-2026 AWS Ambassadors
  • AWS Ambassador - Certification All-Star Award 2024/2025
All-StarAmbassadorCommunity Builders

今ハマってるAWS関連

  • Claude Platform on AWSの環境設定

本日お話しすること・しないこと

○本日お話しすること

  • 公式情報や過去のre:Inventなどからの内部ネットワークに関する話

−本日お話ししないこと

  • 本当にガチの内部だけの話(仮に知っててもできません)
  • 個別サービスの話

登壇資料はアップ済みです

Web Sitehttps://d28axknthffgd8.cloudfront.net/nw_jaws_22_slides.html
スライドは後からゆっくりご覧いただけます

本題

今日の3つの疑問

今日のお話は知らなくてもAWSのエキスパートになれます。AWSの界隈で生きていけます。
「なぜ、こうなるのか?」を説明できるようになる話です。

①VPCは同一リージョン・同一CIDR・同一IPでもなぜ成立する?
②IGWはどこにいる? NAT GatewayはなぜAZごとに配置?
③ALBはなぜ暖気が必要で、NLBはなぜ固定IPを付与できる?

本日の全体像

EC2
ゲストOSNitro HypervisorNitro Card
→
Blackfoot
Hyperplane
→
AZ・グローバル網
→
インター
ネット
マッピングサービスすべての通信の宛先解決を支える

1つのパケットがどのように通信を行うか物理層まで追いかける

疑問①

なぜ、VPCは衝突しない?

VPC A

CIDR: 10.0.0.0/16
EC210.0.1.5
?

VPC B

CIDR: 10.0.0.0/16
EC210.0.1.5

同一リージョン・同一CIDR・同一IP。物理ネットワークの常識では説明できない。

疑問① なぜ、VPCは衝突しない?

EC2インスタンスを支える "Nitro System"

Nitro Cards

機能別の専用ハードウェア群

VPC用 / EBS用 / インスタンスストレージ用 / システム制御用。PCIe接続でI/Oと仮想化をオフロード。
本日の主役はNitro Card for VPC

Nitro Security Chip

ハードウェアレイヤのセキュリティ

ファームウェアを検証し、不揮発領域への書き込みを制御。「AWS自身も顧客データに触れない」を支える

Nitro Hypervisor

軽量ハイパーバイザ

CPU・メモリ割当てなど最小限のみを担当。I/Oの仮想化は持たない。ベアメタルではこれ自体が不在

Nitro Controller

コントロールプレーンの提供

APIエンドポイントの起点で、Nitroカード・ハイパーバイザー・セキュリティチップのコーディネートやハードウェアのコントローラーを担う

従来ハイパーバイザが担っていた機能を、専用ハードウェアへ分解・移譲したのがNitro System

疑問① なぜ、VPCは衝突しない?

ENIの仕組み "物理NIC + マッピングサービス"

ゲストOSから見える世界
ENAデバイス (eth0) — ドライバ越しの「NICのように見えるもの」
↓
論理エンティティ
ENI — マッピングサービス上のエントリ (IP・MAC・SG・サブネットの束)
↓
物理実体
Nitro Card for VPC — サーバーに刺さった本物のNIC。ENIのステートを実行する

「ENIをアタッチする」= 物理カードに論理ステートを流し込む操作

マッピングサービス ネットワーク周りを支える分散データベース
ENI のメタデータ
  • IPアドレス
  • MACアドレス
  • VPC ID
  • セキュリティグループ
疑問① なぜ、VPCは衝突しない?

マッピングサービスの動作モデル

権威ストア

リージョンの親DB

「VPC X の 10.0.2.8 (ENI)」→「物理ホスト N」を知る巨大な対応表。リージョンの全ENIを収容

Nitro Card上のキャッシュ

インメモリキャッシュ

パケット単位の問い合わせは不可能。Nitro Cardsが対応表をキャッシュし、ルックアップはローカルで完結

プッシュ型無効化

イベントドリブン

ENIの移動 (付け替え・フェイルオーバー) は即座にプッシュ配信。TTL切れを待つDNS型とは違う

※ 実装技術は非公開。本スライドは公開情報 (re:Invent 2015 NET403) に基づく動作モデル。
パケット転送の判断に使われる以上、ミリ秒級のDB(ex. DynamoDB)では成立しない — と推論だけは可能。

疑問① なぜ、VPCは衝突しない?

EC2間の通信の仕組み(EC2 ⇒ 物理間)

1
EC2インスタンスENAデバイス (eth0) からARPリクエストを送信
2
物理ホストあて先物理IPと物理MACをマッピングサービスに問い合わせて回答
3
EC2インスタンスIPヘッダとEthernetヘッダを付加して通信
4
送信元 Nitro Card for VPCあて先物理IPとあて先物理MAC、VPC IDを付加して送信
5
送信先 Nitro Card for VPCあて先物理IPとあて先物理MAC、VPC IDが正しいかマッピングサービスとチェック
マッピングサービス 1・2・5の裏で宛先を解決
ENI のメタデータ
  • IPアドレス
  • MACアドレス
  • VPC ID
  • セキュリティグループ
疑問① なぜ、VPCは衝突しない?

EC2間の通信の仕組み(Nitro Card間)

SRD (Scalable Reliable Datagram)
送信側
Nitro Card
受信側
Nitro Card
経路 1
経路 2 (混雑 → 回避)
経路 3
  • 順序保存を行わず、多数の経路へ同時分散したマルチパスルーティング — 混雑経路は避ける
  • 再構成・輻輳応答はNitro Card上に実装 (OSスタック非経由)
  • EFA (HPC/ML) から利用開始 → ENA ExpressでTCP/UDPにも開放
疑問① なぜ、VPCは衝突しない?

まとめ

物理ヘッダ — 宛先 = 物理ホストのアドレス
VPCヘッダ — VPC ID・ENI等のメタデータ
元のIPパケット
10.0.1.5 → 10.0.2.8 (アドレス — 元のIPヘッダ)

AWS上のネットワークは大量の仮想化(カプセル化)で成り立つ

物理網に「10.0.1.5」単独では流れていない — だから同一CIDRでも衝突しない

疑問② IGWはどこにいる? NAT GatewayはなぜAZごとに配置?

IGW/VGWはどこにいる?

NAT Gateway

AZを指定して配置 / ElasticIPを持つ / 帯域・同時接続数の上限が明記

Internet Gateway

AZ ? (指定しない) / IP ? (持たない) / 上限 ? (スループット制限の記載なし)

仮想プライベート Gateway

AZ ? (指定しない) / IP ? (持たない) / 帯域・同時接続数 (クォータの記載あり)

実体が見えない、落ちない。なぜIGWは単一障害点にならないのか?

疑問② IGWはどこにいる? NAT GatewayはなぜAZごとに配置?

Blackfoot — VPCと外をつなぐゲートウェイサービス

VPC
(カプセル化された内側)
Blackfoot フリート
インターネット
VPN
Direct Connect

デカプセル化 + NAT / 逆方向はカプセル化して世界に戻す

IGWは装置ではなく、水平スケールするBlackfootフリートへの「論理ポインタ」

疑問② IGWはどこにいる? NAT GatewayはなぜAZごとに配置?

NAT Gatewayは?

NAT Gatewayの解説図
疑問③ ALBはなぜ暖気が必要で、NLBはなぜ固定IPを付与できる?

ALB/NLBの機能の振り返り

ALB — プロキシフリート型

  • TCP/TLSを終端するL7プロキシノード群
  • スケール = ノードの追加・増強
  • DNSが返すIPは変動 (固定IP不可)
  • 急スパイクへの追従に時間 (かつてのpre-warming)

NLB — ???型

  • 接続を終端しないL4のフロー転送
  • 暖機不要、数百万RPSに即応
  • AZごとの固定IPを提供できる
  • ソースIPをそのまま保持

固定IP・即応・ソースIP保持 — プロキシでは説明できない。この差はどこから?

疑問③ ALBはなぜ暖気が必要で、NLBはなぜ固定IPを付与できる?

NLBの仕組み — Hyperplane(分散ステートマシン)

VPC→共有ENI→どのnodeに当たっても同じ変換
node
node
node
node
共有フローステート (このフローの往路/復路・変換・宛先)
  • VPCフロー単位で動くNFV基盤
  • ステートをノード間でリアルタイム共有
  • ノード障害 ≠ 接続断。容量追加 = セル追加 (暖機という概念がない)

プロキシは「接続」を持つ。Hyperplaneは「フローの合意」を持つ — よって固定IPも即応可能。

疑問③ ALBはなぜ暖気が必要で、NLBはなぜ固定IPを付与できる?

Hyperplaneを使用するサービス例

サービスHyperplaneとしての実体
NAT Gatewayフロー単位のアドレス変換
Network Load Balancerフロー単位のターゲット分散
Transit GatewayVPC間のルーティング
PrivateLinkVPC間のフロー橋渡し (だからNLBが前提)
EFS マウントターゲットVPCへのフロー投影
Lambda VPC接続 (2019〜)共有ENI経由のNAT

各サービスは同じ内部サービスの異なる実装

疑問② 疑問③

まとめ

VPC
Blackfoot フリート
インターネット
VPN
Direct Connect

外部ネットワークとの「翻訳」

VPC→共有ENI
node
node
node
node
共有フローステート

フローの高速・高可用処理

BlackfootとHyperplaneという2つの内部サービスに支えられている。

AZ/リージョン/インターネットへの通信

AZ

1つ以上のデータセンター群。電源・冷却・網が独立した障害ドメイン

AZ間

メトロ圏の冗長ダークファイバー。sub-msの安定遅延

リージョン間

AWS専有バックボーン (インターネット非経由)。自社設計ルーター + 100GbE

グローバルネットワーク図

全体のまとめ

EC2間
→
マッピングサービス
外部ネットワーク接続
→
Blackfoot
ネットワークフローの高速処理
→
Hyperplane

AWSのネットワークを支える内部サービスを知るとVPCはこう見えてくる

全体まとめ図

もっと知りたい人向け

もっと知りたい人はこんな動画を(昔のre:Inventの資料を中心に)