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

「EC2を立てたけど、セキュリティグループとネットワークACL、どっちで何を制御すればいいのか分からない」

オンプレミスでファイアウォールやACLを運用してきたエンジニアほど、AWSのVPCセキュリティに最初は戸惑います。見た目は似ているのに、動作の仕組みがまるで違うからです。

この記事では、AWS VPCにおけるセキュリティグループ（SG）とネットワークACL（NACL）の仕組み・違い・実務での使い分けを、オンプレのファイアウォール運用経験者にも分かりやすく解説します。設定手順、よくあるトラブル、料金の考え方まで網羅しているので、VPCのネットワーク防御を体系的に理解できます。

なぜVPCのセキュリティ設計が重要なのか

オンプレミスでは、データセンターの物理ファイアウォールやスイッチのACLでネットワークを守っていました。外部との境界が明確で、「入口を1つ固めればOK」という運用が成り立っていたわけです。

クラウドでは事情が変わります。VPC内に複数のサブネットを切り、インターネットゲートウェイやNATゲートウェイ、VPCピアリングなど多方向の通信経路が存在します。境界が1つではなくなるため、「インスタンス単位」と「サブネット単位」の2層で防御する設計が標準になっています。

AWSのVPCセキュリティは、この2層防御をセキュリティグループとネットワークACLで実現します。どちらもパケットフィルタリングの仕組みですが、適用範囲・動作モデル・設定の粒度がまったく異なります。

セキュリティグループの基本

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

セキュリティグループ（SG）は、ENI（Elastic Network Interface）単位で適用される仮想ファイアウォールです。EC2インスタンスやRDS、ELBなど、ENIを持つリソースすべてに紐づきます。

オンプレで例えると、サーバーごとに設定するホストベースファイアウォール（iptablesやWindows Firewall）に近い存在です。ただし、SGはAWSの基盤側で処理されるため、OS内のファイアウォールとは別レイヤーで動作します。

2. ステートフルな動作

SGの最大の特徴は「ステートフル」であることです。インバウンドで許可した通信の戻りパケットは、アウトバウンドルールに関係なく自動的に許可されます。

# 例: Webサーバー用SGのインバウンドルール
# タイプ: HTTP
# プロトコル: TCP
# ポート範囲: 80
# ソース: 0.0.0.0/0
#
# → クライアントからのHTTPリクエスト(ポート80)を許可
# → レスポンスの戻りパケットはアウトバウンドルールなしでも通る

この動作はオンプレのステートフルファイアウォール（Palo AltoやFortiGate等）と同じ考え方です。戻りの通信を個別に許可する必要がないため、ルール数がシンプルに保てます。

3. デフォルトの挙動

・インバウンド: すべて拒否（明示的に許可したものだけ通す）
・アウトバウンド: すべて許可（デフォルトで全通信を通す）
・拒否ルール: 設定できない（許可ルールのみ。ホワイトリスト方式）

「許可だけを書く」というシンプルさが、SGの運用しやすさにつながっています。

ネットワークACLの基本

1. ネットワークACLとは

ネットワークACL（NACL）は、サブネット単位で適用されるパケットフィルタリング機能です。サブネットに出入りするすべてのトラフィックに対して、ルール番号の小さい順に評価されます。

オンプレで例えると、L3スイッチやルーターに設定するACL（Access Control List）そのものです。CiscoルーターでACLを書いた経験があれば、NACLの動作モデルはすぐに理解できるでしょう。

2. ステートレスな動作

NACLは「ステートレス」です。インバウンドで許可した通信の戻りパケットも、アウトバウンドルールで明示的に許可しなければ通りません。

