返りの通信が通らない理由はこれ セキュリティグループとNACLの決定的な違い

AWS

セキュリティグループとNACLが混同される理由

セキュリティグループとNACLは、どちらも「ネットワークの通行許可」を決める仕組みです。しかも設定項目が似ています。プロトコル、ポート、送信元や宛先CIDR、インバウンドとアウトバウンド。見た目が近いので、初学者が混乱しやすいのは自然です。

ただ、決定的に違うのは「どこで効くのか」と「往復通信の扱い」です。ここが腹落ちすると、問題文でどちらを問われていても落ち着いて判断できるようになります。

この記事では、暗記ではなく“通信の具体例”で理解することをゴールにします。読み終わる頃には「この現象ならNACL側が怪しい」「これはセキュリティグループの設計の話だな」と切り分けできる状態を目指します。


SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇

まず押さえる基本 どこで効くか 何ができるか

最初に、両者の役割を短く整理します。ここが整理できると、後半の通信例が一気に読みやすくなります。

セキュリティグループはリソースの手前で効く

セキュリティグループは、EC2などのリソースに関連付く“仮想ファイアウォール”です。インスタンス起動時にセキュリティグループを関連付け、インバウンドとアウトバウンドのルールで到達可能な通信を制御します。

ポイントは次の2つです。

  • ステートフル
    コネクショントラッキングにより、往復の状態を追跡します。そのため、片方向の許可があると“返りの通信”が自動的に許可される挙動になります。
  • 許可ルールのみ
    原則として「これを通す」を書く思想で、細かな拒否を積み上げていくより、必要最小限の許可で閉じるのに向きます。

NACLはサブネット境界で効く

NACLはサブネットに紐づく仕組みで、サブネットレベルでインバウンドとアウトバウンドを許可または拒否できます。

ポイントは次の3つです。

  • ステートレス
    往復の状態を見ません。片方向だけ許可しても、反対方向が許可されていなければ通信は成立しません。
  • ルールは番号順に評価され、最初に一致したものが適用
    低いルール番号から評価され、マッチした時点で決まります。
  • どのルールにも一致しなければ拒否される
    デフォルトNACLは“すべて許可”寄りですが、最終的に一致しない通信を拒否する仕組みが入っています。

まず覚える一言まとめ

  • セキュリティグループはインスタンスなどの“近距離の門番”(ステートフル、許可中心)
  • NACLはサブネット境界の“外堀”(ステートレス、許可と拒否、番号順)

ここまでが前提です。次から、具体的な通信の往復で「どこが詰まりやすいか」を体感します。


通信の具体例で腹落ちさせる 3つの往復シナリオ

ここがこの記事の中心です。SAA-C03でも前提として扱われやすい“往復通信”の考え方を、パターン別に整理します。

シナリオ1 自宅からEC2へSSHする

状況はシンプルです。

  • 自宅PC → EC2 : TCP 22(SSH)

このとき、初心者がやりがちな設定はこうです。

  • セキュリティグループのインバウンドで「TCP 22 を自宅のグローバルIPから許可」
  • NACLは触っていない(デフォルトのまま)

この構成なら、多くの場合は通ります。デフォルトNACLは広く許可されていることが多いからです。

では、NACLをカスタム化して“硬く”したときに何が起こるか。

  • NACLのインバウンドで TCP 22 を許可した
  • でもNACLのアウトバウンドを厳しくしすぎて、返り方向が落ちる

NACLはステートレスなので、「行き」を許可しただけではダメで「返り」も許可が必要です。これが“返りの通信が通らない”の典型です。

さらに現場で多いのが「SSHは22だけ通せばいいと思っていた」です。実際には、クライアント側は接続開始時にエフェメラルポート(動的な送信元ポート)を使います。クライアントOSにより範囲は変動します。AWSドキュメントでも、Linux系での例として 32768-61000 などが挙げられています。

つまり、NACLを厳密に書くなら、方向とポートレンジを“往復”で意識する必要があります。

シナリオ2 外部からALB経由でWebアプリにアクセスする

次は少し実務寄りで、SAA-C03でも登場しやすい構成です。

  • ユーザー → ALB : TCP 443
  • ALB → EC2 : TCP 80 または 443
  • EC2 → ALB : 返り通信(ここが重要)

ここで混乱ポイントが一気に増えます。なぜなら、サブネットが複数出てくるからです。

  • ALBがいるサブネット(パブリック)にもNACLがある
  • EC2がいるサブネット(プライベート)にもNACLがある
  • それぞれで「インバウンドとアウトバウンド」を考える必要がある

特にNACLはステートレスなので、ALBとターゲット間の通信が両方向で成立するように許可を揃える必要があります。ロードバランサのトラブルシューティングでも、NACLが双方向の通信を許可していないと問題になることが明記されています。

さらに、ALB系の“詰まり”でよく見るのがエフェメラルポートです。ALB側とターゲット側の通信では、返りに 1024-65535 のようなエフェメラルポート範囲が関わるケースがあり、ドキュメントでもNACL設定不備でタイムアウトが起きる例が触れられています。

