セキュリティグループは、EC2インスタンスに出入りする通信を「許可するもの」だけを列挙して制御する仮想のファイアウォールです。WordPressを動かすなら、HTTP/HTTPSは公開、SSHは自分の接続元だけ、データベースはWebサーバーのセキュリティグループからだけ、という形に分けるのが基本になります。この記事では、セキュリティグループの動きの特徴、用途別のルールの作り方、セキュリティグループ同士を参照する設計、CLIでの設定例、通信が通らないときの確認方法までを説明します。
コンソールの表記やクォータ（上限値）は変わることがあるため、ここでの説明は2026年10月現在の情報をもとにした目安です（2026年10月現在）。
セキュリティグループの4つの特徴
設定を始める前に、動きの特徴を押さえておくと、ルールの意図を読み違えずに済みます。
- 許可ルールだけを書く：拒否のルールはありません。どのルールにも当てはまらない通信は通りません。特定のIPだけを拒否したい場合は、ネットワークACLやAWS WAFを使います。
- ステートフル：許可したインバウンドの通信に対する応答は、アウトバウンドのルールに関係なく返せます。逆も同じです。戻りの通信のためにポートを開ける必要はありません。
- インスタンス（ネットワークインターフェース）単位：同じサブネットにあるインスタンス同士でも、セキュリティグループが許可していなければ通信できません。
- 既定値：新しく作ったセキュリティグループは、インバウンドがすべて拒否、アウトバウンドがすべて許可の状態です。
1つのインスタンスに複数のセキュリティグループを付けると、それぞれのルールを合わせたものが適用されます。「共通の管理用」と「Webサーバー用」のように役割ごとに分けて組み合わせると、ルールの重複を減らせます。
WordPress向けのルールを作る
1台のEC2でWordPressを動かす構成を例に、インバウンドのルールを決めていきます。
HTTP・HTTPS（80・443番）
公開するサイトなら、送信元を 0.0.0.0/0（IPv4のすべて）にします。IPv6でも公開する場合は ::/0 のルールも追加します。80番はHTTPSへのリダイレクトのためだけに開けておくのが一般的です。
前段にロードバランサーやCloudFrontを置く場合は、送信元をそれらに絞ります。ロードバランサーならそのセキュリティグループを、CloudFrontならAWSが用意しているマネージドプレフィックスリスト（CloudFrontのオリジン向けのもの）を指定すると、EC2を直接たたく通信を受け付けずに済みます。
SSH（22番）
送信元は自分の接続元のIPアドレスに /32 を付けて1つに絞ります。0.0.0.0/0 で開けると、世界中から総当たりのログイン試行を受け続けます。鍵認証にしていても、ログが試行で埋まり、SSHのソフトウェアに脆弱性が見つかった場合の危険も大きくなります。
接続元のIPが頻繁に変わる環境では、Session Manager を使ってSSHのポートそのものを閉じる方法があります。インスタンスにSSMエージェントと必要なIAMロールがあれば、インバウンドのルールを1つも開けずにシェルを使えます。
データベース（3306番）
MySQLやMariaDBを別のサーバーやRDSに分ける場合、データベース側のセキュリティグループでは、送信元にWebサーバーのセキュリティグループを指定します。IPアドレスで指定するより、次の節で説明する参照のほうが管理しやすくなります。3306番を 0.0.0.0/0 に開けることは避けてください。
ルールに説明を付ける
各ルールには説明（Description）を入力できます。「事務所の固定IP」「保守業者の作業用」のように、なぜそのルールがあるのかを書いておくと、半年後に見直すときに消してよいか判断できます。誰のためのルールか分からないものが残り続けることが、セキュリティグループの管理でもっとも多い問題です。
セキュリティグループ同士を参照する設計
ルールの送信元には、IPアドレスの範囲の代わりに別のセキュリティグループを指定できます。これを使うと、台数が増えたりIPが変わったりしてもルールを書き換えずに済みます。
[ALB用 sg-alb] インバウンド 443 ← 0.0.0.0/0
↓
[Web用 sg-web] インバウンド 80 ← sg-alb
↓
[DB用 sg-db] インバウンド 3306 ← sg-webこの構成では、Web用のセキュリティグループを付けたインスタンスであれば、何台に増えてもデータベースに接続できます。逆に、インターネットから直接WebサーバーやDBには届きません。Auto Scalingで台数が変わる構成では、この設計がほぼ前提になります。
参照できるのは、基本的に同じVPCの中（または接続されたVPCの一部の条件下）のセキュリティグループです。異なるリージョンのセキュリティグループは参照できないので、その場合はIPアドレスの範囲で指定します。
CLIでルールを追加する例
コンソールでも操作できますが、CLIで書いておくと手順として残せます。IDやIPアドレスは自分の環境の値に置き換えてください。
# SSHを自分のIPだけに許可（説明付き）
aws ec2 authorize-security-group-ingress \
--group-id sg-0123456789abcdef0 \
--ip-permissions 'IpProtocol=tcp,FromPort=22,ToPort=22,IpRanges=[{CidrIp=203.0.113.10/32,Description="office"}]'
# DB用のセキュリティグループで、Web用からの3306だけを許可
aws ec2 authorize-security-group-ingress \
--group-id sg-0db0000000000000 \
--protocol tcp --port 3306 \
--source-group sg-0web000000000000
# 現在のルールを確認
aws ec2 describe-security-group-rules \
--filters Name=group-id,Values=sg-0123456789abcdef0ルールの変更は保存した時点で反映されます。ただし、すでに確立している接続は、ルールを削除してもすぐには切れないことがあります。SSHのルールを消した直後に今のセッションが切れなくても、新しい接続は拒否されている、という状態になり得るので、確認は新しい接続で行います。
通信が通らないときの確認
「ルールを追加したのにつながらない」ときは、セキュリティグループ以外の場所に原因があることも多いです。可能性の高い順に確認します。
- 付けているセキュリティグループが違う：インスタンスの詳細の「セキュリティ」タブで、実際に付いているセキュリティグループを確認します。同じ名前のものを別のVPCに作っていて、違うほうを編集していることがよくあります。
- 送信元のIPが違う：自分の現在のグローバルIPが、ルールの範囲に入っているかを確認します。社内のネットワークではプロキシ経由で別のIPになっていることがあります。
- サーバーのプロセスが待ち受けていない：インスタンスに入れるなら、
sudo ss -tlnpでNginxやApacheが80・443番で待ち受けているかを確認します。127.0.0.1だけで待ち受けている場合は外から届きません。 - OSのファイアウォール：ufwやfirewalldを有効にしている場合は、そちらでも許可が必要です。
- ネットワークACLとルートテーブル：ネットワークACLはステートレスなので、戻りの通信（一時ポートの範囲）も許可されているかを確認します。
それでも分からない場合は、VPCの Reachability Analyzer で送信元から送信先までの経路を分析するか、VPCフローログを有効にして、通信が REJECT になっている場所を探します。
定期的な見直し
セキュリティグループは作ったあと放置されがちです。次の点を定期的に確認します。
0.0.0.0/0に開いているポートが、80・443番以外にないか- 説明のないルールや、もう使っていない接続元のルールが残っていないか
- どのインスタンスにも付いていないセキュリティグループが残っていないか
AWS Security Hub や AWS Config を使うと、SSHが全開放になっているなどの状態を自動で検出できます。
まとめ
- セキュリティグループは許可ルールだけを書くステートフルなファイアウォールで、既定ではインバウンドがすべて拒否。
- 80・443番は公開、SSHは自分のIPに絞るかSession Managerで閉じる、DBはWeb用のセキュリティグループからだけ許可する。
- 送信元にセキュリティグループを指定すると、台数やIPが変わってもルールを書き換えずに済む。
- ルールには説明を付け、つながらないときは付いているグループ・送信元IP・待ち受け・OSのファイアウォール・ACLの順に確認する。