【AWS】VPCの「セキュリティグループ」と「ネットワークACL」の特徴や違いを解説！

AWSでインフラ構築をしているとよく登場するのが「セキュリティグループ」と「ネットワークACL（NACL）」という2種類のアクセス制御機能です。どちらもセキュリティを高めるために欠かせない存在ですが、それぞれの役割や動作には違いがあります。

この記事では、初心者の方でも理解しやすいように、図や具体例を交えながら両者の違いを徹底的に解説します。

「セキュリティグループ」と「ネットワークACL」の違い

「セキュリティグループ」と「ネットワークACL」の違い

セキュリティグループは「インスタンス単位で設定するファイアウォール機能」、ネットワークACL（NACL）は「サブネット単位で設定するファイアウォール機能」です。どちらもVPC内の通信を細かく制御するために使われます。

後ほど「セキュリティグループ」と「ネットワークACL（NACL）」について詳しく説明しますが、各々の特徴を表形式でまとめると以下のようになります。

比較項目セキュリティグループネットワークACL
適用単位EC2インスタンスなどリソース単位サブネット単位
ステートフル /
ステートレス		ステートフル
→ 戻り通信は自動で許可される		ステートレス
→ 戻り通信も明示的に許可が必要
許可／拒否許可のみ設定可能許可・拒否の両方を設定可能
ルールの評価順優先順位なし
（すべてのルールが評価対象）		ルール番号順に評価
（小さい番号が優先）
デフォルトの動作インバウンド：すべて拒否
アウトバウンド：すべて許可		インバウンド：すべて許可
アウトバウンド：すべて許可

インバウンドとアウトバウンドとは

インバウンドは内向きの通信（例: ユーザーのPCからEC2インスタンスへアクセスする）、アウトバウンドは外向きの通信（例: EC2インスタンスからインターネットへアクセスする場合）です。

注意点

VPC内でセキュリティグループとネットワークACLを両方とも適用している場合、どちらか一方で拒否されると通信はブロックされるので注意が必要です。たとえば、セキュリティグループで通信を許可していても、ネットワークACLで拒否していればその通信は通りません。

セキュリティグループとは？

セキュリティグループは、EC2インスタンスなどの個別リソースに適用される仮想ファイアウォールです。主にインスタンスへのインバウンド（受信）・アウトバウンド（送信）通信の制御を行います。

セキュリティグループの特徴

  • 適用単位：インスタンス単位
  • ステートフル：戻り通信は自動で許可される
    • インスタンスから出ていく通信をアウトバウンドルールで許可していれば、その返信はインバウンドルールで許可していなくてもインスタンスに入ってくることができる。
    • 逆も同じで、インスタンスに入ってくる通信がインバウンドルールで許可されていれば、その返信はアウトバウンドルールで許可していなくてもインスタンスから出ていくことができる。
  • 許可のみを定義するホワイトリスト方式：拒否ルールは存在しない。
  • 複数のセキュリティグループを1つのインスタンスに適用可能
  • 1つのセキュリティグループを複数のインスタンスに適用可能
  • 全ルールが同時に評価される
  • デフォルトの通信設定
    • インバウンド　：同じセキュリティグループが付与されたリソースからの通信のみ許可
    • アウトバウンド：すべて許可

インバウンドルールの例（セキュリティグループ）

インバウンドルールの例を以下に示します。

NameセキュリティグループルールIDIPバージョンタイププロトコルポート範囲ソース説明
Webアクセス（HTTPS）sgr-abc123def456IPv4HTTPSTCP4430.0.0.0/0世界中からのHTTPSアクセスを許可。戻りの通信（レスポンス）は自動的に許可されます。
SSH管理アクセスsgr-ghi789jkl012IPv4SSHTCP22203.0.113.10/32管理者が使用する特定のIPアドレス（例：203.0.113.10/32）からのSSH接続を許可。
DB接続sgr-mno345pqr678IPv4MySQLTCP3306sg-12345678abcdefg指定のセキュリティグループからの接続のみ許可。
  • Webアクセス（HTTPS）
    • 世界中のすべてのIPアドレス（0.0.0.0/0）からのHTTPS通信（ポート443）を許可するものです。セキュリティグループはステートフルであるため、インバウンド通信が許可されていれば、それに対応するアウトバウンド通信（レスポンス）は自動的に許可されます。つまり、この設定だけでHTTPSによる双方向の通信が可能になります。
  • SSH管理アクセス
    • 管理者が使用する特定のIPアドレス（例：203.0.113.10/32）からのSSH接続（ポート22）を許可しています。/32は単一のIPアドレスを意味し、それ以外のアクセス元からのSSH通信はすべて拒否されます。
  • DB接続（Appサーバー用）
    • MySQL（ポート3306）で動作するデータベースへの接続を、特定のセキュリティグループ（例：sg-12345678abcdefg）に所属するインスタンスに限定して許可しています。

