はじめに

今日は、AWS 上に 電子カルテアプリを載せるための Windows Server を再構築する作業 を行いました。

元となるサーバはすでに別用途で構築済みで、それを AMIコピーして流用する ところからスタート。
ただ、コピーしただけではアプリや設定が残ってしまうため、

「クリーンで、SSM だけで完全管理できる Windows Server テンプレート」

を作ることを目的に作業しました。

この記事では、その再構築の流れを記録としてまとめます。

---

■ 1. AMI コピーからの新規 EC2 起動

まず、既存サーバの AMI をもとに新しいインスタンスを起動しました。

• インスタンスタイプ：t2.medium
• セキュリティグループ：インバウンドなし（後でRDP削除）
• キーペア：既存のものを流用
• IAM ロール：Systems Manager が動作するロールを再割り当て

これにより、元サーバと同じ構成をもったインスタンス が立ち上がります。

---

■ 2. コピー元アプリ（RSBASE など）の完全削除

AMI コピー元には、もともとテスト用途のアプリが入っていたため、
新しいサーバではこれをすべて削除し、電子カルテ用サーバとしてクリーンにしました。

• RSBASE のアンインストール
• 対応フォルダの削除
• 残存レジストリの確認（不要なものをクリア）

この時点で、

“アプリが何も入っていない、空の Windows Server”

の状態に戻りました。

---

■ 3. ディスク構成の整理（Cドライブ + Dドライブ）

コピーされたサーバは C:80GB / E:20GB の構成でしたが、
内容を削除したため E ドライブをフォーマットし、新しい D ドライブとして再構成。

結果：

• Cドライブ：80GB
• Dドライブ：20GB（アプリやログ用に利用）

※Cドライブは80GBより縮小できないため、今回は現状維持。

ここは将来的に「スリム版テンプレート」を作るときに再検討します。

---

■ 4. Session Manager（SSM）が動作しない問題の修復

AMI コピー直後は SSM Agent がオフライン になっており、
Session Manager で接続できない状態でした。

PowerShell で確認すると amazon-ssm-agent.exe がうまく動いていない。

そこで以下の対処を実施：

1. TLS 1.2 の有効化
2. 正式 URL から SSM Agent を再インストール
3. サービス再起動
4. IAM ロールの再割り当て確認

再インストールコマンド例：

$installer = "$env:TEMP\AmazonSSMAgentSetup.exe"
Invoke-WebRequest "https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/latest/windows_amd64/AmazonSSMAgentSetup.exe" -OutFile $installer
Start-Process $installer -ArgumentList "/S" -Wait
Restart-Service AmazonSSMAgent

これで SSM がオンラインに復帰。
Session Manager 接続が無事成功しました。

---

■ 5. RDP ポートを完全に閉じる（インバウンド0）

SSM が動作した時点で、RDP は管理上不要となったため、
セキュリティグループの 3389 を削除。

結果：

• インバウンド完全ゼロ
• Session Manager のみで管理
• 医療機関でも安心して使えるセキュア構成

AWS が推奨する「RDP を開けない運用」が実現しました。

---

■ 6. Session Manager での RDP（ポートフォワード）も同時検証

必要に応じて RDP を使う場合は、
Session Manager の ポートフォワード で利用できることも確認。

例：

aws ssm start-session \
  --target i-xxxxxxx \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["3389"],"localPortNumber":["23389"]}'

これにより、

• EC2 → 3389
• ローカル → 23389

のトンネルが張られ、
localhost:23389 を RDP クライアントに入力すると GUI ログインが可能。

重要なのは、

AWS側の設定変更は不要で、ローカルポートを変えるだけで複数サーバへ同時接続できる

という点。

---

■ 7. 電カル用の “初期 Windows Server AMI” を最終作成

すべての不要要素を削ぎ落とし、SSMの動作も安定したタイミングで、

• Windows Update 済み
• インバウンド0
• SSMのみで管理可能
• 余計なアプリなし
• ディスク整理済み

という 理想的な“初期テンプレート” の状態が完成。

この状態を改めて AMI 化し、今後
電子カルテサーバの標準構築テンプレート
として利用できるようにしました。

---

■ まとめ

今回の作業で、

「爽快なまでに真っさらな Windows Server」
「SSMのみで完全管理できるセキュア構成」
「即量産できる初期AMI」

の3つが完成しました。

電子カルテ、医療アプリ、オンプレ連携など、
どんな用途にも適用できる理想的なベースサーバが手に入りました。

今後は、このテンプレートを軸に構築を加速していきます。