こんにちは！クラウドインフラの世界へようこそ。SREとして日々さまざまなシステムの裏側を支えていると、「あれ、パケットがどこかで迷子になっているぞ……？」という現場のトラブルに直面することがよくあります。
AWSのVPC（Virtual Private Cloud）を学び始めると、セキュリティグループという名前の「お馴染みの門番」に出会いますが、その一歩外側、サブネットの境界線上で目を光らせるもう一人の厳格な門番がいます。それがネットワークACL（NACL）です。
今回は、このNACLのちょっとクセのある「評価順序」と「ステートレス」という特性について、身近な例えを交えながら、一歩ずつ優しく紐解いていきましょう！
—
1. NACLってどんな存在？ 身近な例えでイメージしよう
セキュリティグループが「個別のサーバー（EC2インスタンス）の入り口を守る警備員」だとすれば、NACLは「マンション全体の敷地（サブネット）の入り口に立っている、ものすごく厳格な管理人さん」です。
マンションの住人（EC2）に会うためには、まず敷地の門（NACL）を通過しなければなりません。しかも、この管理人さんには2つの大きな特徴があります。
1. ルール番号の若い順から、上から下へ機械的にチェックする
2. 「行き」と「帰り」の往復を一切覚えていない（ステートレス）
この2つが、初心者インフラエンジニアを悩ませるポイントなのですが、仕組みさえ分かってしまえば怖くありません。順番に見ていきましょう！
—
2. ルール番号の評価順序：上から順番に「早い者勝ち」！
NACLには、ルールごとに小さな番号（例: 100、200、*など）を割り振ります。
この番号の意味を、私たちはよく誤解しがちです。「数字が小さい方が優先度が高いんでしょ？」……はい、その通りなのですが、厳密には「上から順番に見 ていって、最初にヒットしたルールが即座に採用される（評価が終わり、それ以降のルールは無視される）」という動きをします。
郵便配達のルールに例えてみましょう
あなたがマンションの管理人さんだと想像してください。手元には、住民から言い渡されたこんなメモ（ルール）があります。
- ルール 100：怪しい隣町の住所（
192.0.2.5）からの手紙は、すべて受け取り拒否（Deny）する！ - ルール 200：それ以外のまともな住所からの手紙は、すべて受け取る（Allow）！
もし、このメモの順番を間違えて……
- ルール 100：それ以外のまともな住所からの手紙は、すべて受け取る（Allow）！
- ルール 200：怪しい隣町の住所（
192.0.2.5）からの手紙は、すべて受け取り拒否（Deny）する！
……と書いてあったらどうなるでしょうか？
怪しい隣町の住人から手紙が届いたとき、あなたは上から順に見ていきますよね。すると、最初の「ルール 100（まともな住所はすべて受け取る）」に秒速でヒットしてしまいます。
その結果、「あ、受け取っていいんだな！」と判断してしまい、次の「ルール 200（本当は拒否したかった）」まで目が届きません。つまり、拒否したかったはずの怪しい手紙がスルーされてしまうのです。
これが、NACLのルール番号評価における最大の罠です。「拒否（Deny）」のルールは、必ず「許可（Allow）」のルールよりも上の番号（若い番号）に書く必要がある、という鉄則を覚えておいてくださいね。
—
3. ステートレスの特性と「エフェメラルポート」の悲劇
もう一つの大きな特徴が「ステートレス」です。
先ほどのマンションの管理人さん、実は極度の物忘れ魔（記憶力ゼロ）です。
セキュリティグループ（ステートフル）の門番は、「あ、さっきあなたが出ていくのを見たから、今帰ってきたんだね。通ってよし！」と、往復の文脈を記憶してくれます。
しかし、NACLの管理人さんは違います。あなたが外に出るときにチェックを受け、いざ用事を済ませて帰ってきたときにも、全く同じように「どちら様ですか？」と厳しくチェックされます。
これがWEBサーバーを構築するときに大問題になります。
WEBサイトにアクセスする流れを追ってみましょう
あなたが自分のパソコンから、AWS上のWEBサーバー（ポート 80 または 443）にアクセスしたとします。
1. インバウンド（行き）：
あなたのパソコンから、WEBサーバーの待ち受けポート（443）に向かってパケットが飛んできます。
- -> NACLのインバウンドルールで「
443番ポートへのアクセスを許可（Allow）」しておけば、無事にサーバーへ届きます。
2. アウトバウンド（帰り）：
WEBサーバーは「はい、どうぞ！」と返事を送り返そうとします。
このとき、返事の宛先となるあなたのパソコン側のポートは、一時的にランダムに割り振られたエフェメラルポート（一時ポート：通常 1024 〜 65535 のどれか）になっています。
ここでNACLのステートレスな性質が牙を剥きます。
サーバーが外へ返事を送ろうとしたとき、NACLのアウトバウンドルールがこうなっていたらどうなるでしょう？
> 「サーバーから外部への通信は、WEBの 443 番ポート以外はすべて禁止！」
サーバーは「いやいや、私の返事の宛先は相手のランダムな一時ポート（例えば 54321 番）なんだけど……！」と訴えますが、管理人さんは「ルールにないからダメです！」とパケットをバッサリとドロップ（破棄）してしまいます。
結果、ブラウザが「読み込んでいます……」のままグルグル回り続け、やがてタイムアウトエラーになってしまうのです。
—
4. 実務で役立つ！NACLの設定例と書き方
この悲劇を防ぐためには、NACLのアウトバウンド（またはインバウンド）ルールにおいて、エフェメラルポートの範囲を明示的に許可（Allow）してあげる必要があります。
実際のAWS CLIやTerraform、あるいはマネジメントコンソールで設定する際の、代表的な考え方を見てみましょう。
設定の具体例（インバウンド / アウトバウンドの基本形）
サブネットのデフォルトNACLは、最初は「すべて許可（Allow）」になっていますが、セキュリティを厳しくするためにカスタムNACLを作成した際は、以下のようなルール設計が必要になります。
インバウンドルール（受信）の例
外部からのWEBアクセスを受け付けるサブネットの場合
| ルール番号 | プロトコル | ポート範囲 | 送信元 (CIDR) | アクション | コメント |
| :— | :— | :— | :— | :— | :— |
| 100 | TCP | 443 | 0.0.0.0/0 | ALLOW | 外部からのHTTPSアクセスを許可 |
| 200 | TCP | 1024-65535 | 0.0.0.0/0 | ALLOW | 他のサーバーからの返信やエフェメラルポートを受け入れるため |
| 300 | ALL | ALL | 192.0.2.100/32 | DENY | 特定の悪意あるIPからのアクセスを完全にブロック |
| * | ALL | ALL | 0.0.0.0/0 | DENY | デフォルトの総括拒否ルール |
アウトバウンドルール（送信）の例
サーバーが外部へ通信（パッチのダウンロードや外部API呼び出しなど）を行う場合
| ルール番号 | プロトコル | ポート範囲 | 宛先 (CIDR) | アクション | コメント |
| :— | :— | :— | :— | :— | :— |
| 100 | TCP | 80 | 0.0.0.0/0 | ALLOW | HTTP通信（外部へのパッケージ取得など）を許可 |
| 110 | TCP | 443 | 0.0.0.0/0 | ALLOW | HTTPS通信（外部API連携など）を許可 |
| 200 | TCP | 1024-65535 | 0.0.0.0/0 | ALLOW | これ重要！ サーバーが返信を返す際のエフェメラルポートを許可 |
| * | ALL | ALL | 0.0.0.0/0 | DENY | デフォルトの総括拒否ルール |
このように、「一時ポート（エフェメラルポート）の範囲（1024-65535）」を明示的に許可してあげることで、ステートレスな環境であっても通信の往復を正常に成立させることができます。
—
5. まとめ：一歩ずつ、確実なネットワーク設計を
今回は、AWSのNACLにおける「評価順序の仕組み」と「ステートレス特性によるエフェメラルポートの罠」についてお話ししました。
- 評価順序は上から早い者勝ち！ 厳しいルール（Deny）ほど若い番号（上）に書く。
- ステートレスだから往復両方のルールが必要！ 返しのためにエフェメラルポート（
1024-65535）の許可を忘れない。
「なんだかルールが多くて難しそう……」と感じた方も、実際のパケットの流れを郵便配達やマンションの管理人に置き換えてイメージしてみると、ぐっと身近に感じられたのではないでしょうか？
現場のインフラ構築では、セキュリティグループで十分な制御ができるケースがほとんどですが、「特定の悪意あるIPレンジをサブネット手前で一網打尽にブロックしたい！」といった要件では、このNACLが最強の武器になります。
一つひとつの仕組みを丁寧なステップで理解して、自信を持ってクラウドインフラを構築していきましょう！それではまた次回の技術解説でお会いしましょう。
コメント