WindowsサーバのAWS移行、7つの落とし穴

Linuxサーバの移行が淡々と終わる一方で、Windowsサーバの移行はドメイン・ライセンス・共有フォルダといった「Windowsの生態系」ごと動かすことになり、想定外が出やすい領域です。現場で実際に踏んできた落とし穴を7つ、対策とセットで並べます。

01落とし穴①〜③：ドメインとネットワークの前提

• ① ドメインコントローラをイメージ複製で運ぶ — AD破損の定番コース。AWS側で新規DCを昇格して複製するか、AWS Managed Microsoft ADへの移行を検討（MGNの記事参照）
• ② 固定IP・ホスト名のハードコード — 設定ファイルやレジストリにIP直書きのアプリは移行後に沈黙します。事前の洗い出しと、DNS名参照への置き換えを
• ③ DNS参照先の切り替え漏れ — 移行後のサーバがオンプレDNSを見続けて名前解決が遅い／失敗する。DHCPオプションセットとRoute 53 Resolverの設計を先に

02落とし穴④〜⑤：ライセンスと時刻

• ④ Windowsライセンス認証 — AWS提供AMIから起動したものはAWS側の仕組みで認証されますが、持ち込みイメージは認証経路の設定が必要。BYOLには専有ホスト等の条件も絡むため、ライセンス方針は移行前に確定を
• ⑤ 時刻同期のズレ — オンプレNTPを見続ける設定のままだと、回線断でKerberos認証が壊れます。Amazon Time Sync Service（169.254.169.123）への切り替えが定石

03落とし穴⑥：ファイル共有とプリンタの経路

サーバは移ったのに共有フォルダの参照だけオンプレに残り、拠点⇔AWS間をファイルI/Oが往復して「全部が遅い」——移行後によくある構図です。ファイルサーバの移行（FSxの記事）をサーバ移行と同じ計画に含め、参照経路を揃えてください。プリントサーバや複合機のスキャン連携も同様に忘れがちです。

04落とし穴⑦：EOL間近のOSを「そのまま」運ぶ

サポート終了が近い（または過ぎた）Windows Serverは、持ち込めたとしてもセキュリティ更新の問題が残り続けます。移行はOS更改の絶好の機会なので、「そのまま運ぶ延命」と「この機に上げる」をサーバごとに明示的に判断してください。判断を先送りしたサーバの一覧は、そのまま将来のリスク台帳になります。

05チェックリストとして使う

この7つ（DC複製・IP直書き・DNS・ライセンス・時刻・共有経路・EOL）は、移行計画のレビュー観点としてそのまま使えます。MGNのテスト起動時の確認シナリオにも、この7項目を必ず含めてください。