AWS Application Migration Service (MGN)

解決する課題

オンプレミスや他クラウドで動いているサーバ群を AWS へ移したいとき、アプリケーションを作り直したり構成を組み替えたりしていては時間もリスクも膨らみます。多くの移行では、まず「今動いているものをそのまま AWS に載せ替える」ことが現実的な第一歩です。MGN は、稼働中のサーバをブロックレベルで継続的に AWS へレプリケーションし、本番を止めずに移行準備を整え、短い切替時間だけで AWS 上の EC2 として起動できるようにするサービスです。

• 大量のサーバを、できるだけアプリを改修せずそのまま AWS へ移したい
• 移行のために本番を長時間止めることが許されない
• 移行先で本当に動くかを、本番に影響を与えずに事前検証したい
• 物理・仮想・他クラウドなど多様な元環境を同じやり方で移行したい

主要概念と用語

• ソースサーバ: 移行元となる、現在稼働しているサーバ。物理マシン、仮想マシン、他クラウドのインスタンスなどが該当する
• レプリケーションエージェント: ソースサーバにインストールする小さなエージェント。OS を意識せずディスクをブロックレベルで読み取り、変更を継続的に送り続ける
• ステージングエリア: 移行先 AWS アカウント内に用意される、レプリケーションを受け止める領域。低コストなリソースでデータを保持し続ける
• 継続レプリケーション: 初回の全ブロック同期のあと、ソース側の変更だけを継続的に転送し続けて移行先を最新に保つ仕組み
• テスト起動（テストインスタンス）: 本番を止めずに、レプリケート済みデータから移行先で実際に EC2 を立ち上げて動作確認する工程
• カットオーバー: 最終的に本番を AWS 側へ切り替える工程。直前の差分を反映してから移行先インスタンスを起動する
• 起動テンプレート / 起動設定: 移行先で起動する EC2 のインスタンスタイプ、サブネット、セキュリティグループなどを定義する設定
• ポストランチアクション: 移行先インスタンス起動後に自動実行する処理。エージェント導入や設定変更などの後処理を自動化できる

仕様・制限・クォータ

• レプリケーションはブロックレベルで行われ、OS やファイルシステムの種類に依存せずディスク全体を移行先へ複製する
• 移行はおおむね「エージェント導入 → 継続レプリケーション → テスト起動 → カットオーバー」という共通フローで進む
• 移行元は物理サーバ、各種ハイパーバイザ上の仮想マシン、他クラウドのインスタンスなど幅広い元環境に対応する
• ステージングエリアでは、レプリケーションを受けるために低コストなリソース（小さめのインスタンスや安価なボリューム）が使われ、移行先で起動する本番用 EC2 とは分けて考える
• 同時に扱えるソースサーバ数や、リージョン・アカウントあたりの上限はサービス側で定められており、大規模移行では並行数の管理が必要になる

内部の仕組み

MGN ではまず、移行したいソースサーバにレプリケーションエージェントを導入します。エージェントはディスクをブロックレベルで読み取り、初回はすべてのブロックを移行先アカウントのステージングエリアへ転送します。この初期同期が終わると、以降はソース側で変化したブロックだけを継続的に送り続け、移行先を本番に追従させ続けます。サーバは止めずに動かしたままレプリケーションが進むのが特徴です。

十分に同期できたら、本番に影響を与えずにテスト起動を行えます。ステージングのデータから移行先で実際の EC2 を立ち上げ、アプリが正しく動くかを検証します。問題がなければカットオーバーに進み、直前までの差分を反映してから移行先インスタンスを起動し、本番を AWS 側へ切り替えます。テスト起動もカットオーバーも、起動テンプレートで定義したインスタンスタイプやネットワーク設定に従って EC2 が作られます。

設計パターン / ベストプラクティス