セキュリティグループルールID（例：sgr-abc123def456）は、AWS上で個々のセキュリティグループルールを一意に識別するためのIDです。

補足

インバウンドルールでは「誰からの通信を許可するか」、アウトバウンドルールでは「誰への通信を許可するか」を設定します。インバウンドルールの「誰からの」はソース、アウトバウンドルールの「誰への」は送信先として指定します。このソースや送信先の指定には、以下の2通りの方法があります。

  • IPアドレスで指定する方法
  • セキュリティグループID（例：sg-...）で指定する方法

たとえば、ソースにセキュリティグループIDを指定すると、そのセキュリティグループに所属するインスタンスだけが通信できるようになります。

アウトバウンドルールの例（セキュリティグループ）

アウトバウンドルールの例を以下に示します。

NameセキュリティグループルールIDIPバージョンタイププロトコルポート範囲送信先説明
HTTPS通信のみ許可sgr-aaa111bbb222IPv4HTTPSTCP4430.0.0.0/0外部のHTTPS通信のみ許可。
管理サーバー通信sgr-ccc333ddd444IPv4SSHTCP22203.0.113.10/32特定の管理サーバーへのSSH通信のみ許可
  • HTTPS通信のみ許可
    • 外部の任意のIPアドレス（0.0.0.0/0）に対して、HTTPS通信（TCPのポート443）だけを許可する設定です。このルールを設けることで、不必要なプロトコルやポートでの通信を制限し、セキュリティを高めています。
  • 管理サーバー通信
    • インスタンスから特定の管理サーバー（IPアドレス：203.0.113.10/32）に対して、SSH通信（TCPのポート22）のみを許可しています。この設定により、インスタンスが外部にある管理サーバーと安全に接続することができます。

デフォルトのセキュリティグループ

セキュリティグループには「デフォルトのセキュリティグループ」があります。これは新しくVPCを作成すると、自動的に一緒に作られるものです。つまり、VPCを新規作成するたびに自動で用意されるため、毎回自分でセキュリティグループを作成する必要はありません。また、EC2などを作成する際にセキュリティグループを指定しなければ、このデフォルトセキュリティグループが自動的に適用されます。

便利な存在ではありますが、実際の運用ではあまり使用されず、必要に応じて独自のセキュリティグループを作成するのが一般的です。

また、デフォルトのセキュリティグループは編集できますが、基本的には変更せずそのままにしておくのが無難です。理由は、セキュリティグループの指定を忘れた場合に、このデフォルト設定が使われるためです。たとえば、デフォルトグループを「すべて拒否」に変更していた場合、セキュリティグループを指定せずに作成したEC2が通信できず、原因に気づきにくくなることがあります。デフォルトのセキュリティグループは削除できません。AWSを「ちょっと試してみたい」ときに使う“おまけ”のようなものと考えておけば良いでしょう。

このセキュリティグループの名前は「default」で、マネジメントコンソールでは「Name」列ではなく「セキュリティグループ名」列に表示されます。

デフォルトのセキュリティグループ

デフォルトのセキュリティグループには、初期状態で以下のようなルールが設定されています。

  • アウトバウンド（外への通信）：すべて許可
  • インバウンド（外からの通信）：同じセキュリティグループが付与されたリソースからの通信のみ許可

つまり、同じセキュリティグループを使っているEC2同士であれば通信可能ですが、それ以外（外部や別のセキュリティグループからのアクセス）は許可されません。

ネットワークACL（NACL）とは？

ネットワークACLは、サブネット単位で全インスタンスに適用するファイアウォール機能です。VPCの中で「このサブネットにはこのルールを適用する」といった使い方をします。

セキュリティグループは「許可する通信」だけを設定できますが、ネットワークACLは「許可」と「拒否」の両方を設定できます。たとえば、「IPアドレスxx.xx.xx.xxからのSSH通信は拒否する」といった細かい制御が可能です。

ネットワークACLの特徴

  • 適用単位： サブネット単位
  • ステートレス：戻り通信も明示的に許可が必要
  • 許可・拒否の両方を設定可能
  • ルールには番号があり、小さい順に評価される
  • デフォルトの通信設定
    • インバウンド：すべて許可
    • アウトバウンド：すべて許可
  • カスタムNACLを作成した場合、インバウンドもアウトバウンドも初期状態ではすべて拒否の設定になる。明示的に許可されなければ通信不可です。

