AWS Application Migration Service（MGN）は2026年6月に AWS Transform MGN へ改称しました。API・レプリケーションエンジン・コンプライアンス認証はそのままですが、2026年10月にはエージェントレス複製の新規提供が終わり、対応OSの一覧とサポート終了日も夏以降に何度も書き換わっています。料金・対応OS・ネットワーク要件・導入コマンド・MGNコネクタ・採用すべきでない条件を、AWS公式ドキュメントに沿って整理します。
まとめ：MGN導入前に押さえる要点（2026年10月時点）
- 2026年6月8日に AWS Application Migration Service から AWS Transform MGN へ改称。API・エンドポイント・コンソールURLは不変で、既存のIaCは書き換え不要。
- 役割はリホスト。サーバーをブロックレベルで継続複製し、カットオーバーの停止時間を分単位に抑える。
- 2026年10月にエージェントレス複製が新規提供終了。今後はエージェント方式で、台数が多ければ MGN コネクタで一括導入する。
- 料金は1台ごとに2,160時間（連続90日）無料、その後は1時間0.042ドル（月約30ドル）。無料期間中もステージングのEC2・EBSは課金される。
- CentOS 7 と Amazon Linux 1 は2026年11月20日、Windows Server 2008 は12月30日で MGN のサポートが終わる。
- 同時複製の既定上限は、1アカウント・1リージョンあたり150台。ウェーブ間の複製期間の重なりを調整するか、上限緩和を申請する。
AWS Transform MGNの役割と2026年6月の改称
ブロックレベル継続レプリケーションで停止時間を分単位に抑える仕組み
MGN は移行元サーバーのディスクをブロック単位で継続的にAWSへ複製し、切り替え時に複製済みデータから Amazon EC2 インスタンスを起動します。業務を止めて一括コピーする方式と違い、カットオーバー直前まで差分が流れ続けるので、停止が必要なのは切り替えの時間帯だけです。ただしその停止時間には、最終同期と起動に加え、業務サービスの停止、移行先の動作確認、接続先の切り替えも含まれます。分単位で収まるかはリハーサルで測ってください。移行元は物理サーバー、VMware などの仮想マシン、他クラウドのインスタンスのいずれでも構いません。
設定はレプリケーション・起動・起動後アクションの3つのテンプレートで管理し、新しく追加したサーバーには既定値が自動で入ります。個別サーバーだけ上書きすることもでき、2026年9月からは EBS の「Volume initialization rate」と「Delete on termination」もアカウント既定の起動テンプレートで指定できるようになりました。
AWS Transform MGNへの改称と操作方法・APIの継続性
2026年6月8日の AWS What’s New が改称を発表し、ユーザーガイドのリリースノートは「All MGN capabilities remain unchanged. Same APIs, same replication engine, same compliance certifications (FedRAMP High, HIPAA, PCI DSS, ISO, SOC 1/2/3)」と明記しています。API名（mgn）、エンドポイント（mgn.<region>.amazonaws.com）、IAM の管理ポリシー名も従来のままです。
実務上の変化は、リホストの入口が2つになった点です。1つは従来どおり MGN コンソールでレプリケーションとカットオーバーを自分で操作する方法。もう1つは AWS Transform のエージェント型ワークフローで、検出・ウェーブ計画・ネットワーク作成・リホストまでを AI エージェントが進め、MGN はその裏でレプリケーションエンジンとして動きます。AWS Transform の料金ページは、評価と Windows・VMware・メインフレーム向けのエージェントを無料としています。有料なのはカスタム変換（エージェント稼働1分あたり0.035ドル、AWS管理の.NET変換には月50,000分の無料枠）と continuous modernization です。どちらの入口でも、MGN の無料期間と EC2・EBS の課金は同じ扱いです。
AWS移行サービスの中でのMGNの位置づけ
AWS の移行系サービスは2025〜2026年に提供状況が大きく変わりました。
| サービス | 移すもの | 提供状況（2026年10月） |
|---|---|---|
| AWS Transform MGN | サーバー（OSごと） | 提供中・リホストの主力 |
| AWS Database Migration Service | データベース | 提供中 |
| AWS DataSync | ファイル・オブジェクト | 提供中 |
| AWS Transform | 検出・計画・モダナイズ | 提供中・移行の検出と計画の後継 |
| AWS Migration Hub | 移行状況の集約 | 2025-11-07に新規受付終了 |
| AWS Application Discovery Service | オンプレミスの棚卸し | 新規受付終了 |
| AWS Server Migration Service | VM（スナップショット） | 2022-03-31に提供終了 |
Migration Hub のドキュメントは冒頭で「no longer open to new customers as of November 7, 2025」と告知し、同等の機能として AWS Transform を案内しています。過去の移行手順書で「Migration Hub で進捗を管理し、ADS で棚卸しする」と書かれていても、新しいアカウントではその組み立てがとれません。
リホスト以外を選ぶべき判断基準
MGN が担うのはサーバー単位のリホストです。OSごと持ち上げるのでアプリケーションを改修せずに移せる反面、移行後もOSの保守責任は自社に残ります。データベースだけを移す、あるいは Oracle から PostgreSQL のように異種エンジンへ移すなら AWS Database Migration Service（DMS）、ファイルサーバーの中身だけなら AWS DataSync の転送方式が対象です。逆に、データセンター撤退や保守切れハードウェアの退避のように「動いている状態をまず AWS 上に再現する」ことが最優先なら、MGN が最短距離になります。7R のどれを選ぶかの全体設計は AWS移行の7R戦略と移行ツール、データ転送の段取りは クラウドデータ移行の手順で整理しています。
AWS Server Migration Service（SMS）からの移行先
AWS CLI の SMS リファレンスによると、SMS の新規移行ジョブは2022年1月1日まで、既存プロジェクトの完了期限は2022年3月31日で、その後提供を終えました。AWS はリフト＆シフトの後継として MGN を指定しています。SMS は vCenter 上の VM をエージェントなしでスナップショット複製する方式でしたが、MGN 側のエージェントレス方式も2026年10月に新規提供が終わったため、SMS 時代の「エージェントを入れない」前提の手順書は使えません。
エージェントレス複製の新規提供終了（2026年10月）
2026年10月のリリースノートと、10月22日付のドキュメント改訂履歴で、MGN vCenter Client を使うエージェントレスのスナップショット複製は「no longer available for new deployments」になりました。エージェントレス複製の概要ページも冒頭で、すべての移行にエージェント方式を勧めると書き換わっています。
AWS が挙げる理由は3つです。エージェント方式は変更が発生した時点で複製するためスナップショットの同期待ちが無く、カットオーバー時の差分が小さいこと。本番データストアに VMware スナップショットを作らないので、スナップショットに伴う負荷を避けられること（複製時のソースボリュームの読み取りは発生します）。VMware とそれ以外の環境を同じ方式で扱えること。台数が多くて手作業の導入が負担になる場合は、後述の MGN コネクタを使うよう案内されています。
2026年10月以前の解説記事の多くはエージェントレスを「エージェントを入れられない環境向けの選択肢」として紹介しています。社内ポリシーでエージェント導入を禁じている環境は、移行方式の議論より先に例外承認を取る必要があります。
レプリケーションの通信経路とステージングエリア設計
TCP 443とTCP 1500・S3アクセスの開放範囲
ネットワーク要件のドキュメントによると、各ソースサーバーは MGN API エンドポイントと TCP 443 で常時通信し、ステージングエリアサブネットのレプリケーションサーバーへは TCP 1500 でデータを送ります。複製データは送信元で暗号化・圧縮され、ステージング側で復号されてからボリュームに書き込まれます。
| 経路 | ポート | 用途 |
|---|---|---|
| ソースサーバー → MGN | TCP 443 | 制御・状態通知・エージェント更新 |
| ソースサーバー → ステージング | TCP 1500 | 複製データの転送 |
| ステージング → MGN | TCP 443 | レプリケーションサーバーの管理 |
| ソース・ステージング → S3 | TCP 443 | インストーラ・SSM・AL2023パッケージ |
| ステージング → EC2 | TCP 443 | 当該リージョンのEC2エンドポイント |
詰まりやすいのはS3です。ファイアウォールの許可リストに入れる 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
最後の AL2023 バケットは、レプリケーションサーバーと変換サーバーが Amazon Linux 2023 ベースで動くために参照するパッケージリポジトリで、2026年5月にドキュメントへ追加されました。このバケットだけはデュアルスタックの S3 エンドポイント（s3.dualstack.<region>.amazonaws.com）経由でアクセスされます。インターネット未接続のサブネットで S3 VPC ゲートウェイエンドポイントを使う場合は、エンドポイントポリシーに arn:aws:s3:::al2023-repos-<region>-de612dc2/* を追加してください。到達できないとレプリケーションサーバーの起動や変換処理が失敗します。
ステージングエリアサブネットは専用に新設するのが公式のベストプラクティスです。2025年12月から IPv6 でも使えますが、MGN コネクタは IPv6 に対応していません。VPC・IAM・セキュリティグループの初期設計から詰める場合は AWS環境構築の手順、オンプレミスと専用線やVPNで結ぶ構成は ハイブリッドクラウド移行の接続方式を先に揃えておくと、開放範囲の議論が早く終わります。
FSx for ONTAPをターゲットにする場合の追加要件
移行先のストレージに Amazon FSx for NetApp ONTAP を選ぶ機能は、2026年6月のパブリックプレビューを経て8月30日に一般提供になりました。FSx for ONTAP の設定ページによると、MGN のインスタンスから FSx 側へ TCP 3260（iSCSI）と TCP 443（ONTAP REST API）を開け、ステージングと起動先のサブネットから OS パッケージリポジトリへ出られるようにしておく必要があります。RHEL・CentOS では iscsi-initiator-utils と device-mapper-multipath をソースサーバーへ事前に入れます。Local Zones では使えません。
MGN移行の実行手順とカットオーバーの確認項目
ソースサーバー側の事前要件
インストール要件で止まりやすいのは、OSの版よりも足回りです。
- ルートディレクトリに2GB以上の空き、エージェント用に300MB以上の空きRAM。Linux は
/tmpに1GB、/bootが別パーティションなら50MB以上。 - ボリュームは1本あたり最大16TB。超えるボリュームがあるとエージェントのインストールが失敗する。
- サーバーを識別する値が変わらないこと。MGN は AWS インスタンスID、Google Cloud インスタンスID、vCenter UUID、MACアドレスの順に、最初に取れる値を識別子に使う。使用中の識別子が変わると複製が止まり、エージェントの再インストールと複製のやり直しになる。クローンしたVMは識別子が重複しないようにしてから導入する。
- Linux は GRUB で起動し Secure Boot は非対応。実行中カーネルと同じ版の
kernel-develまたはlinux-headers、Python、dhclientが必要（RHEL 10・Oracle Linux 10・AlmaLinux 10 など dhclient が廃止されたOSでは不要）で、/tmpは exec 付きでマウントする。 - Windows は WMI サービスの有効化が必要。.NET Framework の要件はOS別で、Windows Server 2008は3.5、2008 R2および2012〜2025は4.5以上。Windows Server 2008 などの EOL 版は
AwsReplicationWindowsLegacyInstaller.exe、2012 はAwsReplicationWindows2012LegacyInstaller.exeという専用インストーラを使う。
RHEL・Rocky・AlmaLinux 8.x は事前に sudo yum install elfutils-libelf-devel が必要で、RHEL・Oracle Linux 9.4以下で LVM を使う場合は lvm パッケージを lvm2-2.03.23-1.el9 以上へ上げておきます。ブートモードで迷う場合は UEFIとBIOSの違いとSecure Bootを先に確認すると、変換後に起動しない事故を減らせます。
レプリケーションエージェントを導入するコマンド
まず移行先リージョンでMGNを初期化し、レプリケーション設定とエージェント導入用のIAM権限を準備します。その後、Linux版のエージェントを複製先リージョンのS3から取得して実行します。Linux へのインストール手順が示す東京リージョン相当の形は次のとおりです（us-east-1 の例をリージョン名だけ置き換えたもの）。
wget -O ./aws-replication-installer-init https://aws-application-migration-service-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/linux/aws-replication-installer-init
sudo chmod +x aws-replication-installer-init
sudo ./aws-replication-installer-init引数なしで実行すると、リージョン名・認証情報・複製するディスクを対話で聞かれます。台数分を自動化するなら、AWS STS の一時認証情報を環境変数に入れ、sudo -E で環境変数を引き継いで --no-prompt を付けます。次の例の山括弧で囲んだ3か所は、山括弧ごと実際の一時認証情報に置き換えてください。
export AWS_ACCESS_KEY_ID=<一時アクセスキー>
export AWS_SECRET_ACCESS_KEY=<一時シークレット>
export AWS_SESSION_TOKEN=<セッショントークン>
sudo -E ./aws-replication-installer-init --region ap-northeast-1 --no-prompt \
--no-replication --user-provided-id web-01 --tags Wave=1 Owner=infra引数の役割は次のとおりです。
--no-replication：導入だけ済ませ、複製はコンソールかaws mgn start-replicationで後から始める。停止中の時間は90日の無料期間を消費しない。--user-provided-id：サーバーに識別名を付け、CSV からのインベントリ一括インポートと突き合わせる。2026年8月から大文字と小文字を区別しなくなった。--tags：新規登録時だけ有効。登録済みサーバーのタグ変更には使えない。--devicesと--force-volumes：複製するディスクを明示する。--force-volumesは自動検出を切る障害対応用で、ルートディスクを指定し忘れると複製が失敗する。
通常のディスク自動検出では、ルートディスクは選択の有無にかかわらず複製されます。ただし、--force-volumes を使うときはルートディスクも明示指定が必要です。パーティションを指定しても、複製対象はディスク全体です。ステージング側の EBS 容量を見積もるときは、使用量ではなくディスクサイズで計算してください。
MGNコネクタによる一括導入の要件と設定
1台ずつ SSH や RDP で入ってコマンドを流す作業を省くのが MGN コネクタです。移行元のネットワークに置いた Linux サーバーがコネクタとなり、登録したソースサーバーに対して前提条件の確認とエージェントの導入を代行します。コネクタの前提条件は次のとおりです。
- コネクタを置ける OS は Ubuntu 18〜22.04、Amazon Linux 2、RHEL 8.x（いずれも x86_64）。openssl が必要で、専用サーバーへの導入が推奨。
- 導入時に SSM Agent も入るため、既に SSM Agent がある場合は先にアンインストールする。ディスクは200MB以上の空きが必要。
- IPv6 には非対応。
セットアップはコンソールでコネクタ名を付け、有効期間30日の SSM ハイブリッドアクティベーションを作成し、表示された1行のインストールコマンドをコネクタ用サーバーで実行するだけで、導入は通常2〜3分で終わります。2026年8月からは必要な IAM ロールをコンソールが自動作成するようになり、以前必要だった MGNConnectorInstallerRole は不要になりました。ソースサーバーの管理者認証情報は AWS Secrets Manager に置き、同じシークレットを複数台にまとめて割り当てられます。
テスト起動の確認項目とカットオーバーの実行順序
初回同期が終わると、サーバーは継続レプリケーションの状態に入ります。本番切り替えの前に、EC2 起動テンプレートで指定したサブネットにテストインスタンスを起動し、疎通とアプリケーションの動作を確かめます。テストは何度でも繰り返せますが、その間も複製とインフラ費用は続きます。テストが通ったら切り替え時間帯に移行元の業務サービスを停止し、レプリケーションの遅延がゼロになったことを確認します。その後、カットオーバーインスタンスを起動して動作とデータを確認し、DNS や負荷分散の向き先を切り替えてから、ソースサーバーを「カットオーバー確定」にしてレプリケーションを止めます。
Active Directory に参加しているサーバーは、変換処理でネットワーク設定が DHCP に戻り、ソース側で固定していた DNS サーバーの指定は引き継がれません。ドメインコントローラー自体をテスト起動する場合は、本番クライアントの誤接続を防ぐためテストVPCを本番ネットワークから隔離します。本番切り替えでは、移行先 VPC からドメインコントローラーへの疎通と名前解決を事前に確認しておかないと、起動したインスタンスがドメインに参加できず切り戻しになります。
起動後アクションによる確認の自動化と対応機能
起動後アクションは、テストやカットオーバーのインスタンスが起動した直後に SSM ドキュメントを実行する仕組みです。定義済みアクションには、EC2 の疎通確認、ボリューム整合性の検証、プロセス起動状態の確認、CloudWatch エージェントの導入、Directory Service ドメインへの参加、MS-SQL のライセンス変換、Amazon Inspector の有効化などがあり、1台に最大100件の独自アクションを紐づけられます。2025年8月に「Enable Refactor Spaces」と「App2Container for Replatforming」の2つはサポート対象外になっているので、古い手順書がこれを前提にしていれば差し替えが必要です。
アプリケーション・ウェーブと上限値（大規模移行の計画）
台数が増えたら、サーバーをアプリケーションに、アプリケーションをウェーブにまとめ、テスト起動・カットオーバー・アーカイブをウェーブ単位で一括実行します。サーバー・アプリケーション・ウェーブの定義は CSV で一括インポート・エクスポートでき、2026年8月からは複製設定・起動設定・起動後アクションの設定も CSV で一括変更できるようになりました。数百台規模の移行計画（application migration plan）は、この CSV を正本にして回すのが現実的です。
計画で効いてくるのはサービスの上限値です。いずれも1リージョンあたりの既定値です。
| 項目 | 既定値 |
|---|---|
| 同時にレプリケーションできるサーバー | 150台 |
| 1ジョブに含められるサーバー | 200台 |
| 同時に実行できるジョブ | 20件 |
| 実行中の全ジョブに含められるサーバー合計 | 200台 |
| 1アプリケーションのサーバー | 200台 |
| アクティブなウェーブ | 200件 |
| アカウントの累計サーバー（アーカイブ含む） | 50,000台 |
同時複製150台は、複製開始からカットオーバーまでの期間が重なるサーバーの合計で数えます。300台を一斉に複製し始める計画は既定値では成り立たないので、ウェーブを150台以内に区切るか、着手前にサポートへ上限緩和を申請してください。複数アカウントへ移す場合は、1つの管理アカウントから最大5,000の配下アカウントを扱えるグローバルビューを使います。
対応OSとサポート終了スケジュール（2026年10月時点）
対応OSのページによると、MGN は x86 のOSだけが対象で、32bit の Linux は対応しません。カーネル 2.6.18-164 未満は非対応、4.9.256 はエージェントのインストールが失敗します。
| OS | 対応バージョン |
|---|---|
| Windows Server | 2025 / 2022 / 2019 / 2016 / 2012・2012 R2 / 2008・2008 R2 |
| Windows クライアント | 11 / 10 / 7（自動スリープを無効化） |
| Amazon Linux | 2 / 2023（1 は AWS 間の復旧のみ） |
| RHEL | 6.0〜9.8 / 10〜10.2 |
| Rocky Linux | 8〜9.8 / 10〜10.2 |
| AlmaLinux | 8.6〜8.10 / 9.6〜9.8 / 10〜10.2 |
| Oracle Linux | 7.0〜7.9 / 8.5〜8.10 / 9.0〜9.4 / 9.6 / 9.7 / 10.0 / 10.1（カーネル条件あり） |
| CentOS | 7.0〜8.0 / Stream 9 / Stream 10（10は指定カーネルのみ） |
| Ubuntu | 14.04〜24.04（カーネル3.x以上） |
| Debian | 10〜12（カーネル3.x以上） |
| SLES | 12〜15 SP7 |
2026年7月以降の追加は、RHEL・Rocky・AlmaLinux の 9.8 と 10.2、Amazon Linux 2023 のカーネル 6.18、Oracle Linux 9.6 と 7.9、AlmaLinux 8.6〜8.10、Debian 12 です。Oracle Linux は版ごとに UEK または RHCK のカーネル条件があります。Azure から持ち出す Ubuntu は Azure 用カーネルのままでは対応せず、標準カーネルか linux-aws へ切り替える必要があります。
移行計画に効くのは、対応表よりもサポートの打ち切り日です。
| 終了日 | 対象OS |
|---|---|
| 終了済み | Windows 2003 / RHEL・CentOS 5.x / Debian 6〜9 |
| 2026-08-20（終了済み） | Ubuntu 12.04 |
| 2026-08-28（終了済み） | Oracle Linux 6.x / CentOS 6.x / SLES 11.x |
| 2026-11-20 | CentOS 7〜7.9 / Amazon Linux 1 |
| 2026-12-20 | Ubuntu 14.04 |
| 2026-12-30 | Windows 2008 / Windows 7 / Debian 10 / RHEL 6.x / CentOS 8.x |
CentOS 7 系の MGN サポートは2026年11月20日に終わります。それまでに複製とカットオーバーを終えられない台数は、先に OS を更新してから移すか、別の移行方式を探すことになります。どちらを先にするかの判断は CentOSの終了と後継OSへの移行判断で整理しています。Windows Server 2012 / 2012 R2 は OS 自体の延長サポートが終わっていますが、MGN 側の終了日はまだ告知されていません。
料金：2,160時間の無料期間と無料期間後の単価
製品のよくある質問は「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」と定めています。無料期間はエージェントを入れた時点で始まり、レプリケーション中の時間だけを消費します。料金ページは無料期間後の単価を1台あたり1時間0.042ドル、月額約30ドルとし、全リージョン同額です。
見落としやすいのは、無料なのが MGN のサービス利用料だけという点です。同じページは「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」と書いており、ステージングエリアで動くレプリケーションサーバー（EC2）、EBS ボリュームとスナップショット、テスト・カットオーバーインスタンスは無料期間中も通常料金がかかります。
移行コストは、ステージングの EC2・EBS、スナップショット、テスト・カットオーバーインスタンスなどの費用を合算します。FSx for ONTAPを使う場合はその費用、無料期間を超える場合はMGN利用料も加わります。抑えるには、エージェントを --no-replication で先に入れ、ウェーブ単位で複製の開始をずらし、テストが済んだら速やかにカットオーバーして複製を止めます。インスタンス費用の見積もりは Amazon EC2の料金モデルを参照してください。
MGNを採用すべきでない条件と、事前に潰す前提
MGNの採用判断では、対応OSに加えて、ボリュームサイズ・識別子・通信制御・起動方式を確認します。次のいずれかに当てはまるなら、MGN をそのまま採用すべきではありません。
- 単一ボリュームが16TBを超える：エージェントの導入時点で失敗する。各ボリュームを16TB以下に再構成するか、DataSyncなどでデータを転送し、移行先サーバーを別途構築する設計にする。
- 識別子が変わる：MACアドレスを識別子にしているサーバーで NIC の付け替えなどによりアドレスが変わると、複製が止まり、エージェントの再インストールと複製のやり直しになる。
- 全通信にSSLインターセプトを強制している：MGN API エンドポイントとの通信では明示的に禁止されており、プロキシの例外が通らなければ移行が始まらない。
- エージェントを入れられない：2026年10月以降、新規にエージェントレス複製は使えない。例外承認が取れなければ、VM のエクスポートなど別の方式になる。
- Linux で Secure Boot が必須：Linux の Secure Boot は非対応。
- アプリケーション改修が目的：MGN はOSごと持ち上げるサービスなので、作り替えは別プロジェクトとして計画する。
この6点に加え、共有ストレージやクラスタ構成、データ変更量に対する回線帯域、許容停止時間を確認し、リホストで要件を満たす場合にMGNを採用します。エージェント方式を既定にし、ステージングエリアサブネットを新設し、アプリケーションの依存関係と回線帯域を踏まえてウェーブを設計し、既定では同時複製台数が150台以内になるよう開始時期を調整します。前提条件の洗い出しから外部と進める場合は、AWS・Google Cloud・Azure のインフラ構築支援で移行設計から相談できます。
よくある質問
AWS MGNとは何ですか？
物理サーバー・仮想マシン・他クラウドのサーバーを、OSごと AWS へ移行（リホスト）するためのマネージドサービスです。ディスクをブロックレベルで継続的に複製し、切り替え時は複製済みデータから EC2 インスタンスを起動するため、停止時間を分単位に抑えられます。2026年6月に AWS Application Migration Service から AWS Transform MGN へ改称しましたが、機能とAPIは変わっていません。
AWS Transform MGNとAWS Transformは何が違いますか？
AWS Transform MGN はサーバーを複製して EC2 として起動するレプリケーションエンジンで、コンソールから自分で操作できます。AWS Transform は検出・ウェーブ計画・ネットワーク作成・リホストを AI エージェントで進めるサービスで、リホストの工程では内部で MGN を使います。どちらを入口にしても、MGN の無料期間と EC2・EBS の課金は同じです。
AWS MGNの費用はいくらですか？
移行元サーバー1台ごとに2,160時間（連続で90日）は MGN の利用料が無料で、その後は1台あたり1時間0.042ドル（月約30ドル）です。単価は全リージョン共通です。ただし無料期間中も、レプリケーション用の EC2・EBS・スナップショットとテスト・カットオーバーインスタンスには通常の料金がかかります。
MGNの対応OSはどこで確認できますか？
ユーザーガイドの「Operating systems supported by MGN」が一次情報です。2026年10月時点で Windows Server 2012〜2025、Windows 10/11、RHEL 6.0〜10.2、Ubuntu 14.04〜24.04、Debian 10〜12 などに対応します。CentOS 7 と Amazon Linux 1 は2026年11月20日、Windows Server 2008 は12月30日でサポートが終わるので、移行日程は終了日から逆算してください。
AWS Server Migration Service（SMS）は今も使えますか？
使えません。新規の移行ジョブ作成は2022年1月1日に止まり、2022年3月31日に提供が終わりました。後継は MGN です。SMS のようにエージェントを入れずに VM を複製する方式は MGN でも2026年10月に新規提供が終わったので、エージェントを導入する前提で計画します。
