クラウドインフラやKubernetesのネットワーク設計に日々頭を悩ませている皆さん、こんにちは。現場のSREとして数々の夜間障害や不可解なパケットロスを乗り越えてきた私から、今回はAWSのネットワークの基本でありながら、その深層を理解していないとドハマリする「セキュリティグループ（Security Group: SG）のステートフル挙動」について徹底的に解説しよう。
Web APIの設計や、コンテナ基盤からの外部APIコールを実装する際、「なぜインバウンド（またはアウトバウンド）を開けただけで通信が成立するのか？」を意識したことはあるだろうか。ネットワークACL（NACL）との違いを含め、パケットがAWSの仮想ルーター群をどのように駆け巡っているのか、そのリアルな挙動を紐解いていく。
—
1. セキュリティグループはなぜ「ステートフル」なのか？
AWSのセキュリティグループを語る上で絶対に外せないキーワードが「ステートフル（Stateful）」だ。対義語である「ステートレス（Stateless）」なNACLと比較しながら、その本質を押さえよう。
ステートレス（NACL）の現実
NACLはサブネット境界を守る門番だ。NACLを使う場合、インバウンド（受信）で TCP 443 を許可したとしても、それに対するサーバーからの戻りパケット（送信）を通すためには、アウトバウンド側でもエフェメラルポート（高位ポート: 1024-65535）への通信を明示的に許可しなければならない。これを忘れると、パケットは往路を突破できても復路でNACLの門前払い食らうことになる。
ステートフル（セキュリティグループ）の優位性
一方、インスタンス（ENI）単位でアタッチされるセキュリティグループは完全にステートフルだ。
インバウンドルールで「誰から、どのポートへのアクセスを許可するか」を定義すれば、AWSの仮想ファイアウォール（基盤側のHypervisor層やDPDKで最適化されたパケット処理エンジン）が通信の「状態（State）」を自動的に記憶してくれる。
つまり、インバウンドで通信が許可されてコネクションが確立されると、それに対する戻りパケット（応答パケット）は、アウトバウンドのルールがいかに全拒否（あるいは何も設定されていない状態）であっても、自動的に許可される。この挙動こそが、アプリケーション開発者を複雑なポート管理から解放している最大の立役者だ。
—
2. パケットのライフサイクル：往路と復路のシーケンス
では、実際にクライアントからAWS上のWeb APIサーバーへリクエストが飛び、レスポンスが返るまでのパケットの動きを、裏側のステート管理の視点から追ってみよう。
[クライアント (Public)]
│
▼ (1. SYNパケット送信: Src Port: 54321 -> Dst Port: 443)
[Internet Gateway]
│
▼
[AWS VPC 仮想ルーター / SG評価]
* インバウンドルールに合致！
* コネクションテーブルにエントリを記録（State = ESTABLISHED）
│
▼
[EC2 / ターゲットインスタンス (Web API)]
│
▼ (2. SYN-ACKパケット返送: Src Port: 443 -> Dst Port: 54321)
[AWS VPC 仮想ルーター / SG評価]
* 既存のコネクションテーブルをヒット！
* アウトバウンドルールを評価せず、無条件に戻りパケットを通過させる
│
▼
[クライアント]ここで重要なのは、AWSの基盤レイヤーが保持しているコネクションテーブル（Connection Tracking Table）の存在だ。
TCPであれば 3-way handshake の SYN パケットを検知した瞬間にステートが記録され、UDPやICMPであっても、送信元IP・宛先IP・ポート番号の組み合わせから「擬似的なコネクション状態」が一定時間維持される。
—
3. 実務で直面する「コネクションスラッシング」とタイムアウトの罠
ステートフルだからといって、すべてが万能ではない。現場でよくあるトラブルが、このステート管理に起因する「コネクションスラッシング（Connection Thrashing）」や、通信の突然の切断だ。
アイドルタイムアウトの仕様
AWSのセキュリティグループやNATゲートウェイ、ALBなどのコンポーネントには、通信がない状態が続いた場合にコネクションテーブルからエントリを削除する「アイドルタイムアウト」が定められている。
- TCP通信: デフォルトで 350秒（5分50秒） 間、トラフィック（キープアライブ含む）がないとコネクションが破棄される。
- UDP通信: デフォルトで 120秒。
もし、マイクロサービスのAPIサーバー間や、データベースへのコネクションプールで、この時間以上何も通信を行わずに放置すると、AWS側は勝手にコネクション情報を忘れてしまう。その後に突然パケットを流そうとすると、ステートフルな追跡から外れてしまい、セキュリティグループやNACLに「なんだこの身元不明のパケットは！」とドロップされてしまうのだ。
【実務Tips】
長期的なコネクションを維持する必要がある場合は、アプリケーション層またはTCPのレイヤーで定期的に TCP Keep-Alive パケットを送信し、アイドル状態を回避する設計が不可欠となる。
—
4. 実践：セキュアなWeb API設計と検証コード
それでは、このステートフル挙動を前提とした、最も堅牢なセキュリティグループ設計のプラクティスを見ていこう。
推奨されるセキュリティグループ設計方針
1. インバウンド: 必要な外部（またはALB等）からのトラフィック（例: TCP 443）のみをピンポイントで許可する。
2. アウトバウンド: デフォルトでは全て許可（0.0.0.0/0 の全開放）になっていることが多いが、ゼロトラストの観点やセキュリティ監査の要件によっては、これを「完全に禁止（または外部への通信をプロキシ経由のみに制限）」することがある。
ただし、アウトバウンドを完全に絞る（またはカスタムルールにする）場合でも、ステートフル挙動があるおかげで、「インバウンドで受けたリクエストに対する返答」についてはアウトバウンドを塞いでいても自動で通る。ここを勘違いして「アウトバウンドを閉じたからAPIのレスポンスが返らないのでは」と悩むエンジニアが後を絶たないが、返答パケットはアウトバウンドのルール評価をバイパスする仕様になっているため安心してほしい。
動作確認用：PythonによるAPIクライアントとデバッグスクリプト
実際にAWS上のEC2やECSタスクから外部APIを呼び出す際の挙動をシミュレートするPythonスクリプトを用意した。アウトバウンドの向き先やステートの確認に役立ててほしい。
import urllib.request
import urllib.error
import json
import sys
def test_external_api_connection(api_url):
"""
AWS環境下のインスタンスから外部APIへリクエストを送り、
セキュリティグループのステートフル挙動（アウトバウンド許可＆戻りパケットの自動通過）
が正しく機能しているかを検証するサンプルコード。
"""
print(f"[*] 接続テスト開始: {api_url}")
# リクエストヘッダーの定義
headers = {
"User-Agent": "SRE-Infrastructure-Verifier/1.0",
"Accept": "application/json"
}
req = urllib.request.Request(api_url, headers=headers, method="GET")
try:
# 通信実行（内部でTCP 3-way handshakeが行われ、SGのステートが記録される）
with urllib.request.urlopen(req, timeout=5.0) as response:
status_code = response.getcode()
body = response.read().decode("utf-8")
print(f"[SUCCESS] ステータスコード: {status_code}")
print(f"[INFO] レスポンスボディの一部: {body[:100]}...")
except urllib.error.HTTPError as e:
# HTTPエラー（4xx, 5xx）は通信自体は成功している（＝SGやNACLはクリアしている）
print(f"[WARNING] サーバー側でエラーが返されました: {e.code} - {e.reason}")
except urllib.error.URLError as e:
# タイムアウトや名前解決失敗、またはセキュリティグループのアウトバウンド/NACLブロックによる障害
print(f"[CRITICAL] 通信に失敗しました。セキュリティグループやネットワーク経路を確認してください: {e.reason}", file=sys.stderr)
sys.exit(1)
if __name__ == "__main__":
# パブリックなテスト用APIエンドポイント
target_api = "https://httpbin.org/ip"
test_external_api_connection(target_api)—
5. トラブルシューティング：戻りパケットが拒否される悪夢のシナリオ
最後に、現場で遭遇した「ステートフルのはずなのに戻りパケットが捨てられる」というレアケース（しかし確実に起こる現象）を共有しておこう。
非対称ルーティング（Asymmetric Routing）の罠
AWSの単一VPC内、あるいは単一ENIを使っている限り、セキュリティグループのステート管理が狂うことは基本的にない。しかし、次のような高度なネットワーク構成をとった瞬間に事故が起きる。
- 1つのEC2インスタンスに複数のENI（Elastic Network Interface）をアタッチしている。
- VPN接続やAWS Direct Connect、VPCピアリングを経由して、往路と復路で異なるネットワーク経路（ルーティングテーブル）を通っている。
パケットAが ENI-1 から入り、セキュリティグループのステートが ENI-1 に記録されたにもかかわらず、OS側のルーティング設定の不備によって、応答パケットが ENI-2 から出ていこうとした場合――。
当然、ENI-2 側のセキュリティグループや基盤のトラッキングテーブルには該当するコネクション状態が存在しないため、戻りパケットは容赦なくドロップされる。
【デバッグの手順】
もしAPI通信で「リクエストは相手に届いているのにレスポンスが返ってこない（タイムアウトする）」という現象にぶつかったら、以下の手順で原因を切り分けろ。
1. VPC Flow Logsの有効化: 該当ENIのフローログを出力し、アクションが ACCEPT なのか REJECT なのかを確認する。
2. パケットキャプチャ（tcpdump）: EC2内部で sudo tcpdump -i any port 443 -nnvv を実行し、SYNに対してSYN-ACKが返っているか、あるいはパケット自体がロストしているかをOSレイヤーで直視する。
3. OSルーティングの確認: マルチホーム（複数NIC）環境であれば、ip rule や ip route を確認し、送信元IPに応じた適切なルーティング（Source IP Routing）が構成されているかを点検する。
—
まとめ
AWSセキュリティグループのステートフル挙動は、日々のインフラ運用を劇的にシンプルにしてくれる強力な機能だ。しかし、「裏側でAWSがしっかりコネクションを覚えてくれている」というブラックボックスに対する甘えは、複雑なマルチENI環境やロングコネクションを扱うシステムにおいて思わぬ落とし穴となる。
パケットがどこを通り、どのレイヤーで状態が保持され、どこで破棄されるのか。その「パケットの旅」を頭の中で完璧にトレースできるようになれば、いかなるネットワーク障害が起きたとしても、恐れることは何もない。現場のSREとして、自信を持ってセキュアで堅牢なクラウドインフラを構築していこう。
コメント