はじめに
こんにちは、山本です。
今回は、AWS Systems Manager Fleet ManagerでWindows OSにリモートデスクトップして作業する中でセッションに関する検証を行ったので当記事で紹介します。
Fleet Managerでは顧客環境などのサーバーに対してインバウンドセキュリティグループの穴あけをせず、アウトバウンドセキュリティグループの通信を許可するだけでリモートデスクトップを行える便利でセキュアな機能を携えています。
しかし、リモートデスクトップで作業を行った後、きちんとした手順で通信を切断しなければ作業対象のOS内に無駄なセッションを残存させてしまう可能性があります。
当記事では、セッションが残ってしまう切断パターンとそれによって起こる弊害について紹介します。
検証環境
今回検証で使用した環境は以下のとおりです。
- EC2 Windows Server 2022（Systems Manager 管理ノード）
検証手順
事前準備
- Fleet Manager Remote Desktop で対象 Windows にサインイン。
- コマンドプロンプトで以下を実行し、結果を控える（エビデンス添付）
whoami quser
- quser の ID と STATE=Active を確認
各パターンにおけるセッション切断後の確認
Systems Manager → Run Command → AWS-RunPowerShellScript で、対象インスタンスに下記を実行し、直後の状態を採取（エビデンス添付）。
quser
Logoff なら quser の当該セッション行は消失。
Disconnect なら quser の当該セッションは STATE=Disc で残存し、セッション自体も残存している状態となる。
※Disconnectはネットワーク上の接続のみを終えている状態なのでOS上にセッション情報は残るという仕組みです。
検証内容＆結果
検証1：Ctrl+Alt+Del → サインアウト（Windows 側での明示的サインアウト）
Fleet Manager RDPでサインインした際のセッション情報
cmdでquserコマンドを使用して表示する Fleet Manager 上で「アクション」クリック後「Ctrl + Alt + Delの送信」をクリック
Ctrl + Alt + Delの送信 Windows上の画面で「sign out」をクリックしサインアウトする
sign outを選択 サインアウト後のセッション状態の確認画面（Run Command）
outputが存在しないのでセッションは残存していない
検証2：Fleet Manager の ［接続を停止（End session）］
Fleet Manager RDPでサインインした際のセッション情報
cmdでquserコマンドを使用して表示する Fleet Manager 上で「アクション」クリック後「接続を終了」をクリック
コンソール上から操作する 「接続を終了」をクリック
確認画面が表示されるのでそのまま進む サインアウト後のセッション状態の確認画面（Run Command）
最初に確認したセッションIDと同じものが表示され、Discと示されている
検証3：Fleet Manager ウィンドウ自体の “×” を押して閉じる
Fleet Manager RDPでサインインした際のセッション情報
cmdでquserコマンドを使用して表示する Fleet Manager ウィンドウ自体を閉じる
Chrome上のタブごと削除する ウィンドウ削除後のセッション状態の確認画面（Run Command）
最初に確認したセッションIDと同じものが表示され、Discと示されている
検証4：コマンドからサインアウト
Fleet Manager RDPでサインインした際のセッション情報
cmdでquserコマンドを使用して表示する cmdにてコマンド入力＆実行
shutdown /lを入力するセッション状態の確認画面（Run Command）
検証結果一覧
| 項番 | 操作 | quser コマンド結果 |
|---|---|---|
| 1 | Ctrl+Alt+Del → サインアウト | 該当行無し |
| 2 | Fleet Manager の ［接続を停止（End session）］ | Disconnect |
| 3 | Fleet Manager ウィンドウ自体の “×” を押して閉じる | Disconnect |
| 4 | コマンドからサインアウト | 該当行無し |
セッション残存が起こす弊害について
セッション残存という現象は、ユーザが次回サインインすること自体には直接影響しませんが、以下のように、実務で困ってしまう場面にしばしば出くわします。
- 作業完了後もプロセスやファイルロックが残る（バッチ・スクリプト・エディタのロック等）
- 同時セッション数によるライセンスの圧迫
- 監査的な説明が困難(保守事業者が意図している切断なのかどうか判断がつきづらい)
- Disconnect操作では画面はロックされるものの、セッションは稼働中なので意図しないジョブ継続等が発生する可能性がある
上記のような問題発生により、運用のしやすさを低減させてしまうことがあります。
したがって、運用設計のフェーズでは顧客環境などのサーバーで作業する場合のサインアウト手順を定義しておく必要があります。
一貫したサインアウト手順を事前に用意しておくことでセッション残存におけるファイルロックやライセンスの圧迫などを未然に防ぎ、運用効率を上げることができるのでないでしょうか。
おわりに
今回は、Fleet Manager上でのリモートデスクトップ作業におけるセッション残存の弊害について触れてきました。
個人的には、前職でも同じようなセッションにおける問題に出くわしたことがあった(サインインにおけるセッションではなくファイルへのアクセスにおけるセッションでしたが)ので、どうしてそうなっていたのか今回の検証で深く理解できた気がします。
サインイン＆サインアウトに関するセッションはもちろん、共有ファイルにおけるセッションの重複に関するエラーなども実務ではよく起こるのではないかと思います。 ファイルロックや共有ファイルのセッション問題も原理は同じなので、この記事を読むことによって同じような問題に直面している方への手助けになれれば幸いです。
山本 竜也 (記事一覧)
2025年度新入社員です！AWSについてはほぼ未経験なのでたくさんアウトプットできるよう頑張ります✨
