セキュリティグループとネットワークACLの違いを徹底解説【AWS実務向け】

AWSのネットワークセキュリティを学ぶとき、必ずぶつかるのが「セキュリティグループ（SG）」と「ネットワークACL（NACL）」の違いです。

どちらもトラフィックを制御する仕組みですが、動作の仕方がまったく異なります。この違いを理解していないと、設定したつもりなのに通信できない・意図しないトラフィックが通ってしまうといったトラブルに直結します。

この記事では、SGとNACLの違いを基礎から整理したうえで、実務でどう使い分けるかまで解説します。AWS認定試験（SAA・SOA）の対策としても役立つ内容です。

セキュリティグループとネットワークACLの基本的な違い

まず結論から言います。

	セキュリティグループ（SG）	ネットワークACL（NACL）
適用対象	EC2インスタンス（ENI）	サブネット
ステート	ステートフル	ステートレス
拒否ルール	書けない（許可のみ）	許可・拒否どちらも書ける
ルール評価	全ルールを評価して許可	番号順に評価して最初にマッチで終了
デフォルト（インバウンド）	全拒否	全許可
デフォルト（アウトバウンド）	全許可	全許可

この表だけでも頭に入れておけば、試験でも実務でも迷いにくくなります。以下では各ポイントをひとつずつ掘り下げていきます。

適用対象の違い：インスタンスvsサブネット

セキュリティグループはインスタンス（正確にはENI：ネットワークインターフェース）に紐づくファイアウォールです。同じサブネット内に複数のEC2があっても、インスタンスごとに異なるSGを設定できます。

一方、ネットワークACLはサブネット全体に適用されます。そのサブネットに入ってくるトラフィック・出ていくトラフィックをまとめて制御します。

イメージとしては次のように捉えると理解しやすいです。

トラフィックはまずNACLを通過し、その後SGで判定されます。両方を通過して初めて通信が成立します。

ステートフルとステートレスの違い

ここが最も重要なポイントです。

セキュリティグループはステートフル

ステートフルとは、行きのトラフィックを許可すると、戻りのトラフィックも自動で許可されるという意味です。

たとえばインバウンドでポート443（HTTPS）を許可した場合、そのレスポンスのアウトバウンドトラフィックは自動的に許可されます。アウトバウンドにわざわざルールを追加する必要はありません。

ネットワークACLはステートレス

ステートレスとは、行きと帰りを個別に設定しないといけないという意味です。

インバウンドでポート443を許可しても、レスポンスのアウトバウンドは別途許可が必要です。このとき、レスポンスはエフェメラルポート（1024〜65535）を使って返ってくるため、アウトバウンドでエフェメラルポートの範囲を許可しておく必要があります。

これを忘れると「インバウンドは許可したのに通信できない」という状況が発生します。実務でも試験でもよく引っかかるポイントです。

拒否ルールの違い

セキュリティグループは「許可リスト」しか作れない

SGは許可するルールしか書けません。ルールに書かれていないトラフィックは自動的に拒否されますが、「このIPを明示的にブロックする」というルール自体は存在しません。

つまり、特定の攻撃元IPを名指しでブロックしたい場合、SGでは対応できません。

ネットワークACLは「許可」も「拒否」も書ける

NACLは許可・拒否の両方のルールを書けます。特定のIPアドレスやCIDRブロックを明示的にDENYすることが可能です。

DDoS攻撃や不審なアクセスをブロックしたいときは、NACLに拒否ルールを追加するのが定石です。

ルール評価順序の違い

セキュリティグループは全ルールを評価

SGはすべてのルールを評価し、どれか1つでも許可ルールに一致すれば通過できます。順番は関係ありません。

ネットワークACLはルール番号順に評価

NACLはルール番号の小さい順から評価し、最初にマッチしたルールで処理が終了します。

たとえば次のようなルールがある場合：

192.168.1.10からのアクセスはルール100でALLOWされて終了します。ルール200には到達しません。特定のIPを拒否したい場合は、許可ルールより小さいルール番号に拒否ルールを設定する必要があります。

実務での使い分け

概念の違いを理解したところで、実際の現場でどう使い分けるかを整理します。

セキュリティグループをメインに使う

日常的なアクセス制御はSGで行うのが基本です。インスタンスごとに細かくルールを設定でき、ステートフルなので管理も楽です。

SGはソースにIPだけでなく別のSGを指定できるのも強みです。上記のDBサーバーの例のように、「WebサーバーのSGが付いたインスタンスからのアクセスのみ許可」という書き方が可能です。IPが変わっても自動で追従するため、Auto Scalingとの相性が抜群です。

ネットワークACLは「追加の防衛ライン」として使う

NACLはサブネット全体に適用されるため、大きな単位での制御に向いています。実務では次のような場面で活躍します。

ただし、NACLのルール管理は煩雑になりがちです。ステートレスなのでエフェメラルポートの設定を忘れると通信断の原因になります。変更する際は影響範囲をよく確認してから行いましょう。

Auto Scalingが絡む場合はNACLに注意

Auto Scalingで新しいサブネットが追加された場合、SGは動的に対応できますが、NACLは新しいサブネットのCIDRを手動で追加しないといけません。

これを忘れると「一部のユーザーだけDB接続できない」という問題が起きます。Auto Scalingを使う構成では、NACLのルールをCIDRベースではなく広めのレンジで設定しておくか、定期的に見直す運用が必要です。

AWS試験で狙われるポイント

SAA・SOAでよく出る問題パターンをまとめます。

まとめ

セキュリティグループとネットワークACLの違いを改めて整理します。

両者は「どちらか一方を使う」ものではなく、多層防御として組み合わせて使うのがAWSのベストプラクティスです。それぞれの役割を理解して、適切に使い分けてみてください。