インフラやネットワークの世界へようこそ！クラウドの勉強を始めると、必ずと言っていいほどぶ Burg（壁）になるのが「サブネット」や「NATゲートウェイ」、そして「セキュリティグループ」といった用語の数々ですよね。
「パブリック？プライベート？」「インバウンドとアウトバウンドってどっちがどっちだっけ？」
そんな風に頭がこんがらがってしまうことは、決してあなただけではありません。第一線で活躍しているシニアエンジニアたちも、最初はみんな同じところで迷子になっていました。
今回は、AWSなどのパブリッククラウドにおける「NATゲートウェイのセキュリティグループとステートフルなパケット処理」という、一見すると呪文のようなテーマを、私たちの身近にある「郵便配達」の仕組みに例えながら、一歩ずつ優しく紐解いていきたいと思います。
難解な専門用語は置いておいて、まずはリラックスして読み進めてみてくださいね！
—
1. そもそもNATゲートウェイとセキュリティグループってなに？
パブリッククラウド（AWSなど）の世界では、サーバーを置く場所を大きく2つに分けます。
1. パブリックサブネット：インターネットと直接つながっている「表玄関」
2. プライベートサブネット：インターネットから直接は見えない「秘密の小部屋」
「秘密の小部屋（プライベートサブネット）」にいるサーバーたちは、セキュリティを保つために外の世界から直接見えないようになっています。しかし、「どうしても外の世界（外部のAPIやソフトウェアのアップデート元）と通信したい！」という時がありますよね。
そんな時にお手伝いをするのが、パブリックサブネットにポツンと佇む「NATゲートウェイ（Network Address Translation Gateway）」です。プライベートなサーバーの代わりに、自分が一度インターネットへ荷物（パケット）を出しに行って、返事を受け取って届けてくれる「おつかい名人」のような存在です。
そして、このNATゲートウェイの門番をしてくれるのが「セキュリティグループ（Security Group）」になります。
セキュリティグループは「超優秀なコンシェルジュ」
セキュリティグループは、NATゲートウェイというお城の門に立っている「超優秀なコンシェルジュ」だとイメージしてください。
このコンシェルジュは、お城に出入りする人（パケット）を厳しくチェックします。
- インバウンドルール：お城の「外から中」に入ってくる人をチェックするルール
- アウトバウンドルール：お城の「中から外」に出ていく人をチェックするルール
ここで非常に重要なのが、セキュリティグループの持つ「ステートフル（Stateful）」という性質です。これについて、次の章で詳しく見ていきましょう！
—
2. 身近な例えで理解する「ステートフルパケット処理」
「ステートフル」という言葉、エンジニアの試験などでもよく出てきますが、要するに「一度通した相手の顔（通信の文脈）をしっかり覚えている」ということです。
郵便配達の仕組みに例えてみましょう。
ステートレス（記憶喪失の門番）の場合
もし、セキュリティグループが「ステートレス（記憶なし）」だったらどうなるでしょうか？
1. あなた（プライベートサーバー）が、外の世界へ手紙を出すため、門番に「これ外に出して！」と渡します。門番は「よし、行ってよし！」と外へ出します（アウトバウンド許可）。
2. 数日後、宛先から返事が届きました。門番のところへ手紙が戻ってきます。
3. しかし、この門番は記憶喪失です。「ん？なんだこの手紙は？外から入ってくるやつは、インバウンドルールで許可されてないからダメ！」と言って、返事を取り上げてゴミ箱に捨ててしまいます。
これでは困りますよね！私たちがネットサーフィンをしたり、APIを叩いたりしても、返事が返ってこなくなってしまいます。
ステートフル（記憶力抜群のコンシェルジュ）の場合
AWSなどのクラウドにおけるセキュリティグループは、すべて「ステートフル」に作られています。
1. あなたが外へ向けて手紙を出します（アウトバウンド）。門番は「なるほど、〇〇宛てに手紙を出すんだな」とメモ帳に書き留めます。
2. 相手から返事が届きます（インバウンド）。
3. 門番はインバウンドのルールをいちいち見に行きません。代わりにメモ帳を開き、「あ、これはさっきうちの住民が出した手紙の返事だな！」と確認します。
4. 「返事だから、特別に通してあげよう！」と、何食わぬ顔で中へ通してくれます。
つまり、「自分から外へ出ていく通信（アウトバウンド）を許可していれば、そのお返事（インバウンド）は、わざわざインバウンドルールに書かなくても自動的に通してくれる」という優しい仕組みになっているのです。これがステートフルパケット処理の正体です！
—
3. 実務で役立つ！NATゲートウェイのセキュリティグループ設計
ここからは、実際にクラウド（AWSのAWS CLIやTerraformなど）を触るときに、どうやって設定すればいいのかという実用的なお話をしていきます。
「一歩ずつ理解していきましょう！」ということで、具体的な設定のポイントを見ていきますね。
基本的な考え方
NATゲートウェイ自体は、マネージドサービス（AWSが裏側でよしなに管理してくれるサービス）であるため、厳密には「NATゲートウェイ本体に直接セキュリティグループをアタッチする」というよりも、その背後にあるENI（Elastic Network Interface：仮想NIC）に対してセキュリティグループを適用する形になります。
設計時の鉄則は以下の2つです。
1. アウトバウンド（外へ出ていく通信）は基本的にすべて許可（0.0.0.0/0）する
2. インバウンド（外から入ってくる通信）は基本すべて拒否（何も書かない）する。ただし、ステートフルの性質を信じる！
設定ファイルのサンプル（Terraformの例）
インフラをコードで管理するツール「Terraform」を使って、安全なNATゲートウェイ用のセキュリティグループを書くと、次のようなイメージになります。
# NATゲートウェイ用セキュリティグループの定義
resource "aws_security_group "nat_gateway_sg" {
name "nat-gateway-security-group"
description "Security group for NAT Gateway with stateful rules"
vpc_id = aws_vpc.main.id
# 【アウトバウンドルール】
# 内部のプライベートサーバーからのすべての行き先（インターネット）への通信を許可する
egress {
description = "Allow all outbound traffic to the internet"
from_port = 0
to_port = 0
protocol = "-1" # すべてのプロトコル（TCP, UDP, ICMPなど）を許可
cidr_blocks = ["0.0.0.0/0"]
}
# 【インバウンドルール】
# 原則として直接のインバウンドルールは追加しません。
# なぜなら、アウトバウンドで送り出した通信に対する「お返事（戻りパケット）」は、
# セキュリティグループのステートフルな仕組みによって自動的に許可されるためです。
tags = {
Name = "nat-gateway-sg"
}
}この設定を見て、「あれ？インバウンドルールが1つも書いてないけど、本当に大丈夫なの？」と不安になるかもしれません。でも、大丈夫です！先ほどの郵便配達の例を思い出してください。
プライベートサーバーが「外のAPIサーバーにデータをちょうだい！」とリクエスト（アウトバウンド）を出したその瞬間、コンシェルジュが記憶してくれているため、APIサーバーからのデータ（インバウンドの戻りパケット）は、このセキュリティグループをスルスルと通り抜けてプライベートサーバーの元へ戻ってくるのです。
—
4. トラブルシューティングの現場から：よくあるハマりどころ
最後に、現場でよくある「あれ、通信できないぞ？」というトラブルの傾向と対策をこっそりシェアしますね。
ハマりどころ1：「インバウンドルールに返信用のポートを開けなきゃ！」と勘違いする
初心者のころにやりがちなのが、「外から返事が来るんだから、インバウンドルールに TCP 443 や TCP 80 を追加しなきゃいけないのでは？」と焦って書いてしまうことです。
ステートフルなセキュリティグループにおいては、これは不要です。むしろ、インバウンドを不用意にフルオープンしてしまうと、インターネット上の悪意ある第三者からの予期せぬアクセスを許してしまうリスクになりかねません。基本は「インバウンドは空っぽ（何も書かない）」が正解です。
ハマりどころ2：セキュリティグループとNACL（ネットワークAcl）の混同
AWSには、セキュリティグループのほかに「ネットワークACL（NACL）」という、サブネットの門番も存在します。
ここで大きな違いがあります：
- セキュリティグループ：ステートフル（お返事を自動で覚えていて通してくれる）
- ネットワークACL：ステートレス（記憶力ゼロ。行きも帰りも、両方のルールを自分でガチガチに書かないと通らない）
「あれ、セキュリティグループはちゃんと設定したのに通信できない！」という時は、大体このネットワークACLのルールで、戻りパケット（例えば一時ポートの 1024-65535 など）がブロックされているケースがほとんどです。トラブルシューティングの際は、両者の違いを思い出してみてくださいね。
—
まとめ
いかがでしたでしょうか？今回は、NATゲートウェイのセキュリティグループとステートフルパケット処理について、郵便配達の例えを交えながら解説しました。
- NATゲートウェイは、秘密の小部屋にいるサーバーたちのおつかい名人。
- セキュリティグループは、通信の門番。
- ステートフルなおかげで、一度外へ送り出した通信の「お返事」は、自動でスムーズに受け取ることができる。
インフラやネットワークの世界は、最初は難しく見えますが、身近な例えに置き換えて仕組みの本質（このパケットは今どこに向かっていて、何をしにいくのか）を想像できるようになると、パズルがカチリとハマるように楽しくなってきます。
日々の学習やインフラ構築の中で、もし壁にぶつかったら、いつでもこの記事に戻ってきて「あぁ、記憶力抜群のコンシェルジュだったな」と思い出してみてくださいね。あなたのクラウドライフが、より快適でワクワクするものになりますように！
コメント