AWS Application Migration Service（MGN）入門｜オンプレサーバーをリホストでAWSへ移行するリフト&シフト実践ガイド

オンプレミスのサーバーをAWSへ移行する話になると、「どのサービスを使えばいいのか」「サービスを止めずに移行できるのか」という疑問が必ず出てきます。ファイルサーバーやアプリサーバーを週末に停止してRsyncで同期する——そういった手作業の移行を経験したエンジニアほど、クラウドへの一括移行の難しさを実感しているはずです。

その課題を解決するのがAWS Application Migration Service（MGN）です。旧サービス「AWS Server Migration Service（SMS）」の後継として2021年にGAし、現在AWSが推奨する標準のリフト&シフト移行ツールです。本記事では、MGNの仕組みからセットアップ手順・料金・移行時のハマりポイントまでを、オンプレ経験者の視点で解説します。

AWS MGNとは——ブロックレベルレプリケーションで最小ダウンタイム移行を実現

AWS Application Migration Service（MGN）は、ソースサーバーのディスクをブロックレベルでリアルタイムにAWSへ複製し、準備が整ったタイミングでカットオーバーする移行サービスです。「アプリケーション移行サービス」という名称ですが、OSごとサーバー単位で丸ごとAWSへ持っていくサービスです。

主な特徴は次のとおりです。

・エージェントベース: ソースサーバーにAWS Replication Agentをインストールして動作します
・継続的ブロックレプリケーション: 初期同期後は差分のみをレプリケーションするため、帯域幅の消費を抑えられます
・最小ダウンタイム: カットオーバー直前まで本番環境を動かし続けられるため、サービス停止時間を数分～数十分に抑えられます
・幅広いOS対応: Linux（カーネル2.6.25以降）・Windows Server 2003以降をサポートします
・物理・仮想どちらもOK: VMware、Hyper-V、KVM、物理サーバー、他クラウドからの移行も対象です

週末停止での手動移行と決定的に違うのは、「本番に近い状態をAWS側で常に保持し続ける」点です。カットオーバーは最終同期（通常数分）を経て実行するため、切り替え直前まで本番の変更がAWSに反映され続けます。

SMS（旧サービス）との違い・DRSとの使い分け

MGNを理解するうえで、混同しやすい2つのサービスとの違いを押さえておきましょう。

SMSはVMwareやHyper-Vのエクスポートイメージを定期的にS3へ転送するスナップショット型でした。一方MGNはブロックレプリケーション型のため、差分をより細かく追跡し続けられます。カットオーバー時に失われるデータ量が格段に少ないのが大きな改善点です。

AWS Elastic Disaster Recovery（DRS）はMGNと同じレプリケーション基盤を使いますが、用途が「移行」ではなく「継続的なDR」です。本番環境が障害を起こしたときにAWSへフェイルオーバーするための仕組みで、移行後も常時レプリケーションを続けます。一度きりのクラウド移行にはMGN、DR戦略を組み込みたいならDRSという使い分けです。

MGNのアーキテクチャ全体像

MGNによる移行は、主に4つのコンポーネントで成り立っています。

・ソースサーバー（オンプレ）: 移行対象のサーバー。AWS Replication Agentをインストールします
・Replication Server（ステージングエリア）: AWSが自動的にプロビジョニングするt3.small相当のEC2インスタンス。ソースのブロックデータを受け取り、低コストなEBSに保存します
・ステージングEBS: ソースサーバーのディスクのレプリカを保管する領域。移行完了前の一時保管場所であり、専用のサブネットに配置することが推奨されます
・ターゲットEC2インスタンス: テストまたはカットオーバー時にMGNが起動するEC2。インスタンスタイプや設定はLaunch Settingsで事前に定義します

ソースサーバーはAWSへのポート443（HTTPS）アウトバウンド接続さえあれば動作します。AWS Direct ConnectやSite-to-Site VPNが引かれている環境ではそのまま使え、インターネット経由でも問題ありません。

移行の前提条件と準備

1. IAMロールの準備

MGNを利用するには、以下のIAMロール・ポリシーが必要です。

・AWSApplicationMigrationAgentRole: Replication Agentがソースサーバーから呼び出すロール。AWSマネージドポリシーが用意されています
・AWSApplicationMigrationEC2Access: MGNがEC2リソースを操作するためのサービスロール
・AWSApplicationMigrationFullAccess: 運用担当のIAMユーザー・ロールに付与する管理権限

