セキュリティグループ - AWS

最終更新日: 2026-07-26

TOP(About this memo)) > 一覧(AWS) > セキュリティグループ

セキュリティグループ

(参考) https://ent.iij.ad.jp/articles/1486/

基本

セキュリティグループは、EC2インスタンスの仮想ファイアウォールとして機能し、受信トラフィックと送信トラフィックを制御する。
インバウンドルールはインスタンスへの受信トラフィックを制御する。
アウトバウンドルールはインスタンスからの送信トラフィックを制御する。
インスタンスの起動時に1つ以上のセキュリティグループを指定できる。
セキュリティグループを指定しない場合、Amazon EC2はデフォルトのセキュリティグループを使用する(最大5つのセキュリティグループを割り当て可能)。
トラフィックがインスタンスに到達することを許可するかどうかをAmazon EC2が判断する際、インスタンスに関連付けられているすべてのセキュリティグループのすべてのルールを評価する。

ネットワークACL

ネットワークアクセスコントロールリスト(ACL)は、1つ以上のサブネットのインバウンド/アウトバウンドトラフィックを制御するファイアウォールとして動作する、VPC用のセキュリティのオプションレイヤー。
セキュリティの追加レイヤーをVPCに追加するには、セキュリティグループと同様のルールを指定したネットワークACLをセットアップできる。

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

(IME) AWSでよくある使い方として、ネットワークACLはデフォルト設定の「全て許可」のままにしておき、セキュリティグループでインスタンスへのアクセス制御を行うことが多い。
セキュリティグループは「ステートフルなファイアウォール」で、インスタンスレベルで動作する。ステートフルなため、例えば外部からのSSHを許可する際はインバウンドにのみルールを記載すればよい。
ネットワークACLは「ステートレスなファイアウォール」で、サブネットレベルで動作する。ステートレスなため、インバウンド・アウトバウンドそれぞれにルールを記載する必要がある。

ソース

セキュリティグループにはソース(送信元)を設定できる。送信元は、他のセキュリティグループ、IPv4/IPv6 CIDRブロック、単一のIPv4/IPv6アドレス、プレフィックスリストIDのいずれか。
ソースにはセキュリティグループを指定することもできる。
- (IME) セキュリティグループ(＋ネットワークインターフェース)自体が送信元のグルーピングのようにも機能するため、この仕組みは混同しやすく分かりづらいと感じる。
- セキュリティグループをルールの送信元として指定すると、指定したセキュリティグループに関連付けられた「ネットワークインターフェース」からのトラフィックが許可される。
- セキュリティグループに関連づけられたネットワークインターフェースを探すには、ネットワークインターフェース一覧で対象のセキュリティグループIDによりフィルタをかける。
- (参考) https://ent.iij.ad.jp/articles/1486/

セキュリティグループの多段構成

「ソースにセキュリティグループを指定できる」性質を使うと、IPアドレスではなくロール(層)ベースでアクセス制御ができ、サブネットのCIDRが変わっても設定を直す必要がない。
こうすることで、DBへの通信元は「特定のセキュリティグループが付いたリソース」に限定され、たとえ同じサブネットに他のリソースを後から追加してもDBへは到達できない。CIDRベースの許可よりも意図が明確になり、構成変更にも強い。

具体例

Webアプリ(画面)+API+バッチ用ワーカー+DB+キャッシュという構成の場合、以下のように「層ごとに1つSGを作り、直前の層のSGだけを許可する」設計がよく使われる。

セキュリティグループ	Ingress送信元	Ingressポート	備考
sg-alb	`0.0.0.0/0`	80, 443	インターネットからの入口のみCIDR指定
sg-app(Web/API)	sg-alb	アプリの待受ポート(例: 3000, 4000)	ALBからのみ許可
sg-worker	(なし)	–	インバウンド無し。外向き通信のみ
sg-db	sg-app, sg-worker	DBのポート(例: 5432)	アプリ・ワーカー両方から許可
sg-cache	sg-app, sg-worker	キャッシュのポート(例: 6379)	アプリ・ワーカー両方から許可

