EC2 のセキュリティグループで 22 番を開けたのに SSH がつながらない。Web サーバーは見えているのに、サーバーから外の API を呼ぶと応答が返ってこない。VPC を触り始めた人がつまずく場所の多くは、「通信を止める門が2つある」ことに気づいていないところです。
VPC には、インスタンスの前に立つセキュリティグループと、サブネットの境目に立つネットワーク ACL(NACL)の2つの門があります。どちらも「どの通信を通すか」を決めますが、覚え方の違い(ステートフルかステートレスか)、書けるルールの違い(許可だけか、拒否も書けるか)、評価の順の違いがあります。この記事では、その3つの違いを1本の通信の旅として追い、「片方は開けたのに通らない」を切り分けられるところまで進みます。
この記事の結論
- セキュリティグループはインスタンスの前の門で、ネットワーク ACL はサブネットの境目の門です。
- セキュリティグループはステートフルで、許可した通信の戻りは自動で通します。
- ネットワーク ACL はステートレスで、行きと戻りの両方に許可のルールが要ります。
- セキュリティグループは許可だけを書き、ネットワーク ACL は許可と拒否の両方を番号順に書きます。
- 普段の絞り込みはセキュリティグループで行い、サブネット単位でまとめて拒否したいときにネットワーク ACL を使います。
セキュリティグループとネットワーク ACL とは
VPC の中の通信は、外からインスタンスに届くまでに2つの門を通ります。先にサブネットの境目でネットワーク ACL、次にインスタンスの前でセキュリティグループです。インスタンスから外へ出るときは、その逆の順です。
TWO GATES ON THE WAY外から届くまで
通信はサブネットの門を通ってから、インスタンスの門を通る
-
インターネット
外の利用者が送る
-
ゲートウェイ
VPC の出入口(IGW)
-
NACL
ネットワーク ACL。サブネットの境目
-
SG
セキュリティグループ。インスタンスの前
-
インスタンス
両方で許可されて届く
| 観点 | セキュリティグループ | ネットワーク ACL |
|---|---|---|
| 門の場所 | インスタンス(のネットワークインターフェイス)の前 | サブネットの境目 |
| 状態の覚え方 | ステートフル(戻りは自動で通す) | ステートレス(戻りも別に許可が要る) |
| 書けるルール | 許可だけ | 許可と拒否 |
| 評価の順 | 全部のルールを見て、どれかに当たれば通す | 番号の小さい順に見て、最初に当たったルールで決める |
| 何も書いていないとき | 新しく作った直後は受信が全部止まる | 既定のネットワーク ACL は全部通す。自分で作ったものは全部止まる |
| 付け方 | 1つのインスタンスに複数付けられる | 1つのサブネットに1つだけ |
たとえるなら、ネットワーク ACL はビルの入口の警備、セキュリティグループは各部屋のドアの鍵です。入口で止められれば部屋には届かず、入口を通っても部屋の鍵が合わなければ入れません。ただし、このたとえは門の場所を覚えるためのもので、それぞれの門の「覚え方」と「ルールの書き方」は次の章で正確な言葉に戻します。
READ ALSO — 学習中向け・段1 入口
VPC とは何か|サブネット・ルートテーブル・ゲートウェイ・セキュリティグループと NACL の関係を1枚で
ステートフルとステートレスは何が違うのか
2つの門のいちばん大きな違いは、通した通信を覚えているかどうかです。
セキュリティグループは「行き」を覚えている(ステートフル)
セキュリティグループはステートフルです。受信を許可した通信について、その応答の送信は、送信側のルールに関係なく通します。送信側で許可して出ていった通信の応答も同じで、受信側のルールを書かなくても戻ってきます。AWS はこれを「接続の追跡」(connection tracking)と呼んでいます。
このため、Web サーバーのセキュリティグループには「443 番を受け入れる」とだけ書けば、ブラウザへの応答のためのルールを書く必要はありません。
ネットワーク ACL は1つずつ見る(ステートレス)
ネットワーク ACL はステートレスです。行きの通信を覚えていないので、戻りの通信も「新しくやってきた通信」として、ルールに照らして1つずつ判断します。受信で 443 番を許可しても、応答の送信を許可するルールが無ければ、応答はサブネットから出られません。
ここで効いてくるのがエフェメラルポートです。通信を始めた側(クライアント)は、応答を受け取るための一時的なポート番号を、OS ごとに決まった範囲から選びます。サーバーの応答はこのポートに向けて返るので、ネットワーク ACL では「送信でエフェメラルポートの範囲を許可する」ルールが要ります。公式ドキュメントの例では 1024-65535 を許可しています。範囲はクライアントの OS によって違うので、実際の値は相手の OS に合わせて決めます。
サーバーから外の API を呼ぶ場合は向きが逆になります。サブネットから出ていく 443 番の送信を許可しても、戻ってくる応答(宛先はサーバー側のエフェメラルポート)を受信で許可していなければ、応答はサブネットに入れません。「外に出ていくのは見えるのに、応答が返ってこない」ときに最初に疑う場所です。
CHECK 1ここまでの確認
セキュリティグループで Web サーバーへの 443 番の受信だけを許可した。サーバーが返す応答の通信はどうなる?
答えと解説
答え: 2. 行きの通信を覚えているので、応答は書かなくても通る
セキュリティグループはステートフルで、許可した通信の戻りは自動で通します。ネットワーク ACL はステートレスなので、同じ場面で戻りの許可が別に要ります。「ステートフルとステートレスは何が違うのか」を読み直してください。
ルールはどの順で評価されるのか
2つ目の違いは、ルールに何を書けて、どの順で見るかです。
セキュリティグループ: 許可だけを書き、全部をまとめて見る
セキュリティグループに書けるのは許可のルールだけで、拒否のルールは書けません。ルールに順番は無く、付いているすべてのルール(複数のセキュリティグループを付けていれば、その全部)をまとめて見て、どれか1つに当たれば通します。どれにも当たらなければ通しません。
送信元には IP アドレスの範囲のほかに、別のセキュリティグループを指定できます。「Web サーバーのセキュリティグループが付いたインスタンスからの 3306 番だけを受け入れる」と書けば、Web サーバーが増えたり IP アドレスが変わったりしても、ルールを書き直さずに済みます。
ネットワーク ACL: 許可と拒否を番号順に見る
ネットワーク ACL のルールには番号が付いていて、番号の小さいものから順に見て、最初に当たったルールで決まります。後ろにそれと矛盾するルールがあっても使われません。どの番号にも当たらなかった通信は、最後にある * のルールで拒否されます。
LOWEST NUMBER FIRSTネットワーク ACL の評価
番号の小さい順に見て、最初に当たったルールで決まる
サブネットの境目(ステートレス)
- 90ある IP 範囲からの全通信 拒否拒否を許可より前に置く
- 100443 番の受信 許可全体から
- 110エフェメラルポートへの戻り 許可応答も1つずつ判定
- *どの番号にも当たらない 拒否最後のルール
このため、特定の IP 範囲を拒否したいときは、許可のルールより小さい番号に拒否のルールを置きます。許可より大きい番号に置くと、先に許可のルールに当たって通ってしまいます。あとから間にルールを差し込めるよう、番号は 10 や 100 おきに振るのが、公式ドキュメントでも勧められている付け方です。
CHECK 2ここまでの確認
ネットワーク ACL にルール番号 100 で「全体から 443 番を許可」、ルール番号 90 で「ある IP 範囲からの全通信を拒否」がある。その IP 範囲からの 443 番はどうなる?
答えと解説
答え: 1. 番号の小さい 90 番が先に当たるので拒否される
ネットワーク ACL は番号の小さいルールから順に見て、最初に当たったルールで決まります。後ろの番号に何が書いてあっても関係しません。「ルールはどの順で評価されるのか」を読み直してください。
2つの門はどう使い分けるのか
2つの門は、どちらか一方を選ぶものではなく、重ねて使うものです。通信は両方の門で許可されたときだけ届きます。
WHICH GATE FOR WHAT2つの門の使い分け
普段はセキュリティグループで絞り、まとめて拒否は NACL で
セキュリティグループ
インスタンスの前・ステートフル
- 役割ごとに許可を書く誰から・どのポートを
- 相手のセキュリティグループを指定IP が変わっても書き直さない
- 同じサブネットの中も絞れるNACL では止まらない通信
ネットワーク ACL
サブネットの境目・ステートレス
- IP 範囲をまとめて拒否拒否を書けるのはこちらだけ
- サブネット単位のもう一段の守り多くの構成は既定のまま
- 戻りの許可を忘れないエフェメラルポートの範囲
普段の絞り込みはセキュリティグループで
多くの構成では、ネットワーク ACL は既定のまま(すべて許可)にしておき、絞り込みはセキュリティグループで行います。ステートフルなので戻りを考えずに済み、インスタンスの役割ごとに「誰から・どのポートを」を書けるからです。同じサブネットの中のインスタンスどうしの通信は、サブネットの境目を越えないのでネットワーク ACL では止まりません。ここを絞れるのもセキュリティグループです。
まとめて拒否したいときはネットワーク ACL で
攻撃的なアクセスを続けてくる IP 範囲を、サブネットごとまとめて止めたいときは、拒否を書けるネットワーク ACL を使います。セキュリティグループには拒否が書けないからです。
もう1つ知っておきたいのが、セキュリティグループの接続の追跡の性質です。セキュリティグループのルールを消しても、すでに追跡されている接続は、消した瞬間には切れないことがあります。ネットワーク ACL はステートレスなので、拒否のルールを足せば、その後のパケットから止まります。
2つの門でよくある事故
- セキュリティグループで SSH の 22 番を
0.0.0.0/0(全世界)に開けたままにする - 自分で作ったネットワーク ACL をサブネットに付け、戻りのエフェメラルポートを許可し忘れて、応答が返らなくなる
- 拒否のルールを許可のルールより大きい番号に置き、止めたつもりの通信が通り続ける
通らないときの切り分けの順番
通信が通らないときは、行きと戻りを分けて、門を1つずつ確かめます。
- インスタンスのセキュリティグループに、相手とポートを許可するルールがあるか
- サブネットのネットワーク ACL が、行きの通信を許可しているか(番号の小さい拒否に当たっていないか)
- ネットワーク ACL が、戻りの通信(エフェメラルポート)を許可しているか
- 門の前に、ルートテーブルで経路があるか(門の話ではないが、同じ症状になる)
VPC フローログを有効にしておくと、通信ごとに ACCEPT か REJECT かが残るので、どちらの向きで止まったかが見えます。
CHECK 3ここまでの確認
同じサブネットの中にある2台のインスタンスどうしの通信を止めたい。どちらの門で絞る?
答えと解説
答え: 2. セキュリティグループ。ネットワーク ACL はサブネットを出入りする通信だけを見る
ネットワーク ACL が見るのは、サブネットの境目を越える通信です。同じサブネットの中の通信は、インスタンスの前にあるセキュリティグループで絞ります。「2つの門はどう使い分けるのか」を読み直してください。
まとめ
- セキュリティグループはインスタンスの前、ネットワーク ACL はサブネットの境目に立つ門で、通信は両方で許可されたときだけ届きます。
- セキュリティグループはステートフルで戻りを自動で通し、ネットワーク ACL はステートレスで戻りのエフェメラルポートにも許可が要ります。
- セキュリティグループは許可だけを全部まとめて見て、ネットワーク ACL は許可と拒否を番号の小さい順に見て最初に当たったもので決めます。
- 普段はセキュリティグループで絞り、IP 範囲をまとめて拒否したいときにネットワーク ACL を使います。
ポート番号やエフェメラルポートの考え方があいまいなら、TCP と UDP の記事で「窓口」の話を先に固めておくと、2つの門のルールが読みやすくなります。
READ ALSO — 未経験向け・段1 入口
TCP と UDP の違い|「届いたか確かめる」か「速く送る」かを、用途で使い分ける
参照ソース
- セキュリティグループを使用して AWS リソースへのトラフィックを制御する(Amazon VPC ユーザーガイド) — セキュリティグループがステートフルであること、許可のルールだけを書けること、ネットワーク ACL との比較の根拠(2026年9月時点の記載)
- セキュリティグループのルール(Amazon VPC ユーザーガイド) — 送信元に別のセキュリティグループを指定できることの根拠(2026年9月時点)
- ネットワーク ACL を使用してサブネットのトラフィックを制御する(Amazon VPC ユーザーガイド) — ネットワーク ACL がサブネット単位でステートレスであること、1つのサブネットに1つだけ関連付くことの根拠(2026年9月時点)
- ネットワーク ACL のルール(Amazon VPC ユーザーガイド) — 番号の小さい順の評価、
*のルール、番号を 10 や 100 おきに振ることの根拠(2026年9月時点) - エフェメラルポート(Amazon VPC ユーザーガイド) — 戻りの通信にエフェメラルポートの許可が要ること、範囲がクライアントによって違い 1024-65535 を開ける例の根拠(2026年9月時点)
- VPC の既定のネットワーク ACL(Amazon VPC ユーザーガイド) — 既定のネットワーク ACL がすべての通信を許可することの根拠(2026年9月時点)
- Amazon EC2 セキュリティグループの接続の追跡(Amazon EC2 ユーザーガイド) — 接続の追跡と、ルールを消しても追跡中の接続がすぐに切れない場合があることの根拠(2026年9月時点)
- VPC フローログ(Amazon VPC ユーザーガイド) — 通信ごとの ACCEPT と REJECT の記録の根拠(2026年9月時点)

