はじめに
背景
企業はオンプレミスや他クラウドで動くサーバーをクラウドに移したい場面が増えています。移行には設定の再現やダウンタイム、作業負荷といった不安が付きものです。特に数十台〜数百台の移行では手作業が大きな負担になります。
AWS MGNとは
AWS Application Migration Service（AWS MGN）は、既存の物理サーバーや仮想マシンをほぼ構成を変えずにAmazon EC2へ移すためのマネージドサービスです。サーバーのディスクをブロック単位で継続的に同期し、テスト用の起動や本番切替を自動化します。たとえば、社内で稼働するウェブサーバーを短期間でEC2へ移し、動作確認後に切り替える、といった流れを簡単にします。
本書の目的と構成
本シリーズでは、AWS MGNの概要、主な機能、典型的なユースケース、他サービスとの違い、導入時の注意点を分かりやすく説明します。初心者でも読み進められるよう具体例を交えて解説します。
読者対象
クラウド移行を検討中のIT担当者、システム管理者、プロジェクトマネージャーを想定しています。技術的な背景が浅くても理解できるよう配慮します。
AWS MGNの概要
何をするサービスか
AWS MGN（Application Migration Service）は、オンプレミスや他クラウドのサーバーを、手作業を減らしてAWS上のEC2に移行するためのサービスです。WindowsとLinuxの両方に対応し、元のサーバーを停止せずにデータを継続的に同期できます。最終的に同期データを使ってEC2を起動し、運用を移します。
対応環境
物理サーバー、仮想サーバー（ハイパーバイザー上）、および他クラウドのサーバーに対応します。OSはWindowsとLinuxが主で、多くの商用・オープンソースアプリケーションに適用できます。
仕組み（簡単に）
MGNはブロックレベルでディスクの差分を複製します。ファイル単位ではなく、ディスクの変更部分だけを効率よく送るため、初回の複製後は差分だけが同期されます。移行元のサーバーは通常どおり稼働し続けられるため、業務中断を抑えられます。
向いている場面と利点
大規模なデータセンター移転や多数のサーバー移行で効果が出ます。移行作業を自動化できるため、手作業のミスや作業量を減らせます。段階的に切り替えやテスト起動ができるので、リスクを小さくして本番移行が可能です。
注意点（導入前に確認すること）
ネットワーク帯域や同期時のデータ量、ターゲットのEC2サイズやストレージ要件を事前に評価してください。また、アプリケーション固有の設定やライセンスは別途確認が必要です。移行計画を立てて段階的に進めることをおすすめします。
主な機能・特徴
以下では、AWS MGN（Application Migration Service）の主要な機能と特徴を、分かりやすい例を交えて説明します。
継続レプリケーションとコンバージョン
レプリケーションサーバーがオンプレミスや他クラウドのサーバーからブロックレベルで差分を継続的に複製します。コンバージョンサーバーは複製されたデータをAWSのボリュームやAMI（イメージ）へ変換します。例えば、データベースサーバーの変更をほぼリアルタイムで同期できるため、移行時のデータロスを抑えられます。
テスト用インスタンスと本番カットオーバーの自動化
複製したデータからテスト用のEC2インスタンスを簡単に起動して動作確認できます。本番切替（カットオーバー）時は、事前に作成したAMIを使って自動的にインスタンスを起動し、DNS切替や停止処理などを組み合わせてダウンタイムを最小化します。実際の運用で、事前検証→本番切替の流れがスムーズになります。
CSVによる一括インポート／エクスポート
多数のサーバー情報をCSVでまとめて取り込めます。IPアドレス、OS、役割といった情報を列で指定するだけで、複数サーバーのレプリケーション設定を短時間で行えます。逆に現在の移行対象リストをCSVで出力して管理ツールやチームと共有することもできます。
アプリケーション単位・ウェーブ単位の移行計画機能
サーバーをアプリケーション単位やウェーブ（段階）にまとめて移行計画を立てられます。依存関係のあるサーバーを同じウェーブに入れる、ピーク時間帯を避けて順番に切り替えるなど段階的に進められます。多数のサーバーを扱う場合に管理がしやすく、リスク分散になります。
運用上の利点
- ダウンタイムを抑えた移行が可能です。
- 大量サーバーの一括管理や段階的移行に向いています。
- テストと本番を切り分けて検証でき、失敗時のロールバックが容易です。
以上が主な機能と特徴です。次章では具体的なユースケースを紹介します。
代表的なユースケース
AWS MGNは、既存のサーバー構成を大きく変えずにAWSへ移す「リフト＆シフト（リホスト）」で特に有効です。ここでは代表的な利用場面を分かりやすく説明します。
1) オンプレミス（VMware / 物理）からの移行
企業のデータセンターにあるVMや物理サーバーを、できるだけ短いダウンタイムでAWSへ移す際に適します。複雑な再設計をしなくても、稼働中のままデータを複製して最終的に切り替える運用が可能です。
2) 他クラウド（例: Azure）からAWSへ
別のクラウド上のシステムをAWSへ移したい場合にも使えます。アプリや設定を大きく書き換えずに移せるため、クラウド間の乗り換えがスムーズです。
3) 別AWSアカウント・別リージョンへの移行
アカウント統合や災害対策（DR）の目的で、同じAWS内でも別アカウントや別リージョンへ移すときに便利です。移行後の検証や切替を計画的に行えます。
4) 段階的な移行や検証を重視する場合
まずは非本番環境を移して動作確認を行い、問題なければ本番を切り替えるといった段階的な移行に向きます。移行中のテストや監視を並行して行えます。
実務上の注意点（簡単に）
- 事前にネットワーク帯域やレプリケーション時間を確認してください。
- 切替前に必ずテスト（リハーサル）を行ってください。
- 移行後の監視やバックアップ設定を忘れずに行ってください。
AWS MGNと他移行サービスの違い
範囲（何を移すか）
AWS MGNはサーバー丸ごと（OS・アプリ・設定・データ）を対象にします。移行後はほぼ同じ環境をEC2上で動かせます。他サービス（例：AWS DMS）はデータベースやデータの移行に特化し、テーブルやスキーマ単位での変換・転送が中心です。
出力先と変換の有無
MGNは主にEC2を出力先にし、OSやアプリの変更を最小限にします。DMSはRDSや別のDBをターゲットにし、スキーマ変換や型変換が必要になる場面が多いです。
変更量と工数
MGNはリホスト（lift-and-shift）を自動化し、手作業を減らせます。一方、DB移行はスキーマ調整やテストが増え、工数がかかります。
ダウンタイムと整合性
どちらもレプリケーションで切替時間を短くできますが、DMSはデータ整合性検証や差分同期の機能が充実しています。アプリも含めてそのまま動かしたい場合はMGNが有利です。
使い分けの具体例
・Webサーバー＋アプリ＋ファイルをそのまま移す：MGNが向きます。
・Oracle→AuroraなどDBの移行・近代化：DMS＋移行ツール（例：SCT）が向きます。
選び方のポイント
移行対象の範囲と目的（そのまま動かすか、構造を変えるか）を最初に決めると選びやすいです。セキュリティやネットワーク要件、テスト工数も考慮してください。
使い始める際のポイント
準備チェックリスト
対象サーバーのOSやバージョン、ライブラリがAWS MGNとEC2でサポートされているか確認します。具体例：Windows Server 2016/2019、RHELやUbuntuのLTS版など。ネットワークは管理用にTCP 443（MGN）やSSH/RDPの経路を確保してください。
テスト移行の実施
本番前に必ずテストインスタンスで動作検証します。アプリ起動、接続先（DBや外部API）、パフォーマンスを確認します。期待値と実測値を記録して比較できるようにします。
カットオーバー手順とロールバック
カットオーバー手順を順序立てて作成します（DNS TTL短縮、同期停止、最終レプリケーション、起動確認）。万が一に備え、ロールバック手順も用意します（元サーバーの起動、DNS復元、データ確認）。
ネットワーク・セキュリティ注意点
セキュリティグループ、NACL、IAMロールを適切に設定します。移行用に一時的にアクセスを緩める場合は、終了後に元に戻す運用を決めます。
運用移行後の確認項目
性能監視、ログ確認、バックアップ設定、運用担当者への引き継ぎを行います。問題発生時の連絡フローと担当者を明確にしておきます。
