Amazon VPCでEC2などのリソースを安全に利用するためには、ネットワーク通信を適切に制御する必要があります。
AWSでVPC内の通信を制御する代表的な仕組みが、セキュリティグループ（Security Group）とネットワークACL（Network ACL：NACL）です。
どちらも通信を制御するため、
- セキュリティグループとNACLは何が違う？
- どちらを使えばよい？
- ステートフルとステートレスとは？
- なぜNACLでは戻り通信の設定も必要？
- AllowとDenyはどう違う？
と混乱しやすいポイントでもあります。
最初に結論を整理すると、次のように考えると分かりやすいでしょう。
セキュリティグループ
EC2などのリソース単位で通信を制御する「ステートフル」な仮想ファイアウォール
ネットワークACL（NACL）
サブネット単位で通信を制御する「ステートレス」なアクセス制御
AWSでは基本的にセキュリティグループを中心にアクセスを制御し、必要に応じてNACLを追加の防御レイヤーとして利用します。
本記事では、セキュリティグループとNACLの違いから、ステートフル・ステートレス、Allow/Deny、ルール番号、戻り通信、エフェメラルポートまで、SAA対策として必要なポイントを初心者向けに解説します。
📚 SAA試験対策ボックス
| 試験頻出度 | ★★★★★ |
|---|---|
| 重要度 | ★★★★★ |
| 関連分野 | VPC / EC2 / Security Group / Network ACL / ネットワークセキュリティ |
| 重要キーワード | Stateful / Stateless / Allow / Deny / Inbound / Outbound / Rule Number / Ephemeral Port |
この記事で覚えること
- セキュリティグループはリソースレベルで動作する
- NACLはサブネットレベルで動作する
- セキュリティグループはステートフル
- NACLはステートレス
- セキュリティグループはAllowルールのみ
- NACLはAllowとDenyの両方を設定できる
- NACLはルール番号の小さい順に評価する
- NACLでは戻り通信も明示的に許可する必要がある
セキュリティグループとは？
セキュリティグループ（Security Group）は、EC2などのAWSリソースへ到達する通信と、リソースから出ていく通信を制御する仕組みです。
EC2を例にすると、セキュリティグループをEC2に関連付け、どの通信を許可するのかをルールとして設定します。
Internet
│
▼
Security Group
│
▼
EC2
例えばWebサーバーなら、
| タイプ | プロトコル | ポート | 送信元 |
|---|---|---|---|
| HTTP | TCP | 80 | 0.0.0.0/0 |
| HTTPS | TCP | 443 | 0.0.0.0/0 |
といったインバウンドルールを設定できます。
これによってHTTP/HTTPS通信を許可し、それ以外の許可されていないインバウンド通信を通さない構成を作ることができます。
インバウンドルールとアウトバウンドルール
セキュリティグループには、次の2種類のルールがあります。
| ルール | 意味 |
|---|---|
| Inbound Rule | リソースへ入ってくる通信を制御 |
| Outbound Rule | リソースから出ていく通信を制御 |
例えば、インターネット上のユーザーからEC2へHTTPS通信が送られる場合、
User
↓
HTTPS : 443
↓
Security Group
↓
EC2
という流れになります。
この場合、EC2側のセキュリティグループでTCP/443のインバウンド通信が許可されている必要があります。
セキュリティグループはAllowルールのみ
セキュリティグループを理解するうえで非常に重要なのが、許可（Allow）ルールのみ設定できるという特徴です。
つまり、
203.0.113.10 → DENY
のような明示的な拒否ルールをセキュリティグループへ追加することはできません。
必要な通信だけをAllowし、それ以外の通信は許可ルールに一致しないため通過できないという考え方になります。
📘 SAA試験ポイント
特定IPアドレスだけを明示的に拒否したいという要件が出てきた場合、Security GroupではDenyルールを設定できないことを思い出しましょう。
サブネットレベルのIP制御であれば、Allow/Denyの両方を利用できるNACLが候補になります。
セキュリティグループはステートフル
セキュリティグループ最大の特徴の1つが、ステートフル（Stateful）であることです。
ステートフルとは、通信の状態を記憶しているという意味です。
例えば、ユーザーからWebサーバーへのHTTPS通信を考えてみましょう。
User
│
│ HTTPS : 443
▼
Security Group
│
▼
EC2
EC2
│
│ Response
▼
User
セキュリティグループでインバウンドのTCP/443を許可して通信が成立すると、その通信に対する戻り通信は自動的に許可されます。
戻り通信専用のアウトバウンドルールを追加する必要はありません。
ステートフルの覚え方
「行きの通信を覚えているので、その通信に対する戻りは自動的に通す」
と考えると分かりやすいでしょう。
ネットワークACL（NACL）とは？
ネットワークACL（Network Access Control List：NACL）は、サブネットへ出入りする通信を制御する仕組みです。
セキュリティグループがEC2などのリソース単位で適用されるのに対し、NACLはサブネット単位で適用されます。
VPC
┌─────────────────┐
│ │
│ Subnet │
│ │
│ ┌─────────┐ │
│ │ EC2 │ │
│ └─────────┘ │
│ │
└─────────────────┘
▲
│
NACL
そのため、そのNACLが関連付けられたサブネットに存在するリソースの通信へ影響します。
セキュリティグループとNACLは二重の防御になる
セキュリティグループとNACLは、どちらか一方しか利用できないわけではありません。
両方を利用することで、異なるレベルで通信を制御できます。
通信のイメージは、
Internet
↓
Internet Gateway
↓
Network ACL
【サブネット単位】
↓
Security Group
【リソース単位】
↓
EC2
となります。
NACL
サブネット境界で大きく通信を制御する
Security Group
個々のリソースに必要な通信を細かく許可する
NACLはAllowとDenyの両方を設定できる
NACLでは、セキュリティグループとは異なり、
- ALLOW
- DENY
の両方を設定できます。
例えば、
203.0.113.10/32 → DENY
というルールを作成して、特定のIPアドレスからの通信を明示的に拒否できます。
そのため、サブネット全体に対して「このIPアドレスからの通信だけ拒否したい」といった要件ではNACLが利用できます。
NACLにはルール番号がある
NACLでは、各ルールにルール番号を設定します。
そして、ルール番号の小さい順に評価され、最初に一致したルールが適用されます。
例えば次のルールを考えてみましょう。
| ルール番号 | 送信元 | アクション |
|---|---|---|
| 100 | 203.0.113.10/32 | DENY |
| 200 | 0.0.0.0/0 | ALLOW |
| * | 0.0.0.0/0 | DENY |
203.0.113.10からアクセスが来た場合、ルール100に一致します。
そのため、後にルール200のALLOWが存在していても、通信はDENYされます。
📘 SAA試験ポイント
NACLではルール番号の大小が重要です。
問題に複数のAllow/Denyルールが登場した場合は、番号の小さいルールから確認しましょう。
NACLはステートレス
NACLでもう1つ非常に重要なのが、ステートレス（Stateless）であることです。
NACLは通信状態を記憶しません。
そのため、
Client
↓
Request
↓
NACL
↓
EC2
という通信を許可したとしても、
EC2
↓
Response
↓
NACL
↓
Client
という戻り通信が自動的に許可されるわけではありません。
インバウンドとアウトバウンドをそれぞれ独立した通信として評価します。
ステートレスの覚え方
「行きの通信を覚えていないため、帰りも別途チェックする」
ステートフルとステートレスの違い
ここがセキュリティグループとNACLを理解するうえで最重要ポイントです。
| 項目 | Security Group | Network ACL |
|---|---|---|
| 状態 | Stateful | Stateless |
| 通信状態 | 記憶する | 記憶しない |
| 戻り通信 | 自動的に許可 | ルールによる明示的な許可が必要 |
📘 ここは必ず暗記
Security Group ＝ Stateful
Network ACL ＝ Stateless
SAAでは非常に重要な組み合わせです。
NACLとエフェメラルポート
NACLがステートレスであることを理解すると、次に重要になるのがエフェメラルポート（Ephemeral Port）です。
クライアントとサーバーがTCP通信するとき、サーバー側のHTTPSポート443だけを考えればよいわけではありません。
例えば、
Client : 50000
↓
Server : 443
という通信が行われた場合、戻り通信では、
Server : 443
↓
Client : 50000
となります。
このクライアント側で一時的に利用されるポートがエフェメラルポートです。
セキュリティグループはステートフルなので、許可された通信への戻り通信について細かく意識する必要はありません。
しかしNACLはステートレスなので、必要な戻り通信が通過できるようにルールを設計する必要があります。
📘 SAA試験ポイント
「NACLを設定したところWebアクセスできなくなった」という問題では、戻り通信に必要なポートがNACLで許可されているかを確認しましょう。
セキュリティグループでは別のSGを参照できる
セキュリティグループでは、CIDRだけでなく別のセキュリティグループをルールの参照元として指定できます。
これはAWSで多層Webアプリケーションを設計するときに非常に便利です。
例えば、
Internet
↓
ALB
[SG-ALB]
↓
EC2
[SG-APP]
↓
RDS
[SG-DB]
という構成を考えてみましょう。
EC2側のセキュリティグループでは、
Source：SG-ALB
Port：443
などと設定できます。
RDS側では、
Source：SG-APP
Port：3306
のように設定できます。
これにより、特定IPアドレスを固定的に指定するのではなく、役割ごとのセキュリティグループを基準に通信を許可できます。
💼 実務ではこう考える
ALB → EC2 → RDSのような構成では、必要以上に0.0.0.0/0から通信を許可するのではなく、セキュリティグループ同士を参照して必要な通信だけを許可する設計が重要です。
デフォルトSecurity GroupとデフォルトNACL
VPCを作成すると、デフォルトのセキュリティグループとデフォルトのネットワークACLが用意されます。
ただし、それぞれの初期動作は同じではありません。
デフォルトNACL
デフォルトNACLは、初期状態では基本的にすべてのIPv4インバウンド・アウトバウンド通信を許可するルールを持っています。
IPv6 CIDRが関連付けられている場合は、IPv6用のルールも関係します。
デフォルトSecurity Group
デフォルトSecurity Groupには、同じSecurity Groupが関連付けられたリソース間のインバウンド通信を許可するルールなどが設定されています。
両者を「デフォルトだから同じ」と考えないようにしましょう。
セキュリティグループとNACLの違いを徹底比較
| 比較項目 | Security Group | Network ACL |
|---|---|---|
| 適用レベル | リソースレベル | サブネットレベル |
| 状態 | Stateful | Stateless |
| Allow | 〇 | 〇 |
| Deny | × | 〇 |
| ルール評価 | 許可ルール全体を評価 | 番号の小さい順に評価し、最初の一致を適用 |
| 戻り通信 | 自動的に許可 | 明示的なルールが必要 |
| 主な用途 | リソースへのアクセス制御 | サブネット単位の追加防御 |
| 明示的なIP拒否 | 不可 | 可能 |
Security GroupとNACLはどちらを使う？
「Security GroupとNACLのどちらを使えばよいのか」という疑問も多いでしょう。
基本的には、Security Groupをリソースへのネットワークアクセス制御の主要な仕組みとして利用します。
そのうえで必要に応じて、NACLによるサブネットレベルの追加制御を利用します。
基本
Security Group
追加防御
Network ACL
例えば、特定の悪意あるIPアドレスからサブネット全体へのアクセスを明示的に拒否したい場合などにNACLを利用できます。
Security Group・NACL・WAFの違い
前回の記事で解説したAWS WAFも含めると、AWSのアクセス制御をより整理しやすくなります。
| サービス | 主な制御対象 | 代表的な用途 |
|---|---|---|
| AWS WAF | HTTP/HTTPSリクエスト | SQL Injection / XSS / Webアクセス制御 |
| Security Group | リソースへのネットワーク通信 | EC2 / ALB / RDSなどへの通信制御 |
| Network ACL | サブネットへ出入りする通信 | サブネット単位のAllow / Deny |
例えばWebアプリケーションでは、
Internet
↓
AWS WAF
【Webリクエストを検査】
↓
ALB
↓
NACL
【Subnet Level】
↓
Security Group
【Resource Level】
↓
EC2
というように、異なるレイヤーのセキュリティ機能を組み合わせて多層防御を実現します。
🔥 SAAでよくある判断パターン
パターン① EC2へのHTTPS通信だけ許可したい
要件
↓
EC2へのTCP/443を許可
↓
Security Group
答えの候補：Security Group
パターン② 特定IPアドレスを明示的に拒否したい
要件
↓
DENYルールが必要
↓
Network ACL
答えの候補：Network ACL
パターン③ サブネット全体の通信を制御したい
要件
↓
Subnet Level
↓
Network ACL
答えの候補：Network ACL
パターン④ EC2への戻り通信を自動許可したい
要件
↓
Stateful
↓
Security Group
答えの候補：Security Group
パターン⑤ ALBからの通信だけEC2へ許可したい
ALB
[SG-ALB]
↓
EC2
[SG-APP]
EC2側のSecurity GroupでSG-ALBを参照します。
答えの候補：Security Group参照
パターン⑥ NACL設定後にWebアクセスできなくなった
NACLはステートレスなので、
- インバウンド通信
- アウトバウンドの戻り通信
の両方を確認します。
特にエフェメラルポートを含む戻り通信を確認することが重要です。
⚠ 初心者が間違えやすいポイント
① Security GroupとNACLは同じもの
誤りです。
Security Groupはリソースレベル、NACLはサブネットレベルで動作します。
② Security Groupで特定IPをDenyできる
誤りです。
Security GroupではAllowルールのみ設定できます。
③ NACLも戻り通信を自動許可する
誤りです。
NACLはステートレスなので、戻り通信もルールによって明示的に許可する必要があります。
④ NACLではすべてのルールを評価する
誤りです。
ルール番号の小さい順に評価し、最初に一致したルールが適用されます。
⑤ Security Groupはサブネットに設定する
誤りです。
Security GroupはEC2などの対応リソースへ関連付けます。
サブネットに関連付けるのはNetwork ACLです。
⑥ NACLがあればSecurity Groupは不要
誤りです。
両者は適用レベルや動作が異なります。
基本的にはSecurity Groupを主要なネットワークアクセス制御として利用し、必要に応じてNACLを追加防御として利用します。
通信トラブルではSGとNACLをどう確認する？
AWSで「EC2へ接続できない」という問題が発生した場合は、Security Groupだけを確認すればよいわけではありません。
例えばインターネットからEC2へHTTPS接続する場合、
Internet
↓
Internet Gateway
↓
Route Table
↓
Network ACL
↓
Security Group
↓
EC2
という複数の要素が関係します。
そのため、
- ルートテーブルに適切な経路があるか
- NACLで通信が許可されているか
- Security Groupで通信が許可されているか
- EC2側でサービスが待ち受けているか
といった順番で通信経路を確認すると原因を切り分けやすくなります。
💼 実務ではVPC Flow Logsも活用
VPC Flow Logsを利用すると、VPC・サブネット・ネットワークインターフェイスを流れるIPトラフィックに関する情報を記録できます。
Security GroupやNACLが原因となる通信トラブルを調査するときにも役立ちます。
AWS公式試験ガイドとの関連
SAA-C03では「セキュアなアーキテクチャの設計」が試験領域の1つとなっており、ネットワークとセキュリティは重要な基礎知識です。
Security GroupとNACLについては、単純に名称を暗記するのではなく、
- どのレベルで通信を制御するのか
- StatefulかStatelessか
- Allowだけか、Denyも利用できるか
- 戻り通信をどう扱うのか
- どの順序でルールを評価するのか
を要件から判断できるようにしておきましょう。
🔥 SAA試験頻出ポイント
- Security Groupはリソースレベル
- Network ACLはサブネットレベル
- Security GroupはStateful
- Network ACLはStateless
- Security GroupはAllowルールのみ
- Network ACLはAllow / Denyの両方を利用できる
- Security Groupでは許可された通信への戻り通信は自動的に許可される
- NACLでは戻り通信も明示的に許可する必要がある
- NACLはルール番号の小さい順に評価する
- 最初に一致したNACLルールが適用される
- NACLではエフェメラルポートを含む戻り通信に注意する
- Security Groupでは別のSecurity Groupを参照できる
- Security Groupを主要なアクセス制御として利用し、必要に応じてNACLを追加防御として利用する
Security GroupとNACLの覚え方
Security Group
「リソースを守るステートフルな警備員」
- Resource Level
- Stateful
- Allow Only
- 戻り通信は自動許可
Network ACL
「サブネットの入口を守るステートレスな関所」
- Subnet Level
- Stateless
- Allow / Deny
- 戻り通信もルールが必要
- ルール番号順に評価
まとめ
Security GroupとNetwork ACLは、どちらもAmazon VPCのネットワークセキュリティで重要な仕組みですが、適用範囲と動作が大きく異なります。
| Security Group | Network ACL | |
|---|---|---|
| 適用範囲 | リソース | サブネット |
| 状態 | Stateful | Stateless |
| Allow | 〇 | 〇 |
| Deny | × | 〇 |
| 戻り通信 | 自動許可 | 明示的な許可が必要 |
特にSAAでは、
Security Group
＝ Resource Level
＝ Stateful
＝ Allow Only
Network ACL
＝ Subnet Level
＝ Stateless
＝ Allow / Deny
という違いを確実に覚えておきましょう。
さらに実際のAWS環境では、
Internet
↓
Route Table
↓
Network ACL
↓
Security Group
↓
EC2
のように複数のネットワーク要素が通信に関係します。
「通信がどこを通り、どのレイヤーで許可・拒否されるのか」を意識して考えられるようになると、SAAだけでなくAWSのネットワークトラブルシューティングにも役立ちます。
