物理・仮想サーバをそのままAWSへ — MGNによるリホスト移行の実際

アプリに手を入れずOSごと引っ越す「リホスト」は、期限のある移行の主力手段です。AWSでの道具は実質2つ、AWS Transform MGN（旧称：AWS Application Migration Service、MGN）とVM Import。使い分けと、MGNの実際の流れ、そして「MGNで運んではいけないサーバ」を整理します。

01道具は2つ：MGNとVM Import

• MGN — サーバにエージェントを入れ、稼働したままブロックレベルで継続レプリケーション。切替直前まで同期が続くので停止時間を分単位にできる。物理・仮想どちらも対象
• VM Import/Export — 仮想マシンのイメージ（OVA等）を変換して持ち込むオフライン方式。停止時間は長いが、エージェントを入れられない事情があるときの代替

迷ったらMGNです。継続レプリケーションとテスト起動の仕組みが、移行の失敗リスクを構造的に減らしてくれます。

02MGN移行の流れ

• ① 対象サーバにエージェント導入（稼働への影響は軽微）
• ② 初回フルレプリケーション→以後は差分が流れ続ける
• ③ テスト起動 — 本番を止めずにAWS側でコピーを起動し、動作確認。何度でもやり直せる
• ④ カットオーバー — 業務を短時間止めて最終同期→AWS側を本番に昇格
• ⑤ 問題があれば切り戻し（オンプレ側は残っている）

03MGNで運んではいけないサーバ

• ドメインコントローラ — 複製で運ぶと事故のもと。AWS側で新規にDCを昇格させ、ADの複製機能で同期するのが推奨されることが多い
• データベース — 動きはしますが、ネイティブ手段（ダンプ／レプリケーション／移行ツール）の方が整合性の検証がしやすく、RDS化の好機でもある
• 共有ディスク型のクラスタ — 共有ディスク前提のHA構成はそのまま持ち込めない。AWS流の冗長化（Multi-AZ）に設計し直す

04事前に潰しておくポイント

• OSがMGNのサポート対象か（特に古いWindows／Linuxは要確認）
• 固定IP・ホスト名をハードコードしたアプリの洗い出し（Windows移行の落とし穴も参照）
• Windowsのライセンス認証経路の切り替え
• レプリケーション用の帯域——対象本数×データ変更量で見積もり、業務帯域を圧迫しない設計に

05リホストは「終わり」ではなく「始まり」

リホストで移したサーバは、オンプレの設計をまとった仮住まいです。移行後の最適化（インスタンスの世代・サイズ適正化、EBS見直し、マネージドサービスへの置き換え）を半年以内に回す前提で計画してください。「移して終わり」の環境は、オンプレより高いクラウドになりがちです。