AWSパブリックサブネットの「繋がらない」を解剖する――パケットの視点から見るネットワークの深淵
クラウドのエンジニアとして数え切れないほどの夜を徹してきたが、依然として「パブリックサブネットに置いたはずのEC2に到達できない」というチケットは、現場のエンジニアを最も苛立たせる問題の一つだ。
コンソールを眺めて「設定は合っているはず」と呟く前に、一度立ち止まってほしい。IPパケットは、論理的な設定の背後にある、冷徹で無慈悲な物理（論理）層の制約に従って流れている。今回は、この「パケットの迷子」問題について、カーネルレベルの挙動からTCPスタックのチューニングまで、深く掘り下げていく。
1. パケットが帰路を見失う瞬間：ルートテーブルとIGWの動態
パブリックサブネットとは、単に 0.0.0.0/0 を igw-xxxxxxxx に向けているだけの場所ではない。それは、AWSのSDN（Software Defined Network）の境界線上にあるゲートウェイです。
もし curl が Connection timeout を返すなら、真っ先に疑うべきは非対称ルーティングあるいはルートの欠落だ。
- IGWのアタッチ状態: VPCにIGWがアタッチされていない場合、パケットはVPC境界で黙って破棄される。
- ルートテーブルの伝播: サブネットに関連付けられたルートテーブルに
0.0.0.0/0→igw-xxxが存在しない場合、パケットは「行き場のない手紙」としてカーネル内のルーティングテーブルで破棄される。
2. フィルタリングという名の「黒い壁」：NACLとセキュリティグループ
ネットワークレイヤーを語る上で避けて通れないのが、ステートレスな Network ACL (NACL) とステートフルな Security Group (SG) の違いだ。
パケットの行軍記録
1. NACL: パケットはサブネットの境界で一度足を止められる。ここで Egress（戻り）のルールが欠落していれば、たとえSGが許容していても、TCPの SYN-ACK はサブネットから外に出られない。
2. SG: インスタンスのNIC直前で評価される。ここでの Connection Tracking（conntrack）は、AWSのインフラ層で最適化されているが、誤ったルールは即座に TCP RST を誘発する。
現場のトラブルシューティングでは、tcpdump を使って以下のコマンドでパケットの生死を確認するのが定石だ。
# eth0インターフェースでSYNパケットをキャプチャし、戻りのパケットがあるか確認する
# 非対称ルーティングやNACLのブロックを可視化する
sudo tcpdump -ni eth0 tcp port 80 or tcp port 443 -vv3. RTT削減とTCPスタックの極限チューニング
パケットが到達したとして、次は「パフォーマンス」の話だ。特にレイテンシに厳しいアプリケーションでは、OSのデフォルト設定は甘すぎる。TCPハンドシェイクのRTT（Round Trip Time）を削減し、スループットを最大化するためのカーネルパラメータを調整せよ。
/etc/sysctl.conf に以下の設定を投入し、TCPの窓口を広げることを推奨する。
# TCPウィンドウサイズを拡大し、高遅延環境でのスループットを向上させる
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# SYNフラッド攻撃を緩和しつつ、ハンドシェイクを高速化する
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1 # TIME_WAIT状態のソケットを再利用可能にする4. トランスポートセキュリティとヘッダー圧縮
現代の通信において、TLSハンドシェイクはコストが高い。もしWebフロントエンドのパフォーマンスを最適化するなら、TLS 1.3 への完全移行は必須だ。また、HTTP/2やHTTP/3 (QUIC) を利用することで、HPACK や QPACK といったヘッダー圧縮アルゴリズムを活用し、パケットのオーバーヘッドを劇的に減らすことができる。
特に、パケットロスが発生しやすい不安定な回線においては、QUIC の採用がTCPの Head-of-Line Blocking を回避する唯一の解となる場合が多い。
結論：ネットワークは「生き物」である
「パブリックサブネットに繋がらない」というエラーは、単なる設定ミスではない。それはインフラの設計図が、現実世界のパケットの流れと乖離していることを示すサインだ。
- ルートテーブルはパケットの「地図」
- NACLはサブネットの「国境警備」
- SGはインスタンスの「門番」
これらをパケットの視点で追いかけるスキルこそが、真のSREの武器となる。ドキュメントをなぞるだけではなく、パケットがどの瞬間に破棄され、どのルートで迷子になったのかを想像する。その泥臭い洞察こそが、圧倒的な可用性を支える基盤となるのだ。
次回のトラブルシューティングでは、ぜひ traceroute や mtr だけでなく、AWS Flow Logs を駆使して、パケットの「拒絶された理由」まで深掘りしてみてほしい。技術の深淵は、その先にある。
コメント