AWSインターネットゲートウェイ：物理なき「論理の怪物」を解剖する
クラウドエンジニアとしてAWS VPCを触り始めると、誰もが一度は「インターネットゲートウェイ（IGW）って結局何者なんだ？」という疑問にぶつかるはずです。コンソールから数クリックで作成でき、ルートテーブルに 0.0.0.0/0 を設定すれば疎通する。あまりに簡単すぎて、その裏側にある凄まじいエンジニアリングを忘れがちです。
今日は、この「論理の怪物」の正体を、パケットレベルの挙動からネットワークチューニングの深淵まで掘り下げて解き明かしていきましょう。
—
1. IGWは「ソフトウェア定義の巨大なパケットルーター」である
まず誤解を解きましょう。IGWは特定のEC2インスタンスやハードウェアアプライアンスではありません。AWSの広大な物理ネットワークファブリックの中に分散配置された、高度に最適化された仮想化ネットワーク機能の集合体です。
パケットの行方：NATの真実
プライベートサブネットからIGWへパケットが送られる際、何が起きているか。IGWはステートフルなNATゲートウェイ（別サービス）とは異なり、IGW自体はIPマスカレード（NAPT）を行いません。IGWの役割は、VPC内のプライベートIPとパブリックIPの「マッピング」を管理し、適切なルーティングを行うことです。
もしあなたがトラフィックの監視に tcpdump を使っているなら、IGWを通過するパケットのヘッダーを見てみてください。パケットはカプセル化（GENEVEやNVGREに近い仕組み）を経て、AWSのアンダーレイネットワークを光速で駆け抜けています。
—
2. 極限のパフォーマンスを引き出す：TCPバッファとRTTの制御
IGWそのものは水平スケーリングするため帯域制限は事実上ありません。しかし、ボトルネックは常に「エンドツーエンドのTCPスタック」にあります。特にグローバル展開するアプリケーションでは、RTT（往復遅延時間）の削減が全てです。
TCP ウィンドウサイズのチューニング
カーネルレベルでの最適化なしに、広帯域・高遅延のネットワークを語ることはできません。Linuxインスタンスでは、以下のパラメーターを調整してスループットを最大化します。
# /etc/sysctl.conf に追記し、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
# TCP Fast Open を有効化し、ハンドシェイクのRTTを削減
net.ipv4.tcp_fastopen = 3net.ipv4.tcp_fastopen を有効にすることで、2回目以降の接続においてSYNパケットにデータを含めることが可能になります。これは、特にモバイル回線のような不安定かつ高遅延な環境下で、体感速度を劇的に向上させる魔法です。
—
3. TLSハンドシェイクの最適化とセキュリティ
IGWを通過する通信のほとんどはTLSで保護されています。TLS 1.3の採用はもはや必須ですが、アーキテクトとしては「TLSハンドシェイクの回数」をいかに減らすかに注力すべきです。
- OCSP Stapling: 証明書失効確認をサーバー側で行い、クライアントの追加ハンドシェイクを抑制する。
- Session Resumption:
TLS Session Ticketsを利用し、再接続時の非対称暗号計算（CPU負荷の高い処理）をスキップする。
セキュリティの観点では、IGWが「AWS Network Firewall」や「WAF」とどう連携するかを設計してください。特に、IGWを通過する全パケットを検査する際は、サイドカー的なアーキテクチャよりも、AWSのマネージドサービスによるインライン検査を推奨します。
—
4. 脆弱性を回避するための「攻めの」ネットワーク設計
IGWを介した攻撃の典型は、DDoSやポートスキャンです。これらを防ぐための現場の知見を共有します。
1. Security Groupの「最小権限」原則:
0.0.0.0/0 からの全開放は論外です。特定のポートのみを許可し、可能であれば Prefix List を用いてAWS管理のIP範囲と連携させてください。
2. Network ACLの「防波堤」化:
Security Groupがステートフルなのに対し、Network ACLはステートレスです。IGWの手前で不要なプロトコルや特定の攻撃源を DENY するのは、カーネルの負荷を軽減する有効な手段です。
# セキュリティグループでのPrefix List利用例
resource "aws_security_group_rule" "allow_cloudfront" {
type = "ingress"
from_port = 443
to_port = 443
protocol = "tcp"
prefix_list_ids = ["pl-xxxxxxxx"] # CloudFrontのIP範囲を限定して制限する
security_group_id = aws_security_group.web_server.id
}—
最後に：インフラ屋の矜持
IGWはAWSの抽象化の極致です。「物理的なコンポーネントがない」ということは、私たちがハードウェアの故障に悩まされる必要がないことを意味します。しかし、だからこそ私たちは、その上で動くプロトコルの挙動に集中しなければなりません。
パケットがどのルートを辿り、どうカプセル化され、TCPのウィンドウサイズがどう変化しているか。この「目に見えない流れ」を想像できることこそが、真のインフラアーキテクトの矜持です。
次は、このIGWを介したトラフィックをさらに最適化する「AWS Global Accelerator」の活用法について深掘りしましょう。ネットワークの旅は、まだ始まったばかりです。
コメント