【入門編】 AWS Network Firewallのステートレスおよびステートフルルール評価順序 – クラウドインフラと仮想化ネットワーク実践ガイド

AWS Network Firewallの「関所」を攻略せよ！ステートレスとステートフルの違いを完全理解する

こんにちは！現場のSREとして日々クラウドのネットワークと格闘しているエンジニアです。

今日は、AWS環境の「門番」として強力な役割を果たす「AWS Network Firewall」について解説します。名前からして少し堅苦しい印象がありますが、パケットの動きを「郵便配達」に例えてみると、驚くほどスッキリ理解できるんですよ。

「ステートレス？ステートフル？なんだか難しそう…」と身構える必要はありません。一歩ずつ、丁寧に紐解いていきましょう！

—

郵便配達でイメージする「2段階の検問」

AWS Network Firewallでのパケット検査は、いわば「2段階の関所」です。

第1の関所：ステートレスルール（「住所」だけの簡易チェック）

まずは、荷物の「宛先」や「送り主」の住所だけを見て、「この町（VPC）に入れていいか？」をサクッと判断する窓口です。

特徴： 非常に高速。ヘッダー情報（IPアドレスやポート番号など）だけで、「許可」「拒否」「次へ回す」を即断します。
現実世界でいうと： 「この宛先住所は怪しいから通さない！」「この宛先は安全だから中に入れて！」と、封筒の表書きだけを見て仕分ける郵便局の自動仕分け機のようなものです。

第2の関所：ステートフルルール（「中身」まで見る精密検査）

ステートレスで「通しても良さそうだ」と判断されたものだけが、さらに奥の精密検査へ進みます。

特徴： 通信の文脈（ステート）を理解します。「さっき通信を開始したのは自分からか？それとも外部からか？」まで考慮し、パケットの中身まで深く見ます。
現実世界でいうと： 税関の検査官です。単に住所が正しいかだけでなく、中身が危険物でないか、ルール違反をしていないかをじっくり確認します。

—

評価の順序：パケットはこう駆け巡る

パケットがVPCに飛び込んできたとき、AWS Network Firewallは以下の順序で処理を行います。

1. ステートレスルールの評価

上から順番にルールを適用します。
もし PASS や DROP が決まれば、そこで処理は終了です。
もし「どちらでもない（FORWARD_TO_STATEFUL）」と判定されれば、次の「ステートフルルール」の関所へ回されます。

2. ステートフルルールの評価

ここでは、Suricataという有名な検知エンジンのルールを使います。
複雑な条件（特定のドメインへのアクセス禁止など）もここでチェックします。

—

実践！ステートレスルールの設定例

まずは「とりあえず80番ポート（HTTP）と443番ポート（HTTPS）の通信は通して、あとはステートフルに任せる」という設定を考えてみましょう。

AWS CLIなどでルールグループを定義する際のイメージはこんな感じです。

{
  "Priority": 10,
  "RuleDefinition": {
    "MatchAttributes": {
      "Sources": [{"AddressDefinition": "0.0.0.0/0"}],
      "DestinationPorts": [
        {"FromPort": 80, "ToPort": 80},
        {"FromPort": 443, "ToPort": 443}
      ],
      "Protocols": [6]  // 6はTCPを指します
    },
    "Action": "FORWARD_TO_STATEFUL" // ステートレスで止めず、次の精密検査へ回す！
  }
}

この設定では、80や443宛の通信を「まずはステートフルで詳しく見てね」とパスしています。これ以外の通信が来た場合、デフォルトでDROP（拒否）するように設定しておけば、不要な通信を入り口でシャットアウトできるわけです。

—

なぜ「2段階」に分ける必要があるの？

「最初から全部精密検査すればいいのでは？」と思うかもしれません。でも、それだとネットワークがものすごく重くなってしまうんです。

全てのパケットを精査すると、CPUパワーを大量に消費し、通信速度がガタ落ちします。
「明らかに安全な通信（Webサイト閲覧など）」は、ステートレスの高速な処理で捌き、「怪しい通信や詳細なルールが必要な通信」だけをステートフルに回す。

この「メリハリ」こそが、クラウドインフラを設計する上での究極の最適化なんです。

—

現場のSREからのアドバイス

実務でAWS Network Firewallを触る際は、以下の3点に注意してください。

1. デフォルトアクションの罠：
ステートレスルールで何も設定に引っかからなかった場合の挙動（Default Actions）を正しく設定しましょう。うっかり全てDROPにすると、通信が一切通らなくなります。
2. Suricataルールの書き方：
ステートフルルールで使うSuricataの構文は、最初は難しく感じるかもしれません。まずは「特定のドメインへのアクセスを禁止する」といった簡単なルールから書き始めるのがコツです。
3. ログの可視化：
CloudWatch Logsにフローログを流しましょう。「なぜこの通信が遮断されたのか？」という答えは、すべてログの中にあります。

—

まとめ

ステートレスは「郵便の表書きチェック」。高速だが大雑把。
ステートフルは「税関の精密検査」。時間はかかるが確実。
この2つを組み合わせることで、「速さ」と「堅牢さ」を両立させるのがAWS Network Firewallの醍醐味です。

ネットワークの仕組みは、現実世界の物理的なフローとそっくりです。難しく考えすぎず、まずはパケットの「旅」を想像してみてください。きっと、あなたのクラウドインフラ設計がもっと楽しく、クリアに見えてくるはずですよ！

それでは、次回のインフラ解説もお楽しみに！