# 例: Webサーバー用NACLのルール
#
# インバウンドルール:
# ルール番号100: HTTP(80) 許可 / ソース 0.0.0.0/0
# ルール番号 * : すべて拒否（デフォルト）
#
# アウトバウンドルール:
# ルール番号100: エフェメラルポート(1024-65535) 許可 / 宛先 0.0.0.0/0
# ルール番号 * : すべて拒否（デフォルト）
#
# → アウトバウンドでエフェメラルポートを許可しないと
#   HTTPレスポンスが返せない

エフェメラルポート（一時ポート）の許可を忘れるのは、NACLでもっとも多い設定ミスです。Linuxの場合は32768-60999、Windowsの場合は49152-65535がエフェメラルポートの範囲ですが、クライアント側のOSが特定できない場合は1024-65535で許可するのが実務上の定番です。

3. デフォルトの挙動

・デフォルトNACL: インバウンド・アウトバウンドともにすべて許可
・カスタムNACL: インバウンド・アウトバウンドともにすべて拒否
・拒否ルール: 設定できる（SGとの最大の違い）

デフォルトNACLは全通信を許可しているため、VPC作成直後はNACLの存在を意識しないことが多いです。しかし、カスタムNACLを作成した途端にすべて拒否になるため、「NACLを作ったらサーバーにつながらなくなった」という事故が起きがちです。

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

実務での使い分けガイド

1. 基本方針: SGをメイン、NACLは補助

AWSの公式ベストプラクティスでも推奨されている使い分けは、「SGで日常的なアクセス制御を行い、NACLはサブネット全体の大まかな制御に使う」です。

SGがステートフルで管理しやすいのに対し、NACLはステートレスでエフェメラルポートの考慮が必要なため、運用コストが高くなります。普段のアクセス制御はSGに任せ、NACLは「特定IPの一括ブロック」や「サブネット間通信の大枠制御」に限定するのが現場での定番パターンです。

2. NACLが効果を発揮するケース

・特定IPアドレスのブロック: 攻撃元IPをサブネットレベルで遮断したいとき。SGには拒否ルールがないため、NACLでしか実現できない
・サブネット間の通信制御: パブリックサブネットとプライベートサブネット間の通信を大枠で制限したいとき
・コンプライアンス要件: 監査で「ネットワーク境界での制御」を求められたとき、NACLの存在が証跡として有効

3. 設計例: 3層アーキテクチャ

# 3層アーキテクチャのセキュリティ設計例
#
# [パブリックサブネット] ALB
#   SG: 80/443をインターネットから許可
#   NACL: デフォルト（全許可）
#
# [プライベートサブネット] EC2 (Webアプリ)
#   SG: 8080をALBのSGから許可
#   NACL: デフォルト（全許可）
#
# [プライベートサブネット] RDS (データベース)
#   SG: 3306をEC2のSGから許可
#   NACL: カスタム（DBサブネット以外からの3306を拒否）

ポイントは、SGのソースに「IPアドレス」ではなく「別のセキュリティグループのID」を指定している点です。これにより、インスタンスのIPが変わっても設定変更が不要になります。オンプレではIPベースのACLが当たり前でしたが、クラウドではリソースが動的に変わるため、SG参照が基本です。

AWS CLIでの設定手順

1. セキュリティグループの作成と設定

# AWS CLI: セキュリティグループの作成
aws ec2 create-security-group \
  --group-name web-server-sg \
  --description "Web Server Security Group" \
  --vpc-id vpc-0123456789abcdef0

# インバウンドルールの追加（HTTP許可）
aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 80 \
  --cidr 0.0.0.0/0

# インバウンドルールの追加（SSH: 管理用IPのみ）
aws ec2 authorize-security-group-ingress \
  --group-id sg-0123456789abcdef0 \
  --protocol tcp \
  --port 22 \
  --cidr 203.0.113.10/32

2. ネットワークACLの作成と設定

# AWS CLI: カスタムNACLの作成
aws ec2 create-network-acl \
  --vpc-id vpc-0123456789abcdef0

