▪️目的

AWSでVPCのネットワークを構築していると、「Network ACL（ネットワークACL）」という機能が登場します。

Network ACLは、略して**NACL（ナックル）**と呼ばれることもあります。

NACLは、簡単にいうと、

Subnet（サブネット）単位で通信を許可・拒否するためのアクセス制御機能

です。

前回の記事では、EC2などのリソースに対して通信を制御する「Security Group」について解説しました。

Security GroupとNACLはどちらも通信制御に利用されますが、適用される範囲やルールの仕組みが異なります。

この記事では、NACLとは何なのか、Security Groupと何が違うのか、どのように通信を制御するのかをAWS初心者向けに解説します。

---

目次

• NACLとは
• NACLはSubnetに関連付ける
• InboundとOutbound
• NACLのルール
• ルール番号とは
• NACLは許可と拒否の両方を設定できる
• NACLはステートレス
• Security Groupとの違い
• NACLを使った通信のイメージ
• NACLを設定するときの考え方
• まとめ

---

▪️NACLとは？

NACLとは、

Network Access Control List

の略です。

AWSのVPC内にあるSubnet単位で通信を制御する機能です。

例えば、

VPC
│
├─ Public Subnet
│
└─ Private Subnet

という構成があった場合、それぞれのSubnetにNACLを関連付けることができます。

イメージとしては、

Internet
   ↓
NACL
   ↓
Subnet
   ↓
EC2

のように、Subnetへ出入りする通信を制御します。

---

▪️NACLはSubnetに関連付ける

NACLを理解するときに、まず覚えておきたいのが、

NACLはSubnet単位で適用される

ということです。

例えば、

VPC
│
├─ Public Subnet
│     └─ NACL-A
│
└─ Private Subnet
      └─ NACL-B

のように構成できます。

Public SubnetとPrivate Subnetで、異なるNACLを利用することもできます。

ただし、1つのSubnetに関連付けられるNACLは1つです。

また、1つのNACLを複数のSubnetに関連付けることもできます。

---

▪️InboundとOutbound

NACLでは、Security Groupと同じように、

• Inbound
• Outbound

という2つの方向についてルールを設定します。

♦︎Inbound

Inboundは、Subnetの外側からSubnet内部へ入ってくる通信です。

例えば、

Internet
   ↓
Public Subnet

という通信であれば、Subnetに入ってくるためInboundルールが関係します。

---

♦︎Outbound

Outboundは、Subnet内部から外側へ出ていく通信です。

例えば、

Private Subnet
   ↓
Internet

という通信であれば、Outboundルールが関係します。

つまり、

Inbound
外 → Subnet

Outbound
Subnet → 外

と考えると分かりやすいでしょう。

---

▪️NACLのルール

NACLでは、通信を許可するルールと拒否するルールを設定できます。

例えば、

Rule number : 100
Type        : HTTPS
Protocol    : TCP
Port        : 443
Source      : 0.0.0.0/0
Action      : ALLOW

とすると、IPv4のHTTPS通信を許可するルールになります。

一方、

Rule number : 110
Type        : SSH
Protocol    : TCP
Port        : 22
Source      : 203.0.113.10/32
Action      : DENY

とすると、特定のIPアドレスからのSSH通信を拒否できます。

このようにNACLでは、

ALLOW
通信を許可する

DENY
通信を拒否する

の両方を設定できます。

これはSecurity Groupとの大きな違いの一つです。

---

▪️ルール番号とは？

NACLを理解するときに、もう一つ重要なのがルール番号です。

例えば、

Rule number    Action
-----------------------
100            ALLOW
110            DENY
120            ALLOW

のようにルールに番号を付けます。

NACLでは、番号の小さいルールから順番に評価されます。

例えば、

100 → ALLOW
110 → DENY

というルールがある場合、通信がルール100に一致すれば、そこで許可されます。

そのため、後ろにあるルール110まで評価されません。

---

▪️ルールの順番が重要

例えば、以下のようなルールを設定したとします。

Rule 100
TCP 443
0.0.0.0/0
ALLOW

Rule 110
TCP 443
203.0.113.10/32
DENY

この場合、

203.0.113.10
      ↓
TCP 443

の通信はどうなるでしょうか。

先に評価されるのは、

Rule 100
ALLOW

です。

そのため、Rule 100に一致した時点で通信が許可され、Rule 110のDENYまで到達しません。

つまり、

NACLではルールの内容だけでなく、ルール番号による評価順序も重要

ということです。

---

▪️NACLはステートレス

NACLの非常に重要な特徴が、

ステートレス（Stateless）

であることです。

Security Groupはステートフルでした。

一方、NACLでは通信の状態を保持しません。

例えば、Subnet内のEC2からインターネットへHTTPS通信を開始したとします。

EC2
 ↓
HTTPS
 ↓
Internet

このとき、Outbound側で通信を許可しただけでは、戻ってくるレスポンスが自動的に許可されるとは限りません。

戻りの通信についても、Inbound側のルールを考える必要があります。

イメージとしては、

