はじめに

今回はあまりWindowsサーバに詳しくなかった私が嵌ったことについて、備忘を兼ねて共有したいと思います。
簡単に言うと、EC2でWindowsサーバを利用する際に設定は問題ないはずなのにSSMのFleet Managerに出てこない！（またはSession Managerで接続できない！）という時は、Windowsサーバに設定されているルート情報を疑ってみてはどうでしょう、というお話です。

目次

結論
 発生した事象
 環境情報
 原因
 解決方法
 注意点
 まとめ

結論

まずは事象説明等の前に結論から記載します。

1. 基本的に複製用途のEC2 WindowsサーバのAMIを取得する場合は、Sysprepを行ってAMIを標準化する必要がある

SysprepはSIDだけでなく、Windowsサーバに設定されているルート情報についても初期化してくれます
複製する場合はSysprepを行わないと、SID等の固有の値が更新されないだけでなく、Windowsサーバに設定されている古いルート情報を読み込んで、AWSメタデータ等に正常にアクセスできなくなります

2. バックアップ用途のEC2 WindowsサーバをAMI取得時と異なるサブネットで復旧する場合は、ルート情報の更新を行う必要がある（※参考に記載の内容）

複製目的でなく、バックアップ目的でEC2 WindowsサーバのカスタムAMIを取得する場合Sysprepを行わないことが推奨されます
Sysprepを行わないということは、1に記載した通り古いルート情報が残っているため、取得時と異なるサブネットで復旧すると、Windowsサーバに設定されている古いルート情報を読み込んで、AWSメタデータ等に正常にアクセスできなくなります

発生した事象

パブリックサブネット(ap-northeast-1a)にAWS提供AMIから起動したEC2(Windows2019)に必要な設定を入れて起動し、AMIを取得する
※上記サブネットに作成したEC2(Windows2019)はSystems ManagerによるRDPが可能
取得したAMIからプライベートサブネット(ap-northeast-1a)に複製する
複製したEC2にSystems ManagerにてRDPをで行おうとしたが、マネージドノードに表示されなかった
※ネットワーク関連の設定不足かと考え、パブリックサブネット(ap-northeast-1c)でも複製したが、同じようにマネージドノードに表示されなかった
ネットワーク経路(VPCエンドポイント・RTなど)やIAMロール・SG・SSM Agentのインストールなどには問題がなく、原因に見当がつかなかった
AWSSupport-TroubleshootManagedInstanceというAWS提供のSSMトラブルシュートツールでも問題なしと結果が出た
過去にUbuntuやLinuxでSession Managerを利用した際は上記までの設定で接続できたため、Windowsサーバが原因かもしれないと判断

環境情報

EC2：Windows Server 2019 Base
SSM Agent：3.1.1634.0
VPCエンドポイント：ssm・ssmmessages・ec2messages

原因

Windowsサーバにパブリックサブネット(ap-northeast-1a)のルート情報が保持されていたため、ルート情報が異なる他のサブネットに複製するとAWSメタデータにアクセスできなくなることが原因でした。
→そのためSSM経由のRDPやSession Managerに限らず、AWSメタデータを利用する場合はうまくいかなくなると思います。

解決方法

sysprepで標準化したAMIで異なるサブネットに複製する

sysprepで標準化したAMIの取得手順

AWS提供AMIからEC2（Windowsサーバ）を起動する
　
起動したEC2にRDPなどで接続する
　
必要な設定等を入れてから、「スタートメニュー」→「EC2 Launch Settings」を選択する

　
4. Shutdown with Sysprepを押下する
※「Administrator Password」で「Specify」や「Do Nothing」を選択すると、マネジメントコンソールからパスワードの参照をしようとしても、パスワードの参照ができなくなりますのでご注意ください

　
5. Sysprep Confirmationのポップアップ画面で「Yes」を選択する

　
6. Sysprep is working ...のポップアップが表示され、数分でシャットダウンされる

　
7. EC2が「停止済み」になったらAMIを取得する

※参考

SSM以外の経路でEC2にアクセスできる場合は、下記のコマンドを入力することでもAWSメタデータへのアクセスができるようになります。
ただし、こちらに関してはAMIを標準化するわけではなく、コマンドを入力したインスタンスのルート情報を正しいものに上書きするだけです。
そのため、バックアップ目的のAMIを元となったEC2と異なるサブネットで復旧する際などには、Sysprepではなくこちらが使えるかと思います。

Import-Module c:\ProgramData\Amazon\EC2-Windows\Launch\Module\Ec2Launch.psm1 ; Add-Routes

注意点

Sysprep を使用してインスタンスのバックアップを作成しないこと
Sysprep はシステム固有の情報を削除するため、インスタンスバックアップで意図しない結果が生じる可能性があります

まとめ

今回の件はWindowsサーバを触る機会がほとんどなかったため、SysprepのようなWindows独自のサービスに思い当たらず調査に時間を要してしまいました。
一見関係なさそうなもの（AWSのSystems ManagerとWindowsサーバのSysprepなど）でもどこに問題があるかはわからないので、固定観念に縛られずに問題の原因を絞り込むということが重要だと改めて思いました。