AWS Transform MGN（旧AWS Application Migration Service）とは｜料金・対応OS・移行手順【2026年版】

AWS Application Migration Service は 2026年6月に AWS Transform MGN へ改称しました。名前は変わりましたが、API もレプリケーションエンジンも取得済みのコンプライアンス認証も従来のままで、既存の移行プロジェクトに手を入れる必要はありません。この記事では、改称で実際に何が変わったのか、無料期間2,160時間でどこまで無料になるのか、対応OSとサポート終了日、TCP 443/1500 を軸にしたネットワーク設計、そして「MGNを選ぶべきでない条件」までを、AWS公式ドキュメントの記述に沿って整理します。

まとめ：MGN導入前に押さえる7点

• 2026年6月、AWS Application Migration Service は AWS Transform MGN へ改称。API・レプリケーションエンジン・コンプライアンス認証（FedRAMP High、HIPAA、PCI DSS、ISO、SOC 1/2/3）は変更なし。
• 役割はリホスト（lift and shift）。物理・仮想・他クラウドのサーバーをブロックレベルで継続レプリケーションし、カットオーバーの停止時間を数分単位に抑える。
• 2022年3月31日に提供を終えた AWS Server Migration Service（AWS SMS）の後継。SMS 由来の移行要件はすべて MGN 側で組み直す。
• 無料期間は移行元サーバーごとに2,160時間（連続使用で90日）。ただし無料なのはMGNのサービス利用料だけで、レプリケーション用のEC2・EBSは無料期間中も課金される。
• ネットワークは TCP 443（ソースサーバー→MGN APIエンドポイント）と TCP 1500（ソースサーバー→ステージングエリアサブネット）が必須。ステージング側は S3 の6バケットと EC2 エンドポイントへの到達も要る。SSLインターセプトは適用不可。
• 対応OSは x86 のみで32bit Linuxは非対応。ボリュームは最大16TB、MACアドレスが変わるとレプリケーションが停止しやり直しになる。
• エージェントレス（vCenter）は例外手段。AWS自身が「可能な限りエージェント方式」を推奨しており、CDPが使えるのはエージェント方式だけ。

以下、改称の中身と課金の境界、移行手順、そして事前に潰しておくべき前提条件を順に見ていきます。

AWS Transform MGNの役割と2026年6月の改称

ブロックレベル継続レプリケーションで停止時間を数分に抑える仕組み

MGN は移行元サーバーのディスクをブロック単位で継続的にレプリケーションし、AWS 上で起動できる形へ変換します。公式ドキュメントは停止時間を「typically cutover windows of minutes」と表現しており、業務停止を伴う一括コピー方式とは前提が異なります。移行元は物理サーバー、仮想マシン、他クラウド上のインスタンスのいずれでも構いません。

設定はレプリケーション・起動・起動後アクションの3テンプレートで管理し、新しく追加したサーバーにはテンプレートの内容が自動で適用されます。個別サーバーだけ設定を上書きすることも可能です。台数が増えたら、サーバーをアプリケーションに、アプリケーションをウェーブにまとめ、起動・カットオーバー・アーカイブをウェーブ単位で一括実行できます。数百台規模の移行計画（application migration plan）を段階的に区切る実行単位が、このウェーブです。

改称で変わったこと・変わらないこと

2026年6月8日の AWS What’s New は、AWS Application Migration Service を AWS Transform MGN へリブランドすると発表しました。ユーザーガイドの Release notes も「All MGN capabilities remain unchanged. Same APIs, same replication engine, same compliance certifications」と明記しており、API 名（mgn）もエンドポイント（https://mgn.{region}.amazonaws.com）もコンソールURL（https://console.aws.amazon.com/mgn/home）もそのままです。既存のIaCやスクリプトの書き換えは不要です。