EC2
 ↓
Outbound NACL
 ↓
Internet
 ↓
Inbound NACL
 ↓
EC2

となります。

そのため、NACLを設定するときは行きの通信だけでなく戻りの通信も考える必要があります。

---

▪️Security Groupとの違い

ここまでの内容を整理すると、Security GroupとNACLには大きな違いがあります。

項目	Security Group	NACL
適用単位	リソース（ENIなど）	Subnet
Stateful	○	×
Allow	○	○
Deny	×	○
ルールの評価	許可ルールに一致するか	ルール番号順
主な役割	リソースへの通信制御	Subnetへの通信制御

簡単に覚えるなら、

Security Group
↓
リソースを守る

NACL
↓
Subnetを守る

というイメージです。

---

▪️Security GroupとNACLは両方使われる

実際のAWS環境では、Security GroupかNACLのどちらか一方だけを利用するとは限りません。

両方を組み合わせて利用することができます。

例えば、

Internet
   ↓
NACL
   ↓
Public Subnet
   ↓
Security Group
   ↓
EC2

という構成です。

この場合、

NACL

Subnet単位で通信を制御

Security Group

EC2などのリソース単位で通信を制御

という役割分担になります。

---

▪️NACLを使った通信のイメージ

例えば、Public SubnetにWebサーバーを配置するとします。

Internet
   ↓
Public Subnet
   ↓
EC2

このSubnetにNACLを設定します。

Inboundでは、

Rule 100
TCP 443
0.0.0.0/0
ALLOW

としてHTTPS通信を許可します。

さらに、

Rule 110
TCP 22
0.0.0.0/0
DENY

とすれば、インターネットからのSSH通信を拒否することができます。

イメージとしては、

Internet
   │
   ├── HTTPS 443 ──→ ALLOW ──→ Subnet
   │
   └── SSH 22 ─────→ DENY

となります。

ただし、実際にEC2へ通信が到達するには、NACLだけではなくSecurity Groupなどの条件も満たす必要があります。

---

▪️NACLのデフォルト

AWSでは、NACLを新しく作成するときに、デフォルトのNACLとは別にカスタムNACLを作成することができます。

デフォルトNACLは、初期状態ではInbound・Outboundともに通信を許可するルールが設定されています。

一方、カスタムNACLを利用する場合は、自分で必要なルールを設計していくことになります。

そのため、カスタムNACLを利用するときは、

Inbound
Outbound

の両方について、必要な通信を確認することが重要です。

---

▪️NACLを設定するときの考え方

NACLを設定するときは、

Subnetを通過する通信をどこまで許可するのか

を考えます。

例えば、

Web Subnet

であれば、

HTTPS
TCP 443

を許可する必要があるかもしれません。

一方、

Database Subnet

であれば、

Database通信

だけを許可する構成を考えることができます。

ただし、NACLはステートレスなので、戻りの通信も忘れないことが重要です。

例えば、

Client
  ↓
TCP 443
  ↓
Server

だけではなく、

Server
  ↓
レスポンス
  ↓
Client

についても通信が成立するようにルールを考える必要があります。

---

▪️通信トラブルではNACLも確認する

AWSで通信できない場合、NACLが原因になっていることもあります。

例えば、

ブラウザ
   ↓
Internet
   ↓
Internet Gateway
   ↓
NACL
   ↓
Subnet
   ↓
Security Group
   ↓
EC2

という通信であれば、

• Route Table
• Internet Gateway
• NACL
• Security Group
• EC2
• アプリケーション

など、複数のポイントを確認する必要があります。

特に、

「Security Groupでは許可しているのに通信できない」

という場合には、NACLなど別のネットワーク制御も確認してみましょう。

---

▪️まとめ

今回はNACLについて解説しました。

NACLとは、

Subnet単位で通信を許可・拒否するためのアクセス制御機能

です。

Security Groupと同じようにInbound・Outboundの通信を制御できますが、NACLには以下のような特徴があります。

• Subnet単位で適用される
• InboundとOutboundの両方を設定する
• AllowとDenyの両方を設定できる
• ルール番号の小さい順に評価される
• ステートレスである
• 戻りの通信についてもルールを考える必要がある

Security Groupとの違いをまとめると、

Security Group
↓
リソース単位
Stateful
Allowのみ

NACL
↓
Subnet単位
Stateless
Allow / Deny

となります。

AWSのネットワークを理解するときは、

VPC
 ↓
Subnet
 ↓
Route Table
 ↓
IGW / NAT Gateway
 ↓
NACL
 ↓
Security Group
 ↓
EC2などのリソース

と、それぞれの役割を分けて考えることが重要です。

ここまで理解できると、AWSのネットワーク構成図を見たときに、

「どこを通って、どこで通信が制御されているのか」

を追えるようになってきます。

次回は、AWSでデータを保存するときに利用される**EBS（Elastic Block Store）**について解説します。
＊「EBS」の記事はこちら
→「https://lovelabengineer.com/2026/10/08/awsのebsとは？ec2で使うブロックストレージの仕組みを/」