ここでの理解のコツは、通信を次の2段に分けることです。

  • ユーザー ↔ ALB(インターネット側の往復)
  • ALB ↔ EC2(VPC内の往復)

そして、**各段で「NACLは往復で許可」「セキュリティグループは戻りが自動許可されやすい」**を当てはめていくと、設定の読み解きが安定します。

シナリオ3 ICMPの疎通確認で片方向だけ許可した

最後は“理解チェック”にちょうどいい例です。pingは学習でも検証でも使うので、ここでステートフルとステートレスの差がはっきり出ます。

AWSのVPC Flow Logsのレコード例で、次のような状況が説明されています。

  • セキュリティグループのインバウンドで ICMP を許可
  • セキュリティグループのアウトバウンドでは ICMP を許可していない
    それでもセキュリティグループがステートフルなので応答が返る
  • 一方でNACLはアウトバウンドで ICMP を許可していないと、そちら側で落ち得る

この例は、学習者が「アウトバウンド閉じてるのにpingが返るのはなぜ?」と感じた瞬間に刺さります。コネクショントラッキングによる“戻り許可”が、セキュリティグループ理解の核心です。


設計の考え方 役割分担とよくある落とし穴

理解できたら、次は“どう使い分けるか”です。ここはSAA-C03でも実務でも、判断軸として効いてきます。

基本はセキュリティグループを主役にする

AWSのVPCセキュリティに関するガイダンスでは、ネットワークアクセス制御の主役としてセキュリティグループを使い、必要に応じてNACLを補助的に使う、という方向性が示されています。

理由はシンプルです。

  • リソース単位で細かく制御できる
  • ステートフルで運用が安定しやすい
  • セキュリティグループ参照など、設計の柔軟性が高い

NACLは外堀として使うと強い

NACLはサブネット境界の“ガードレール”として効きます。例えば、誤ってセキュリティグループでSSHを全開放してしまっても、NACL側で特定の送信元しか通さないようにしておけば被害を抑えられる、という例が公式ドキュメントでも紹介されています。

また、セキュリティグループはコネクショントラッキングにより、ルール変更しても既存コネクションがすぐには切れないことがあります。即時に遮断したい場合などに、ステートレスなNACLが役立つという説明もあります。

よくある落とし穴

実務でも学習でも、詰まりポイントはだいたいここに集まります。

  • NACLで返り方向を許可していない(ステートレスの罠)
  • エフェメラルポートを意識していない(特にLB、VPCエンドポイント、外部クライアント)
  • ルール番号の優先順位で意図しないマッチをしている(先に当たったルールで決まる)
  • デフォルトNACLを“安全だと思って放置”または“全部閉じて事故る”
    デフォルトは広く許可される一方、一致しない通信は拒否される設計です。カスタム化するときは往復と例外設計が重要になります。

試験と実務で使える 迷ったときの切り分け手順と学び方

最後に、問題演習やハンズオンで迷ったときの“考え方の順番”を置いておきます。丸暗記より、この順番を持っているほうが強いです。

切り分けは サブネットか リソースか から入る

  • サブネット全体の話をしている → まずNACLが候補
  • 特定のEC2やENIの話をしている → まずセキュリティグループが候補

次に ステートフルか ステートレスか で確認する

  • 「返り通信」「片方向だけ許可」などの匂いがある → ステートレスのNACLが怪しい
  • 「アウトバウンド閉じてるのに返る」みたいな話 → セキュリティグループのステートフル性の話かもしれない

迷ったらVPC Flow Logsで現象を言語化する

VPC Flow Logsは、セキュリティグループやNACLが“厳しすぎる/緩すぎる”ときの診断に役立つとAWS側でも説明されています。学習中でも、通信が落ちたときにログで確認すると理解が定着します。

体系的に学ぶならUdemyも相性がいい

このテーマは、文章で理解したあとに「自分で通信を流して詰まらせる」経験をすると一気に強くなります。UdemyにはSAA-C03対策として、VPCの設計からセキュリティグループとNACLの使い分け、ロードバランサやVPCエンドポイントまで一連で演習できる講座が複数あります。

ブログ記事で概念を整理して、Udemyで手を動かして詰まりポイントを再現し、最後に模試で文章問題に慣れる。この流れは、暗記に寄りすぎずに理解を積み上げるやり方として取り入れやすいはずです。


SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇

まとめ

セキュリティグループとNACLは、どちらもVPC内の通信制御ですが、役割と挙動ははっきり違います。セキュリティグループはリソースの近くで動くステートフルな仕組みで、コネクショントラッキングにより返りの通信が扱いやすいのが特徴です。
一方、NACLはサブネット境界で動くステートレスな仕組みで、インバウンドとアウトバウンドの両方を揃えないと通信が成立しません。さらにルール番号の評価順やエフェメラルポートの考慮が、理解していないと混乱しやすいポイントになります。

SAA-C03の学習では、「どっちが何者か」を暗記するより、通信を往復で追って“どこで落ちるか”を説明できる状態を目指すと強いです。文章で整理したら、Flow Logsで観察したり、Udemyのハンズオン系講座で再現してみると、知識が実務レベルの判断力に変わっていきます。

タイトルとURLをコピーしました