• テスト起動で事前検証: カットオーバー前に必ずテスト起動で動作確認し、ネットワークや依存関係の問題を本番影響なく洗い出す
• アプリ単位でまとめて切り替える: 相互に依存するサーバ群は同じタイミングでカットオーバーし、片側だけ移行して整合が崩れる事態を避ける
• 早めにエージェントを入れて同期を進めておく: レプリケーションは継続するため、カットオーバーの直前ではなく余裕をもって同期を開始し、切替時の差分を小さくする
• ポストランチアクションで後処理を自動化: 監視エージェント導入や設定投入などを起動後に自動実行し、移行直後の手作業を減らす
• 移行してから最適化: まずリフト＆シフトで載せ替え、その後にインスタンスタイプの適正化やマネージドサービスへの置き換えを段階的に進める
• 切り戻し方針を決めておく: カットオーバー後に問題が出た場合の判断基準と手順を事前に用意しておく

運用・監視

• 各ソースサーバのレプリケーション状態（初期同期の進捗、継続同期の遅延、健全性）はコンソールや API で追跡できる
• CloudWatch と連携し、移行の進捗やリソースの状態を監視できる
• テスト起動の結果やカットオーバーの履歴を確認し、どのサーバがどの段階にあるかを移行ダッシュボードで把握する
• レプリケーションの遅延が大きいときは、ソース側の負荷、ネットワーク帯域、ステージングリソースの能力を疑う
• カットオーバーが完了したサーバは移行完了としてマークし、不要になったステージングリソースを片付けて課金を止める

コスト

• MGN のサービス利用自体は、ソースサーバ単位での利用に対して課金される形が基本で、無償で使える初期期間が設けられている
• 継続レプリケーション中は、移行先アカウント内のステージングリソース（小さなインスタンスやボリューム）の費用が発生する
• テスト起動やカットオーバーで作られる EC2 や EBS は、通常どおりそれらのリソースの料金がかかる
• 移行元が AWS の外にある場合は、データ転送に関わる費用も考慮する
• 移行が完了したら、ステージングリソースや不要になったテスト用インスタンスを速やかに片付けるのがコストの基本

セキュリティ

• レプリケーションデータの保存時暗号化は KMS の鍵で管理できる
• ソースから AWS への転送時の暗号化が行われ、本番データが平文で流れないようにする
• MGN の操作権限や、起動する EC2 が引き受けるロールは IAM で最小権限に絞る
• ステージングや移行先 EC2 は VPC 内に配置し、必要なネットワーク経路だけを開ける設計にする
• レプリケーションのために開ける通信経路は、必要なポートと送信元に限定して攻撃面を広げない

Well-Architected の観点

• 運用上の優秀性: 共通フローで多数のサーバを計画的に移行でき、テスト起動とポストランチアクションで検証と後処理を仕組み化できる
• 信頼性: 継続レプリケーションで移行先を最新に保ち、テスト起動で事前検証してからカットオーバーすることで切替リスクを下げる
• セキュリティ: KMS による保存時暗号化、転送時の暗号化、IAM の最小権限、VPC でのプライベート配置
• コスト最適化: ステージングは低コストリソースで保持し、移行完了後に速やかに片付けてムダを排除する

試験で問われるポイント

関連サービス・比較

データベースの移行に特化した AWS DMS とよく対比されます。MGN はサーバ丸ごとをディスクごと移すのに対し、DMS はデータベースの中身を移します。どちらも継続同期で最小停止を狙いますが、移す対象の粒度が異なります。

ハンズオン / CLI例

# このリージョンで MGN を初期化（ステージング用のロールなどを準備）
aws mgn initialize-service

# 登録済みのソースサーバ一覧を確認
aws mgn describe-source-servers

# 対象サーバのテスト起動を開始（本番に影響を与えず検証）
aws mgn start-test \
  --source-server-ids s-1234567890abcdef0

# 検証が問題なければカットオーバーを実行して本番を切り替え
aws mgn start-cutover \
  --source-server-ids s-1234567890abcdef0

# カットオーバー完了後、移行完了としてマークしてステージングを整理
aws mgn finalize-cutover \
  --source-server-id s-1234567890abcdef0