【AWS_51】AWS Application Migration Service（AWS MGN） でオンプレLinuxサーバの移行を検証する

　
この記事を書いている人 - WRITER -
ブログ運営者のtkjzblogです。 仕事柄新しいシステムに触れることが多いです。 Windows、Linux（RHEL）がメインです。その他、VMwareやOffice365など仮想環境やクラウド環境も少しですが触れることがあります。 いろいろ忘れがちのため、このサイトへ情報を書き溜めていきたいと思います。 どうぞ、よろしくお願い致します。

Application Migration Serviceとは、オンプレミス環境や他のクラウドにあるサーバーやアプリケーションを、AWS（Amazon Web Services）などのクラウド環境にスムーズかつ効率的に移行するためのサービスです。
移行元サーバーにエージェントをインストールし、データを継続的に複製（レプリケーション）することで、最小限のダウンタイムでサーバーをAWSに移行することを支援します。
MGNは、Migrationの一部の文字を取っているそうです。

今回は、オンプレのVirtualBOXへRockyLinux9.6をインストールし、それをAWS MGNで移行します。
RockyLinux9.6は、Apacheをインストール、ブラウザで表示されることを確認しておき、移行後も表示されることを確認します。
オンプレでは、SSH接続しますが、移行後は、セッションマネージャーで接続します。

サポートされているOSは、公式情報を確認してください。

※公式情報にない「AlmaLinux」で移行しようとしたらカーネルが対応してないとエラーになりましたのでしっかり確認しておいたほうがいいです

今回は、とにかく途中で停止したり、エラー出たりと何回もリトライしました。
そのあたりも記事の中に含めてますので参考にしていただければと思います。

移行の流れとしては、オンプレサーバをAWS側へレプリケーションします。レプリケーションが完了したらテストインスタンスを作成して起動します。
テストインスタンスで動作確認し、問題なければ、カットオーバーインスタンスを作成します。
最終的にカットオーバーすることで本番稼働のEC2インスタンスがリリースされるという、ざっくりした流れになります。

オンプレサーバをAWS側へレプリケーションする際、IAMユーザーのアクセスキーが必要になります。
今回は、レプリケーション用IAMユーザー（mgn-user）を作成しています。それ以外のコンソール作業は、AdministratorAccessの権限がある adminユーザー で作業しています。

以下のサイトを参考にさせていただきました。

AWS MGN(application migration service)を使ってみた https://qiita.com/TADASHI_KANDA/items/3b40b53171f5968038be

今回は何度もリトライして時間もかかったのでところどころ画像とホスト名などが一致してない箇所がありますがご了承ください。

　　　

環境

ホスト端末：Windows11 HOME
VirtualBox：ver.7.2.0
仮想マシン：RockyLinux 9.6（1 vCPU、1GiB メモリ）
ネットワーク：ブリッジモード
有線LAN（※無線LANで検証したら、タイムアウトなど失敗しました）

　　　

IAMユーザ作成

レプリケーション用に使用するユーザを作成します。ユーザ名をmgn-userとして作成しています。
MGNを利用することとAWS CLIで確認することを踏まえてアクセス権をアタッチしています。
※移行にあたりAdministratorAccessは必須ではないですが、今回、AWS CLIでいろいろ確認しながら進めるために付与しています

　・AWSApplicationMigrationAgentPolicy（必須）
　・AdministratorAccess（任意）

作成したIAMユーザー「mgu-user」でアクセスキーを作成します。
AWSマネジメントコンソールで「iam」を検索し、「IAM」をクリックします。
左ペインのユーザーを選択、ユーザー画面で「mgn-user」をクリックし、「セキュリティ認証情報」タブを選択します。
画面を下へスクロールし、「アクセスキー」項目の「アクセスキーを作成」をクリックします。

ユースケースは「コマンドラインインタフェース(CLI)を選択、「上記のレコメンデーションを理解し、アクセスキーを作成します。」にチェックを入れて、「次へ」をクリックします。

説明タグを設定画面は何も入力せず、「アクセスキーを作成」をクリックします。

「.csvファイルをダウンロード」をクリックしてCSVファイルをダウンロードし、「完了」をクリックします。CSVファイルにあるAccess key ID、Secret access keyは、Agentインストールの際に利用します。

　　　

事前準備（オンプレRockyLinux）

Apacheやその他必要なモジュールなどをすべてインストールしておきます。
コマンドと簡単な説明のみ記載しています。
コマンド実行は、ルートユーザーで実行していますが sudo で実行しても問題ありません。

パッケージ最新化、ホスト名変更

パッケージを最新化します。

dnf -y update

ホスト名を変更します。

hostnamectl set-hostname rocky-sv09

　　　

カーネルのヘッダーまたはソースを持つパッケージのインストール

dnf install -y epel-release
dnf install -y gcc make perl kernel-devel kernel-headers dkms bzip2

VirtualBox の場合、kernel-devel と kernel-headers の組み合わせが正しくないと同じエラーが出続けます。
uname -r のカーネルバージョンと同じ結果である必要があります。

