はじめに
本記事の目的
本記事は、AWSの「セキュリティグループ」について基本から実践までやさしく解説します。セキュリティグループを仮想ファイアウォールとして捉え、その役割や設定方法、運用時のポイントをわかりやすく伝えます。
誰に向けた記事か
- これからAWSを学ぶ方
- サーバー運用やインフラ担当の方
- 実際のルール設定に不安がある開発者
専門的な前提知識は多く必要ありません。EC2やVPCの基本が分かれば読み進めやすいです。
本記事の構成（読み方の目安）
各章で1つのテーマを丁寧に扱います。第2章で概要を把握し、第3〜5章で具体的な要素や設定例を確認します。第6章では似た機能との違いを説明し、第7章で日常運用のコツを紹介します。料金やまとめも最後にあります。必要な章だけ読んでも理解できます。
注意点
実際の運用では、まずテスト環境で設定を確認してください。誤ったルールはサービス停止やセキュリティリスクにつながります。
セキュリティグループとは何か
概要
セキュリティグループは、AWSのVPC内で動くリソース（例：EC2、RDS）に適用する仮想的な防護ルールの集まりです。ネットワークの入出力を絞り込み、「誰がアクセスできるか」「どこへ通信できるか」を決めます。門番のように不正な通信を防ぎます。
なぜ必要か
外部や別のサーバからの不要な接続を防ぐために使います。例えば、管理用のSSHは特定のIPからだけ許可し、データベースはアプリサーバからのみ接続可能にできます。これにより攻撃面を小さくします。
簡単な例
- Webサーバ：HTTP(80)とHTTPS(443)を世界に許可、SSH(22)は自分のIPだけ許可
- DBサーバ：ポート3306をアプリサーバのセキュリティグループだけ許可
主なポイント
- ルールは「許可」のみで構成します。明示的な拒否ルールは使いません。
- ステートフルです。ある方向を許可すると、その対向の応答は自動で許可されます。
- 複数のインスタンスに適用できます。IDで管理し、柔軟に変更できます。
この章ではまず役割と使い方のイメージを掴んでください。次章で内部の構成要素を丁寧に説明します。
セキュリティグループの主な構成要素
AWSリソース
セキュリティグループはEC2インスタンスやRDS、ロードバランサーなどVPC内のリソースに割り当てます。1つのリソースに対して最大5つまでセキュリティグループを適用できます。複数のグループを付ければ、役割ごとにルールを分けて管理できます。
グループ本体
セキュリティグループは「名前」「説明」「ルールの集合」として定義します。各グループは特定のVPCに属します。名前や説明を分かりやすく付けると、あとで管理しやすくなります。
ルール
1グループあたり最大60ルールまで設定できます。ルールは「インバウンド（受信）」と「アウトバウンド（送信）」の2種類です。各ルールで次を指定します：
– プロトコル（例：TCP/UDP/ICMP）
– ポート番号（例：HTTPは80、SSHは22）
– 通信元または通信先（IPアドレスやCIDR、ほかのセキュリティグループ）
例えば、SSHを管理者の固定IPだけ許可する、Webは全世界から許可する、データベースはアプリサーバのセキュリティグループからのみ許可する、といった設定が可能です。ルールは明確にし、不要な開放を避けると安全です。
セキュリティグループの動作と特徴
ステートフル（Stateful）な動作
セキュリティグループは状態を覚えます。たとえば、サーバーに対してポート80の受信（インバウンド）を許可すると、その通信に対する応答（アウトバウンド）は自動で許可されます。応答を個別に設定する必要がないため、設定がシンプルになります。
デフォルトで拒否する設計
明示的に許可したトラフィックだけ通します。何も設定しなければ全て遮断されるので、必要最小限の通信だけ許可する方針を自然に実現できます。たとえば管理用のSSHだけ開けて、他は閉じるといった運用が容易です。
IPアドレスの変動に強い
セキュリティグループはインスタンスやリソースに紐づきます。IPアドレスが変わってもルールを変える必要がありません。スケールアウトでサーバーを増やしたり、再起動でIPが変わっても同じセキュリティポリシーを維持できます。
複数リソースへの割り当てと一元管理
同じセキュリティグループを複数のサーバーに割り当てられます。ルールを一度変更すれば、割り当て先すべてに反映されます。大規模な環境でも設定の再利用と管理が楽になります。
具体的なルール設定例
以下では、よく使うルールを具体例で示します。各例はインバウンド（着信）ルールが中心です。
- インターネット全体からWebサーバーへHTTPを許可
- 目的: 公開Webサイトの閲覧を可能にします。
- ルール: インバウンド TCP ポート80、送信元 0.0.0.0/0
-
補足: HTTPS（ポート443）も必要なら同様に設定します。不要なポートは閉じます。
-
社内ネットワークからのみSSHで管理アクセスを許可
- 目的: 管理者だけが安全にサーバーに接続できます。
- ルール: インバウンド TCP ポート22、送信元 社内IPのCIDR（例: 10.0.0.0/24）
-
補足: 公開SSHは避け、ポート変更や鍵認証も併用すると安全性が高まります。
-
特定のアプリケーション間通信のみ許可（セキュリティグループ指定）
- 目的: アプリ層で通信を限定して、不要なアクセスを防ぎます。
- ルール: インバウンド TCP ポート（例: 3306 for MySQL）、送信元に別のセキュリティグループIDを指定
- 補足: セキュリティグループ参照を使うと、IPを意識せずインスタンス単位で通信を制御できます。
運用のコツ: 最小権限を心がけ、不要なポートは開けません。テスト用に緩める場合は、作業後すぐに元に戻す習慣をつけてください。
セキュリティグループとネットワークACLの違い
概要
セキュリティグループ(SG)はインスタンス単位で使います。ネットワークACL(NACL)はサブネット単位で適用します。用途と挙動が違うので、両方を役割分担して使うと安全性が高まります。
ステートフルとステートレス
SGはステートフルです。つまり、インバウンドで許可した通信の応答は自動で許可されます。例：80番ポートで許可すると、その応答パケットは戻ってきます。NACLはステートレスです。入ってきた通信の応答も明示的に許可する必要があります。
方向と適用範囲
どちらもインバウンドとアウトバウンドのルールを持ちますが、SGは個々のインスタンスに細かく設定できます。NACLはサブネット全体に対して広く制限をかけます。
主な使い分け例
- SG：Webサーバーへ特定ポート（例：80/443）だけ許可し、管理者のIPだけSSHを許可します。複数のSGを組み合わせて柔軟に設定します。
- NACL：サブネット全体で不正なIPレンジをブロックしたり、外部からの大量接続を粗く制限したりします。
設定のポイント
SGは細かなアクセス制御に向きます。NACLは全体のガードレール役です。両方を組み合わせて使い、まずNACLで大まかに制限し、SGで個別に調整すると効果的です。
セキュリティグループのベストプラクティス
1. 最小権限の原則
必要な通信だけを許可します。例えばSSHは管理者の固定IPだけ（例：203.0.113.12/32）に限定し、0.0.0.0/0は避けます。アプリごとにポートを絞り、不要なポートは閉じます。
2. 役割ごとに分離する
Web、アプリ、DBなど役割ごとにセキュリティグループを分けます。例えば「app-web-prod」「app-db-prod」のように命名し、相互アクセスは最小限のルールで許可します。これにより変更の影響範囲を小さくできます。
3. ルールの整理とドキュメント化
各ルールに目的、作成者、作成日を残します。なぜそのポートを開けたのか、いつ見直すのかを明記すると運用が楽になります。変更履歴を残して定期的にレビューします。
4. 監査と自動化を組み合わせる
定期スキャンで全開放（0.0.0.0/0）や不要ルールを検出し、アラートを出す仕組みを持ちます。IaC（Infrastructure as Code）で設定を管理し、変更はコードレビューと自動テストを通します。
5. 一元管理と再利用性の意識
共通ルールはテンプレート化して共有セキュリティグループにまとめます。これにより設定の重複を減らし運用コストを下げます。
6. 運用時の注意点
変更時は影響範囲を確認し、ロールバック手順を用意します。本番変更は時間帯を工夫して影響を最小化し、テスト環境で検証してから適用します。
料金について
概要
セキュリティグループ自体の利用は無料です。ルールを作成してインスタンスやデータベースに適用しても、セキュリティグループそのものに対する直接の課金は発生しません。ただし、セキュリティグループを適用するEC2、RDS、ロードバランサーなどのサービス利用料は別途かかります。
料金のポイント
- セキュリティグループ：無料（作成数やルール数で課金されない）
- 対象サービス：EC2はインスタンスの稼働時間、RDSはDBの稼働時間、ELBは利用時間とデータ転送量で課金されます
- データ転送：インターネットやリージョン間の転送は別途料金が発生する場合があります
具体例
- EC2にSGを適用しても追加料金は発生しません。EC2の稼働による料金が課金されます。
- ロードバランサー経由の通信ではELBの料金やデータ転送料金が発生するため、トラフィック量に注意が必要です。
コスト管理のヒント
- 使っていないインスタンスや未使用のロードバランサーは停止・削除して無駄を減らす
- データ転送を抑えるためにリソースを同一リージョン・同一アベイラビリティーゾーンに配置する
- 請求アラートやコストレポートを設定し、予期せぬ増加を早めに検知する
注意点
セキュリティグループ自体は無料でも、誤った設定で不要なサービスが稼働するとコストが増えます。運用時は定期的に設定とリソース状況を確認してください。
まとめ
AWSのセキュリティグループは、VPC内のリソースごとに適用する「仮想ファイアウォール」です。インバウンド（受信）とアウトバウンド（送信）をルールで許可する仕組みで、許可していない通信は基本的に遮断されます。
状態を保持するため、受信を許可するとその応答トラフィックは自動で許可されます。この性質により、個別の通信ごとに応答ルールを追加する必要がありません。
ルールはポート・プロトコル・送信元（または送信先）で指定します。送信元に特定のIPや別のセキュリティグループを指定でき、たとえば「WebはTCP 80を全世界に開く」「管理用SSHは特定IPのみに限定する」といった運用が可能です。
利点は、柔軟で扱いやすくスケールしやすい点です。設計では最小権限の原則に従い、役割ごとにセキュリティグループを分け、タグで管理すると運用が楽になります。運用面では定期的な見直し、VPCフローログなどでの監査、ルール変更時のテストを習慣にしてください。
料金面では、セキュリティグループ自体に追加料金は発生しません。ただし、ログや監視など別サービスの利用には費用がかかる点にご注意ください。
正しく設計・運用すれば、セキュリティグループはAWS環境の重要な防御層になります。具体的な環境や要件があれば、例を交えて一緒に考えていけますのでご相談ください。
