はじめに
Amazon EventBridge から Systems Manager（SSM）の Run Command を自動実行する仕組みを実装しました。
EC2 上の SSM Agent は、インターネットを経由せず VPC エンドポイント経由で SSM に通信する構成です。
ある日、ふと Session Manager を試したところ、AWSコンソール上から EC2 にログインできてしまったことに気づきました。
正直、想定外だったため少しヒヤッとしました。
最初は設定ミスを疑いましたが、調べてみると、EC2（SSM Agent） と SSM がどう通信しているかを理解していなかっただけで、仕様上予想される結果であることが分かりました。
この記事では、同じところでモヤっとしそうな人向けに、以下を整理します。
- Run Command を設定すると Session Manager も成立する理由
- SSM が EC2 とどう通信しているか（なぜ EC2 のインバウンド通信不要なのか）
- IAM 権限での安全な制御方法
この記事を読んでほしい人
- Run Command を自動実行している、または検討している人
- VPC エンドポイントやセキュリティグループで「SSMを安全に利用しているつもり」の人
- Run Command / Session Manager が「EC2へのインバウンド接続不要」と聞いたことはあるが仕組みを理解していない人
実際の構成と起こった事象
構成概要
- EventBridge スケジューラー → Run Command 実行
- EC2 に SSM Agent インストール済み
- EC2 のインバウンド通信は 拒否
- アウトバウンドは VPC エンドポイント向けHTTPSのみ許可
VPCエンドポイントサービス（使用するもの）
com.amazonaws.ap-northeast-1.ssmmessagescom.amazonaws.ap-northeast-1.ssm-
com.amazonaws.ap-northeast-1.ec2messages（Agent 3.3.40.0 以降は必須ではない）
セキュリティグループ設定（簡略化）
VPCエンドポイントのSG
- インバウンド：EC2 SG からのHTTPS通信を許可
- アウトバウンド：なし
EC2のSG
- アウトバウンド：SSMエンドポイント SG へのHTTPS通信を許可
- インバウンド：なし
起こった事象
この状態で Run Command は問題なく動作しましたが、意図せず Session Manager でのログインも可能になっていました。
Session Manager は非常に便利ですが、 OSアカウント単位の厳密なアクセス制御や、操作ログの統制が必要な環境では、 設計方針として利用を制限・禁止する判断が適切です。
なぜ Session Manager でもログインできてしまったのか
理由はシンプルです。
Run Command / Session Manager は同じ通信経路・SSM Agentを使っているためです。
すなわち、 Run Command が動作する条件を満たしたことで、
同時に Session Manager が成立する前提条件も満たしていたということです。
SSMはどうやってEC2と通信しているのか
ここがこの記事の一番のポイントです。
SSM から EC2 に接続しているように見えますが、実際には EC2 上の SSM Agent が SSM に通信しています。
- EC2（SSM Agent） → SSM API にアウトバウンド通信
- 自分宛ての Run Command / Session を確認（ポーリング） ※ポーリング間隔は2025/12現在非公開
- 指定されたコマンドやセッションがあれば実行
通信経路はVPCエンドポイントでもインターネット経由でも変わりません。
重要なのは EC2 から SSM へのアウトバウンド通信が許可されているか です。
制御ポイントはネットワークではなく IAM
EC2 のインバウンド通信を閉じても、SSMの利用可否は制御できません。
SSM の制御ポイントは IAM 権限 です。
今回の事象では以下が揃っていました。
| ロール | 機能 | 許可するアクション | 可能になること |
|---|---|---|---|
| EC2 用ロール① | - |
ssm:UpdateInstanceInformation, ec2messages:GetMessages, ec2messages:SendReply
|
EC2 が SSM と通信・ポーリングしてコマンドを受信 |
| EventBridge 実行用ロール② | Run Command | ssm:SendCommand |
EC2 にコマンドを実行させる |
| マネジメントコンソール操作用ロール③ | Session Manager | ssm:StartSession |
ユーザーが Session Manager で接続可能 |
この状態では、Session Manager が使えるのは仕様通りとなります。
上記の通り、EC2 にアタッチされたロールで SSM との接続が成立しており、さらにマネジメントコンソール用ロールに Session Manager 権限が付与されていたため、意図せず Session Manager も使える状態になっていたことが分かります。
安全に制御するポイント
今回の経験から、SSM で Run Command を利用する際に意識すべきポイントは以下の通りです。
1.ロールの分離
各ロールに対し、役割ごとに必要最小限の IAM 権限を付与することで、意図しない操作を防止しましょう。
2. 明示的な Deny の設定
IAMロールに明示的なDenyを付与し、意図せぬ動作を防ぎましょう。
例えば今回の場合、マネジメントコンソール操作用ロールにて、「ssm:StartSession」権限を明示的に拒否すれば、Session Manager の利用を防ぐことができます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"ssm:StartSession"
],
"Resource": "*"
}
]
}
補足： SSM の機能は強力であることを認識する
・Run Command → Linux の場合は root 権限でコマンドを実行可能
・Session Manager → EC2 に端末操作可能、必要に応じ sudo 取得可
まとめ
- Run Command / Session Manager は同じ通信経路・SSM Agent を使って動作している
- SSM は「接続している」のではなく SSM Agent が SSM にポーリングしている ため、EC2 のインバウンド通信は不要
- 制御ポイントはネットワークではなく IAM 設計 である
SSM を使った自動化は非常に便利ですが、 意図しない操作経路が成立していないか、一度確認してみると安心です。