セキュリティグループ vs ネットワークACL難易度 高無料
プライベートサブネットのアプリケーションサーバから、インターネット上の外部 API（ポート 443）へ NAT ゲートウェイ経由でアウトバウンド接続を行っている。セキュリティグループの設定は問題ないと確認済みだが、外部 API からのレスポンスが届かず接続がタイムアウトする。サブネットのネットワークACL（NACL）の設定を確認したところ、次のようになっていた。
インバウンドルール: 100 ALL TRAFFIC DENY アウトバウンドルール: 100 TCP 443 0.0.0.0/0 ALLOW
タイムアウトの原因と、修正として最も適切なものを選べ。（単一選択）
- ANACL はステートフルなのでアウトバウンドの443許可だけで戻り通信も自動的に通るはずであり、原因は NACL 以外（セキュリティグループの再確認が必要）である
- Bインバウンドルールで、外部 API からの戻り通信を受けるためにエフェメラルポート範囲（例：1024-65535）を送信元
0.0.0.0/0から TCP で許可する ALLOW ルールを、既存の DENY ルール（ルール番号100）より小さいルール番号で追加する - Cアウトバウンドルールのポート指定を
443からALL TRAFFICに変更すれば、ステートレスな NACL でも戻り通信を含めて許可される - DNAT ゲートウェイを経由する通信は NACL の評価対象外となるため、原因は NAT ゲートウェイのルートテーブル設定にある
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：BAI作成・独立検証済
解説
ネットワークACL（NACL）はステートレスであり、往路と復路のルールをそれぞれ独立して明示的に許可しなければならない。
- アウトバウンドでポート 443 を許可しているため、アプリケーションサーバから外部 API へのリクエスト自体は送出できる。
- しかし外部 API からのレスポンスは、クライアント側（アプリケーションサーバ）が接続時に使用した一時的な送信元ポート＝エフェメラルポート（一般的に 1024〜65535）宛てに返ってくる。インバウンドルールが「ALL TRAFFIC DENY」のままでは、この戻りのレスポンスがブロックされる。
- 修正には、インバウンドルールに送信元
0.0.0.0/0・プロトコル TCP・ポート範囲1024-65535（OS のエフェメラルポート範囲に応じて調整）を許可する ALLOW ルールを、DENY ルールより小さいルール番号で追加する必要がある（NACL はルール番号の小さい順に評価し最初にマッチしたルールが適用される）。
- ANACL はステートレスであり、往路の許可だけで復路が自動的に通ることはない。本問の原因はまさに NACL のインバウンド側にある。
- Cアウトバウンド側をいくら緩めても、戻り通信は「インバウンド方向」の評価を受けるため、インバウンドルールで許可しない限り通らない。方向の取り違え。
- DNAT ゲートウェイを経由していても、送信元／宛先のサブネットに関連付けられた NACL の評価は通常どおり行われる。NACL が評価対象外になることはない。
ひっかけ： 「セキュリティグループの443許可＝双方向で通る（Aの発想）」との混同、および「NACLのアウトバウンド443許可だけで往復とも通る」という誤解が罠。NACL は方向ごとに別ルールが必要で、戻り通信はエフェメラルポート宛という点が最頻出のひっかけ。
またルール番号の評価順（若い番号が優先）を理解していないと、「ALLOW ルールを追加したのに DENY が先に評価されて効かない」という事故につながる（本問では番号を DENY(100) より小さくする必要がある）。
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）