uname -r
rpm -q kernel-headers
rpm -q kernel-devel

　　　

【補足】Guest Additionsインストール

自分用のメモです。不要な方は、読み飛ばしてください。

Linuxサーバへログインします。
VirtualBOXの「デバイス」タブ > Guest Additions CDイメージの挿入 をクリックします。
SSHで接続し、cd /run/meda/ユーザー名/VBox_GAs_バージョン名　へ移動します。
VBoxLinuxAdditions.runを実行します。
OS再起動で設定が反映されます。
VirtualBOXの「デバイス」タブ > 光学ドライブ > Remo Disk From Virtual Drive を選択し、Diskイメージを解除します。

　　　

Apacheのインストール、ファイアウォールの設定

Apacheをインストールしてサービスを起動します。

dnf -y install httpd
systemctl start httpd
systemctl enable httpd
systemctl status httpd

AlmaLinux の標準ファイアウォール firewalld が起動しているので「http（80番ポート）」「https（443番ポート）」が通るように追加します。
OSが再起動されても永続的に HTTP を許可（設定を保存）するよう「–permanent」オプションを追加しておきます。

firewall-cmd –add-service=http –permanent
firewall-cmd –add-service=https –permanent

設定を反映します。

firewall-cmd –reload

追加されたことを確認します。

firewall-cmd –list-all

/var/www/html/index.html ファイルを作成し、検証結果が見やすいようにしておきます。
ブラウザから「http://192.168.11.60」へアクセスして表示されることを確認します。

　　　

AWS CLIのインストール

後でわかったことですが、「aws-replication-installer-init」を動作させるためにAWS CLI が必要となりますのでインストールします。

cd /tmp
curl “https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip” -o “awscliv2.zip”
unzip awscliv2.zip
./aws/install
aws –version

aws configure

※IAMユーザーで作成したアクセスキー情報を入力します

APIの呼び出しを行った IAM Identity の情報を返します。

aws sts get-caller-identity

　　　

SSM Agentインストール

MGNで移行したあとに AWS Systems Manager (SSM) のセッションマネージャー接続する予定なので 事前に移行元仮想マシン（VirtualBox上の Rocky Linux 9.6）に SSM Agent をインストールしておきます。 wgetがインストールされてない場合は、インストールします。

dnf -y install wget

Rocky Linux 9.x では AWS が公式に RPM を提供しています。
EPEL ではなく、AWS公式から直接ダウンロードします。
Amazon Linux 用ではなく Red Hat 系 (RHEL 9 向け) の RPM を使用します。
リージョンごとにS3のURLが異なりますが、東京リージョン（ap-northeast-1）の例を示します。

◆ダウンロード

cd /tmp
wget https://s3.ap-northeast-1.amazonaws.com/amazon-ssm-ap-northeast-1/latest/linux_amd64/amazon-ssm-agent.rpm

◆インストール

dnf install -y ./amazon-ssm-agent.rpm

◆サービス開始
プロンプトが返ってきてサービスが起動する（active (running)）まで数分かかりました。なかなか起動しないことが多い感じがしました。

systemctl start amazon-ssm-agent

◆サービス自動起動を有効化

systemctl enable amazon-ssm-agent

◆状態確認

systemctl status amazon-ssm-agent

　　　

事前準備（AWS環境）

AWS環境へ以下リソースを作成します。細かい手順説明は割愛しています。ご了承ください。

・VPC
・インターネットゲートウェイ
・パブリックサブネット
・ルートテーブル
・セキュリティグループ（2つ）

VPC（20250907-vpc）を作成します。

インターネットゲートウェイ（20250907-igw）を作成して、VPCへアタッチします。

サブネット（20250907-subnet）を作成します。IPv4 CIDRは、10.0.7.0/24 としました。

ルートテーブル（20250907-routetable）を作成して、サブネットへ関連付けます。

ルートテーブルへインターネットゲートウェイへのルーティングを追加します。

セキュリティグループを2つ作成します。
理由の1つ目は、今回の移行時に「セキュリティグループを作成」で何度も失敗したことです。
理由の2つ目は、レプリケーションテンプレートとEC2起動テンプレートが利用するセキュリティグループが異なるためです。
レプリケーションテンプレート用セキュリティグループは、MGNが自動で作成するよう設定することもできますが、検証でいろいろはまったこともあり、明示的に確認できるようセキュリティグループを作成しておきたいと思います。

・レプリケーションテンプレート用セキュリティグループ（20250907-rept-sg）
　　インバウンドルール：すべて許可
　　アウトバウンドルール：すべて許可（デフォルト）

・EC2起動テンプレート用セキュリティグループ（20250907-ec2t-sg）
　　インバウンドルール：すべて許可
　　アウトバウンドルール：すべて許可（デフォルト）
　　※テストインスタンス起動前に必要なポートのみに変更する予定

　　　

MGNコンソールの初期設定

※後述してますが、私の環境では「AdministratorAccess」を付与した管理者ユーザーで初期設定を実施しようとしたらエラーになったので、この部分だけルートユーザーで作業しています。