# インバウンドルールの追加（HTTP許可）
aws ec2 create-network-acl-entry \
  --network-acl-id acl-0123456789abcdef0 \
  --rule-number 100 \
  --protocol tcp \
  --port-range From=80,To=80 \
  --cidr-block 0.0.0.0/0 \
  --rule-action allow \
  --ingress

# アウトバウンドルールの追加（エフェメラルポート許可）
aws ec2 create-network-acl-entry \
  --network-acl-id acl-0123456789abcdef0 \
  --rule-number 100 \
  --protocol tcp \
  --port-range From=1024,To=65535 \
  --cidr-block 0.0.0.0/0 \
  --rule-action allow \
  --egress

# サブネットへの関連付け
aws ec2 replace-network-acl-association \
  --association-id aclassoc-0123456789abcdef0 \
  --network-acl-id acl-0123456789abcdef0

料金の仕組み

セキュリティグループとネットワークACLの利用自体に追加料金はかかりません。VPCの機能として無料で利用できます。

ただし、以下の点に注意してください。

・SGのルール数上限: 1つのSGにつきインバウンド・アウトバウンド各60ルールがデフォルト上限。1つのENIに5つまでSGを紐づけ可能（2026年3月時点）
・NACLのルール数上限: 1つのNACLにつきインバウンド・アウトバウンド各20ルールがデフォルト上限
・上限緩和: AWS Supportに申請すれば上限を引き上げ可能。ただし、SGのルール数 x 紐づけ数が1,000を超えるとネットワーク性能に影響が出る場合がある
・VPC Flow Logs: SGやNACLの動作を記録するVPC Flow Logsは、S3やCloudWatch Logsへの配信料金が別途発生する

よくあるトラブルと対処法

1. 「SGを正しく設定したのに通信できない」

まずNACLを確認してください。カスタムNACLが適用されていると、デフォルトですべて拒否になります。SGだけを見て原因が分からないケースの大半は、NACLが原因です。

VPC Flow Logsを有効にすると、パケットがどこでREJECTされているかを特定できます。

2. 「NACLでHTTPを許可したのにWebページが表示されない」

アウトバウンドのエフェメラルポート許可を忘れていないか確認してください。NACLはステートレスなので、行きの通信を許可しても戻りは自動許可されません。

3. 「特定IPをブロックしたい」

SGでは拒否ルールが書けないため、NACLで対応します。ルール番号は許可ルールより小さい番号（若い番号が優先）で拒否ルールを追加してください。

# AWS CLI: 特定IPをNACLでブロック
aws ec2 create-network-acl-entry \
  --network-acl-id acl-0123456789abcdef0 \
  --rule-number 50 \
  --protocol -1 \
  --cidr-block 198.51.100.0/24 \
  --rule-action deny \
  --ingress

4. 「SGを変更したのに反映されない」

SGの変更は即時反映されます。反映されないと感じる場合は、以下を確認してください。

・変更したSGが対象インスタンスに紐づいているか
・複数のSGが紐づいている場合、別のSGで許可されていないか（SGは全ルールをOR評価）
・ブラウザのキャッシュやDNSキャッシュが原因ではないか

本記事のまとめ

セキュリティグループとネットワークACLは「どちらか一方」ではなく、2層防御として組み合わせて使うのがAWSの基本設計です。日常のアクセス制御はステートフルで管理しやすいSGに任せ、NACLはサブネット全体の大枠制御や特定IPブロックの切り札として位置づけてください。

オンプレでファイアウォールやACLを運用してきた経験があれば、考え方の土台はすでにできています。「ステートフル vs ステートレス」と「適用単位の違い」さえ押さえれば、VPCのセキュリティ設計は自信を持って取り組めるはずです。

ネットワークセキュリティの基本的な考え方やファイアウォール設計の原則については、姉妹サイトSecurityMasters.TOKYOでも体系的に解説しています。クラウドとオンプレ両方の視点からセキュリティを深掘りしたい方はあわせてご覧ください。