AWS Migration本番運用Vol1｜DMS × MGN × Snow Family × Application Migration Service 完全ガイド

1. なぜMigration本番運用 Vol1か — 6つのR + 移行サービス4本柱選定 + 全17軸からの架橋

1-1. 全17軸完遂後に直面するクラウド移行プロジェクトの6つの壁

AWS本番運用シリーズ全17軸を完遂したエンジニアが次に直面するのが「本番クラウド移行プロジェクト」という実践的な戦場だ。ネットワーク・データベース・セキュリティ・コンテナ・IaCの各軸でベストプラクティスを習得しても、移行プロジェクトには固有の難しさがある。本稼働中のオンプレミスシステムを止めることなくAWSに移行するという「ダブルバインド」を解決するのが Migration本番運用シリーズの目的だ。

全17軸完遂者が Migration プロジェクトで直面する6つの壁:

1. 6Rs選定の壁: どのワークロードをRehost/Replatform/Refactorするかを決める判断フレームワーク不在
2. DMS vs MGNの判断: DBはDMS、ServerはMGNというシンプルな分割がどこで崩れるかの見極め
3. Snow Family タイムライン: Snowball 発送から AWS取り込みまでの現実的なスケジュール認識
4. Wave設計の壁: 100台を一括Cutoverしてはいけない理由とWave分割の原則の習得
5. 検証ストラテジの壁: Test Cutover を一度もせずに本番Cutoverを迎える事故の防止
6. Cutover Windowの壁: ダウンタイム許容値と CDC Replication Lag の現実的な制約整合

1-2. 6つのR (6Rs) — 移行戦略選択フレームワーク

6Rs とは AWS が提唱する移行戦略の分類体系だ。各ワークロードをどの戦略で移行するかが、コスト・リスク・工数すべてに影響する。全17軸を習得した段階でも、6Rs の判断を体系化しないまま移行プロジェクトに入ると Rehost 一択になりクラウド最適化の機会を逃す。

Rehost vs Replatform の判断基準: アプリケーションがOS依存のミドルウェアを持たず、DB接続先変更のみで動作する場合はReplatform (RDS化) が優先だ。ライセンス費用の節約と運用コスト削減を同時に達成できる。Refactorは移行フェーズには持ち込まないのが原則 — 移行完了後の最適化フェーズで実施することでスコープを制御する。

実際の規模感: 50ワークロード移行プロジェクトの典型構成は Rehost 30% / Replatform 40% / Retire 20% / Retain 5% / Repurchase 5% 程度だ。Refactorを移行フェーズに混在させると工数が3倍になる事例が多く、スコープ管理の失敗につながる。

1-3. 移行サービス4本柱の選定マトリクスと本記事の対象範囲

移行プロジェクトで扱うワークロードのカテゴリに応じて、使用するAWSサービスが決まる。

2. DMS本番運用 — Replication Instance × Endpoint × Task × CDC × SCT × 同種・異種DB移行

2-1. DMS アーキテクチャ4要素の役割

AWS Database Migration Service (DMS) は Source DB → Replication Instance → Target DB というパイプラインで動作する。4要素の役割を正確に理解することがDMS本番運用の出発点だ。

DMS 4要素:

1. Replication Instance: 移行処理を実行するマネージドサーバー。SourceDBから変更を読み取りTargetに書き込む中間処理エンジン。本番用は Multi-AZ 必須。
2. Source Endpoint: 移行元DBへの接続設定。接続文字列・認証情報・SSL設定・DB固有の追加パラメータを含む。
3. Target Endpoint: 移行先DBへの接続設定。Source Endpoint と同じ構造だが Target 特有のパラメータ (BulkLoad, BatchApply 等) を持つ。
4. Replication Task: Full Load / CDC / Full Load + CDC の移行タスク定義。対象テーブル選択・変換ルール・ログ設定を含む。

DMS がサポートする主なSource/Target:

2-2. Replication Instance — クラス選定 × Multi-AZ × VPC配置

Replication Instance のサイジングはDMS移行の成否を左右する最重要パラメータだ。サイジング不足がCDC Lag増大の直接原因になる。移行プロジェクト開始時にサイジングを確定し、本番移行前に負荷テストで検証することが鉄則だ。

インスタンスクラス選定指針:

基準となる選択: 本番環境では dms.r5.xlarge を最低ライン とする。dms.t3 系はバースト性能のためCDCの継続的な処理に向かない。LOB (Large Object Binary) カラムが多い場合はメモリ重視で dms.r5.4xlarge 以上を検討する。

Multi-AZ 設定: 本番環境では必須。Replication Instance のスタンバイを別AZに配置することで、AZ障害時にも移行タスクが継続する。Multi-AZ 有効化は追加コスト (約2倍) を伴うが、移行プロジェクトの途中でAZ障害が発生した場合の影響を考慮すると必須投資だ。

VPC配置設計:
– Replication Instance を Source DB と同一VPC または Peering 済みVPCに配置する
– Source がオンプレミスの場合: DirectConnect または VPN 経由でPrivate IP アクセスを確立
– Target が RDS/Aurora の場合: 同一VPC またはVPC Peering + Security Group 許可
– Replication Instance → Source: Source DB Port (3306/5432/1521) へのアウトバウンド許可
– Replication Instance → Target: Target DB Port へのアウトバウンド許可
– パブリックアクセスは原則無効化 (publicly_accessible = false)

2-3. Source/Target Endpoint — 接続設定 × SSL/IAM認証 × 接続テスト

Endpoint 設定はDMS タスクの前提条件だ。接続テスト (Test Connection) を必ずパスさせてからタスクを作成する。認証情報はSecrets Managerで管理し、プレーンテキストのパスワードをTerraformに埋め込まないのが本番ルールだ。

MySQL Source Endpoint 設定例:

resource "aws_dms_endpoint" "source_mysql" {
  endpoint_id= "prod-source-mysql"
  endpoint_type = "source"
  engine_name= "mysql"

  server_name= "mysql-onprem.internal.example.com"
  port = 3306
  database_name = "appdb"
  username= "dms_migration_user"
  password= var.source_db_password  # Secrets Manager から渡す

  ssl_mode = "require"

  mysql_settings {
 events_poll_interval = 5
 target_db_type = "specific-database"
 parallel_load_threads = 4
 server_timezone= "UTC"
  }

  tags = {
 Environment = "production"
 Role  = "dms-source"
  }
}

IAM認証 (Aurora/RDS の場合): パスワード認証の代わりに IAM Database Authentication を使用すると認証情報の管理コストを削減できる。DMS Endpoint の AuthMechanism を iam_auth に設定し、Replication InstanceにIAMロールをアタッチする。

接続テスト手順:

# DMS Endpoint 接続テスト
aws dms test-connection \
  --replication-instance-arn "arn:aws:dms:ap-northeast-1:123456789012:rep:REP_INSTANCE_ID" \
  --endpoint-arn "arn:aws:dms:ap-northeast-1:123456789012:endpoint:SOURCE_ENDPOINT_ID"

# 結果確認 (Status が "successful" になるまで待機)
aws dms describe-connections \
  --filters "Name=replication-instance-arn,Values=arn:aws:dms:ap-northeast-1:123456789012:rep:REP_INSTANCE_ID" \
  --query "Connections[*].[EndpointIdentifier,Status,LastFailureMessage]" \
  --output table

よくある接続失敗パターン:

2-4. Replication Task — Full Load vs CDC vs Full Load+CDC 選択基準

3種類のTask モード:

Full Load: Source DB の全データをTargetに一括コピーする。移行中はSourceが書き込み可能なため、Full Load完了時点とTarget DBの内容が一致しない可能性がある。静的データの移行や、移行後にSourceを廃止するシナリオ向けだ。

CDC (Change Data Capture) Only: Full Load が完了済みの状態から以後の変更差分のみを同期する。別手段でBase Snapshotを作成した場合 (例: RDS Snapshot リストア) に組み合わせて使用する。

Full Load + CDC (本番第一選択): Full Load 完了後に自動的にCDC同期を開始する。Cutover直前まで Source の変更を継続同期し、Replication Lag が規定値以内 (通常5-10秒) になった時点でCutoverを実施する。本番DB移行での標準モードだ。

Task 設定の重要パラメータ:

2-5. CDC 本番運用 — table設定 × トリガー罠 × PostgreSQL/MySQL固有設定

CDC は Source DB の変更ログを読み取ってTargetに適用するメカニズムだ。DBエンジンによってログの種類と設定が異なる。設定ミスがLag増大の直接原因になるため、移行前の確認を徹底する。

MySQL / Aurora MySQL の CDC 設定:

MySQLはbinlogを使用してCDCを実現する。ROW フォーマットが有効になっていることが前提条件だ。

# MySQL binlog 設定確認 (Source DB で実行)
SHOW VARIABLES LIKE 'log_bin'; # ON であることを確認
SHOW VARIABLES LIKE 'binlog_format'; # ROW であることを確認
SHOW VARIABLES LIKE 'binlog_row_image'; # FULL であることを確認

# RDS Parameter Group で設定する場合
# binlog_format = ROW
# binlog_row_image = FULL
# binlog_expire_logs_seconds = 86400  # 移行期間 + 24時間分は最低限保持

PostgreSQL / Aurora PostgreSQL の CDC 設定:

PostgreSQLはWAL (Write-Ahead Log) の Logical Replication を使用する。wal_level = logical の設定と replication slots の適切な管理が重要だ。

# PostgreSQL WAL設定確認
SHOW wal_level; # logical であることを確認
SHOW max_replication_slots; # DMS用スロット数 (最低1) 以上であることを確認

# DMS用 replication slot の確認
SELECT slot_name, plugin, active, restart_lsn, confirmed_flush_lsn
FROM pg_replication_slots;

# RDS PostgreSQL Parameter Group 設定
# rds.logical_replication = 1(自動的にwal_level=logicalが有効になる)
# max_replication_slots >= 5
# max_wal_senders >= 5

2-6. SCT (Schema Conversion Tool) — 同種DB移行 vs 異種DB移行

Schema Conversion Tool (SCT) は Source DB のスキーマを Target DB のスキーマに変換するデスクトップツールだ。使用が必要かどうかはDBエンジンの組み合わせによって決まる。

同種DB移行 (SCT不要):

同種DB移行ではDMSがスキーマをそのままコピーするため、SCTによる変換作業は不要だ。DMSタスクを作成しFull Load + CDCを実行するだけで移行が完了する。

異種DB移行 (SCT必須):

異種DB移行の作業フロー:

1. SCT でスキーマ解析: Source DBに接続し変換率レポートを取得。変換不可能なオブジェクト (PL/SQL Procedure, Oracle-specific Function等) を特定する。
2. 変換不可能オブジェクトの手動修正: SCT が変換できないコード (Action Required マーカー) を Target DB用言語で手動書き直しする。
3. 変換スキーマをTarget DBに適用: SCTで変換されたDDLをTarget DBに適用し、Applicationの接続先を切り替えて互換性テストを実施する。
4. DMS でデータ移行: スキーマが準備できた状態でDMSタスク (Full Load + CDC) を実行する。

Oracle → Aurora PostgreSQL の変換限界:

• PL/SQL パッケージ・コレクション型: SCTは基本構造を変換するが、複雑なパッケージは手動修正が必要
• Oracle 固有関数 (DECODE, NVL2, ROWNUM): PostgreSQL 互換の関数 (CASE WHEN, COALESCE, ROW_NUMBER()) に書き直し
• シーケンス: OracleのSequenceはPostgreSQLのSERIAL/IDENTITYに変換可能だが、起動値の同期に注意
• DB Link: PostgreSQLの postgres_fdw に変換可能だが、パフォーマンス特性が異なるため負荷テストが必要

2-7. DMS Terraform 完全設定例 — Replication Instance + Task + CloudWatch Alarm