実務上の変化は、リホストの入口が2系統になった点です。ひとつは従来どおり AWS Transform MGN コンソールでレプリケーションとカットオーバーを直接操作する方法。もうひとつは AWS Transform 側のエージェント型ワークフローで、検出・ウェーブ計画・ランディングゾーン構築・ネットワーク設定・リホストまでを自動化する方法です。MGN は後者の内部でレプリケーションエンジンとして動きます。手順を自分で握りたい移行なら前者、計画立案から任せたい大規模移行なら後者、という切り分けになります。

AWS移行サービスの中でのMGNの選び分け

リホスト以外を選ぶべき判断基準

MGN が担うのはサーバー単位のリホストです。OSごと持ち上げるため、アプリケーションの改修なしに移行できる反面、移行後もOSの保守責任は自社に残ります。データベースだけを移す、あるいは異種DBエンジンへ移す用途では AWS Database Migration Service が対象で、MGN の守備範囲ではありません。マネージドサービスへの置き換え（リプラットフォーム）やコンテナ化を最初から狙う場合も、MGN 単体では完結しません。

逆に、期限が決まっているデータセンター撤退や保守切れハードウェアの退避のように「まず動いている状態を AWS 上に再現する」ことが最優先なら、MGN が最短距離です。公式ドキュメントも移行後の再構築について「making rehosting a fast first step toward modernization」と位置づけており、リホストを終点ではなく起点として扱う設計を前提にしています。移行そのものの進め方はクラウドデータ移行の手順、オンプレミスを残す構成はハイブリッドクラウド移行の設計も合わせて検討してください。

AWS SMSからの移行先としてのMGN

「aws server migration service」で情報を探している場合、探しているサービス自体がすでにありません。AWS Server Migration Service（AWS SMS）は、新規の移行ジョブ作成が2022年1月1日で停止し、2022年3月31日に提供を終了しました。公式ユーザーガイドは「Going forward, we recommend AWS Application Migration Service (AWS MGN) as the primary migration service for lift-and-shift migrations」として MGN を後継に指定しています。

SMS はエージェントレスで vCenter 上の VM をスナップショット複製する方式でしたが、MGN の既定はエージェント方式で、レプリケーションの粒度も継続的なブロックレベル複製に変わります。SMS 時代の手順書をそのまま流用することはできず、ステージングエリアサブネットの用意とファイアウォールの開放から設計し直す必要があります。

レプリケーションの通信経路とステージングエリア設計

TCP 443とTCP 1500・S3アクセスの開放範囲

MGN のネットワーク要件は4経路に整理できます。まず、各ソースサーバーは MGN API エンドポイントへ TCP 443 で常時通信します（エージェントの配布と更新、レプリケーション状態の表示、テスト・カットオーバー準備）。次に、エージェントを入れたソースサーバーはステージングエリアサブネット内のレプリケーションサーバーへ TCP 1500 で通信し、この経路が実データの転送路です。データは送信元で暗号化・圧縮され、エージェントからレプリケーションサーバーまで TLS 1.2 でエンドツーエンドに保護されます。残る2経路は、ステージングエリアサブネット自体から MGN（443）へ、そして Amazon S3 と当該リージョンの Amazon EC2 エンドポイントへの到達です。

詰まりやすいのは4行目です。公式ドキュメントの Network requirements が許可リストへの登録を求めている S3 バケットは、次の6本あります。

• aws-mgn-internal-<region> と aws-mgn-internal-hashes-<region>
• aws-application-migration-service-<region> と aws-application-migration-service-hashes-<region>
• amazon-ssm-<region>
• al2023-repos-<region>-de612dc2