AWSマネジメントコンソールで「Application Migration Service」を検索し、「AWS Application Migration Service」をクリックします。
「使用を開始」をクリックします。
料金は、最初の90日は無料と表示されているので今回はおそらく無料かと思います。

Application Migration Service のセットアップ画面でサービスを初期化してくださいと出るので「サービスをセットアップ」をクリックします。

エラーとなりました。
IAMユーザーに「AdministratorAccess」が付与されていれば大丈夫と公式にもありますがダメでした・・・
時間の制約もあるので今回はいったんAWSアカウントのルートユーザーでサインインし直して進めたいと思います。

ルートユーザーで再実行するとうまくいきました。
この時点でルートユーザーはサインアウトして、元のAdministratorAccess権限のあるIAMユーザーでサインインし直します。

　　　

自分メモ（EC2コンソールの起動テンプレートについて）

検証前に環境をキレイにする目的でEC2コンソールにある「起動テンプレート」を削除して検証を始めましたが削除するとMGNコンソールの起動テンプレート側で起動テンプレートが存在しないとエラーが出ました。エラーを解消するには、以下操作をしたら起動テンプレートが再作成され、解消されたのでメモとして残しておきます。

１．MGNコンソールの起動テンプレート > 編集をクリックします。
２．「一般的な起動設定」項目の上2つのチェックをはずして「テンプレートを保存」をクリックします。
　・インスタンスタイプの適切なサイズ設定を起動
　・起動時にインスタンスを開始
３．再度、MGNコンソールの起動テンプレート > 編集をクリックします。
４．「一般的な起動設定」項目の上2つのチェックを入れて「テンプレートを保存」をクリックします。
　・インスタンスタイプの適切なサイズ設定を起動
　・起動時にインスタンスを開始
５．しばらくしたらEC2コンソールの起動テンプレートに新しい起動テンプレートが作成されます。
６．EC2コンソールの起動テンプレートに表示された「起動テンプレートID」がMGNコンソールの起動テンプレートに表示されている「起動テンプレートID」と一致していることを確認します。

■MGNコンソールの起動テンプレート画面

■EC2コンソールの起動テンプレート

　　　

レプリケーションテンプレートの設定

この時点でルートユーザーはサインアウトして、IAMユーザーでサインインし直しています。

レプリケーションテンプレートの設定

AWSマネジメントコンソールで「Application Migration Service」を検索し、「AWS Application Migration Service」をクリックします。
左ペインで設定 > レプリケーションテンプレート を選択し、画面中央の「編集」をクリックします。

画面遷移後、「ステージング領域サブネット」に事前に作成した「20250907-subnet」を選択します。
レプリケーションサーバーインスタンスタイプ、ボリュームは、デフォルトとします。

「常に Application Migration Service セキュリティグループを使用」のチェックをはずします。
今回はこの設定の意味が曖昧であったためはまりまくりました。特定まではできてませんが、おそらくこの設定のあり、なしによって「セキュリティグループを作成」で失敗していたと思います。
チェックあり、なしで以下のどちらかの状態にしておかないと「セキュリティグループを作成」で失敗すると思います。ご参考まで。

　・「常に Application Migration Service セキュリティグループを使用」のチェックあり
　・「追加のセキュリティグループ」は選択しない
　
　・「常に Application Migration Service セキュリティグループを使用」のチェックなし
　・「追加のセキュリティグループ」は、事前に作成したセキュリティグループを選択する

セキュリティグループは、レプリケーションテンプレート用セキュリティグループ（20250907-rept-sg）を選択します。
その他もデフォルト設定として、「テンプレートを保存」をクリックします。

テンプレートが保存されました。
レプリケーションテンプレートに設定したサブネット、セキュリティグループが事前に作成した値と同じか確認しておきます。

■レプリケーションテンプレートの表示
　　サブネット：subnet-07f7a4bc298207ea7
　　セキュリティグループ：sg-093377b0513a92bb1

■実際の設定画面

　　　

レプリケーションテンプレートの設定値の確認（AWS CLI）

本来、この段階で確認は不要なのですが、検証時に初回同期のセキュリティグループを作成で何度も失敗したことがありました。
原因は、MGNが持っているサブネット、セキュリティグループの情報が古いままでGUIでは、それが確認できず、はまったためです。
この時点でしっかり確認しておけば、初回同期もスムーズに行くと考え、chatgptに確認用シェルスクリプトを作成してもらいました。
シェルスクリプトは2パターンあり、オンプレRockyLinuxサーバにAWS CLIをインストールしているので、そこで実行します。

■パターン１
利用しているリージョンを確認しておきます。今回は東京リージョン「ap-northeast-1」です。
シェルスクリプトを任意の場所に保存し、実行権限を付与します。
以下のとおり、リージョンを引数としてシェルスクリプトを実行します。

./mgn_env_check.sh -r ap-northeast-1

