導入
VPCの中にリソースを置いたら、次は「誰の通信を許可し、誰を拒否するか」を決める番です。AWSにはこの目的のための仕組みが2種類あり、役割が異なります。
説明
セキュリティグループは、EC2インスタンスなど個々のリソース単位にかける仮想的なファイアウォールです。
ネットワークACL（Network Access Control List）は、サブネット単位にかけるファイアウォールです。
両者の違いは試験で頻出のポイントなので、表で比較しておきましょう。
| 観点 | セキュリティグループ | ネットワークACL |
|---|---|---|
| 適用範囲 | インスタンス単位 | サブネット単位 |
| ルールの種類 | 許可ルールのみ設定できる | 許可・拒否の両方を設定できる |
| 状態管理 | ステートフル（行きの通信を許可すると、戻りの通信は自動的に許可される） | ステートレス（行きと戻りを別々にルール設定する必要がある） |
| ルールの評価 | すべてのルールを評価してから判定 | 番号の若い順にルールを評価し、最初に一致した時点で確定 |
flowchart LR
Internet(("インターネット")) --> NACL["ネットワークACL\n（サブネットの門番）"]
NACL --> SG["セキュリティグループ\n（インスタンスの門番）"]
SG --> EC2["EC2インスタンス"]
通信は、まずサブネットの門番であるネットワークACLを通過し、次にインスタンスの門番であるセキュリティグループを通過して初めてリソースに届きます。基本的な用途にはセキュリティグループだけで十分なことが多く、ネットワークACLは「特定のIPアドレスを明示的に拒否したい」といった追加の防御層として使われます。
具体例
先ほどのネットショップで、実際に設定する内容を見てみましょう。
セキュリティグループ（Webサーバーの門番）
- インターネットの誰からでも
443番ポート（HTTPS）は許可 → 一般のお客さんがサイトを見られる 22番ポート（SSHログイン）は社内オフィスのIPアドレスからだけ許可 → 管理者以外はログインできない- ここで「行き」を許可すれば、「戻り」の通信はステートフルなので自動で通る（戻り用のルールは書かなくていい）
ネットワークACL（サブネットの門番）
- ある日、特定のIP帯から不正アクセスが多発。セキュリティグループは「許可」しか書けないので、この特定IPをまとめて拒否するのは苦手。そこでサブネット単位で「拒否」も書けるネットワークACLに、そのIP帯の拒否ルールを追加した。
「普段の許可はセキュリティグループ、特定の相手を明示的に締め出す追加の壁はネットワークACL」——この使い分けが実務での定石です。
読んでみよう
「セキュリティグループ＝ステートフルで許可のみ・インスタンス単位」「ネットワークACL＝ステートレスで許可も拒否も・サブネット単位、番号順評価」——この対比をセットで丸暗記しておくと得点源になります。