# DMS Replication Subnet Group
resource "aws_dms_replication_subnet_group" "main" {
  replication_subnet_group_id = "prod-dms-subnet-group"
  replication_subnet_group_description = "DMS Replication Subnet Group for production migration"
  subnet_ids = [
 aws_subnet.private_1a.id,
 aws_subnet.private_1c.id,
  ]
  tags = { Environment = "production" }
}

# DMS Replication Instance (本番最小構成)
resource "aws_dms_replication_instance" "main" {
  replication_instance_id = "prod-dms-replication-instance"
  replication_instance_class = "dms.r5.xlarge"

  multi_az = true# 本番必須
  allocated_storage = 100 # GB: CDCログバッファ用

  replication_subnet_group_id = aws_dms_replication_subnet_group.main.id
  vpc_security_group_ids= [aws_security_group.dms_sg.id]
  publicly_accessible= false

  engine_version= "3.5.3"
  auto_minor_version_upgrade= true
  preferred_maintenance_window = "sun:03:00-sun:04:00"  # 移行期間外を設定

  tags = {
 Environment = "production"
 Project  = "database-migration"
  }
}

# DMS Replication Task (Full Load + CDC)
resource "aws_dms_replication_task" "full_load_cdc" {
  replication_task_id= "prod-mysql-to-aurora-fullload-cdc"
  migration_type  = "full-load-and-cdc"
  replication_instance_arn = aws_dms_replication_instance.main.replication_instance_arn
  source_endpoint_arn= aws_dms_endpoint.source_mysql.arn
  target_endpoint_arn= aws_dms_endpoint.target_aurora.arn

  table_mappings = jsonencode({
 rules = [
{
  rule-type = "selection"
  rule-id= "1"
  rule-name = "include-all-tables"
  object-locator = {
 schema-name = "appdb"
 table-name  = "%"
  }
  rule-action = "include"
},
{
  rule-type = "selection"
  rule-id= "2"
  rule-name = "exclude-temp-tables"
  object-locator = {
 schema-name = "appdb"
 table-name  = "temp_%"
  }
  rule-action = "exclude"
}
 ]
  })

  replication_task_settings = jsonencode({
 TargetMetadata = {
SupportLobs  = true
FullLobMode  = false
LimitedSizeLobMode = true
LobMaxSize= 32768
 }
 FullLoadSettings = {
TargetTablePrepMode= "DO_NOTHING"
MaxFullLoadSubTasks= 8
CommitRate= 50000
 }
 Logging = {
EnableLogging = true
LogComponents = [
  { Id = "SOURCE_UNLOAD", Severity = "LOGGER_SEVERITY_DEFAULT" },
  { Id = "TARGET_LOAD",Severity = "LOGGER_SEVERITY_DEFAULT" },
  { Id = "TASK_MANAGER",  Severity = "LOGGER_SEVERITY_DEFAULT" }
]
 }
 ControlTablesSettings = {
historyTimeslotInMinutes = 5
StatusTableEnabled = true
SuspendedTablesTableEnabled = true
 }
  })

  tags = {
 Environment = "production"
 TaskType = "full-load-cdc"
  }
}

# CloudWatch Alarm: CDC Replication Lag 監視
resource "aws_cloudwatch_metric_alarm" "dms_cdc_lag" {
  alarm_name = "dms-cdc-replication-lag-high"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 3
  metric_name= "CDCLatencySource"
  namespace  = "AWS/DMS"
  period  = 60
  statistic  = "Average"
  threshold  = 60# 60秒超でアラート

  dimensions = {
 ReplicationInstanceIdentifier = aws_dms_replication_instance.main.replication_instance_id
 ReplicationTaskIdentifier  = aws_dms_replication_task.full_load_cdc.replication_task_id
  }

  alarm_actions = [aws_sns_topic.alerts.arn]
  ok_actions = [aws_sns_topic.alerts.arn]
}

2-8. mermaid01 — DMS Full Load + CDC ライフサイクルフロー

graph LR
  A["Pre-Migration Assessment<br/>(SCT解析 / 接続テスト / 権限確認)"] --> B["Full Load開始<br/>(全テーブル並列コピー)"]
  B --> C["Full Load完了<br/>(CDC自動切替)"]
  C --> D["CDC同期中<br/>(差分変更をリアルタイム反映)"]
  D --> E{"CDC Lag<br/>≤ 10sec?"}
  E -->|No| F["Lag監視継続<br/>(Replication Instance増強検討)"]
  F --> D
  E -->|Yes| G["Cutover判断<br/>(Business承認 / Maintenance Window確認)"]
  G --> H["Application停止<br/>(新規書き込み停止)"]
  H --> I["最終CDC同期<br/>(残差分 0件確認)"]
  I --> J["Target切替<br/>(DNS / Connection String変更)"]
  J --> K["本番Cutover完了<br/>(Source DB 読み取り専用化)"]
  K --> L["移行後検証<br/>(Data Validation / Application動作確認)"]

3. MGN本番運用 — Replication Agent × Wave設計 × Test Cutover × Production Cutover × Re-host vs Re-platform

AWS Application Migration Service（MGN）は、オンプレミスや他クラウドで稼働するサーバーをAWSへリフト＆シフト移行するための中心サービスだ。MGNが扱う領域は「OS ごと丸ごと AWS へ持ち込む」Server Rehost であり、DMS が Database 専用なのに対し、MGN はアプリケーションスタックとOSを含めたサーバー全体を対象とする。本セクションでは、Replication Agent のインストールから Wave 設計・Test Cutover・Production Cutover・Re-host vs Re-platform 判断まで、移行プロジェクトで直面する全工程を体系化する。

3-1. MGN アーキテクチャ概要 — Replication Server × Staging Area × Target Instance

MGN は 4 つのコンポーネントで構成される。Source Server（移行元）、Replication Server（レプリケーション中継）、Staging Area（一時バッファ領域）、Target Instance（移行先 EC2）の連鎖によって、ほぼリアルタイムのブロックレベルレプリケーションが実現される。

データフロー:

Source (On-Prem) → [TCP 1500 / TLS 암호화] → Replication Server → EBS (Staging) → Launch Template → Target EC2

Replication Server は MGN が自動的に起動・終了を管理する。エンジニアが直接操作する必要はなく、管理コンソールからソースサーバーの Lifecycle State を監視するだけでよい。

MGN は Agent-based（Replication Agent を Source にインストール）方式のみをサポートする。Agentless 方式は VMware vCenter 環境向けの MGN Agentless Snapshot Replication で提供されているが、本番運用の主流は Agent-based だ。VMware 環境向けの Agentless はスナップショットベースのため RPO が数時間単位になる点に注意が必要だ。

3-2. Replication Agent インストール — Linux / Windows / 初回同期タイムライン

Linux インストール手順

Replication Agent は Python ベースのインストーラで提供される。インストール前に Source Server から AWS の Replication Service エンドポイント（TCP 443 と TCP 1500）への疎通が必要だ。

# STEP 1: インストーラ取得（AWS リージョンごとに URL が異なる）
wget -O ./aws-replication-installer-init.py \
  https://aws-application-migration-service-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/\
latest/linux/aws-replication-installer-init.py

# STEP 2: Python3 で実行（IAM 権限が必要）
sudo python3 aws-replication-installer-init.py \
  --region ap-northeast-1 \
  --aws-access-key-id YOUR_ACCESS_KEY \
  --aws-secret-access-key YOUR_SECRET_KEY \
  --no-prompt

# STEP 3: エージェントサービス確認
sudo systemctl status aws-replication-agent

# STEP 4: MGN コンソール Source Servers に表示されることを確認
# Lifecycle: Not ready → Backlog → Continuous data replication

インストーラ実行には AWSApplicationMigrationAgentRole の IAM ポリシーが必要だ。最低限 mgn:SendClientMetricsForConnector・mgn:GetChannelCommandsForAgent が必要になる。本番環境では専用の IAM User を作成し、Source Server に認証情報をインストールするのではなく、AWS Secrets Manager 経由で取得する設計が望ましい。

Windows インストール手順