インバウンドルールの例（ネットワークACL）

インバウンドルールの例を以下に示します。

ルール番号タイププロトコルポート範囲送信元許可/拒否説明
100HTTPTCP800.0.0.0/0ALLOW全世界からのHTTPアクセスを許可
110SSHTCP22203.0.113.10/32ALLOW管理者IPからのSSH接続を許可
＊すべてのトラフィックすべてすべて0.0.0.0/0DENY上記以外のすべての通信を拒否

ルール番号100では、全世界のIPアドレス（0.0.0.0/0）からのHTTP通信（TCPのポート80）を許可しています。ネットワークACLはステートレスなため、戻りの通信についてはアウトバウンドルール側にも別途許可設定が必要です。

ルール番号110では、特定の管理者のIPアドレス（203.0.113.10/32）からのSSH通信（TCPのポート22）を許可するものです。SSHはリモートサーバーに安全にログインするためのプロトコルで、管理者による操作に必要不可欠です。

番号がアスタリスク（*）のルールは、その通信がどの番号のルールとも一致しない場合に適用されます。上記のHTTPやSSHなど、明示的に許可した通信を除き、それ以外のすべてのトラフィックはブロックされます。このように許可ルールの後に拒否ルールを設けることで、想定外の通信が入ってこないようにし、安全性を高めています。

アウトバウンドルールの例（ネットワークACL）

アウトバウンドルールの例を以下に示します。

ルール番号タイププロトコルポート範囲宛先（送信先）許可/拒否説明
100HTTPTCP800.0.0.0/0ALLOWWebサーバーからのHTTP通信を許可
110DNS (UDP)UDP530.0.0.0/0ALLOWDNSの名前解決用の通信を許可
＊すべてのトラフィックすべてすべて0.0.0.0/0DENYその他すべてのアウトバウンド通信を拒否

ルール番号100では、インスタンスから外部（0.0.0.0/0）へのHTTP通信（TCPのポート80）を許可するものです。ネットワークACLはステートレスであるため、対応するインバウンドルール側でも戻りのレスポンスを許可しておく必要があります。

ルール番号110では、外部（0.0.0.0/0）のDNSサーバーに対する名前解決のための通信を許可するものです。

デフォルトのネットワークACL

ネットワークACLには「デフォルトのネットワークACL」があります。これは新しくVPCを作成すると、自動的に一緒に作られるものです。つまり、VPCを新規作成するたびに自動で用意されるため、毎回自分でネットワークACLを作成する必要はありません。また、新しく作成したサブネットには、このデフォルトのネットワークACLが自動的に関連付けられます。

このデフォルトのネットワークACLには、初期状態で「すべての通信を許可するルール」が設定されています。具体的には、インバウンド（受信）とアウトバウンド（送信）の両方で、すべてのトラフィックを許可するルールのみが含まれています。つまり、VPC内にあるサブネットに対して、特に制限をかけずに自由に通信ができる状態です。

一見便利な設定に見えますが、セキュリティ要件が厳しい本番環境などでは、このまま使うのは望ましくありません。たとえば、外部からの不正アクセスを防ぎたい、特定のポートやIPからの通信だけ許可したいといった場合には、この「すべて許可」ルールでは対応できないからです。

そういった場合でも、デフォルトのネットワークACLを直接編集するのは避けたほうが無難です。既存のサブネットや将来の構成に影響を与える可能性があるためです。もし制御が必要な場合は、新しく自分でネットワークACLを作成し、それをサブネットに関連付けて使うことをおすすめします。

このデフォルトのネットワークACLはマネジメントコンソールでは「デフォルト」列に「はい」と表示されているものです。

デフォルトのネットワークACL

なお、デフォルトのネットワークACLは編集はできますが、削除はできません。セキュリティグループと同様に、「まずはAWSを使ってみたい」といった試用目的で最低限の通信確認を行うための“おまけ”のような存在と考えるとよいでしょう。

「セキュリティグループ」と「ネットワークACL」の使い分け

セキュリティグループとネットワークACLは、どちらもAWSで通信を制御するための機能ですが、基本的にはセキュリティグループを使えば十分です。セキュリティグループはインスタンス単位でアクセスを制御できるため、多くのケースでこれだけで対応できます。実務でも、セキュリティグループをいじることは多いですが、ネットワークACLを触ることはほとんどありません。

一方、ネットワークACLは、より細かい制御が必要なときに補助的に使うのがおすすめです。たとえば、「特定のIPアドレスからのアクセスをブロックしたい」といった場合や、「サブネット全体に対して一律の通信ルールを設定したい」といった場面では、ネットワークACLが効果を発揮します。

スポンサーリンク