加えて、ステージングエリアサブネットは当該リージョンの Amazon EC2 エンドポイントへの外向き通信も必要です。最後の AL2023 バケットは、レプリケーションサーバーと変換サーバーが Amazon Linux 2023 ベースで動くために参照するパッケージリポジトリで、2026年5月にこの要件がドキュメントへ明記されました。到達できないとレプリケーションサーバーの起動や起動時の変換処理が失敗します。インターネット未接続のサブネットで S3 VPC ゲートウェイエンドポイントを使う場合は、エンドポイントポリシーに arn:aws:s3:::al2023-repos-<region>-de612dc2/* を追加してください。このバケットだけはデュアルスタックの S3 エンドポイント経由でアクセスする点も、ポリシーを絞っている環境では引っかかります。なお、レプリケーションサーバーやソースサーバーと MGN API エンドポイント間の通信に SSL インターセプトを適用してはいけません。

ステージングエリアサブネットは既存サブネットの流用も可能ですが、公式は専用サブネットの新設をベストプラクティスとしています。外向き経路は「パブリックIP＋インターネットゲートウェイ」か「プライベートIP＋NATゲートウェイ」の2択です。AWS Local Zones へ移行する場合も特別な設定は不要ですが、レプリケーションサーバーと変換サーバーの性能を考えると、ステージングエリアサブネットは Local Zone ではなく親リージョン側に置くのが公式の推奨で、Local Zone に置くなら本番前に十分なテストが要ります。VPC の初期設計から詰める場合はAWS環境構築の手順で VPC・IAM・セキュリティグループの前提を揃えておくと、開放範囲の議論が早く終わります。

エージェント型とエージェントレスの使い分け

vCenter 環境では、MGN vCenter Client を導入してエージェントレスのスナップショットレプリケーションを行えます（vCenter 8 対応は2024年1月）。ただしこれは既定の選択肢ではありません。公式ドキュメントは「MGN recommends using agent-based replication when possible, as it supports CDP (Continuous Data Protection) and provides the shortest cutover window」と述べ、エージェントレスは「社内ポリシーで各サーバーにエージェントを入れられない場合」に使うものと位置づけています。

判断は単純で、エージェントを入れられるならエージェント方式にします。継続的データ保護が効くのはエージェント方式だけで、カットオーバー時のデータ差分も最小になるためです。エージェントレスを選ぶ場合は、スナップショット間隔の分だけ差分が残る前提でカットオーバー計画を立ててください。

移行の実行手順：エージェント導入からカットオーバーまで

ソースサーバー側の事前要件

AWS Replication Agent の導入前に確認すべき要件は、OSの版よりも足回りに集中しています。

• ルートディレクトリ（/）に2GB以上、エージェント稼働用に300MB以上の空きRAM。Linux は /tmp に1GB、/boot が別パーティションなら50MB以上。
• ボリュームは1本あたり最大16TB。これを超えるボリュームを検出するとエージェントのインストールがエラーで失敗する。
• MACアドレスが再起動などで変わらないこと。MGN は MAC アドレスからソースサーバーの一意IDを算出するため、変化するとレプリケーションが停止し、エージェント再インストールと初回同期のやり直しになる。
• Linux は GRUB（1または2）で起動し、Secure Boot は非対応。/tmp は exec 付きでマウントし、実行中カーネルと完全に同一バージョンの kernel-devel / linux-headers を入れておく。Python 2.4以上または3.0以上と dhclient パッケージも必要。
• GPT パーティションのディスクから起動するマシンは grub2-pc-modules の導入が前提。複数の物理ディスクにまたがるブートディスクは非対応。インストーラの実行ユーザーは root か sudoers に入っていること。Linux 版インストーラは aws-replication ユーザーとグループを作成して sudoers へ追加するため、追加できない構成では導入が失敗する。
• Windows は .NET Framework 4.5以上と WMI サービスの有効化が必要。マウントポイントはドライブレターを割り当てないと認識されない。

ディストリビューション固有の追加作業もあります。Rocky Linux 8.x では事前に sudo yum install elfutils-libelf-devel が必要で、RHEL / Oracle Linux 9.4以下で LVM を使っている場合は lvm パッケージを lvm2-2.03.23-1.el9 以上へ更新しておきます。完全準仮想化のソースサーバーは非対応です（VMware の I/O デバイス準仮想化のような部分的な準仮想化は対応）。ブートモードまわりで悩む場合はUEFIとBIOSの違いを先に整理しておくと、変換後に起動しない事故を減らせます。

エージェント導入からテスト起動・カットオーバーまで

Linux 版エージェントは、リージョンごとの S3 からインストーラを取得して実行します。ユーザーガイドが us-east-1 の例として示しているコマンドは次のとおりです。

wget -O ./aws-replication-installer-init https://aws-application-migration-service-us-east-1.s3.us-east-1.amazonaws.com/latest/linux/aws-replication-installer-init
sudo chmod +x aws-replication-installer-init; sudo ./aws-replication-installer-init

インストーラのハッシュを検証する場合は、同名の hashes バケットにある aws-replication-installer-init.sha512 を参照します。実行するとリージョン名と認証情報、複製対象ディスクが対話で聞かれます。無人実行は --no-prompt の役目で、認証情報は --aws-access-key-id などのパラメータで渡す形です。複製するディスクの明示は --devices、自動検出そのものを切るのは --force-volumes（--no-prompt との併用が必須で、ルートディスクを指定し忘れると複製が失敗）と役割が分かれています。ルートディスクは選択の有無にかかわらず必ず複製対象になり、パーティションを指定してもディスク全体が複製される点は、容量見積もりに直結する仕様です。

エージェント導入後、初回の同期が終わると継続レプリケーション状態に入ります。本番切り替えの前にテストインスタンスを起動し、EC2 起動テンプレートで指定した運用サブネット上で疎通と動作を確認しておきましょう。テストインスタンスの起動・停止は何度でも繰り返せる一方、その間もレプリケーションは走り続けるので、テスト期間が延びるほど後述の課金が積み上がります。

Active Directory に参加しているサーバーでは、変換処理でネットワーク設定が DHCP に戻され、ソースサーバー側のインスタンス単位のDNS指定は引き継がれません。ターゲットVPCからドメインコントローラーへの疎通と名前解決を、カットオーバー前に必ず確認してください。ここを詰めずにカットオーバーすると、起動したインスタンスがドメインに参加できず切り戻しになります。

起動後アクションによる移行後検証の自動化

起動後アクション（post-launch actions）は、テスト／カットオーバーインスタンスの起動直後に SSM ドキュメントを実行する仕組みです。定義済みアクションとして、EC2 の疎通チェック、ボリューム整合性の検証、プロセス起動状態の確認、CloudWatch エージェントの導入、Directory Service ドメインへの参加、MS-SQL のライセンス変換、Amazon Inspector の有効化に加え、監視エージェント連携として TrendMicro（2024年9月追加）、New Relic（2024年7月追加）、Dynatrace（2024年6月追加）が用意されています。移行後の手作業チェックリストを、そのまま自動化に載せられる範囲です。

ただし、ここは AWS 側の整理が入っている領域でもあります。2025年8月に「Enable Refactor Spaces」と「App2Container for Replatforming」の2アクションがサポート対象外になりました。過去記事や社内手順書がこの2つを前提にしている場合は差し替えが必要です。

対応OSとサポート終了スケジュール（2026年7月時点）

MGN は x86 アーキテクチャ向けのOSのみを対象とし、32bit の Linux は対応しません。カーネルは 2.6.18-164 未満が非対応で、4.9.256 はエージェントのインストールが失敗します。

Windows Server 2012 / 2012 R2 は OS 自体が延長サポートを終えていますが、MGN 側の対応は続いており、終了日の告知も出ていません。オンプレミスに残った2012系サーバーは、いまのところ MGN で持ち上げられます。

むしろ移行計画に効いてくるのは、対応表よりも打ち切り日です。ドキュメントのサポート終了告知は、Windows 2003 が2026年2月15日で終了済み、Windows 2008 と Windows 7 が2026年12月30日。Linux 側は RHEL 5.x と CentOS 5.x が2025年12月30日、Debian 6.x〜9.x が2026年4月30日でいずれも終了済み、Ubuntu 12.04 が2026年8月20日、Oracle 6.x・CentOS 6.x・SLES 11.x が2026年8月28日、CentOS 7〜7.9 と Amazon Linux 1 が2026年11月20日、Ubuntu 14.04 が2026年12月20日、Debian 10・RHEL 6.x・CentOS 8.x が2026年12月30日です。

つまり、2026年内に古いディストリビューションを抱えたまま移行を計画している場合、MGN のサポート打ち切りが移行期限そのものになります。CentOS 7 系を残しているなら、CentOSの終了と後継OSへの移行判断を先に済ませ、OS更新と AWS 移行のどちらを先に行うかを決めてから着手してください。

料金：2,160時間の無料期間で無料になる範囲

MGN の料金体系でつまずくのは、無料期間の対象範囲です。公式FAQは「For each source server that you want to migrate, you can use AWS Transform MGN for a free period of 2,160 hours, which is 90 days when used continuously」と定めています。起算点は AWS Replication Agent をインストールした時点で、消費されるのはレプリケーション実行中の時間だけです。90日を超えて複製を続ける場合は、そのサーバーについて時間単位の課金に切り替わります。単価はリージョン共通ですが、2026年7月時点の公式料金ページは実額を掲載しておらず、見積もりフォームと AWS Pricing Calculator へ誘導する構成です。従来は1時間あたり0.042ドル（1台あたり月額30ドル前後）として紹介されてきた水準で、社外の解説記事もこの数字を引いていますが、公式の一次記載が確認できない以上、実額は Pricing Calculator で確認してください。なお、エージェントを --no-replication 付きで導入するなどしてレプリケーションを停止している時間は、無料期間の90日を消費しません。

問題はここからです。同じFAQに「While your source servers are actively replicating, including during the free period, you will incur charges for any AWS infrastructure that is provisioned by AWS Transform MGN to facilitate data replication」とあるとおり、無料期間中もレプリケーション用にプロビジョニングされるEC2インスタンスとEBSボリューム、スナップショットは課金対象です。テストインスタンスやカットオーバーインスタンスも同様に、通常のEC2・EBS料金がかかります。

したがって、実際の移行コストは「MGNのサービス料金」ではなく「ステージングエリアで動かし続けるレプリケーションサーバーとEBSの費用×日数」で決まります。100台を90日間並行してレプリケーションすれば、MGN の利用料が0円でも EC2 と EBS の請求は積み上がります。見積もりの精度を上げるなら、ウェーブ単位で複製開始をずらし、テスト完了後は速やかにカットオーバーしてレプリケーションを終わらせる設計にするのが実質的なコスト対策です。インスタンス費用の見積もり自体はAmazon EC2の料金モデルを参照してください。

MGNを採用すべきでない条件と、事前に潰す前提

MGN の導入検討でよく共有されるのは対応OS表ですが、実際に移行を止めるのはOSの版ではなく、環境側の前提条件です。次のいずれかに当てはまる場合、MGN をそのまま採用すべきではありません。

• 単一ボリュームが16TBを超えるサーバー。エージェントのインストール時点で失敗します。ボリューム分割か、別方式でのデータ移送を先に設計してください。
• MACアドレスが変動する環境（DHCPベースの仮想NIC再割り当てなど）。再起動のたびにレプリケーションが振り出しに戻り、大容量サーバーほど損失が大きくなります。
• SSLインターセプトを全通信に強制しているネットワーク。MGN API エンドポイントとの通信では明示的に禁止されており、プロキシ設計の例外化が通らなければ移行自体が始まりません。
• Secure Boot を必須にしている Linux サーバー。Linux では Secure Boot が非対応のため、要件を外せないなら別の移行方式を選びます。
• アプリケーション改修を伴うモダナイゼーションが目的の場合。MGN はOSごと持ち上げるサービスであり、リホスト後の作り替えは別プロジェクトとして計画する必要があります。

逆に、この5点をクリアできるなら、移行方式の議論に時間をかける価値は小さくなります。エージェント方式を既定にし、ステージングエリアサブネットを新設し、ウェーブを切って順に流すのが最も事故が少ない進め方です。

直近の機能追加も判断材料になります。2025年12月に IPv6 対応、2026年3月に AWS Local Zones 内でのEBSスナップショット保存、2026年6月に Amazon FSx for NetApp ONTAP をターゲットストレージとして選べる機能（パブリックプレビュー）が加わりました。FSx for ONTAP を使う場合は、ターゲットインスタンスから TCP 3260（iSCSI）と TCP 443（ONTAP REST API）の開放が追加で必要になります。プレビュー段階の機能なので、本番移行の前提には置かず、EBS を基本線として計画してください。

よくある質問

AWS MGNとは何ですか？

物理サーバー・仮想マシン・他クラウドのサーバーを、OSごと AWS へ移行（リホスト）するためのマネージドサービスです。移行元ディスクをブロックレベルで継続的にレプリケーションし、切り替え時は複製済みデータから EC2 インスタンスを起動するため、停止時間を数分程度に抑えられます。2026年6月に AWS Application Migration Service から AWS Transform MGN へ改称しましたが、機能とAPIは変わっていません。

MGNは何の略ですか？

AWS は MGN の正式な展開形を定義しておらず、ドキュメントは「AWS Transform MGN (MGN)」と定義したうえで以降は MGN と略記する書き方です。migration を縮めた表記とみられ、API エンドポイント mgn.{region}.amazonaws.com、コンソールURL /mgn/home、IAM ポリシー名などに一貫して使われます。

AWS MGNの費用はいくらですか？

移行元サーバーごとに2,160時間（連続使用で90日）の無料期間があり、この範囲内であれば MGN のサービス利用料はかかりません。ただし無料期間中も、レプリケーションのために起動されるEC2インスタンス・EBSボリューム・スナップショット、およびテスト／カットオーバーインスタンスの費用は通常どおり課金されます。90日を超えて複製を続ける場合は、そのサーバーが時間単位の課金対象になります。2026年7月時点の公式料金ページは実額を掲載していないため、金額は AWS Pricing Calculator で見積もってください。

AWS Server Migration Service（SMS）は今も使えますか？

SMS は vCenter 上の仮想マシンをエージェントレスでスナップショット複製し、AMI として AWS へ移行する旧世代のサービスでしたが、現在は使えません。新規の移行ジョブ作成は2022年1月1日で停止し、2022年3月31日にサービス提供が終了しました。AWS は後継としてリフト＆シフト移行に MGN を推奨しています。MGN の既定はエージェント方式で継続ブロックレベル複製になるため、SMS 時代の手順とネットワーク要件は組み直しが必要です。

エージェントを入れずに移行することはできますか？

vCenter 環境であれば、MGN vCenter Client を導入してエージェントレスのスナップショットレプリケーションが可能です（vCenter 8 対応済み）。ただし AWS は可能な限りエージェント方式を推奨しており、継続的データ保護（CDP）とカットオーバー窓の最短化はエージェント方式でしか得られません。エージェントレスは、社内ポリシーで各サーバーへのエージェント導入が認められない場合の選択肢と位置づけられています。

関連記事

• クラウドデータ移行の手順とは?移行ツール・整合性検証・大容量転送の実務を実装者向けに解説
• ハイブリッドクラウド移行とは？接続方式・ネットワーク設計・アプリ配置判断まで解説
• AWS環境構築の手順｜VPC・EC2・IAM・セキュリティグループの初期設計を解説
• Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説
• CentOSとは？RHEL互換OSの終了とCentOS Stream・後継OSへの移行判断を実装目線で解説【2026年版】