AWS VPCの深淵：EIPのパケットマッピングとフローログが語る「真実の経路」
クラウドインフラの設計において、AWS VPCのパブリックサブネットは一見シンプルに見える。しかし、その裏側で起きているパケットの変換処理やトラフィックの可視化仕様を理解しているか否かで、障害対応の質とセキュリティ設計の深さは決定的に変わる。
今回は、AWSにおけるパケットの「静的マッピング」という名の虚像と、フローログが捉える「真実のIP」について、ネットワークエンジニアの視点から解剖していく。
—
1. エラスティックIP（EIP）の正体：1:1静的NATのメカニズム
AWSにおいて、EC2インスタンスやNATゲートウェイに EIP を割り当てた瞬間、何が起きているのか。
多くの技術者が誤解しがちだが、OS（Linuxカーネル）の eth0 に見えるプライベートIPが、そのままインターネットへ流出しているわけではない。AWSの物理ネットワーク層では、EIP はVPCのゲートウェイ付近で実行される 1:1の静的NAT（Network Address Translation） として実装されている。
パケットのライフサイクル
1. 送信時: インスタンスがプライベートIPでパケットを送り出す。VPCのエンクレーブ（物理ホスト上の仮想スイッチ層）を通過する際、送信元IPがプライベートIPから EIP に書き換えられる。
2. 受信時: インターネットからのパケットがVPCのIGW（インターネットゲートウェイ）に到達すると、マッピングテーブルが参照され、宛先IPが EIP からインスタンスのプライベートIPへと変換される。
この処理はAWSのハードウェアオフロード層（Nitroシステム）で極めて低遅延に実行されるため、アプリケーション層がこの変換を意識する必要はない。しかし、TCPのハンドシェイクにおいては、このNAT処理がRTT（往復遅延）の微細な変動要因になることは頭の片隅に置いておくべきだ。
—
2. VPCフローログの「罠」：なぜ送信元IPは変換前なのか
トラブルシューティングで最もハマりやすいのが、VPC Flow Logs の記録仕様だ。
結論から言えば、フローログには「NAT変換前のプライベートIP」が記録される。これが何を意味するか。外部からの攻撃を受けた際、ログ上の srcAddr はインターネット上の攻撃者IPだが、dstAddr はインスタンスのプライベートIPとなる。
もし EIP を経由した通信の正確なパケットトレースが必要なら、フローログだけでは不十分だ。なぜなら、AWSのフローログは「ENI（Elastic Network Interface）」レベルでキャプチャされるため、NATという「外側の皮」を剥いた後の、純粋なプライベートトラフィックとして記録されるからだ。
セキュリティの最適化：パケットフィルタリング
フローログを分析する際は、以下の点に注意せよ。
- コンテキストの補完:
dstAddrがプライベートIPであるため、ログ集約時に「どのEIP宛の通信か」を紐付けるメタデータ（interface-idやpkt-srcaddr）を必ずクエリに含めること。 - 脆弱性の回避: パブリックサブネットに公開するインスタンスには、
Security Groupだけでなく、必ずNetwork ACLを併用し、ステートフルなフィルタリングとステートレスな防御の二重構造を構築すべきだ。
—
3. 極限のパフォーマンスチューニング：TCPとカーネルの最適化
パブリックサブネット上のインスタンスにおいて、スループットとレイテンシを極限まで絞り出すには、カーネルパラメータのチューニングが不可欠だ。特に、インターネットとの往復が多いWebサーバーやAPIサーバーでは、以下の設定を推奨する。
# /etc/sysctl.conf に追記し、再読み込みする設定例
# TCPウィンドウサイズを拡大し、高遅延環境でのスループットを改善
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# TIME_WAIT ソケットを再利用し、ポート枯渇を防ぐ（EIP環境で必須）
net.ipv4.tcp_tw_reuse = 1
# TCP Fast Open を有効化し、3-wayハンドシェイクのRTTを1往復削減
net.ipv4.tcp_fastopen = 3
# 輻輳制御アルゴリズムをBBRに変更（Google開発の最新アルゴリズム）
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbrTCP Fast Open と BBR の組み合わせは、特に物理的な距離が離れたクライアントとの通信において、劇的なレスポンス向上をもたらす。
—
4. 結びに：可視化なきアーキテクチャは盲目である
クラウドのネットワークは「ソフトウェア定義」であるがゆえに、目に見えない変換処理が多層に重なっている。
1. EIP は単なるIPの割り当てではなく、ハードウェアレベルのNAT変換点である。
2. フローログはENIベースであり、NAT変換後のプライベートIPが記録される。
3. パフォーマンスは、カーネルパラメータという「OSの奥底」まで突き詰めて初めて最適化される。
これらの仕様を深く理解したSREであれば、パケットがどこでドロップし、どこで変換されているかを、ログの数値から透視できるようになるはずだ。
「なぜか繋がらない」「なぜか遅い」。そう感じた時こそ、抽象化されたクラウドのレイヤーを一枚剥がし、パケットの旅路を想像してほしい。そこには必ず、答えがある。
コメント