# STEP 1: インストーラ取得
Invoke-WebRequest -Uri "https://aws-application-migration-service-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/windows/AwsApplicationMigrationServiceAgentInstaller.exe" `
  -OutFile ".\AwsApplicationMigrationServiceAgentInstaller.exe"

# STEP 2: サイレントインストール実行
.\AwsApplicationMigrationServiceAgentInstaller.exe `
  --region ap-northeast-1 `
  --aws-access-key-id YOUR_ACCESS_KEY `
  --aws-secret-access-key YOUR_SECRET_KEY `
  /quiet

# STEP 3: Windows サービス確認
Get-Service -Name "AWS Application Migration Service Agent"

# STEP 4: イベントログでエラー確認
Get-EventLog -LogName Application -Source "AWS*" -Newest 20

初回同期タイムライン

Agent インストール後、最初の Full Sync は Source のディスク総容量に依存する。一般的なタイムラインは以下の通りだ。

Full Sync 完了後、Lifecycle は Continuous data replication に遷移し、差分データのみをリアルタイム転送する。この状態で Replication Lag は通常 0〜数秒 に収まる。

Source Server Lifecycle States（全 6 状態）:

Not ready
  └→ Backlog（初回同期待ち）
└→ Continuous data replication（定常状態）
 ├→ Ready for testing（Test Cutover 可能）
 │ └→ Test in progress
 │└→ Ready for cutover
 └→ Cutover in progress
└→ Cutover complete（移行完了）

Disconnected は Agent が停止またはネットワーク断が発生した際に表示される異常状態だ。この状態では Replication Lag が蓄積するため、Agent を即座に再起動して再同期を開始させる必要がある。

3-3. Wave設計 — サーバーグループ化 × 依存関係マッピング × 移行波順序決定

Wave 設計は MGN 本番運用の核心だ。移行対象サーバーを無秩序に一括 Cutover すると、1 台の失敗が全体に波及しロールバック不能に陥る。Wave 分割は blast radius を局所化し、各 Wave を独立した移行単位として扱うことでリスクを管理可能にする。

サーバーグループ化の考え方

サーバーを Wave に割り当てる際の基本単位は「アプリケーションスタック単位」だ。フロントエンド・バックエンド・データベースが密結合している場合は、同一 Wave 内に収める。独立したバッチサーバーや監視サーバーは単独 Wave でも移行できる。

依存関係マッピング手順

Application Discovery Service（または Migration Hub Discovery Connector）を活用すると、オンプレミス環境のプロセス間通信を自動検出して依存関係マップを生成できる。手動でマッピングする場合は以下のコマンドを活用する。

# オンプレ Linux サーバでの依存関係調査（netstat で接続先を収集）
sudo netstat -tnp | awk '{print $5,$7}' | grep -v "Local\|127\|::" | sort -u

# または ss コマンド（新しいディストリビューション向け）
ss -tnp | awk '{print $5,$6}' | grep -v "Addr\|127\|::" | sort -u

依存関係をスプレッドシートに整理し、有向グラフとして可視化することで Wave の順序が自然に決まる。Tier 0（共有インフラ）→ Tier 1（DB）→ Tier 2（AP/バックエンド）→ Tier 3（Web/フロントエンド）の順番が一般的だ。

移行波の順序決定

3-4. Launch Template設定 — EC2インスタンスタイプ × ストレージ × ネットワーク

Launch Template はターゲット EC2 の起動設定を事前定義するものだ。Source Server ごとに最適な設定を割り当てる。

Terraform による Launch Template 設定例

# MGN Launch Template — Re-host 用 EC2 テンプレート
resource "aws_launch_template" "mgn_web_tier" {
  name_prefix= "mgn-web-tier-"
  image_id= data.aws_ami.latest_amazon_linux2.id  # MGN が動的に差し替え
  instance_type = "m5.xlarge"

  network_interfaces {
 associate_public_ip_address = false
 security_groups = [aws_security_group.web_tier_sg.id]
 subnet_id = aws_subnet.app_private_a.id
  }

  block_device_mappings {
 device_name = "/dev/xvda"
 ebs {
volume_size  = 100
volume_type  = "gp3"
iops= 3000
throughput= 125
encrypted = true
kms_key_id= aws_kms_key.ebs_key.arn
delete_on_termination = true
 }
  }

  iam_instance_profile {
 name = aws_iam_instance_profile.ec2_base_profile.name
  }

  metadata_options {
 http_tokens  = "required"  # IMDSv2 強制
 http_put_response_hop_limit = 1
  }

  user_data = base64encode(<<-EOT
 #!/bin/bash
 # Post-launch: CloudWatch Agent インストール
 yum install -y amazon-cloudwatch-agent
 /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config -m ec2 -s \
-c ssm:/cloudwatch-agent/config
  EOT
  )

  tag_specifications {
 resource_type = "instance"
 tags = {
Name  = "web-tier-migrated"
MigrationWave = "wave-2"
Environment = "production"
 }
  }
}

# MGN Source Server Launch Template 紐付け（AWS CLI が必要なため null_resource で実行）
resource "null_resource" "mgn_launch_template_assign" {
  provisioner "local-exec" {
 command = <<-EOT
aws mgn update-launch-configuration \
  --source-server-id "${var.mgn_source_server_id}" \
  --launch-disposition STARTED \
  --target-instance-type-right-sizing-method NONE \
  --region ap-northeast-1
 EOT
  }

  depends_on = [aws_launch_template.mgn_web_tier]
}

3-5. Test Cutover 本番運用 — 本番影響ゼロの検証 × テスト後クリーンアップ

Test Cutover は本番 Cutover のリハーサルだ。Source Server（オンプレ）は稼働したままターゲット EC2 を起動し、Application の動作を検証する。本番影響はゼロで、いつでも Test instance を終了して再実施できる。

Test Cutover の実施は 本番 Cutover の 1 週間前に最低 2 回実施することを強く推奨する。1 回目は技術的な疎通確認、2 回目は Application チームによる本格的な動作検証に充てる。

Test Cutover 実行手順（AWS CLI）

# STEP 1: Source Server ID を取得
SOURCE_SERVER_ID=$(aws mgn describe-source-servers \
  --filters '{"isArchived":false}' \
  --region ap-northeast-1 \
  --query 'items[?hostname==`web-server-01`].sourceServerID' \
  --output text)

# STEP 2: Test Cutover 開始
aws mgn start-test \
  --source-server-ids "${SOURCE_SERVER_ID}" \
  --region ap-northeast-1

# STEP 3: Job 状態監視（Completed になるまで待機）
watch -n 30 "aws mgn describe-jobs \
  --filters '{\"fromDate\":\"2026-05-18\"}' \
  --region ap-northeast-1 \
  --query 'items[0].{Status:status,Type:type}'"

# STEP 4: テスト完了後、Test Instance を終了（クリーンアップ）
aws mgn finish-test \
  --source-server-ids "${SOURCE_SERVER_ID}" \
  --region ap-northeast-1

# STEP 5: MGN コンソールで "Ready for cutover" Lifecycle に遷移したことを確認
aws mgn describe-source-servers \
  --filters "{\"sourceServerIDs\":[\"${SOURCE_SERVER_ID}\"]}" \
  --region ap-northeast-1 \
  --query 'items[0].lifeCycle.state'

Test Cutover 後は必ず finish-test を実行し Test Instance を終了させること。テスト用 EC2 は Terminate されないと費用が発生し続けるうえ、次の Test Cutover に混乱を招く。

3-6. Production Cutover フロー — Cutover Window × RPO/RTO × ロールバック判断基準

Cutover Window 設計

Cutover Window はビジネス影響が最小化される時間帯に設定する。Database・AP・Web の全 Tier を同一 Window 内で完遂できる時間幅を確保することが重要だ。

Production Cutover 実行ステップ

# STEP 1: Final Sync 状態の確認（Replication Lag が 5 秒以内であること）
aws mgn describe-source-servers \
  --filters "{\"sourceServerIDs\":[\"${SOURCE_SERVER_ID}\"]}" \
  --region ap-northeast-1 \
  --query 'items[0].dataReplicationInfo.{Lag:lagDuration,LastSnapshotDateTime:lastSnapshotDateTime}'

# STEP 2: Source Application の停止（書き込み停止・Graceful Shutdown）
# ← ここが RPO ゼロポイント。DB は DMS で Cutover 済みであること。

# STEP 3: Production Cutover 開始
aws mgn start-cutover \
  --source-server-ids "${SOURCE_SERVER_ID}" \
  --region ap-northeast-1

# STEP 4: Cutover Job の完了確認
aws mgn describe-jobs \
  --filters '{"fromDate":"2026-05-18"}' \
  --region ap-northeast-1 \
  --query 'items[?type==`LAUNCH`].{ID:jobID,Status:status}'

# STEP 5: Application 動作確認（ヘルスチェック）
curl -o /dev/null -s -w "%{http_code}" https://your-app-endpoint/healthcheck

# STEP 6: DNS 切替（Route 53 A レコード or CNAME 更新）
aws route53 change-resource-record-sets \
  --hosted-zone-id YOUR_ZONE_ID \
  --change-batch file://dns-cutover-changeset.json

# STEP 7: Source Server の Disconnect（Cutover 完了確認後）
aws mgn disconnect-from-service \
  --source-server-id "${SOURCE_SERVER_ID}" \
  --region ap-northeast-1

RPO / RTO 計測

• RPO（Recovery Point Objective）: Source 停止〜Final Sync 完了の時間差。Replication Lag が 0 に近ければ RPO ≒ 0。
• RTO（Recovery Time Objective）: Source 停止〜Application がサービス再開するまでの時間。Cutover Job の完了 + DNS TTL 切替 + Application 起動時間の合計。

ロールバック判断基準

Cutover 後 30 分以内に Application のヘルスチェックが成功しない場合はロールバックを発動する。判断基準を事前に合意しておくことが重要だ。

ロールバック手順: Source Server を再起動 → DNS を旧 IP に戻す → Replication Agent の再接続 → 事後レビュー実施（何が失敗したかを記録し次回の改善計画に繋げる）。

3-7. Re-host vs Re-platform 選定マトリクス

MGN の主用途は Re-host（リフト＆シフト）だが、移行を契機に OS・ミドルウェアのバージョンアップや RDS 移行を実施する Re-platform も選択肢に入る。移行前に Re-host か Re-platform かを確定させておかないと、Cutover 後の障害対応に大量の時間を費やすことになる。

Re-platform が適切なケース（具体例）:

Re-platform の場合、互換性テストは Test Cutover 段階で完了させることが必須だ。本番 Cutover 後に互換性問題が発覚するとロールバックを強いられる。

3-8. MGN + DR — 継続レプリケーションを Disaster Recovery 目的で活用

MGN の継続レプリケーションは移行完了後も DR 目的で活用できる。通常、移行完了後は Source Server を Disconnect するが、あえて継続レプリケーションを維持することで低コストの Pilot Light 型 DR を実現できる。

MGN + DR 構成パターン:

MGN を Cross-Region DR で活用する場合、東京リージョン（ap-northeast-1）の EC2 を Source として大阪リージョン（ap-northeast-3）にレプリケーションする構成が現実的だ。ただし、Source が EC2 の場合は Replication Agent の再インストールが必要になる。

復旧本番運用 Multi-Region編 — MGN継続レプリケーションを活用したDR設計の詳細

オンプレからの移行が完了した後も MGN の仕組みを理解しておくことは、DR 設計の選択肢を広げる。Replication Agent ベースのブロックレベル継続同期は、Recovery Point をリアルタイムに近い状態で保つ最も低コストな手段の一つだ。復旧本番運用 Multi-Region 編では MGN 継続レプリケーションを活用した Pilot Light・Warm Standby の具体的な設計を詳述している。

4. Snow Family本番運用 — Snowcone × Snowball Edge × Snowmobile × オフライン大容量移行

オンプレミスからクラウドへのデータ移行において、ネットワーク帯域が不足する場面や、データ量が膨大すぎてオンライン転送では現実的な期間内に収まらない場面が必ず発生します。AWS Snow Family はそのような課題を物理デバイスの発送というアプローチで解決するサービス群です。100GBから100PBまでの幅広いデータ量・運用環境に対応し、デバイスごとに異なるスペックとユースケースを持ちます。本節では Snow Family の全デバイス選定基準・発送タイムライン・Direct Connect との比較判断・エッジコンピューティング活用・S3 インポート手順を体系化します。

4-1. Snow Family 全デバイス概要と選定マトリクス

AWS Snow Family は 2026 年時点で以下の 4 デバイスで構成されます。移行データ量・設置環境・エッジコンピューティング要否の 3 軸で選定します。

Snowcone (8TB / 14TB SSD)

Snowcone は Snow Family 最小サイズのデバイスで、重量 2.1kg・IP67 耐塵防水の堅牢筐体です。辺境地・工場フロア・車載など電力・スペース制約が厳しい環境向けに設計されており、USB-C 電源 (バッテリー動作も可) で動作します。

• ストレージ容量: 8TB HDD または 14TB SSD
• コンピューティング: 2vCPU / 4GiB メモリ (EC2 SBE インスタンス)
• エッジ機能: AWS IoT Greengrass 対応 / Lambda 実行
• 主なユースケース: IoT センサーデータ収集 / 間欠接続環境でのローカル処理 / 辺境地フィールドデータ収集 / 小容量データの物理輸送
• 転送方式: Wi-Fi / 有線 LAN (10GbE) / DataSync エージェント内蔵でオンライン同期も可

Snowcone のエッジコンピューティング機能は、常時インターネット接続が困難な現場環境での前処理に特化しています。例えば、油田・鉱山・建設現場で収集したセンサーログを Greengrass + Lambda でフィルタリング・集計し、衛星通信経由か次回訪問時に物理返送でクラウドにアップロードするパターンが典型例です。

Snowball Edge Storage Optimized (80TB)

Snowball Edge Storage Optimized は Snow Family の主力デバイスです。大量データの一括移行においてもっとも広く採用され、NFS / S3 互換インターフェースで既存ツールからそのまま書き込みが可能です。

• ストレージ容量: 80TB HDD (S3 互換 / NFS 互換)
• コンピューティング: 40vCPU / 80GiB メモリ (EC2 SBE インスタンス最大 24 台)
• ネットワーク: 25GbE × 2 ポート / RJ45 × 3 ポート
• 主なユースケース: データセンターからの一括データ移行 (10-100TB 規模) / バックアップデータの S3 Glacier 移行 / 複数拠点からの集約移行
• 転送方式: S3 API 互換 (既存 SDK 利用可) / NFS マウント (ファイルサーバ直接接続)

Storage Optimized は複数台同時注文・並列転送で実効スループットを線形スケールできます。例えば 400TB 移行では 5 台並列で各 80TB を同時転送し、発送タイムラインを大幅に短縮できます。

Snowball Edge Compute Optimized (GPU 搭載)

Snowball Edge Compute Optimized はエッジでの機械学習・ビデオ解析・リアルタイムデータ処理に特化したデバイスです。GPU (NVIDIA Tesla V100 相当) を搭載し、EC2 SBE インスタンス上で機械学習推論・画像認識ワークロードを現場で実行できます。

• ストレージ容量: 28TB NVMe SSD (高速 I/O) + 42TB HDD
• コンピューティング: 52vCPU / 208GiB メモリ + GPU (NVIDIA V100)
• ネットワーク: 100GbE × 2 ポート
• 主なユースケース: 製造ラインでの欠陥検知 AI / 遠隔地での衛星画像解析 / 録画データのリアルタイム映像解析 / クラウド帰還前の前処理でデータ量圧縮
• 特徴: GPU 推論結果のみをクラウド返送することで送信データ量を 1/10 以下に削減可能

Snowmobile (最大 100PB)

Snowmobile はトレーラートラックに搭載したコンテナ型データ転送サービスで、100PB までの超大容量移行を物理輸送で実現します。AWS の専門チームが対応し、発注から設置まで完全マネージドです。

• ストレージ容量: 最大 100PB (45フィートコンテナ)
• 転送速度: 1Tbps (ファイバーチャネル / データセンター直結)
• セキュリティ: GPS 追跡 / 24時間警備員同乗 / 防弾筐体 / 不正開封検知
• 主なユースケース: 大規模データセンター廃止・丸ごとクラウド移行 (1PB 超) / メディア・放送局のアーカイブ全量移行 / ゲノム解析研究機関の大規模データ移送
• 注意: Snowmobile は AWS 営業経由の個別商談対応 (セルフサービス注文不可)

4-2. 発送タイムライン — 実プロジェクト計画で最重要の工程設計

Snow Family 導入で最も多い失敗パターンは発送タイムラインの見積もり不足です。「デバイスが翌日届く」という誤解が根強いですが、実際には Order からデータが S3 に入るまで最低 2〜3 週間を要します。プロジェクトスケジュールへの組み込みが必須です。

フェーズ別タイムライン詳細

Phase 1: Order → デバイス到着 (5〜7 営業日)

AWS Management Console または AWS CLI でジョブを作成し、デバイスを注文します。注文後、AWS がデバイスを準備・発送し、指定住所に到着するまで 5〜7 営業日かかります。

• 注文: AWS Console → Snow Family → Create Job (30〜60 分)
• 輸送: AWS → 顧客施設 (国内 2〜3 日・海外 5〜7 日)
• 受取確認: デバイスシリアル番号を Console で照合 (E-ink 表示と一致確認)
• 電源投入・ネットワーク接続: OpsHub インストール → デバイス解錠 (IAM 認証) → 接続確認

Phase 2: データ転送 (データ量に応じて 1〜数週間)

データ転送速度はネットワーク接続とデータパターンに依存します。以下は理論値と実際の目安です。

• Snowball Edge Storage Optimized: 25GbE 接続時 理論値 〜2GB/s / 実効 〜500MB/s〜1GB/s
• USB 3.1 (Snowcone 補助接続): 〜1GB/s 理論値 / 実効 〜400〜600MB/s
• 10TB データ: 1GB/s 実効で 〜3時間 (理想) / ファイル小・多数の場合は 12〜24時間
• 80TB データ (1台フル): 1GB/s 実効で 〜22時間 / 実際は 2〜4日を想定
• 複数台並列の場合: 各デバイスが独立して並列転送するため比例短縮

転送はストレージ Optimized なら aws s3 cp / NFS マウントどちらでも可です。ファイル数が多い場合 (数百万ファイル超) は S3 sync よりも NFS + rsync で並列転送するほうが高速になる場合があります。

Phase 3: 返送 → S3 Ingest 完了 (7〜14 営業日)

データ転送完了後、OpsHub で転送ジョブを完了させ、デバイスを返送します。AWS がデバイスを受領後、S3 へのデータ Ingest が開始されます。

• 転送完了処理: OpsHub → Complete Transfer Job (5〜10 分)
• デバイス返送 (顧客 → AWS): ラベル自動生成 → 宅配業者引き渡し (国内 1〜2 日・海外 3〜5 日)
• AWS 受領 → S3 Ingest: 3〜7 営業日 (AWS センター処理・データ書き込み)
• S3 Ingest 完了通知: SNS 通知 + Console Job Status = “Completed”
• データ検証: S3 チェックサム確認 (Manifest ファイルと照合)

4-3. Direct Connect / VPN との帯域比較判断

Snow Family の採用判断で必ず比較すべきが既存ネットワーク回線を使ったオンライン転送です。単純にデータ量だけで判断せず、コスト・期限・帯域の 3 軸で評価します。

転送時間の計算式

転送時間(時間) = データ量(TB) × 1024(GB) × 8(Gbps換算) ÷ 実効帯域(Gbps)
例: 10TB, 1Gbps 実効 → 10 × 1024 × 8 ÷ 1 = 81,920秒 ≒ 22.8時間
例: 10TB, 10Gbps 実効 → 10 × 1024 × 8 ÷ 10 = 8,192秒 ≒ 2.3時間

帯域別の Snow Family 優位点移行量

• 10Mbps 回線 (VPN 一般): 1TB 転送 = 9日 → 1TB でも Snow Family 優位
• 100Mbps 回線: 1TB = 22時間 / 10TB = 9日 → 10TB 超で Snow Family 優位
• 1Gbps 回線 (一般 Direct Connect): 10TB = 22時間 → 100TB 超で Snow Family 優位
• 10Gbps 回線 (DX Hosted Connection): 10TB = 2.3時間 → 200TB 超で Snow Family 優位

コスト比較の視点

Direct Connect 帯域コストは転送量に依存し、大容量ほど割高になります。Snowball Edge 1台のレンタル費用 (10日間) は約 $300 (2026年目安・地域により変動)。10TB の Direct Connect 転送コスト (データ転送 OUT 料金 + Direct Connect 時間コスト) と比較して、データ量が多いほど Snow Family のコスト優位性が増します。

判断の実務的な境界線

4-4. Edge Compute 用途 — IoT × 間欠接続 × 現地処理

Snow Family のエッジコンピューティング機能は、データ転送だけでなく「クラウドに接続できない現場での処理実行」を可能にします。

Snowcone のエッジ活用パターン

Snowcone は AWS IoT Greengrass V2 と Lambda を内蔵し、クラウド接続なしに以下の処理を現場で実行できます。

• IoT センサーデータのリアルタイム集計・異常検知 (Lambda)
• 産業機器の稼働ログ圧縮・フィルタリング (不要データ削除でデータ量削減)
• 間欠接続環境での DataSync エージェント動作 (接続復帰時に自動同期)
• 軽量機械学習推論 (エッジデプロイされたモデルで現地判断)

典型的なデプロイ構成: オフショア施設・採掘現場・移動体 (車両・船舶) に設置。衛星通信が確立した時間帯だけ AWS IoT Core に接続し、DataSync で増分アップロードします。Snowcone 本体は定期的に回収して物理返送、または次の現場に持ち込んで使い回します。

Snowball Edge Compute Optimized のエッジ活用パターン

GPU を活用した高負荷処理が必要な現場向けです。

• 製造ライン: 高速カメラ映像をリアルタイムで機械学習モデルが欠陥検知し、NG 製品を即時排除
• 医療: 遠隔地病院での MRI 画像解析 (クラウド接続なしに診断支援)
• 農業: ドローン撮影画像を現地で解析し、農薬散布マップを即時生成
• 映像制作: 撮影現場でのリアルタイム 4K/8K エンコード

GPU 推論結果 (テキスト・数値・座標) のみをクラウドに返送することで、生の映像データ (数TB) をアップロードする必要がなくなります。通信コストを劇的に削減できます。

EC2 SBE (Snowball Edge) インスタンスタイプ

Snowball Edge 上で起動できる EC2 互換インスタンスは以下の通りです。

sbe-c.large — 2vCPU / 4GiB  (軽量処理)
sbe-c.xlarge— 4vCPU / 8GiB
sbe-c.2xlarge  — 8vCPU / 16GiB
sbe-c.4xlarge  — 16vCPU / 32GiB
sbe-g.xlarge— 4vCPU / 16GiB + GPU (Compute Optimized のみ)

4-5. S3 Bucket へのインポート手順 — OpsHub / AWS CLI

データ転送後、デバイスを返送すれば AWS センターで自動的に S3 に Ingest されます。しかし事前の設定と手順が Ingest 成功の鍵です。

Step 1: ジョブ作成 (Order 時)

# AWS CLI でジョブ作成
aws snowball create-job \
  --job-type IMPORT \
  --resources '{
 "S3Resources": [{
"BucketArn": "arn:aws:s3:::my-migration-bucket",
"KeyRange": {}
 }]
  }' \
  --address-id "ADID1234567890EXAMPLE" \
  --kms-key-arn "arn:aws:kms:ap-northeast-1:123456789012:key/example-key-id" \
  --role-arn "arn:aws:iam::123456789012:role/SnowballImportRole" \
  --snowball-type EDGE_STORAGE_OPTIMIZED \
  --shipping-option NEXT_DAY

Step 2: デバイス到着後 — AWS OpsHub によるアクセス

AWS OpsHub (GUI ツール) をローカル PC にインストールし、デバイスに接続します。

# Snowball Edge クライアント (CLI) での認証
snowballEdge unlock-device \
  --endpoint https://192.168.1.100 \
  --manifest-file /path/to/manifest.bin \
  --unlock-code UNLOCK-CODE-HERE

# 接続確認
snowballEdge describe-device \
  --endpoint https://192.168.1.100 \
  --profile snowball-profile

Step 3: データ転送 — S3 API 経由

# Snowball Edge を S3 エンドポイントとして利用
aws s3 cp /local/data/ s3://my-snowball-bucket/ \
  --recursive \
  --endpoint-url http://192.168.1.100:8080 \
  --profile snowball-profile

# 大量ファイルの場合: 並列転送で高速化
aws s3 sync /local/data/ s3://my-snowball-bucket/migration/ \
  --endpoint-url http://192.168.1.100:8080 \
  --profile snowball-profile \
  --no-sign-request \
  --delete

# 転送状況確認
snowballEdge describe-transfer-progress \
  --endpoint https://192.168.1.100 \
  --profile snowball-profile

Step 4: NFS マウントによる転送 (ファイルサーバ直接接続)

# NFS インターフェース有効化 (OpsHub または CLI)
snowballEdge create-nfs-interface \
  --endpoint https://192.168.1.100 \
  --profile snowball-profile

# NFS マウント
sudo mount -t nfs \
  -o nolock,hard,timeo=100,retrans=2 \
  192.168.1.100:/bucket/my-snowball-bucket \
  /mnt/snowball

# rsync で高速並列転送
rsync -avz --progress \
  --partial \
  /local/data/ \
  /mnt/snowball/migration/

Step 5: 転送完了 → ジョブ終了

# 転送完了後にジョブを終了
snowballEdge stop-service \
  --endpoint https://192.168.1.100 \
  --profile snowball-profile

# ジョブステータス確認
aws snowball describe-job --job-id JID1234567890EXAMPLE

# 返送ラベル確認
aws snowball get-shipping-label --job-id JID1234567890EXAMPLE

Step 6: S3 Ingest 完了確認

# Ingest 完了後のデータ確認
aws s3 ls s3://my-migration-bucket/migration/ --recursive | wc -l

# チェックサム検証 (Manifest との照合)
aws s3api get-object \
  --bucket my-migration-bucket \
  --key migration/important-file.tar.gz \
  --checksum-mode ENABLED \
  /tmp/verify-output.tar.gz

4-6. データ暗号化とセキュリティ

Snow Family はジョブ作成時に指定した KMS キーで全データを AES-256 暗号化します。Customer Managed Key (CMK) 推奨で、IAM 認証情報 + Manifest ファイル + Unlock Code の 3 要素がそろった場合のみアクセス可能です。AWS センターはデータ Ingest 後に NIST 800-88 準拠でデバイスを消去します。物理面では Snowcone が IP67 耐塵防水・落下耐性、Snowball Edge が不正開封検知センサー+GPS 追跡、Snowmobile が 24 時間警備員同乗+防弾コンテナを実装しています。

4-7. Job Status 監視と Run Book 化

Snow Family の移行プロジェクトは「デバイス注文 → 転送 → 返送 → Ingest」の長期間工程になるため、Job Status の継続的な監視と Run Book 化が必要です。

Job Status の状態遷移

New → PreparingAppliance → Preparing Shipment → InTransitToCustomer
→ WithCustomer (データ転送フェーズ)
→ InTransitToAWS → WithAWS → InProgress (S3 Ingest)
→ Complete

EventBridge + SNS での自動通知は aws.snowball ソース・Snowball Job State Change イベントを EventBridge ルールで捕捉し、SNS トピックに転送するパターンで実装します。WithCustomer / InTransitToAWS / Complete の 3 状態変化を通知対象にすることで、担当者がリアルタイムで工程進捗を把握できます。

Run Book 必須項目

移行プロジェクトの Run Book には以下を必ず記載します。

1. デバイス受取時の確認手順 (シリアル番号照合・開封検査)
2. OpsHub / snowballEdge CLI のセットアップ手順 (Manifest パス・Unlock Code 保管場所)
3. 転送方法 (S3 API vs NFS) と並列度設定
4. 転送進捗確認コマンドと監視頻度
5. デバイス返送前の完了確認チェックリスト (転送ジョブ終了確認・ラベル印刷)
6. S3 Ingest 完了確認手順 (SNS 通知 + aws s3 ls によるファイル数確認)
7. データ整合性検証手順 (チェックサム照合)
8. エスカレーション先 (AWS Support ケース番号・担当者)

5. Application Migration Service + Migration Hub — Portfolio Discovery × Application Discovery × 移行プロジェクト管理

大規模クラウド移行プロジェクトで最初に突き当たる壁は「何から移行するか」の意思決定だ。DMS・MGN・Snow Family の移行ツールを揃えても、どのワークロードをいつ・どの順序で移行するかを体系化しなければ、移行プロジェクトは混乱に陥る。AWS Migration Hub と Application Migration Service (AMS) は、この移行プロジェクト管理と Portfolio Discovery を担う2本柱である。

本セクションでは「Application Discovery → Strategy Recommendations → Wave Planning → Wave Execution → Validation → Cutover Complete」の完全フローを体系化する。

5-1. Migration Hub の位置づけ — 移行プロジェクト統合ダッシュボード

AWS Migration Hub は、AWS が提供する移行プロジェクト統合管理コンソールである。DMS・MGN・Snow Family・サードパーティの移行ツール（CloudEndure / Carbonite 等）が個々のサービスに分散している中、Migration Hub はそれら全体の進捗状況を一元的に可視化するダッシュボードレイヤーとして機能する。

Migration Hub が統合するサービス群:

Migration Hub のホームリージョンは プロジェクト開始前に一度だけ設定する（後から変更不可）。us-east-1 または ap-northeast-1 のいずれかを選択し、全サービスのデータ集約先として固定する。

# Migration Hub ホームリージョン確認
aws migrationhub get-home-region

# ホームリージョン設定（初回のみ）
aws migrationhubconfig create-home-region-control \
  --home-region ap-northeast-1 \
  --target '{"Type": "ACCOUNT"}'

# 移行プロジェクト一覧
aws migrationhub list-migration-tasks \
  --progress-update-stream "DMS" \
  --region ap-northeast-1

5-2. Application Discovery Service — Portfolio Discovery の基盤

移行プロジェクトの出発点は オンプレミス環境の完全な棚卸し だ。どのサーバーが存在し、どのアプリケーションが稼働し、サーバー間でどのような通信が行われているかを把握しなければ、Wave 設計も 6Rs 判断もできない。Application Discovery Service (ADS) がこの Portfolio Discovery を担う。

Discovery Connector（Agentless 方式）

Discovery Connector は VMware vCenter に接続するアプライアンス VM であり、vCenter 管理下の仮想マシン情報を OS 内エージェントなしに収集する。

収集データ:
– VM 仕様（vCPU / Memory / Disk / OS / IP アドレス）
– 稼働状態（Power State / 平均 CPU 使用率 / ネットワーク I/O）
– vCenter のタグ情報（環境ラベル / オーナー）

適用場面: VMware vSphere 環境 / エージェントインストールが困難な本番環境 / まず高速にインベントリを取得したいフェーズ。

# Discovery Connector 経由で収集したサーバー一覧
aws discovery describe-servers \
  --filters Name=agentType,Values=CONNECTOR \
  --region ap-northeast-1

# サーバー詳細情報取得
aws discovery list-server-neighbors \
  --server-id "d-server-xxxxxxxxxx" \
  --region ap-northeast-1

Discovery Agent（Agent-based 方式）

Discovery Agent は個々の OS にインストールするエージェントであり、Connector より深いレベルのデータを収集する。

収集データ:
– プロセス一覧（稼働プロセス名 / PID / CPU/Memory 消費量）
– ネットワーク通信詳細（接続先 IP / ポート / 通信量 / プロトコル）
– 詳細パフォーマンス指標（15秒間隔のリアルタイム収集）
– 依存関係マッピング（サーバー間の実際の通信パス）

対応 OS: Amazon Linux / RHEL / CentOS / SUSE / Ubuntu / Windows Server 2008 R2 以降

# Discovery Agent インストール（Linux）
curl -O https://s3-us-west-2.amazonaws.com/aws-discovery-agent.us-west-2/linux/latest/aws-discovery-agent.tar.gz
tar -xzf aws-discovery-agent.tar.gz
sudo ./install -r ap-northeast-1 -k <ACCESS_KEY> -s <SECRET_KEY>

# Agent 稼働状態確認
aws discovery describe-agents \
  --filters Name=agentType,Values=AGENT \
  --region ap-northeast-1

依存関係マッピングの活用

ADS が収集したネットワーク通信データは 依存関係マップ として可視化される。Web サーバー → AP サーバー → DB サーバーという通信パスが見えることで、「このサーバーセットは同じ Wave で移行しなければ整合性が崩れる」という Wave 設計の根拠になる。

Migration Hub 上で Application グループ を作成し、依存関係で束ねたサーバーセットを1つの移行単位として管理する。

# Application グループ作成
aws discovery create-application \
  --name "WebTier-Wave1" \
  --description "Web servers with AP dependency" \
  --region ap-northeast-1

# サーバーをグループに追加
aws discovery associate-configuration-items-to-application \
  --application-configuration-id "d-application-xxxxxxxxxx" \
  --configuration-ids "d-server-aaaa" "d-server-bbbb" \
  --region ap-northeast-1

5-3. Migration Hub Strategy Recommendations — 6Rs 自動推奨

ADS でインベントリを収集した後、次のステップは 移行戦略の策定だ。Migration Hub Strategy Recommendations は、収集したサーバー・アプリケーション情報を分析し、6Rs（Rehost / Replatform / Refactor / Repurchase / Retire / Retain）のうち最適な戦略を自動推奨するサービスである。

Strategy Recommendations が分析する観点:

推奨カテゴリ:

• Rehost: 変更なし EC2 移行。依存関係が複雑 / 移行期限が短い場合の現実解
• Replatform: OS / DB 一部変更。SQL Server → Aurora / Windows → Linux 等
• Refactor: アーキテクチャ変更。モノリス → コンテナ / Lambda / マイクロサービス
• Repurchase: SaaS 代替。CRM 自社構築 → Salesforce 等
• Retire: 廃止。稼働率低 / 機能重複 / 業務廃止済みシステム
• Retain: 移行見送り。規制 / 技術的困難 / 移行対効果が低い

.NET / Java アプリへの特別推奨:

Strategy Recommendations は .NET Framework アプリを Linux コンテナへの移植推奨、Java EE アプリを Amazon ECS または EKS へのコンテナ化推奨 として自動判定する機能を持つ。また、自社 DB サーバーには RDS マネージドサービスへの移行を推奨し、ライセンスコスト削減シナリオを試算して提示する。

# Strategy Recommendations データ収集開始
aws migrationhubstrategy start-assessment \
  --region ap-northeast-1

# アセスメント結果一覧
aws migrationhubstrategy list-applications \
  --region ap-northeast-1

# 特定アプリの推奨戦略詳細
aws migrationhubstrategy get-application-component-strategies \
  --application-component-id "app-xxxxxxxxxx" \
  --region ap-northeast-1

5-4. Migration Hub Refactor Spaces — モノリス段階的マイクロサービス化

Strategy Recommendations で「Refactor」推奨を受けたアプリケーションに対して、Migration Hub Refactor Spaces がモノリス → マイクロサービスの段階的移行を支援する。

Refactor Spaces の核心は Blue/Green パターンによる段階的ルーティング制御だ。オンプレのモノリスアプリ（Blue）を稼働させたまま、切り出したマイクロサービス（Green）を並走させ、一部のトラフィックのみを Green へルーティングする。機能単位で少しずつ分割・検証できるため、一括置き換えによるリスクを排除できる。

Refactor Spaces の構成要素:

段階的分割フロー:

1. Refactor Spaces 環境作成（VPC + TGW 自動プロビジョニング）
2. モノリス（Blue）を DEFAULT ルートとして登録
3. 機能単位でマイクロサービス（Green）を Service として追加
4. 特定パス（/api/orders）を Green Service へルーティング
5. 動作確認後、ルーティング比率を段階的に変更（10% → 50% → 100%）
6. 全機能移行完了後、モノリスを廃止

# Refactor Spaces 環境作成
aws migration-hub-refactor-spaces create-environment \
  --name "OrderSystem-Refactor" \
  --network-fabric-type TRANSIT_GATEWAY \
  --region ap-northeast-1

# マイクロサービス Service 追加
aws migration-hub-refactor-spaces create-service \
  --environment-identifier "env-xxxxxxxxxx" \
  --application-identifier "app-xxxxxxxxxx" \
  --name "OrderService" \
  --endpoint-type LAMBDA \
  --lambda-endpoint '{"arn":"arn:aws:lambda:ap-northeast-1:123456789012:function:OrderService"}' \
  --region ap-northeast-1

# ルーティング設定（パスベース）
aws migration-hub-refactor-spaces create-route \
  --environment-identifier "env-xxxxxxxxxx" \
  --application-identifier "app-xxxxxxxxxx" \
  --service-identifier "svc-xxxxxxxxxx" \
  --route-type URI_PATH \
  --uri-path-route '{"SourcePath":"/api/orders","ActivationState":"ACTIVE"}' \
  --region ap-northeast-1

5-5. Application Migration Service (AMS) — MGN 後継と命名注意点

Application Migration Service (AMS) は、AWS MGN（Application Migration Service）の統合版・後継ブランドとして位置づけられる。MGN が Server の Lift & Shift を中心としていたのに対し、AMS は Migration Hub との統合を強化し、移行プロジェクト全体を管理するコンテキストでサーバー移行機能を提供する。

命名混乱注意点:

AMS = Application Migration Service（本記事で扱うサービス）
AWS Managed Services（AMS）= AWS が IT インフラ運用を代行するマネージドサービス

この2つは 全く異なるサービス であり、同じ略称「AMS」を共有している。本記事での「AMS」は Application Migration Service を指す。コンテキストによって混同しないよう注意が必要だ。AWS 公式ドキュメントでも文脈で使い分けており、Migration 文脈の「AMS」は Application Migration Service を指す。

Migration Hub での AMS 統合:

Migration Hub は AMS（Application Migration Service）とネイティブ統合されており、個々のサーバーの Replication 状態・Lifecycle State・Test Cutover / 本番 Cutover 進捗を Migration Hub ダッシュボードで一元表示する。

5-6. Wave Execution — Migration Hub による移行進捗トラッキング

Wave Execution は、移行プロジェクト全体を複数の Wave（移行バッチ）に分割し、順次実行する運用プロセスだ。Migration Hub は Wave ごとの完了率・エラー状況・ブロッカーをダッシュボードで可視化し、ステークホルダーへの進捗報告を効率化する。

Wave 設計の原則:

1. 依存関係優先: ADS で収集した依存マップを基に、依存するサーバーセットを同一 Wave に配置
2. Wave サイズ上限: 本番環境は 20-30 台 / Wave が現実解（100 台一括は Rollback 不能リスク）
3. Test Cutover 必須: 各 Wave の本番 Cutover 前に必ず Test Cutover を実施・検証
4. Cutover Window 合意: 業務影響最小化のためダウンタイム許容時間を事前合意（深夜 2:00-4:00 等）
5. Rollback 計画: 本番 Cutover 後 24 時間以内のロールバック実行計画を事前準備

Migration Hub での進捗管理:

# Migration Task 進捗一覧（Wave1 対象）
aws migrationhub list-migration-tasks \
  --progress-update-stream "MGN" \
  --region ap-northeast-1

# 移行タスクのステータス更新（AMS/MGN が自動送信）
aws migrationhub notify-migration-task-state \
  --progress-update-stream "MGN" \
  --migration-task-name "server-web01" \
  --task '{"Status":"IN_PROGRESS","StatusDetail":"Replication in progress","ProgressPercent":45}' \
  --update-date-time 2026-05-18T09:00:00Z \
  --region ap-northeast-1

# 移行タスクへのリソース関連付け
aws migrationhub associate-created-artifact \
  --progress-update-stream "MGN" \
  --migration-task-name "server-web01" \
  --created-artifact '{"Name":"arn:aws:ec2:ap-northeast-1:123456789012:instance/i-xxxxxxxxxx","Description":"Migrated EC2 instance"}' \
  --region ap-northeast-1

ステークホルダーレポートの自動化:

Migration Hub の API を定期実行し、Wave 別の完了率を集計して週次レポートを自動生成するパターンが本番プロジェクトの標準だ。EventBridge スケジュールで毎週月曜に集計スクリプトを起動し、S3 に HTML レポートを出力、SNS でステークホルダーへ通知する。

# Application 単位での Migration 状態集計
aws migrationhub describe-migration-task \
  --progress-update-stream "MGN" \
  --migration-task-name "server-web01" \
  --region ap-northeast-1

# Wave 完了イベントの SNS 通知設定（EventBridge Rule）
aws events put-rule \
  --name "MigrationWave1Complete" \
  --event-pattern '{"source":["aws.migrationhub"],"detail-type":["Migration Task State Change"],"detail":{"status":["COMPLETED"]}}' \
  --region ap-northeast-1

5-7. mermaid02 — Migration Hub 統合フロー

graph TD
  A["Application Discovery Service<br/>Discovery Connector / Discovery Agent"] --> B["Migration Hub<br/>Portfolio Discovery<br/>依存関係マッピング"]
  B --> C["Strategy Recommendations<br/>6Rs 自動推奨<br/>.NET/Java コンテナ化判定"]
  C --> D{"推奨戦略分岐"}
  D -->|"Rehost"| E["AMS / MGN<br/>EC2 Lift & Shift"]
  D -->|"Refactor"| F["Refactor Spaces<br/>モノリス→マイクロサービス<br/>Blue/Green ルーティング"]
  D -->|"Replatform"| G["DMS + RDS/Aurora<br/>DB マネージド移行"]
  D -->|"Retire"| H["廃止計画<br/>コスト削減"]
  E --> I["Wave Planning<br/>Wave サイズ: 20-30台<br/>依存関係グループ化"]
  F --> I
  G --> I
  I --> J["Wave Execution<br/>Test Cutover → 検証 → 本番 Cutover"]
  J --> K["Migration Hub Dashboard<br/>Wave 別完了率トラッキング<br/>ステークホルダー週次レポート"]
  K --> L["Validation<br/>機能検証 / Performance Benchmark<br/>Rollback 判断"]
  L -->|"OK"| M["Cutover Complete<br/>Source 廃止 / コスト最適化"]
  L -->|"NG"| N["Rollback<br/>Source 再起動 / DNS 切戻し"]
  N --> J

5-8. 統合監視 — CloudWatch × EventBridge × SNS

Migration Hub と各移行サービスの統合監視は、CloudWatch Metrics + EventBridge + SNS の3層構成で実装する。

監視対象と対応アクション:

# MGN Replication Lag アラーム設定
aws cloudwatch put-metric-alarm \
  --alarm-name "MGN-ReplicationLag-High" \
  --metric-name "ReplicationBacklogDuration" \
  --namespace "AWS/MGN" \
  --statistic Maximum \
  --period 300 \
  --threshold 3600 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 3 \
  --alarm-actions "arn:aws:sns:ap-northeast-1:123456789012:migration-alerts" \
  --region ap-northeast-1

5-9. Application Migration Service + Migration Hub 本番運用のポイント

大規模移行プロジェクトで Migration Hub と AMS を最大限活用するための実践ポイントをまとめる。

1. Discovery ファーストの徹底

移行開始前に ADS による全 Resource Inventory を完了させることが最重要だ。Inventory が不完全な状態で移行を開始すると、未発見サーバーとの依存関係切断で Application 障害が発生する。目安として移行開始の 4 週間前 には Discovery を完了し、依存関係マップのレビューを終える。

2. Strategy Recommendations を出発点として活用

自動推奨はあくまで出発点だ。Recommendations が「Rehost」を提案しても、業務要件・ライセンス制約・将来拡張性を加味してプロジェクトチームが最終判断する。特に Oracle / SQL Server の「Replatform → Aurora」推奨はライセンスコスト削減効果が大きいが、SQL 互換性検証を SCT で必ず実施する。

3. Wave サイズと Cutover Window の事前合意

Wave サイズは 20-30 台 を上限とし、ビジネスオーナーと Cutover Window（開始〜終了時刻 / 許容ダウンタイム）を移行カレンダーとして全 Wave 分を事前に合意する。当日の「やっぱりやめよう」を防ぐための GO/NO-GO 基準（最終 Replication Lag < 30 分 / Test Cutover 成功済み）も明文化する。

4. AMS と AWS Managed Services の命名分離

プロジェクトドキュメント・チケット・コミュニケーションで「AMS」を使う場合は必ず文脈を明示する。社内で混乱が生じる場合は「Application Migration Service (AppMS)」「AWS Managed Services (AMS-Ops)」のように独自略称で分離することも有効だ。

5. Refactor Spaces はパイロット 1 機能から開始

Refactor Spaces を使ったモノリス分割は、まず最もシンプルな 1 機能（例: ログイン処理 / 検索機能）を対象にパイロット実施し、Blue/Green ルーティングの動作・ロールバック手順・監視体制を確立してから本格展開する。いきなり複数機能を同時分割すると障害切り分けが困難になる。

Network本番運用 Vol2 — TGW × PrivateLink × Direct Connect (移行ネットワーク基盤)

6. 詰まりポイント7選 — Migration本番運用の地雷とフィックス

大規模クラウド移行プロジェクトを現場で実施すると、計画段階では見えなかった落とし穴に必ずぶつかる。本セクションでは DMS × MGN × Snow Family × Application Migration の横断で頻発する詰まりポイント7選を「なぜ詰まるか → どう解くか」の2段構成で解説する。いずれも実際の移行プロジェクトで発生したインシデントをベースにしており、「知っていれば避けられた」地雷ばかりだ。

7選の詰まりポイントはそれぞれ独立して発生するが、複合的に重なるケースも多い。例えば「CDC Lag 増大 (詰まり1) + Cutover Window 設計甘さ (詰まり2) + 検証ストラテジ不在 (詰まり7)」が三重に重なると、Cutover 延期 → 再Cutover時に別問題発覚 → プロジェクト全体が2ヶ月遅延という事態になりかねない。7選を個別に対処するのではなく、移行計画フェーズで全7選のチェックを事前ゲートとして組み込むことが本番品質移行の鉄則だ。

詰まり1: DMS CDC Replication Lag増大でCutover延期

なぜ詰まるか

DMS CDC (Change Data Capture) は Source DB の binlog (MySQL 系) または replication slot (PostgreSQL 系) から Change Event を読み取り、Target に変更を適用し続ける。問題は主に2つの経路で発生する。

経路A — binlog retention 不足 (MySQL/Aurora MySQL):
expire_logs_days=1 などで retention を短く設定している環境では、DMS Replication Instance が高 Lag から回復しようとしている最中に binlog ファイルが削除される。Task は ERROR: Binary log is no longer available で強制失敗し、Full Load から再実行する羽目になる。本番環境で Full Load の再実行は数時間 〜 数日の追加ダウンタイムを意味する。

経路B — replication slot bloat (PostgreSQL/Aurora PostgreSQL):
pg_replication_slots に DMS 用の slot が作成されるが、DMS Task が停止している間も slot は WAL を保持し続ける。max_slot_wal_keep_size 未設定の環境では、長時間停止後に Source DB のディスクが枯渇し、DB クラッシュが発生した事例がある。Cutover Window 30分前に Source DB がクラッシュした場合、移行は数日間延期となる。

CDC Lag が5分を超えた状態で Cutover Window (通常30-60分) に突入すると、Window 内での追いつきが不可能となり Cutover 延期が確定する。

どう解くか

MySQL 系の対策は expire_logs_days を最低7日以上に設定する。Aurora MySQL では Parameter Group で binlog_retention_hours=168 (7日) を設定し、DMS Pre-Migration Assessment で事前検証する。

PostgreSQL 系の対策は以下の設定を RDS Parameter Group で必ず適用する: max_slot_wal_keep_size = 10240 (10GB)、wal_level = logical、max_replication_slots = 20。

Lag 監視は CloudWatch Logs + Metric Filter で構築し、CDCLatencySource が1分超でアラートを発報する設定とする。Replication Instance のスペックアップ (dms.r5.4xlarge 以上) と Multi-AZ 化でフェイルオーバー耐性を確保する。CDC タスクフィルタで不要テーブルを除外すると、Lag 発生の主因だった大量書き込みテーブルを分離できる。

詰まり2: MGN Cutover Window内でFinal Sync未完了

なぜ詰まるか

MGN は Cutover 実行時に Final Sync フェーズ (Source → Target 差分転送) を自動的に開始する。このフェーズの所要時間は Cutover 直前のディスク書き込み量に比例するが、現場では以下の2つの誤算が頻発する。

誤算A — Cutover 直前バッチ処理の Delta Sync 急増:
夜間バックアップや ETL バッチが Cutover Window と重複すると、Delta Sync 量が平常時の10倍以上に膨れ上がる。30台サーバで1台あたり 50GB の Delta が発生すれば 1.5TB の転送が必要となり、Replication Server の帯域が逼迫する。

誤算B — Wave 内のサーバ数が多すぎる:
30台を1 Wave で Cutover しようとすると、Replication Server 1台では Bandwidth が分散して1サーバあたりの Final Sync 速度が極端に低下する。Cutover Window 1時間では到底完了しない。

Cutover Window (深夜1時間) を超過すると、移行断念 → Rollback 強制となり、次の Cutover 機会は最早で翌週末になるケースも多い。

どう解くか

Cutover Window 48時間前に「差分量測定テスト」を実施する。aws mgn describe-source-servers で Source Server ごとのバックログサイズを確認し、Delta Sync 予測時間を算出する。

Delta Sync 予測時間が Window の 50% を超える場合は Wave を分割する (30台 → 15台 × 2 Wave)。Cutover Window 直前は Source 側の非必須バッチ処理を一時停止する運用手順を事前合意しておく。Final Sync 進捗は MGN コンソールの Job ログ + CloudWatch Metrics (ReplicationBytes) でリアルタイム監視する。

詰まり3: Snow Family発送タイムラインの過小見積もり

なぜ詰まるか

Snowball Edge の調達タイムラインを軽視した計画が最も多いミスの1つ。実態の内訳は下表の通りで、楽観的に見積もっても2週間、繁忙期 (12月〜1月) は5週間以上かかる。

プロジェクト計画で「来週データ転送しよう」という前提を立てると、デバイス到着待ちでプロジェクト全体が2-3週間停止する。複数 Snowball が必要な場合 (100TB 超) は並列調達しないと指数的に遅延する。また、データ転送完了後の「S3 Import 完了通知」が来るまで次工程に着手できないため、バッファを取らない計画は必ず破綻する。

どう解くか

プロジェクト計画策定時点で 6週間バッファを必ず確保する。AWS Snowball Order は移行開始の6週間前に発注し、aws snowball create-job --job-type IMPORT --snowball-type EDGE_STORAGE_OPTIMIZED で Job を作成する。KMS CMK による暗号化 (--kms-key-arn) を必ず指定する。

100TB 超の場合は Snowball 数 = ceil(データ量 / 80TB) × 1.5 (余裕係数) 台を並列発注する。Snowball Edge Client のバッチモードを使用してスループットを最大化し、aws snowball describe-job --job-id <id> で Job Status 追跡を自動化する。

詰まり4: Re-host vs Re-platform 判断迷いで移行後障害多発

なぜ詰まるか

全ワークロードを Re-host (Lift and Shift) で移行すると、以下の問題が後から浮上する。①オンプレで Windows Server 2012 を使っていたが、EC2 でそのまま動かすと Extended Security Updates コストが発生する (月額数万円/台)。②JBoss/WebLogic 等の旧 Middleware Version が最新 AWS サービスと統合できず、マネージドサービス移行が2度手間となる。③ROI 計算なしで Re-platform を選択すると、OS アップグレードコストがクラウド移行コストを上回るケースも存在する。

逆に「せっかく移行するから全部 Re-platform しよう」という方針も危険だ。移行と同時に大量の変更を加えると、障害発生時の切り分けが困難になり、Root Cause 特定に数日かかる事態が現場で頻発している。

どう解くか

6ヶ月 TCO 比較表を全ワークロードに適用する。評価軸: ①現状インフラコスト ②クラウド Re-host コスト ③Re-platform コスト (変更工数含む) ④リスク (互換性問題) ⑤将来の拡張性。TCO 比較で Re-platform の投資回収が 18ヶ月未満なら採用。EOL が近い OS/Middleware は移行と同時に Re-platform が効率的。

Migration Hub Strategy Recommendations の 6Rs 自動推奨を初期スクリーニングに活用し、Application Owner 最終決裁フローを整備する:

詰まり5: VPC設計不備 — オンプレIPとVPC CIDRの重複

なぜ詰まるか

オンプレネットワークが 192.168.0.0/16 や 10.0.0.0/8 を使用していて、移行先 VPC に同じ CIDR を割り当てると、Direct Connect / VPN 接続でルーティングが重複してパケットが混乱する。移行中は Source (オンプレ) と Target (AWS) が共存するため、両者が通信できることが絶対条件となる。

Transit Gateway 経由のマルチアカウント構成では、同じ CIDR を持つ VPC が複数アタッチされた場合にルートテーブルの競合が発生し、BGP 経路広報が不安定になる。移行開始後に VPC CIDR を変更することは実質不可能 (全リソース再作成が必要) なため、発見が遅いほど被害が大きくなる。

どう解くか

移行前の CIDR 設計レビューを必須ゲートとする。オンプレで使用中の全 IP レンジを Application Discovery Service で棚卸しし、VPC CIDR は必ずオフセット範囲を使用する (例: オンプレが 10.0.0.0/8 なら VPC は 172.16.0.0/12 の未使用範囲)。Terraform の validation ブロックで CIDR 重複をビルド時にエラー検知できる仕組みを IaC に組み込む。

マルチアカウント移行先 (AWS Organizations + Landing Zone) では Transit Gateway CIDR テーブルも照合し、重複なし確認を IaC の validation test として組み込む。NAT 方式 (Transit Gateway の CIDR NAT) も選択肢だが複雑になるため、設計段階での CIDR 整理を優先する。

CIDR 設計の推奨プラクティス: ①オンプレが 10.x.x.x 系 → VPC は 172.16.0.0/12 または 100.64.0.0/10 を採用。②マルチアカウントで10 VPC 以上 → /16 以上の大ブロックを Organizations単位で事前割り当て。③移行後の VPC Peering/Transit Gateway も考慮し、将来的な拡張分のアドレス空間も確保する。

詰まり6: BYOL (Bring Your Own License) 違反でライセンスコスト爆発

なぜ詰まるか

SQL Server / Windows Server / Oracle Database をオンプレから AWS に移行する際、既存ライセンスを持ち込む (BYOL) か AWS License Included インスタンスを使うかの判断を誤ると、ライセンス違反または不要なコスト増大が発生する。

具体的な失敗例:
– SQL Server を Dedicated Host 以外の EC2 (共有ハードウェア) で動かし BYOL を主張 → Microsoft のモビリティ規約違反。Dedicated Host または Dedicated Instance が必須条件
– Oracle Database を Virtual Host (共有ハードウェア) で動かすと物理コア数全てにライセンスが計上される → オンプレ比で3-5倍のライセンスコスト発生
– AWS RDS への DB 移行後もオンプレライセンスを継続購入し続けている → 年間数百万円の無駄コスト

どう解くか

BYOL 適用前に Microsoft Software Assurance License Mobility の適用条件を確認する。SQL Server BYOL は Dedicated Host 必須であり、Terraform では aws_ec2_host リソースで Dedicated Host を作成し、aws_instance の host_id に紐付ける。host_recovery = "on" を設定してホスト障害時の自動復旧を有効化する。

Oracle DB は License Included RDS/Aurora PostgreSQL への移行 (SCT 利用) でライセンス費用を根本排除するのが最も確実。移行前に License Audit を実施し、AWS License Manager で全ライセンスを管理する。aws license-manager list-license-configurations で追跡ルールを確認し、過剰使用をリアルタイム検知する体制を整える。

詰まり7: 移行検証ストラテジ不在で本番Cutover後に障害多発

なぜ詰まるか

「動くはず」という見込みで Cutover を実施し、本番環境で初めて障害を発見するパターン。典型的な4つの障害ルート:

1. 接続文字列ハードコード: Application がオンプレ DNS 名 (db.internal.company.com) をハードコードしていて、AWS の Route53 Private Hosted Zone (db.internal.aws) に切り替わらない
2. Charset/Collation 差異: Oracle から Aurora PostgreSQL への異種 DB 移行で、NLS_CHARACTERSET の差異により日本語文字化けが本番初日に大量発生
3. Instance Type 低スペック: オンプレで物理32コアだったサーバを m5.2xlarge (8vCPU) に Re-host し、CPU 律速でレスポンス 10 倍劣化
4. Test Cutover 1回のみ: 再現性を確認していないため、2回目に別の問題が発生しても原因追跡できない

どう解くか

Test Cutover × 2回以上 + 受け入れ基準の事前定義が根本解。受け入れ基準は本番 Cutover 前に Application Owner と合意し、Git で管理する。具体的な指標: ①API レスポンス P99 が Baseline の 120% 以内、②スループット (RPS) が Baseline の 95% 以上、③E2E テストスイート 100% 通過、④DB 行数差分 0・チェックサム一致、⑤監視アラート 0件での 24時間安定稼働。

DNS 名・接続文字列は Parameter Store/Secrets Manager で環境変数化し、ハードコード禁止をコードレビューで強制する。Test Cutover 結果は必ず2回分の Report を保存し、2回連続で受け入れ基準を通過してから本番 Cutover Approval Gate を通過させる運用を定着させる。

7. アンチパターン→正解パターン変換演習5問

移行現場での失敗パターンを「アンチパターン → 正解パターン」形式で整理する。各演習では「問題の根本原因」「正解への具体的な移行手順」「注意すべき Trade-off」を解説する。実際に試験や設計レビューで問われる頻出ポイントでもあるため、パターンを体に染み込ませてほしい。

5問の演習は「移行計画の大枠設計 (演習1) → DB移行の実装 (演習2) → サーバ移行の実装 (演習3) → データ転送の帯域設計 (演習4) → ライセンス最適化 (演習5)」という移行プロジェクトの進行順に並んでいる。実際の移行プロジェクトでもこの順番で設計判断が発生するため、演習をプロジェクトのフェーズと対応付けて理解すると実践的な知識として定着しやすい。

演習1: Big Bang移行 → Wave移行 (依存関係グループ化)

アンチパターン: 全 100 台のオンプレサーバを単一 Cutover Window で一斉移行する “Big Bang 移行”。移行計画書には「4月1日深夜2時〜6時に全台切替」と書かれているが、1台でも障害が発生すると Rollback 対象が全台になり、4時間では到底 Rollback が完了しない。深夜の Cutover で大規模障害を引き起こした後に全台をオンプレに戻すという最悪シナリオが現実に起きている。

根本原因: 移行計画時の依存関係マッピング不足と、Cutover 失敗時の blast radius への配慮欠如。「失敗したらどうするか」のシナリオが計画から欠落している。移行マネージャが「成功することを前提とした計画」しか作っておらず、失敗シナリオの Rollback Run Book が存在しない状態で深夜 Cutover に突入するのは最悪のプロジェクトリスク管理。

正解パターン: Application Discovery Service で Dependency Map を生成し、依存関係グループ (App Tier + DB Tier + Cache 等) を識別する。aws discovery start-data-collection-by-agent-ids でエージェントからデータ収集を開始し、aws discovery describe-export-tasks で依存関係レポートを取得する。

同一依存グループ内のサーバを1 Wave として束ね、20-30台以内の Wave に分割する。Wave 間は独立性を保ち、Wave1 Cutover 成功 → Wave1 安定稼働確認 (24時間) → Wave2 Cutover の逐次パイプラインで実施する。1 Wave が失敗しても他 Wave には無影響な設計となる。

Trade-off: Wave 分割で Cutover 期間は伸びる (1週間 → 3-4週間)。期間延長はステークホルダーへの事前合意が必要。「全体が長くかかる代わりに1回の障害影響が局所化される」をビジネス判断者に正確に伝えることが移行プロジェクトマネージャの役割。

演習2: 手動DB dump移行 → DMS CDC継続レプリケーション

アンチパターン: mysqldump や pg_dump で全 DB をダンプ → S3 にアップロード → Target に Restore する手順を本番 DB に適用する。数百 GB 以上の DB では Dump/Restore 自体が数時間かかり、その間の Source 更新が全てロストする。本番 DB の Cutover での使用は原則不可。

特に「移行完了後にデータが古い」という問題が発生し、最悪の場合は数時間分のトランザクションが消失する。受注管理 DB などでこれが起きると、ビジネスクリティカルなデータ損失となる。

根本原因: ダウンタイム設計の欠如。Full Load 移行はダウンタイムを許容した設計にしか適用できないという原則を移行担当者が理解していない。「mysqldump は使えるツール」という知識と「本番 DB の移行に使える」という判断は全く別物であり、ここに思考の断絶がある。

正解パターン: DMS Full Load + CDC で継続レプリケーションを構築する。aws dms create-replication-task --migration-type full-load-and-cdc で Task を作成し、table-mappings で全スキーマを対象に設定する。

Full Load でベースライン転送後、CDC で差分をリアルタイム適用し続ける。Cutover Window は Final Sync (Lag < 5秒確認) → Source 接続停止 → DMS Task 完了確認 → Target 切替 → Route53 DNS 更新の15分以内で完了できる。

Trade-off: DMS Replication Instance のコストが追加発生する (dms.c5.4xlarge で月額約 $600)。大規模 DB (10TB 超) は Full Load に数日かかるため、移行の6-8週間前から DMS を起動する計画が必要。

演習3: 全量再構築 → MGN Re-host + 段階的Re-platform

アンチパターン: オンプレサーバ移行と同時に OS/Middleware/Application 全てをバージョンアップする “全量再構築”。「どうせ移行するなら全部新しくしよう」という発想は理解できるが、移行と Re-platform 変更が同時に走るため、障害発生時にインフラ変更原因かアプリ変更原因かの切り分けが困難になる。

実際に起きた事例: Re-host と同時に Java 8 → Java 17 アップグレードを実施 → Cutover 後に Application が起動しない → インフラ問題か Java 非互換か3日間判断できなかった。

根本原因: 変更の独立性を無視した設計。複数の変更を同時にリリースすると、問題の根本原因の特定が困難になる原則 (Change Management の基本) が守られていない。また「移行と同時に最新化」という発想自体は合理的だが、実行計画として「移行フェーズ」と「近代化フェーズ」を分離しないと Rollback の粒度が大きくなりすぎる。

正解パターン: 3フェーズ分離で実施する:

各 Phase 間で受け入れテストを実施し、問題があれば前 Phase に戻せる設計とする。

Trade-off: フェーズ分離で移行プロジェクト期間は 2-3 倍になるが、各 Phase の変更範囲が明確になり Rollback コストが大幅に低下する。「遅くなる」ではなく「安全に確実に前進できる」と説明する。

演習4: 帯域逼迫 → Snow Family併用 + Direct Connect帯域計画

アンチパターン: Direct Connect 1Gbps 回線だけで 100TB のデータを転送しようとする設計。理論値: 1Gbps × 86400秒 = 10.8TB/日なので 9.3 日。実際は回線共用・プロトコルオーバーヘッド・TCP 輻輳制御により 20 日以上かかる。その間、既存業務通信への影響が発生し、帯域不足で DMS/MGN のレプリケーションも遅延する。

また、100TB を全てオンライン転送しようとすると Direct Connect の帯域を Migration に占有するため、業務通信のレイテンシが急増してビジネス影響が発生する。

根本原因: データ量 × 転送帯域 × タイムラインの三軸計算の欠如。「転送可能か」だけを検討し、「業務影響なく転送可能か」を検討していない。

正解パターン: Hybrid 戦略で3系統を並行稼働させる。①静的データ (アーカイブ/バックアップ) は Snowball Edge 複数台でオフライン並列転送。②アクティブ DB の CDC データは Direct Connect 専用帯域で DMS Replication。③業務通信は Direct Connect の残り帯域 (最低50% 確保) を VLAN 分離で割り当てる。帯域計画例: Direct Connect 1Gbps を Migration 専用 500Mbps / 業務通信 500Mbps に分割。Snowball Edge × 3台並列で 240TB をオフライン転送 (2週間)。Snow + DX 並行で合計転送期間を DX 単独比 1/5 に短縮できる。

Trade-off: Snowball 調達コスト (1台あたり $300程度) + 発送タイムライン追加。ただし回線増強コスト (100Gbps DX 追加 = 月額数十万円) と比較すると安価なケースが大半。

演習5: 移行後ライセンス超過 → 事前License Audit + BYOL/License Included選定

アンチパターン: ライセンス設計なしで移行を実施し、移行完了後に「EC2 上の SQL Server が BYOL 違反だった」「Oracle DB を Shared Host で動かしていた」と判明し、retroactive なライセンス費用が数百万円〜数千万円規模で発生する。

または逆に「License Included RDS が使えたのに BYOL を選んでいてコストが 2 倍になっていた」という過払いケースも存在する。どちらも事前の License Audit があれば防げる問題。

根本原因: 移行計画時の License Audit とコスト試算の欠如。ライセンスを「インフラチームではなく調達チームの仕事」として切り分けた結果、誰も全体像を把握していない状況が発生する。

正解パターン:

1. 移行前 License Audit: 全 DB エンジン・OS のライセンス種別を棚卸しする (SQL Server/Oracle/Windows Server)
2. AWS License Manager でライセンス追跡ルール設定 → 過剰使用をリアルタイム検知
3. BYOL 採用条件: Microsoft SA 保有 + Dedicated Host 利用 のセット (両方必須)
4. Oracle → Aurora PostgreSQL への DB 移行 (SCT 利用) で License Included 化 → TCO 50% 削減が典型値
5. 移行後12ヶ月でライセンス費用削減額を CFO にレポート → 移行 ROI の可視化

Trade-off: Oracle → PostgreSQL 移行は SCT によるコード変換工数が発生する (数百ストアドプロシージャの場合 3-6ヶ月)。TCO と工数の ROI 計算が必須。「ライセンス費用を年間1000万円削減できるなら3ヶ月の変換工数は回収できる」という計算を必ず提示する。

8. まとめ + 落とし穴10選 + 全17軸クロスリンク

Migration本番運用 Vol1 — 4本柱統合本番運用の総括

DMS × MGN × Snow Family × Application Migration Service の4本柱を体系化した本 Vol1 で確立した設計力を整理する。§1〜§8 で解説した内容は、20-500 ワークロード規模のクラウド移行プロジェクトを本番品質で完遂するための全技術的判断基準を網羅している。

§1 ではクラウド移行の6つの壁 (6Rs 選定・DMS vs MGN 判断・Snow 発送タイムライン・Wave 設計・検証ストラテジ・Cutover Window) を整理し、Migration 本番運用 5原則の基盤を確立した。

§2 では DMS のアーキテクチャ4要素 (Replication Instance / Source Endpoint / Target Endpoint / Replication Task) を体系化し、Full Load + CDC + SCT による異種 DB 移行の本番品質実装を解説した。CDC Lag 監視・Multi-AZ 冗長化・Cutover Window 最小化の3セットが DMS 本番運用の核心。

§3 では MGN の Replication Agent 展開 → Wave 設計 → Test Cutover → Production Cutover のライフサイクル全体を詳述した。Re-host vs Re-platform 判断マトリクス・Rollback Run Book・Final Sync 進捗監視が MGN 本番品質の必須要素。

§4 では Snow Family 3種 (Snowcone/Snowball Edge/Snowmobile) の選定基準と発送タイムライン管理、Direct Connect との使い分け判断 (10TB 未満 → オンライン / 100TB 超 → Snow) を確立した。

§5 では Migration Hub + Application Discovery + Strategy Recommendations による移行プロジェクト統合管理、Wave Tracking・SNS 通知・Stakeholder Report の運用体制を整備した。

§6〜§8 の実践知識 (詰まり7選・アンチパターン5問・落とし穴10選) と組み合わせることで、本番移行プロジェクトの全設計フェーズを自走できる設計力が完成した。

設計完遂チェックリスト — DMS / MGN / Snow / AMS 各フェーズ

Migration本番運用 5原則 — 本番品質移行を担保する設計哲学

Vol1 全体を通じて繰り返し登場した5つの設計原則を最後に整理する。これらは個々の技術的設定を超えた「移行プロジェクトを成功させる思考の枠組み」であり、どの移行案件でも通じる普遍的原則だ。

原則1: Blast Radius の局所化。Wave 設計・DMS Multi-AZ・Rollback Run Book の全てはこの原則に帰着する。「1つの失敗が全体に波及しない設計」を移行プロジェクトのあらゆるレイヤーで徹底する。Big Bang 移行は Blast Radius が最大化された反面教師であり、Wave 分割 + 依存関係グループ化が正解パターン。

原則2: Test Cutover は本番同等の条件で複数回。本番 Cutover を「初めての本番」にしてはいけない。Test Cutover で洗い出した問題を修正し、2回目以降で受け入れ基準を通過してから本番承認するゲートプロセスを必ず組み込む。「1回 Test Cutover を実施した」は「0回」と同じリスクを内包している。

原則3: ダウンタイム設計の明示化。「移行中のダウンタイムはどのくらい許容されるか」を Application Owner と事前合意しないまま技術選定すると、後から設計変更を強いられる。DMS Full Load + CDC (最小ダウンタイム) / Snowball (物理輸送による数週間) / MGN Cutover Window (数時間) は全て許容ダウンタイムから逆算して選択する。

原則4: タイムラインは楽観値でなく悲観値で計画。Snow Family の発注タイムライン・DMS Full Load 所要日数・License Audit 期間いずれも、楽観的見積もりで計画し遅延で失敗するパターンが横行している。常に「最悪のケースで何日かかるか」を計画の基線とし、楽観値は「前倒し完了ボーナス」として扱う。

原則5: ライセンスは移行計画の最初に検討。BYOL vs License Included の選択・Oracle の TCO 分析・Windows Server の EOL 計画は、移行技術選定よりも先に実施する。移行後にライセンス問題が発覚した場合のリカバリは「インフラを全部作り直す」レベルのコストになり得る。技術選定よりも先に License Audit を完了させることが移行計画の鉄則。

Vol1完遂で得られる Migration本番運用設計力

AWS Migration 本番運用 Vol1 を完遂することで、以下の設計力が確立した:

• DMS Replication Instance + CDC + SCT による Database 本番移行を最小 Cutover Window で完遂する能力
• MGN Wave 設計 + Test Cutover + Rollback Run Book による Server 本番移行の本番品質運用
• Snow Family 選定 + 発送タイムライン管理 + Direct Connect 併用による大容量移行の計画的完遂
• Migration Hub + Application Discovery + Strategy Recommendations による移行プロジェクト統合管理
• 移行本番5原則 (Blast Radius局所化 / Test Cutover複数回 / ダウンタイム設計明示 / 悲観値計画 / License Audit先行) の体得
• 全17軸の AWS 本番運用知識と Migration 本番運用を架橋した36記事体系の確立 (本記事 = Migration軸の起点)

本番Cutover当日の進行 — ゼロダウンタイム移行のタイムライン

Cutover 当日の標準タイムライン (DMS + MGN 併用の場合) を整理する:

• T-48h: Final Sync 差分量測定テスト実施。Wave 内全サーバの Delta Sync 予測時間を確認
• T-24h: DMS CDC Lag が5秒以内で安定稼働中か確認。MGN Replication 状態 READY_FOR_CUTOVER 確認
• T-4h: Source 側非必須バッチ処理を停止。Stakeholder (DBAdmin/AppOwner/ネットワーク担当) 待機開始
• T-1h: DMS Lag を1分ごとにモニタリング開始。MGN コンソールで Source Server 全台 Lifecycle 確認
• T-0 (Cutover開始): DMS Task を STOP → Final CDC Flush 確認 → MGN Cutover Job 発火 → Staging Area から Target EC2 起動
• T+10min: Application 接続確認 (Parameter Store の接続文字列が Target を向いているか) → E2E テスト実行
• T+15min: DNS 切替 (Route53 Record Update → TTL=60秒での伝播確認)
• T+30min: パフォーマンスモニタリング (CloudWatch Dashboard 全指標が受け入れ基準以内か確認)
• T+60min: 受け入れ基準全通過 → Cutover 成功宣言 → Stakeholder 通知 → Source Server 停止 (この時点でRollback不可となるため慎重に)

AWS本番運用36記事体系 — Migration Vol1で新軸が確立

AWS 本番運用シリーズは IAM/EKS/復旧/AI×2/セキュリティ/コスト/マルチアカウント/Observability/Network×3/DevOps/Database×3/Serverless×2/Container×2/Storage/Edge/Analytics/ML-AI の17軸35記事で構成されてきた。本記事 (Migration 本番運用 Vol1) で Migration軸が新たに開拓され、シリーズは36記事体系へ拡張された。

クラウド設計の全技術基盤 (Vol1〜35記事) に、クラウドへの移行技術 (Migration 本番運用 Vol1) が統合されたことで、オンプレミスから AWS クラウドまでの全設計・全移行を体系的に習得できる完全体系が確立した。次は Vol2 でコンテナ移行・モノリス解体・Database 近代化の実践へと進んでほしい。

Database本番運用 Vol1 — DMS活用元のRDS×Aurora本番設計を理解する

復旧 Multi-Region編 — MGNをDR構成で活用するRunbook設計