SSM Session ManagerのRDPセッション記録中にOSを再起動や停止をしても正常に録画データが処理されるのか確認してみた
2025.05.01EC2インスタンスを停止しても途中までのRDPセッションの記録はされるのか気になる
こんにちは、のんピ(@non____97)です。
皆さんはSSM Session ManagerのRDPセッションの記録機能を使っていて、EC2インスタンスを停止しても途中までのRDPセッションの記録はされるのか気になったことはありますか? 私はあります。
2025/4/30にジャストインタイムノードアクセス機能とともに、RDPセッションの記録機能が追加されました。
これによってRDP接続中にどんな操作をしたのか簡単に確認することが可能になります。監査にも使えそうですね。
ここで疑問に思うのが、EC2インスタンスを停止した場合の挙動です。
SSM Session ManagerのセッションログはCloudWatch Logsへストリーミング出力する場合を除いて、途中でEC2インスタンスが停止すると(正しくはssm-agent-workerが正常に停止しなければ)ログ出力がされません。詳細な挙動は以下記事をご覧ください。
では、RDPセッションの記録機能はどうでしょうか。
気になったので実際に確認してみます。
いきなりまとめ
- SSM Session ManagerのRDPセッション記録中にOSを再起動や停止をしても正常に処理される
- RDPセッションの録画はEC2インスタンス側で行なっているのではなく、SSMのサービスとして行われている
- RDPセッションの録画はスタンダードセッションでも行われる
- ジャスタインタイムノードアクセスによる接続 = ジャストインタイムセッションかどうかは関係ない
やってみた
OS再起動
まずはOSを再起動する場合です。
ジャスタインタイムノードアクセスではなく、StartSessionの権限を持った状態でアクセスします。つまりはスタンダードセッションという事です。
レコーディングされているかどうか確認したところ、レコーディングされていました。RDPセッションの記録はジャスタインタイムノードアクセスによる接続 = ジャストインタイムセッションかどうかは関係ないようですね。これは嬉しい。
それでは、RDPセッション上からOSを再起動します。
すると、接続履歴タブで該当セッションのレコーディングステータスが処理中になっていることを確認できました。これは期待大です。
しばらくすると、処理が完了しました。
出力されたmp4のオブジェクトをダウンロードし、確認すると再起動の過程でシャットダウンする瞬間まで記録されていました。これは最高です。
OSシャットダウン
OSシャットダウンの場合も試します。
RDPセッション上からOSをシャットダウンします。
シャットダウン後のセッション履歴を確認すると、こちらもレコーディングステータスが完了となり、mp4のオブジェクトが出力されていました。
ダウンロードして内容確認すると、こちらもシャットダウンする瞬間まで記録されています。最高ですね。
EC2インスタンス再起動
EC2のコンソールからも試しましょう。
まずは再起動です。
EC2のコンソールから対象インスタンスの再起動を実行しました。その後、SSMのセッション履歴を確認すると、レコーディングステータスが完了となり、mp4のオブジェクトが出力されていました。
録画されている内容を確認すると、再起動の過程でシャットダウンする瞬間の様子が記録されていました。
EC2インスタンス停止
EC2インスタンスの停止も試します。
EC2のコンソールから対象インスタンスの停止を実行しました。その後、SSMのセッション履歴を確認すると、レコーディングステータスが完了となり、mp4のオブジェクトが出力されていました。
録画されている内容を確認すると、シャットダウンする瞬間の様子が記録されていました。
考えられること
EC2インスタンスが停止される瞬間まで記録されているとなると、SSM Agentは関係なさそうですね。
となると、Fleet Manager側で記録しており、それをS3にPUTしている事になりそうです。
AWS公式ドキュメント上で録画データの取り扱いについて言及しているのは以下程度でした。
The KMS key is used to temporarily encrypt the recording data while it's generated and stored on Systems Manager resources.
ここで言うSystems Manager resourcesというのがポイントだと思います。今までの検証からこちらはEC2ではなく、Systems Managerの裏側で動作しているリソースと推測しています。
加えて、EC2インスタンスにアタッチしているIAMロールには指定したKMSキーについて暗号化/復号を行う権限は付与していません。つまりはここでは暗号化はしていない事になります。
また、ドキュメントに記載のS3バケットに設定するバケットポリシーを確認すると、プリンシパルがssm-guiconnect.amazonaws.comと言うサービスになっていました。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ConnectionRecording",
"Effect": "Allow",
"Principal": {
"Service": [
"ssm-guiconnect.amazonaws.com"
]
},
"Action": "s3:PutObject",
"Resource": [
"arn:aws:s3:::bucket name",
"arn:aws:s3:::bucket name/*"
],
"Condition":{
"StringEquals":{
"aws:SourceAccount":"123456789012"
}
}
}
]
}
やはり、RDPセッションの録画はEC2インスタンス側で行なっているのではなく、SSMのサービスとして行なっている事になりそうですね。
RDPセッションを切ってからOSを停止する運用はしなくても良い
SSM Session ManagerのRDPセッション記録中にOSを再起動や停止をしても正常に録画データが処理されるのか確認してみました。
結論、大丈夫です。
RDPセッションを切ってからOSを停止する運用はしなくても良いですね。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
![[アップデート] Amazon Q Developer in chat applications がジャストインタイムノードアクセス機能の承認/却下をサポートしました](https://images.ctfassets.net/ct0aopd36mqt/1dD7b8HkT2sbiJzUIewMTD/e5cdc6f33c4fdd9d798f11a4564612ff/eyecatch_developersio_darktone_1200x630.jpg)