トラフィックの流れを図にすると以下のようになる。

Internet
   │ 80, 443
   ▼
┌─────────┐
│ sg-alb  │
└─────────┘
   │ Ingress送信元: sg-alb
   ▼
┌────────────────────┐   ┌────────────┐
│ sg-app (Web/API)   │   │ sg-worker  │  ← Ingressルール無し(外向きのみ)
└────────────────────┘   └────────────┘
   │ Ingress送信元: sg-app / sg-worker (両方から許可)
   ▼
┌─────────┐   ┌───────────┐
│ sg-db   │   │ sg-cache  │
└─────────┘   └───────────┘

ポイントは、sg-workerにはインバウンドルールが1つも無いこと。ワーカーは外部からの接続を一切受け付けず、キューのポーリングやDB接続など「自分から始める通信」しか行わないため、この設計で成立する(詳細は後述の「インバウンドルールが1つも無いセキュリティグループ」を参照)。
sg-db・sg-cacheはいずれも「sg-appかsg-workerのどちらか」ではなく「sg-appとsg-workerの両方」を送信元として許可している点にも注目。DBやキャッシュにアクセスする主体が複数ある場合、それぞれの主体のSGを個別にルールとして追加していく。

デフォルトのアウトバウンド設定

コンソールで新規作成したセキュリティグループには、デフォルトで「すべてのトラフィックを許可する」アウトバウンドルールが1本自動的に入っている。
IaCツールでセキュリティグループを作成する場合、この暗黙のデフォルトルールが引き継がれず「アウトバウンドルールなし(＝すべて拒否)」になる実装もあるため、意図せず外向き通信ができなくなることがある。全許可にしたい場合は、プロトコル(すべてのプロトコルを表す値)・ポート範囲(すべてのポートを表す指定)・送信先0.0.0.0/0のルールを明示的に書く必要がある場合がある点に注意。

インバウンドルールが1つも無いセキュリティグループ

「外部から一切接続を受け付けず、自分から外に通信するだけ」のリソース(バッチ処理、キューを監視するワーカーなど)には、インバウンドルールを1つも設定しない構成がありうる。
セキュリティグループはステートフルなため、インバウンドルールが無くても、そのリソース自身が開始した通信の戻りパケットは自動的に許可される。「戻り通信のために自分宛のインバウンドルールを書く」必要は無い。

ソースの指定方法の使い分け(セキュリティグループ vs CIDRブロック)

送信元を「特定のセキュリティグループ」で絞るか「CIDRブロック」で絞るかは、アクセス元の性質によって使い分けるとよい。
- 送信元が「特定の役割を持つリソース群」に限定できる場合はセキュリティグループ参照を使う(例: 上記のALBやアプリケーションサーバーなど)。IPレンジの変更(サブネット追加など)に影響されず、意図も明確になる。
- 送信元がインターネット、あるいは「VPC内の特定の層に限らずVPC全体」のように特定のセキュリティグループにひも付けにくい場合はCIDRブロックで指定する。

具体例(VPCエンドポイント用SG)

VPCエンドポイント(Interfaceタイプ)にアタッチするセキュリティグループは、CIDRブロックで指定する代表例。ECRやSecrets Managerへの通信は、Web/API/Workerなど「VPC内のどのリソースが使うか」を限定する意味が薄いため、個々のSGを参照するのではなくVPC全体のCIDRブロックを送信元にするのが自然になる。

sg-vpce (VPCエンドポイント用)
  Ingress: VPCのCIDRブロック全体 → 443

一方、前述のsg-app/sg-worker→sg-db/sg-cacheのような「特定の層からのみアクセスさせたい」ケースではセキュリティグループ参照を使う、という対比で覚えるとよい。

This site is open source. Improve this page.