AWS MGNを複数アカウントで使う場合、Organizations連携による「移行状況の一元管理」と、アカウント・リージョンごとの「初期設定の配布」を分けて設計します。Global viewで操作できることを、そのまま「OU配下の初期設定をすべて一括作成できる」と読み替えないことがポイントです。
本記事は、複数アカウントへの初期設定を簡略化したいという問い合わせを出発点に、公開されているAWS公式資料で対応範囲を整理したものです。対象はAWS Transform MGN（旧Application Migration Service）の移行基盤を準備する担当者です。仕様確認日：2026年9月15日。
まず分ける3つの作業
| 目的 | 確認する機能 | 混同しやすい点 |
|---|---|---|
| 複数アカウントの移行をまとめて管理 | Organizations連携・Global view | 閲覧できることと、すべての設定を一括配布できることは別 |
| これから登録するサーバーの標準値を揃える | レプリケーションテンプレート・起動設定テンプレート | 既存サーバーへの反映範囲を別に確認する |
| サブネットやSGなどを各環境へ準備 | ネットワーク構築と設定の自動化 | 各アカウント・リージョンで異なるIDをそのまま複製しない |
Global viewでできることと制約
Organizations連携により、複数アカウントのソースサーバー、アプリケーション、Waveをまとめて管理できます。組織の管理と移行運用を分離する場合は、委任管理者の利用も検討できます。連携方法はMGNとAWS Organizationsの公式説明を確認してください。
Global viewの操作一覧には、レプリケーション設定の変更、一般的な起動設定の編集、テスト起動やカットオーバーなどが記載されています。一方、複数サーバーのレプリケーション設定編集には「同じアカウント」の条件があり、起動設定の編集もgeneral launch settingsに限定されています。
したがって、Global viewを使うからといって、別アカウントの全設定を一つの操作で同じ値にできるとは判断できません。対象操作・アカウント・サーバー登録状態を先に確認します。Organizationsの閲覧権限だけで移行操作の全権限が揃うわけでもありません。
初期設定で共通化する値と、環境ごとに変える値
以下は設定管理表の例です。必須パラメータの完全な一覧ではなく、自動化の入力を整理するために使います。
| 設定 | 共通化する方針の例 | 環境ごとの確認 |
|---|---|---|
| ステージングサブネット | 専用サブネットを使う | 実際のサブネットIDと到達性 |
| レプリケーションサーバー | 性能・運用要件に応じたインスタンスタイプ | 対象リージョン・AZでの利用条件 |
| ストレージ暗号化 | 標準暗号化かカスタマー管理キーか | 使用するKMSキーARNと権限 |
| セキュリティグループ | 必要な通信元・宛先・ポート | SG IDと実際の接続経路 |
| データルーティング | プライベートIPでの転送方針 | 往復経路とAPI向け接続 |
| タグ | 用途・移行Wave・運用担当のキー | 各移行案件に対応する値 |
APIには、InitializeService、CreateReplicationConfigurationTemplate、CreateLaunchConfigurationTemplateがあります。サービス初期化、レプリケーション設定、起動設定は別の操作として扱います。MGNの起動設定テンプレートとEC2 Launch Templateも区別し、どちらに保存する値かを確認してください。
テンプレート変更は既存サーバーへ自動反映される？
レプリケーションテンプレートを変更しても、すでに登録済みのサーバーには自動反映されません。これから追加するサーバーに適用される標準値と、登録済みサーバーの個別設定を分けます。既存サーバーを変更する場合は、対象サーバーまたは同一アカウントのグループの設定を確認します。レプリケーションテンプレートの適用範囲に基づく重要な確認点です。
自動化するときの実装順序
次の流れは、本記事で提案する運用設計です。AWSが提供するOU一括初期設定機能の手順ではありません。
- 対象アカウントとリージョンを一覧化し、除外環境と実行担当を決める。
- 各環境のサブネット・SG・KMSキーなどの対応表を準備する。
- 初期化済みか、既存テンプレートがあるか、登録済みサーバーがいるかを読み取る。
- 現在値との差分を出し、新規作成と更新を分ける。毎回Createを実行するだけの処理にしない。
- 1アカウントの検証環境で、サーバー登録からレプリケーション開始まで確認する。
- 小さな単位で展開し、アカウント・リージョン・実行結果・変更前後の値を記録する。
途中で失敗した場合は成功済みの環境を巻き戻すか、未完了の環境だけ再実行するかを決めておきます。APIによる自動化は、権限・再実行・例外処理まで含めて設計すると手作業の削減につながります。
ネットワークはテンプレート保存だけでは完成しない
プライベートIPでのレプリケーションを選んでも、MGN・EC2・S3への接続経路が自動的に整うわけではありません。DNS、エンドポイント、SG、ポリシーを確認してください。特に、VPC内からS3へのアクセスはGateway型に限定されません。構成例と必須要件の違いはMGNの閉域エンドポイント設計で整理しています。
設計レビューの確認メモ
対象アカウント・リージョン：
Organizations連携・運用担当：
登録前の標準テンプレート：
登録済みサーバーの変更対象：
サブネット・SG・KMSキーの対応表：
テスト対象サーバー：
失敗時の再実行方法：
変更前の値と切り戻し条件：構成全体の確認順序はAWS閉域ネットワークの設計・調査ガイドを参照してください。本記事ではAWSアカウントへの設定変更や実機での移行試験は行っていません。