先ほど目視で確認したサブネット、セキュリティグループと比較確認します。一致しており問題ありません。
rct-* は、レプリケーションテンプレートに割り当てられたIDでMGNコンソールを見てみましたが見当たりませんでした。いったん問題なしとして進めます。

■実際の設定画面

　　　

■パターン２
パターン１で確認したレプリケーションテンプレートID、サブネット、セキュリティグループに加え、VPCの情報も追加してシェルスクリプトを実行します。

■実際の設定画面

./mgn_env_check.sh -r ap-northeast-1 -t rct-6654d47950aba9361 -v vpc-0517236d2c0700351 -u subnet-07f7a4bc298207ea7 -g sg-093377b0513a92bb1

すべて[ OK ] なのでMGNが内部で持つ情報にも問題ないことが確認できました。

■シェルスクリプト

※シェルスクリプトはChatGPT（OpenAI）からの提案をもとに、筆者が検証・加筆しています。実行は、「自己責任での利用」「環境に合わせて調整が必要」ですのでご了承のうえ、ご利用ください。

#!/usr/bin/env bash
# mgn_env_check.sh - VPC / Subnet / SG / MGNテンプレートの確認
set -euo pipefail

REGION=""
VPC_ID=""
SUBNET_ID=""
SG_CSV=""
TEMPLATE_ID=""

usage() {
  cat <<EOF
Usage:
  $0 -r <region> [-v <vpc-id>] [-u <subnet-id>] [-g <sg1,sg2,...>] [-t <replication-template-id>]

Examples:
  # すべてのテンプレートの現状を俯瞰
  $0 -r ap-northeast-1

  # あるテンプレートの現状＋想定のVPC/Subnet/SGと整合を確認
  $0 -r ap-northeast-1 -t rct-xxxx -v vpc-abc -u subnet-123 -g sg-111,sg-222
EOF
  exit 1
}

while getopts ":r:v:u:g:t:" opt; do
  case "$opt" in
    r) REGION="$OPTARG" ;;
    v) VPC_ID="$OPTARG" ;;
    u) SUBNET_ID="$OPTARG" ;;
    g) SG_CSV="$OPTARG" ;;
    t) TEMPLATE_ID="$OPTARG" ;;
    *) usage ;;
  esac
done

[[ -z "$REGION" ]] && usage
IFS=',' read -r -a SG_ARR <<< "${SG_CSV:-}"

ok()   { echo -e "[OK ] $*"; }
warn() { echo -e "[WARN] $*"; }
err()  { echo -e "[ERR] $*"; }
info() { echo -e "[INFO] $*"; }
hr()   { echo "----------------------------------------"; }

hr; info "Caller/Region 確認"; aws sts get-caller-identity >/dev/null; ok "AWS CLI 認証済 / Region=$REGION"

hr; info "MGN レプリケーションテンプレート（一覧）"
aws mgn describe-replication-configuration-templates \
  --region "$REGION" \
  --query 'items[].{Id:replicationConfigurationTemplateID, Subnet:stagingAreaSubnetId, SGs:replicationServersSecurityGroupsIDs}' \
  --output table || true

