▪️目的
AWSでEC2などのリソースを構築していると、「Security Group（セキュリティグループ）」という設定が登場します。
Security Groupは、簡単にいうと、
AWSのリソースに対する通信を許可・制御するための仮想ファイアウォール
です。
例えば、
- WebサーバーへのHTTPS通信だけ許可する
- SSH接続を特定のIPアドレスからだけ許可する
- データベースへの通信をアプリケーションサーバーからだけ許可する
といった通信制御を行うことができます。
この記事では、Security Groupとは何なのか、Inbound・Outboundとは何なのか、Security Groupがどのように通信を制御しているのかを、AWS初心者向けに解説します。
▪️Security Groupとは？
Security Groupとは、EC2などのAWSリソースに対して設定できる仮想ファイアウォールです。
例えばEC2に、
Security Group
│
├─ HTTP : 80 許可
├─ HTTPS : 443 許可
└─ SSH : 22 許可
のようなルールを設定できます。
このルールによって、
「どの通信を許可するのか」
を制御します。
例えばWebサーバーとして利用するEC2でHTTPS通信を受け付けたい場合、
Protocol : TCP
Port : 443
Source : 0.0.0.0/0
のようなInboundルールを設定します。
これによって、インターネット上のクライアントからEC2へのHTTPS通信を許可できます。
▪️ファイアウォールとは？
Security Groupを理解するために、まずファイアウォールについて簡単に確認しておきましょう。
ファイアウォールとは、ネットワーク通信を監視し、
許可する通信と拒否する通信を判断する仕組み
です。
例えば、
インターネット
│
│ HTTPS
↓
ファイアウォール
│
↓
サーバー
という構成があった場合、
HTTPS → 許可
SSH → 拒否
のように通信を制御できます。
AWSでは、このような役割をSecurity Groupが担います。
▪️InboundとOutbound
Security Groupを理解するうえで重要なのが、
- Inbound
- Outbound
の2つです。
♦︎Inbound
Inboundは、リソースの外部から内部へ入ってくる通信です。
例えば、
Internet
↓
EC2
という通信であれば、EC2から見てInbound通信になります。
Webサーバーの場合、
Internet
↓
TCP 443
↓
EC2
というHTTPS通信を許可するルールを設定できます。
♦︎Outbound
Outboundは、リソースから外部へ出ていく通信です。
例えば、
EC2
↓
Internet
という通信です。
EC2から外部APIへHTTPS通信を行う場合などが該当します。
つまり、
Inbound
外 → EC2
Outbound
EC2 → 外
と考えると分かりやすいでしょう。
▪️Security Groupのルール
Security Groupでは、通信を許可するためのルールを設定します。
例えば、
Type Protocol Port Source
HTTPS TCP 443 0.0.0.0/0
とした場合、
どこからでもHTTPS（TCP 443）でEC2へアクセスすることを許可する
という意味になります。
一方、
Type Protocol Port Source
SSH TCP 22 203.0.113.10/32
とした場合、
203.0.113.10というIPアドレスからのSSH接続だけを許可する
という意味になります。
▪️ポート番号とは？
Security Groupでは、ポート番号を指定して通信を制御することができます。
代表的なポートには以下のようなものがあります。
| サービス | プロトコル | ポート |
|---|---|---|
| HTTP | TCP | 80 |
| HTTPS | TCP | 443 |
| SSH | TCP | 22 |
| DNS | UDP/TCP | 53 |
| RDP | TCP | 3389 |
例えば、
TCP 443
を許可すると、HTTPS通信を受け付けるためのルールを作れます。
ただし、ポート番号を許可しただけで、そのサービスが必ず動作するわけではありません。
例えば、
Security Group
TCP 443 → 許可
でも、EC2上でHTTPSを待ち受けるアプリケーションが動作していなければ通信は成立しません。
▪️Security Groupはどのように通信を判断する？
ここまで学んできたネットワーク構成と合わせて考えてみましょう。
例えば、
Internet
↓
Internet Gateway
↓
Public Subnet
↓
EC2
という構成があるとします。
EC2にはSecurity Groupが設定されています。
EC2
│
└─ Security Group
└─ TCP 443 → 許可
ユーザーがEC2へHTTPSアクセスすると、
Internet
↓
Internet Gateway
↓
EC2
↓
Security Group
↓
TCP 443？
というイメージで通信が制御されます。
Security Groupのルールに一致していれば、通信が許可されます。
一致する許可ルールがなければ、通信は許可されません。
▪️Security Groupは「どこからの通信か」も判断する
Security Groupでは、ポート番号だけでなく通信元も指定できます。
例えば、
TCP 443
Source: 0.0.0.0/0
なら、IPv4アドレスからのHTTPS通信を広く許可します。
一方、
TCP 443
Source: 203.0.113.10/32
なら、特定のIPアドレスからのHTTPS通信だけを許可します。
このように、
どのプロトコル？
どのポート？
どこから？
という条件で通信を制御できます。
▪️Security Groupの大きな特徴
Security Groupには、いくつか重要な特徴があります。
1. デフォルトでInboundは許可されない
Security Groupを新しく作成した場合、基本的にInboundルールは許可されていません。
そのため、
Internet
↓
EC2
という通信を受け付けたい場合は、必要なInboundルールを追加する必要があります。
例えばWebサーバーなら、
TCP 443
Source: 0.0.0.0/0
などを設定します。
2. Statefulな通信制御
Security Groupはステートフルです。
これは非常に重要な特徴です。
例えば、EC2から外部のWebサーバーへHTTPS通信を開始したとします。
EC2
↓
HTTPS
↓
Internet
この通信に対するレスポンスが、
Internet
↓
HTTPS Response
↓
EC2
と戻ってきた場合、戻りの通信について明示的なInboundルールを追加しなくても、Security Groupは通信の状態を認識して戻りの通信を許可します。
つまり、
Security Groupでは、通信の状態を追跡して戻りの通信を許可する
という特徴があります。
▪️Security Groupは許可ルールのみ
Security Groupでは、基本的に許可ルールを設定します。
例えば、
TCP 443 → 許可
というルールは設定できますが、
203.0.113.10 → 拒否
のような明示的なDenyルールをSecurity Groupに設定することはできません。
許可ルールに一致しない通信は、基本的に許可されません。
そのため、
許可ルールに一致
↓
通信を許可
一致しない
↓
通信を許可しない
という考え方になります。
▪️Security Groupは複数のEC2で利用できる
Security Groupは、複数のEC2などに関連付けて利用できます。
例えば、
Web Server
│
└─ Web-SG
Application Server
│
└─ App-SG
Database
│
└─ DB-SG
のように、役割ごとにSecurity Groupを分けることができます。
▪️Security Groupを使ったWebシステムの構成
例えば、以下のようなWebシステムを考えてみましょう。
Internet
│
↓
ALB
│
↓
Application Server
│
↓
RDS
この場合、それぞれの通信をSecurity Groupで制御できます。
例えば、
ALB-SG
↓
TCP 443
Internetから許可
App-SG
↓
TCP 8080
ALB-SGから許可
DB-SG
↓
TCP 3306
App-SGから許可
という構成です。
イメージすると、
Internet
│
│ HTTPS 443
↓
ALB
│
│ TCP 8080
↓
App
│
│ TCP 3306
↓
RDS
となります。
このようにSecurity Groupを利用することで、
必要な通信だけを許可する
という構成を作ることができます。
▪️Security GroupはIPアドレスだけでなくSecurity Groupを指定できる
AWSのSecurity Groupには、もう一つ便利な特徴があります。
通信元として、別のSecurity Groupを指定することができます。
例えば、
App-SG
が付いているEC2から、
DB-SG
が付いているRDSへ通信させたいとします。
この場合、DB側のInboundルールで、
TCP 3306
Source: App-SG
のように設定できます。
つまり、
App-SGが付いているリソースからのMySQL通信だけを許可する
という考え方ができます。
これによって、IPアドレスを個別に指定するよりも、構成を柔軟に管理できます。
▪️Security GroupとNACLの違い
AWSのネットワークセキュリティでは、Security Groupだけでなく**Network ACL（NACL）**も登場します。
両者は似ていますが、役割が異なります。
| 項目 | Security Group | Network ACL |
|---|---|---|
| 主な対象 | ENIなどのリソース | Subnet |
| Stateful | ○ | × |
| Allow | ○ | ○ |
| Deny | × | ○ |
| ルールの考え方 | 許可する通信を設定 | 許可・拒否をルール化 |
簡単に考えると、
Security Group
→ リソース単位の通信制御
NACL
→ Subnet単位の通信制御
です。
NACLについては、今後AWSのネットワークをさらに学ぶときに詳しく解説します。
▪️Security Groupを設定するときの考え方
Security Groupを設定するときは、
必要な通信だけを許可する
という考え方が重要です。
例えば、
SSH
TCP 22
Source: 0.0.0.0/0
とすると、インターネット上のどこからでもSSH接続を試行できる状態になります。
必要がなければ、より限定した送信元を設定します。
例えば、
TCP 22
Source: 自分のグローバルIP/32
などです。
また、Webサーバーの場合は、
TCP 443
Source: 0.0.0.0/0
のように、インターネットからのHTTPSアクセスを許可することがあります。
このように、サービスの用途に応じて必要な通信だけを開けることが重要です。
▪️通信できないときはSecurity Groupを確認する
AWSでEC2などに接続できない場合、Security Groupは確認すべき重要なポイントの一つです。
例えば、
ブラウザ
↓
EC2
へHTTPS接続できない場合、
① Route Table
② Internet Gateway
③ Public IP
④ Security Group
⑤ Network ACL
⑥ EC2上のアプリケーション
などを確認します。
Security Groupだけを確認して終わりではなく、通信経路全体を見ることが重要です。
これはAWSのトラブルシューティングでも非常に大切な考え方です。
▪️まとめ
今回はSecurity Groupについて解説しました。
Security Groupは、
AWSのリソースに対する通信を制御する仮想ファイアウォール
です。
通信を、
Inbound
外 → リソース
Outbound
リソース → 外
という方向から考え、必要な通信を許可します。
例えばWebサーバーなら、
TCP 443
を許可することでHTTPS通信を受け付けられます。
また、Security Groupには、
- Statefulである
- 基本的に許可ルールを設定する
- 明示的なDenyルールは設定できない
- 複数のリソースに関連付けられる
- 通信元として別のSecurity Groupを指定できる
といった特徴があります。
これまで学んできたAWSネットワークと合わせると、
VPC
↓
Subnet
↓
Route Table
↓
Internet Gateway / NAT Gateway
↓
Security Group
↓
EC2などのリソース
という形で、それぞれの役割がつながってきます。
AWSのネットワークでは、
「どこを通るのか」
をRoute Tableなどで決め、
「その通信を許可するのか」
をSecurity Groupなどで制御します。
この2つを分けて考えることが、AWSネットワークを理解するうえで重要です。
次回は、Security Groupとセットで覚えておきたい**Network ACL（NACL）**について解説します。
次の記事では「ネットワークACL」について解説します。
＊「ネットワークACL」の記事はこちら
→「https://lovelabengineer.com/2026/10/08/awsのネットワークacl（nacl）とは？サブネット単位で通/」
No responses yet