AWSコンソールでApplication Migration Serviceを最初に開くと、サービスロールの自動作成が案内されます。初回セットアップではこれに従うのが最も簡単です。

2. ステージングエリア用のVPCとサブネット

MGNのReplication Serverが配置されるステージングエリア用のサブネットを事前に設計しておきます。推奨構成は次のとおりです。

・専用のプライベートサブネット（例: 172.31.200.0/24）にステージングを配置
・ソースサーバーからの通信はTCP 443のアウトバウンドのみ必要
・ステージングエリアとターゲットサブネットはVPC内で分離しておくと管理が楽になります

VPCのサブネット設計の基礎については、Amazon VPC入門も参考にしてください。

3. ソースサーバーの要件確認

移行前にソースサーバー側で確認すべきポイントです。

・OS要件: Linux カーネル2.6.25以降、Windows Server 2003 SP2以降
・ディスク上限: 1台あたり最大60TBまでレプリケーション可能
・ネットワーク: ポート443でAWSのMGNエンドポイント（mgn.ap-northeast-1.amazonaws.com等）への接続が可能であること
・Pythonランタイム: LinuxのReplication AgentにはPython 2.7または3.x が必要です（ほとんどのディストリビューションで標準インストール済み）

ステップバイステップの移行手順

1. MGNの初期セットアップ

AWSコンソールでApplication Migration Serviceを開き、「Initialize service」をクリックするとサービスロールが自動作成されます。次に「Replication template」でデフォルトのレプリケーション設定（ステージングサブネット、ストレージタイプ等）を定義します。

2. Replication Agentのインストール

ソースサーバーにエージェントをインストールします。コンソールから「Add source server」を選ぶと、OS別のインストールコマンドが生成されます。Linuxでの例は次のとおりです。

# AWS MGN Replication Agent のインストール（Linux / 東京リージョン ap-northeast-1）
wget -O ./aws-replication-installer-init.py \
  https://aws-application-migration-service-ap-northeast-1.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py

# IAMユーザーのアクセスキーを指定してインストール
sudo python3 aws-replication-installer-init.py \
  --region ap-northeast-1 \
  --aws-access-key-id AKIA************ \
  --aws-secret-access-key ******** \
  --no-prompt

エージェントのインストール後、コンソール上のソースサーバー一覧に対象サーバーが表示され、初期同期が自動的に始まります。

3. 初期同期と継続レプリケーション

初期同期ではディスク全体のデータをAWSへ転送するため、ディスク容量と回線速度によっては数時間から数日かかります。同期完了後は差分のみが継続的にレプリケーションされ、コンソールの「Replication state」が「Continuous data replication」に変わります。

この段階では本番のソースサーバーは引き続き稼働したままです。日々の変更がリアルタイムでAWS側に反映されていきます。

4. Launch Settingsの設定

カットオーバー時に起動するEC2インスタンスの設定を「Launch settings」で定義します。主な設定項目は次のとおりです。

・インスタンスタイプ: ソースのスペックに合わせたEC2タイプを選択します。インスタンスタイプの選び方はAmazon EC2入門が参考になります
・サブネット・セキュリティグループ: 本番用のVPC・サブネット・セキュリティグループを指定します
・IAMインスタンスプロファイル: SSM AgentやCloudWatchエージェント利用のために付与しておくと便利です
・Post-launch settings（起動後スクリプト）: OS固有の設定変更やエージェントインストールをカットオーバー後に自動実行できます

5. テスト起動

本番カットオーバーの前に必ずテスト起動を実施します。「Launch test instance」を実行すると、ステージングエリアのデータからEC2インスタンスが起動します。

テストで確認すべきポイントです。

・OSが正常に起動するか（コンソールスクリーンショット、Systems Manager Session Managerで接続確認）
・アプリケーションが起動するか（Webサーバー・アプリサーバー・DBの各プロセスの起動確認）
・データが正しく移行されているか（DBのレコード件数、ファイルの整合性）
・ネットワーク疎通（必要なポートが開いているか、依存先との接続が取れるか）

テストが完了したら、テストインスタンスは終了（Terminate）します。このとき起動した時間分のEC2料金が発生する点に注意してください。テストで問題が見つかれば、ソース側を修正したうえで継続レプリケーションが続く中で再テストできます。