if [[ -n "$TEMPLATE_ID" ]]; then
  hr; info "対象テンプレートの詳細: $TEMPLATE_ID"
  aws mgn describe-replication-configuration-templates \
    --region "$REGION" \
    --query "items[?replicationConfigurationTemplateID=='$TEMPLATE_ID'].{Id:replicationConfigurationTemplateID, Subnet:stagingAreaSubnetId, SGs:replicationServersSecurityGroupsIDs}" \
    --output table || true

  # テンプレートに登録された Subnet/SG を取得
  T_SUBNET="$(aws mgn describe-replication-configuration-templates \
    --region "$REGION" \
    --query "items[?replicationConfigurationTemplateID=='$TEMPLATE_ID'].stagingAreaSubnetId" \
    --output text 2>/dev/null | tr -d '\r')"
  mapfile -t T_SGS < <(aws mgn describe-replication-configuration-templates \
    --region "$REGION" \
    --query "items[?replicationConfigurationTemplateID=='$TEMPLATE_ID'].replicationServersSecurityGroupsIDs[]" \
    --output text 2>/dev/null || true)

  if [[ "$T_SUBNET" != "None" && -n "$T_SUBNET" ]]; then
    T_VPC="$(aws ec2 describe-subnets --region "$REGION" --subnet-ids "$T_SUBNET" --query 'Subnets[0].VpcId' --output text 2>/dev/null || true)"
    [[ "$T_VPC" == "None" || -z "$T_VPC" ]] && err "テンプレートの Subnet $T_SUBNET が見つかりません" || ok "テンプレート Subnet: $T_SUBNET / VPC: $T_VPC"
  else
    warn "テンプレートの Subnet が未設定です"
    T_VPC=""
  fi

  if [[ ${#T_SGS[@]} -eq 0 ]]; then
    warn "テンプレート SG が未設定です"
  else
    for sg in "${T_SGS[@]}"; do
      SG_VPC="$(aws ec2 describe-security-groups --region "$REGION" --group-ids "$sg" --query 'SecurityGroups[0].VpcId' --output text 2>/dev/null || true)"
      [[ -z "$SG_VPC" || "$SG_VPC" == "None" ]] && err "テンプレート SG $sg が見つかりません" || ok "テンプレート SG: $sg / VPC: $SG_VPC"
      [[ -n "$T_VPC" && -n "$SG_VPC" && "$T_VPC" != "$SG_VPC" ]] && err "VPC不一致 (Subnet:$T_VPC vs SG:$SG_VPC)"
    done
  fi
fi

# 想定(VPC/Subnet/SG)が与えられていれば整合性をチェック
if [[ -n "$VPC_ID" || -n "$SUBNET_ID" || ${#SG_ARR[@]} -gt 0 ]]; then
  hr; info "想定リソースの存在/整合性チェック"
  if [[ -n "$VPC_ID" ]]; then ok "想定 VPC: $VPC_ID"; fi

  if [[ -n "$SUBNET_ID" ]]; then
    S_VPC="$(aws ec2 describe-subnets --region "$REGION" --subnet-ids "$SUBNET_ID" --query 'Subnets[0].VpcId' --output text 2>/dev/null || true)"
    [[ "$S_VPC" == "None" || -z "$S_VPC" ]] && err "想定 Subnet $SUBNET_ID が見つかりません" || ok "想定 Subnet: $SUBNET_ID / VPC: $S_VPC"
    if [[ -n "$VPC_ID" && -n "$S_VPC" && "$VPC_ID" != "$S_VPC" ]]; then err "VPC不一致: 想定VPC($VPC_ID) vs Subnet($S_VPC)"; fi
  fi

  for sg in "${SG_ARR[@]}"; do
    SG_VPC="$(aws ec2 describe-security-groups --region "$REGION" --group-ids "$sg" --query 'SecurityGroups[0].VpcId' --output text 2>/dev/null || true)"
    [[ "$SG_VPC" == "None" || -z "$SG_VPC" ]] && err "想定 SG $sg が見つかりません" || ok "想定 SG: $sg / VPC: $SG_VPC"
    if [[ -n "$VPC_ID" && -n "$SG_VPC" && "$VPC_ID" != "$SG_VPC" ]]; then err "VPC不一致: 想定VPC($VPC_ID) vs SG($SG_VPC)"; fi
    if [[ -n "${S_VPC:-}" && -n "$SG_VPC" && "$S_VPC" != "$SG_VPC" ]]; then err "VPC不一致: Subnet($S_VPC) vs SG($SG_VPC)"; fi
  done
fi

hr; info "完了（必要なら上書きスクリプトで修正してください）"

　　　

オンプレRockyLinuxへAWS Replication Agentのインストール

インストール用コマンドの作成

MGNコンソールのソースサーバーからAWS Replication Agentのインストール用コマンドを作成することができます。事前に作成したアクセスキー、リージョンの情報が必要になります。

AWSマネジメントコンソールで「Application Migration Service」を検索し、「AWS Application Migration Service」をクリックします。
左ペインでソースサーバー を選択し、画面中央の「サーバーを追加」をクリックします。

サーバー追加画面で今回はLinuxサーバーを移行するので「1. オペレーティングシステムを選択します」は、「Linux」を選択します。
「2. レプリケーション設定を選択します」は、「すべてのディスクをレプリケート」を選択します。

「3. 必要な認証情報を入力してください」は、事前にダウンロードしたCSVファイルから
Access key ID、Secret access keyをそれぞれ入力します。入力することで6番のコマンド作成へ反映されます。
セッショントークン、4. ユーザー提供のリソース IDは、空欄のままとします。

「5. 次のコマンドを使用して、 インストーラを (またはダウンロード後にコピーします)」、6. 以下のコマンドをコピーして、ソースサーバーのコマンドラインに入力しますから作成されたコマンドをコピーします。私の場合は、以下のとおりです。
コマンドをコピーしたら右下の「戻る」をクリックして戻ります。

　　　

インストール用コマンドの実行

ネットワークの帯域が遅い場合、タイムアウトして処理に失敗することがあります。（私は自宅の無線LAN環境で実行すると何度も失敗しました。有線LANへ変更したら１回で成功しました。）

オンプレサーバで実行します。

ホスト名の設定（任意）や時刻同期（必須）はできています。

まずはモジュールをダウンロードするため、以下コマンドを実行します。（※画像は使いまわしです）

cd /tmp
sudo wget -O ./aws-replication-installer-init https://aws-application-migration-service-ap-northeast-1.s3.ap-sudo 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

次にダウンロードしたモジュール（aws-replication-installer-init）を実行するため、以下コマンドを実行します。
モジュールに実行権限を付与して、そのまま実行されます。
コマンド内にはAccess key ID、Secret access keyが記載されています。

sudo chmod +x aws-replication-installer-init; sudo ./aws-replication-installer-init –region ap-northeast-1 –aws-access-key-id –aws-secret-access-key –no-prompt

sudo chmod +x aws-replication-installer-init; sudo ./aws-replication-installer-init –region ap-northeast-1 –aws-access-key-id ＊＊＊＊＊＊＊＊＊＊–aws-secret-access-key ＊＊＊＊＊＊＊＊＊＊ –no-prompt

（＊＊＊は、事前にダウンロードしたaccess-key-id、aws-secret-access-keyを入力してください。）

ネットワークの状態が問題ないなら2～3分で以下画面まで進みます。

「Installing the AWS Replication Agent onto the source server…」が表示されたら実行ファイルと同階層にログファイル「aws_replication_agent_installer.log」が作成されます。

余談ですが、ネットワークが遅い時は「Downloading the AWS Replication Agent onto the source server…」から進まず、ログファイルも出力されませんでした。
そして40分くらい経過するとエラーとなりました。処理がタイムアウトしていたみたいです。

ログファイル「aws_replication_agent_installer.log」の中身です。ERRORがなくFinishedとなっていれば、そのまま待ちでよいと思います。

10分ほどで処理が完了しました。
Agentのインストールが無事完了するとAWS MGNへ向けて通信が発生し、情報が登録されます。
次は、AWS MGNのコンソールを確認していきます。

　　　

MGN レプリケーション確認

Agentのインストールが無事完了するとAWSへ向けて通信が発生し、情報が登録されます。
AWSマネジメントコンソールで「Application Migration Service」を検索し、「AWS Application Migration Service」をクリックします。
左ペインでソースサーバー を選択します。
すると以下のような画面が表示されます。「アラート」が「 – 」であること、「データレプリケーションステータス」が「開始中」であれば問題ありません。

（私は何度もここで「アラート」が「停止中」となり「セキュリティグループを作成」の処理で止まってはまりました・・・）

ソースサーバー名のリンクをクリックすると、さらに詳細な状況が確認できます。

「移行ダッシュボード」タブを選択します。
「ライフサイクル」でおおまかな進捗が確認できます。

画面を下へスクロールし、「データレプリケーションのステータス」を確認します。
「レプリケーション開始ステップ」で詳細な進捗が確認できます。
（私の場合は、最初の「セキュリティグループを作成」で何度も失敗して苦労しました・・・）

「レプリケーション開始ステップ」がすべて完了すると次に進みます。
「レプリケーションの進行状況」に残り19分と記載されています。

EC2コンソールを確認しています。
AWSマネジメントコンソールで「ec2」を検索し、「EC2」をクリックします。
左ペインでインスタンス を選択します。
「AWS Application Migration Service Replication Server」が作成されて「実行中」になっています。

左ペインで起動テンプレート を選択します。
もう1つ作成されていました。

左ペインでボリューム を選択します。
2つほど作成されています。

左ペインでスナップショット を選択します。
4つほど作成されています。

MGN コンソールへ戻り、ソースサーバー名をクリックします。
「レプリケーションの進行状況」が「最初のレプリケーションが終了しました」となり、「ライフサイクル」も「テストの準備完了」へ進みました。

　　　

MGN テストインスタンス起動

MGNコンソールで「テストの準備完了」になったということは、
オンプレサーバ（VirtualBox上の Rocky Linux 9.6）とAWSの間で レプリケーションが完了し、移行先のテストインスタンスを起動できる準備が整ったということになります。

テストインスタンスやカットオーバーインスタンスが使用するサブネットやセキュリティグループは、「レプリケーションテンプレート」で使用したものではなく、EC2の起動テンプレートの起動設定で決まります。
ざっくりですが、テストインスタンスやカットオーバーインスタンスの意味は以下のとおりです。

●テストインスタンス：レプリケーションしたデータから“検証用”に起動する一時的なEC2インスタンスでOS起動・アプリ動作・接続性を安全に確認するのが目的です。
●カットオーバーインスタンス：本番切替のために“最終差分を取り込んで”起動するEC2インスタンス。

そのEC2の起動テンプレートにサブネットやセキュリティグループの指定が無いと、既定のサブネット（Default）で起動するので明示的に設定しておきます。

　　　

テストインスタンスのEC2起動テンプレートを設定

MGNコンソール > ソースサーバー > 対象ソースサーバー名 をクリックします。
「起動設定」タブを選択、「EC2起動テンプレート」の右側の「変更」をクリックします。

「変更」をクリックします。

「ネットワーク設定」の項目を変更します。

・サブネット：設定したサブネットを指定（20250907-subnet）
・ファイアウォール（セキュリティグループ）：EC2起動テンプレート用に作成したセキュリティグループを指定（20250907-ec2t-sg）

「高度なネットワーク設定」の項目を展開します。

「パブリックIPの自動割り当て」を「有効化」に設定します。
右下の「テンプレートのバージョンを作成」をクリックします。

テンプレートを保存するとEC2コンソールの起動テンプレートが選択された画面が表示されます。
「デフォルトバージョン」と「最新バージョン」がズレていることが確認できます。

EC2 コンソール > 起動テンプレート で対象の起動テンプレートにチェックを入れます。
画面下の「バージョン」タブで、目的のバージョンを選択します。
右上の「アクション」>「デフォルトバージョンを設定」をクリックします。
（「最新」=常に正解ではありません。中身（ネットワーク設定のサブネット、セキュリティグループ）を必ず確認しましょう）

内容を確認し、「デフォルトバージョンとして設定」をクリックします。

起動テンプレートの「デフォルトバージョン」が「3」へ変更されました。

参考：
何回かの検証のなかでデフォルトバージョンを設定した後、「コンテンツのロード中に問題が発生しました」が表示されました。
chatgpt曰く、その赤いバナーは「EC2コンソールが裏で呼んだ“表示用の読み取りAPIのどれか”が失敗した」という意味で、実際の“デフォルト版の更新”という操作自体は完了しているケースが多いとのことでした。（あまり意味はわかっていませんが）
私の場合、「デフォルトバージョン」が更新されていたのでそのまま進めたら、結果カットオーバーまで完了したので参考にしていただければと思います。

　　　

テストインスタンスの起動

MGNコンソールへ戻り、ソースサーバ > ソースサーバ名にチェックを入れます。
テストおよびカットオーバー > テストインスタンスを起動 をクリックします。

「起動」をクリックします。

移行ライフサイクルが「テストが進行中」に変わりました。

ソースサーバ > ソースサーバ名をクリックします。
「起動ステータス」が「待機中」でグルグル回っているのでしばらく待ちます。

ソースサーバ > ソースサーバ名をクリックします。
「起動ステータス」が「起動済み」に変わりました。

EC2コンソールへ移動します。
オンプレから移行対象のサーバ名が作成されているのでチェックし、「詳細」タブを選択します。
パブリックIPアドレスが割り振られていること、VPC、サブネットが設定どおりであることを確認します。

次に「セキュリティ」タブを選択します。
設定どおりのセキュリティグループ（20250907-ec2t-sg）であることを確認します。
インバウンドルール、アウトバウンドルールはすべて許可しています。

インバウンドルールは、この時点で「http」のみにして、接続元も「マイIP」からのみへ変更します。

　　　

テストインスタンスの動作確認

テストインスタンスでは、以下2点を確認します。
　・セッションマネージャーによる接続
　・ブラウザから http://パブリックIPアドレス へアクセスし、WEBページが表示されることを確認

まずは、ブラウザから http://パブリックIPアドレス へアクセスし、WEBページが表示されることを確認します。　 http://52.194.251.5 

次は、セッションマネージャーで接続するための設定をしていきます。
今回は、管理者権限（Administrator Access）を付与した管理者ユーザーである admin でアクセスするので EC2インスタンス に関する権限はすでにあります。
パブリックサブネットのEC2インスタンスへセッションマネージャーで接続するには、追加で以下設定が必要です。
・SSM Agent のインストール（事前準備でインストール、自動起動済み）
・必要なIAMポリシーをEC2インスタンスへアタッチ（AmazonSSMManagedInstanceCore）

詳細は、以下関連ブログを書いているので参考にしてください。

【AWS_48_01】セッションマネージャーを利用してパブリックサブネットのEC2インスタンスへSSH接続する

必要なIAMポリシーをEC2インスタンスへアタッチします。
セキュリティタブをもう一度確認します。IAMロールは割り当たっていません。

IAMポリシー（AmazonSSMManagedInstanceCore）がアタッチされたIAMロール（20250826-role）を事前作成しているのでそれを適用していきます。

EC2コンソールでEC2インスタンスにチェックを入れます。
右上のアクション > セキュリティ > IAMロールを変更 をクリックします。

今回作成したIAMロール（20250826-role）を選択し、「IAMロールの更新」をクリックします。

「セキュリティ」タブを選択するとIAMロール（20250826-role）がアタッチされていることが確認できます。

設定を反映させるため、EC2インスタンスを再起動します。

EC2インスタンスにチェックを入れ、「接続」をクリックします。

「セッションマネージャー」タブを選択し、「接続」をクリックします。

以下のようにプロンプトが返ってきたらログインできています。
「終了」ボタンを押すか、セッション閉じるかで抜けることができます。

　　　

カットオーバーの準備

テストインスタンスの動作に問題なかったので次へ進みます。

MGNコンソールへ移動します。
ソースサーバーにチェックを入れ、テストおよびカットオーバー > 「カットオーバーの準備完了してマーク」をクリックします。
これをしないと次のフェーズに進めないため、必ず実行します。

「続行」をクリックします。

EC2コンソールでテストインスタンスがシャットダウンして「終了済み」になるまで待ちます。

MGNコンソールへ移動し、ソースサーバ > ソースサーバ名をクリックします。
ソースサーバーのライフサイクルは、「カットオーバーの準備完了」へ進みました。

　　　

本番カットオーバー

カットオーバーインスタンスを起動

カットオーバーの準備が完了したので次は、「カットオーバーインスタンスを起動」を実施します。
「カットオーバーインスタンスを起動」を実施すると、移行データから Conversion Server が起動し、カットオーバーインスタンスが作成されるプロセスが開始されます

MGNコンソールへ移動し、ソースサーバ をクリックします。
ソースサーバーにチェックを入れ、テストおよびカットオーバー > 「カットオーバーインスタンスを起動」をクリックします。

「起動」をクリックします。

ソースサーバ名をクリックします。
ソースサーバーのライフサイクルは、「カットオーバーが進行中」に進みます。流れはテストインスタンスを起動した時と同じです。しばらく待ちます。
「起動ステータス」は「待機中」となり、グルグル回っています。

EC2コンソールで確認します。
しばらくするとインスタンスがあらたに1台増えていることが確認できます。
Name列をよく見てみると「AWS Application Migration Service Conversion Server」と「Conversion」という部分が以前と異なることがわかります。
※「AWS Application Migration Service Conversion Server」が2つありますが、1つは前回検証の残骸です

しばらく待つと「AWS Application Migration Service Conversion Server」が「終了済み」となり、あらたにオンプレから移行したサーバが作成されていました。
「実行中」、「停止中」と何度か状態遷移するみたいです。

オンプレから移行したサーバのステータスチェックが「3/3 のチェックに合格しました」になることを確認します。
オンプレから移行対象のサーバ名にチェックを入れて「詳細」タブを選択します。
パブリックIPアドレスが割り振られていること、VPC、サブネットが設定どおりであることを確認します。

MGNコンソールへ移動し、ソースサーバを選択します。
ソースサーバー名をクリックします。
起動ステータスが「待機中」から「起動済み」に変更されました。

　　　　

カットオーバー最終処理

次の操作でEC2インスタンスは「本番機」となります。
MGNコンソールのソースサーバをクリックします。
ソースサーバーにチェックを入れ、テストおよびカットオーバー > 「カットオーバー最終処理」をクリックします。

「最終処理」をクリックします。

移行ライフサイクルが「カットオーバー完了」となりました。

EC2コンソールへ移動します。
ちょっと別件があったため3時間ほど経過してEC2コンソールのインスタンス画面を開くとオンプレから移行したサーバのみになっていました。これはAWSの仕様で切断またはカットオーバー確定の 約90分後に削除されるそうです。
（AWS MGN は、カットオーバーを完了したマシン、または サービスから切断されたマシンに紐づく EC2 起動テンプレートと起動設定を自動削除します。削除は「切断またはカットオーバー確定の 約90分後」に行われます。）

https://docs.aws.amazon.com/mgn/latest/ug/key-considerations.html

セキュリティタブを確認するとIAMロールが外れています。セッションマネージャーで接続するために事前に作成しているIAMロールをアタッチして、EC2インスタンスを再起動しておきます。

セッションマネージャーで接続できました。

「詳細」タブを選択して、パブリックIPアドレスが変更されているので確認しておきます。

ブラウザから「http://パブリックIPアドレス」で接続することもできました！！

http://54.250.108.14 

移行作業の検証は、完了しました。

　　　

その他の確認

カットオーバーしてから数時間経過した後、EC2コンソールを確認してみました。起動テンプレート、ボリューム、スナップショットは、それぞれ1つになっていました。自身の参考メモ程度として記載しています。

　　　

検証後のリソースの削除

■自動削除されるもの
・EC2 起動テンプレート（LT）：
　カットオーバーをFinalize（完了）した 約90分後、そのサーバーに紐づく LT は 自動削除されます（Disconnect した場合も同様）。手動で消す必要は基本ありません。
　
・レプリケーション用リソース（Replication/Conversion サーバ、ステージングディスク等）：
　Finalize cutover時に自動終了/破棄されます。

■手動削除するもの
・EC2インスタンス
　　削除
・ボリューム
　　削除
・スナップショット
　　削除
　
・VPC
　　削除
　　※同時にサブネット、インターネットゲートウェイ、セキュリティグループも削除される
　
・MGN
　　ソースサーバー
　　　切断 > アーカイブ を選択
　　　非表示になるため削除されたのかなと思っていましたが削除はされていませんでした。
　　　※chatgpt 曰く、削除するにはAWS CLI による削除が必要とのことでした。
「アーカイブ済み（Mark as archived）」にしているだけでは、MGNそのものの課金は発生しません。MGNはサービス利用料が基本無料です。

　　　

まとめ

今回何度も検証したので時間はかかりましたが、その分詳細まで理解することができました。細かいところまで検証できたので誰かのお役に立てれば幸いです。

　　　

以下、他の記事をまとめた一覧です。AWSもまとめています。

記事一覧

　　　

この記事を書いている人 - WRITER -
ブログ運営者のtkjzblogです。 仕事柄新しいシステムに触れることが多いです。 Windows、Linux（RHEL）がメインです。その他、VMwareやOffice365など仮想環境やクラウド環境も少しですが触れることがあります。 いろいろ忘れがちのため、このサイトへ情報を書き溜めていきたいと思います。 どうぞ、よろしくお願い致します。

Copyright© しっぱいはせいこうのもと , 2025 All Rights Reserved.