6. 最終カットオーバー

テストで問題がないことを確認したら、メンテナンスウィンドウに合わせてカットオーバーを実施します。「Launch cutover instance」を実行すると、最終同期（通常数分）が完了したのち、EC2インスタンスが本番設定で起動します。

その後の作業は次のとおりです。

・Route 53のDNSレコード変更、またはロードバランサーのターゲット切り替えでトラフィックをAWSへ向ける
・動作確認が完了したら「Mark as cutover」でMGN上のサーバーを移行完了としてマークする
・ソースサーバー上のReplication Agentを「Disconnect from service」でMGNから切り離してアンインストールする

DNSの切り替えについては、Amazon Route 53入門も参考にしてください。

料金の仕組み（2026年8月時点）

10台のサーバーを90日以内に移行する場合、MGNのサービス料金は0円です。一方でステージングエリアのEC2とEBSの費用は継続してかかります。たとえばt3.small（東京リージョン: $0.0208/時間）で10台・90日間の場合は概算で約$450（2026年8月時点）です。ディスク容量が大きいサーバーを長期間レプリケーションし続けると、ストレージコストが積み上がることを念頭に置いてください。

移行前の詳細なコスト試算には、AWS Pricing Calculator実践ガイドが役に立ちます。

移行時のハマりポイントと対処法

【注意1】Windowsのライセンス認証が通らない

Windows ServerをAWSへ移行すると、ハードウェアの変化によってライセンスが無効化される場合があります。対処法は2通りです。

・ライセンス持ち込み（BYOL）: ソフトウェアアシュアランス（SA）を保有していれば、Dedicated Hostsで既存ライセンスを使えます
・AWSのWindowsライセンスを使う: EC2の「License included」インスタンスに切り替えると、AWSがライセンスを提供します。コストは増えますが手間が省けます

【注意2】移行後にネットワーク構成が変わる

オンプレではMACアドレスやIPアドレスをハードコードしているアプリ設定が残っていることがあります。EC2に移行するとMACアドレスが変わるため、ライセンス認証や接続先設定としてMACアドレスを使っているアプリは要注意です。移行前の棚卸しで洗い出しておくことが重要です。

【注意3】ディスク暗号化済みサーバーの扱い

ソース側でディスク暗号化（BitLockerやLVMのLUKS等）が施されている場合、ブロックレプリケーションはOS起動後のデータをそのまま取り込むため、基本的に問題ありません。ただし、ブート前にパスフレーズが求められる設定になっている場合は、起動フローを事前に確認しておく必要があります。

【注意4】NTPとタイムゾーンの確認

AWSのEC2はデフォルトでUTCを使います。オンプレのサーバーがJSTで動いていた場合、カットオーバー後に時刻がずれてログの突き合わせが難しくなることがあります。Post-launch settingsでタイムゾーン設定を変更するスクリプトを仕込んでおくと安全です。

【注意5】カットオーバー後のエージェント削除忘れ

カットオーバー後にソースサーバー上のReplication Agentをアンインストールし忘れるケースがあります。MGNコンソールで「Disconnect from service」を実行し、エージェントも削除してください。これによりステージングエリアのEC2・EBSが停止し、余計なコストがかかり続けることを防げます。

MGNは「6R移行戦略」のRehost自動化ツール

MGNはあくまで「Rehost（リホスト）」——クラウド移行戦略の6Rのうち最もシンプルな「そのままAWSへ移す」パターンを自動化するサービスです。AWS移行の6R入門で解説したとおり、全サーバーをリホストするのが最善とは限りません。

実際の現場では次のような判断を事前に行います。

・Rehost（MGN対象）: 短期でクラウドへ移したい、アプリの改修が難しい、まず動かすことを優先するサーバー
・Replatform: RDSやElastiCache等のマネージドサービスへのDB置き換えが現実的なサーバー
・Refactor: コンテナ化や再設計が見込めるアプリケーション

MGNで全台をリホストしてからクラウドの安定稼働を確認し、徐々にReplatform・Refactorへ移行していく段階的アプローチも現場ではよく使われます。

本記事のまとめ

オンプレのサーバーをAWSへ持っていく最初の一歩として、MGNは非常に強力なツールです。まずは開発・検証環境の1台から試すと、カットオーバーの流れを体感できます。90日間の無料期間を活用して、移行プロジェクトの見積もりとリハーサルを進めてみてください。