AWS移行戦略ガイド

周辺資料: 学習インデックス · AWSサービス一覧（2026） · アーキテクチャパターン集 · アンチパターン集

オンプレミス・他クラウドからAWSへの移行を 6R 戦略と AWS Migration Hub を軸に体系化した実践ガイド。

1. 移行戦略 6R

6R の概要と選択基準

戦略	概要	いつ選ぶか	工期	TCO 改善
Rehost（リホスト）	そのまま EC2 へ移行	期限優先・まず移行	短	△
Replatform（リプラットフォーム）	最小限の改修でクラウド最適化	効果と速度のバランス重視	中	○
Refactor（リファクタリング）	クラウドネイティブ設計に再構築	長期的な競争優位を狙う	長	◎
Repurchase（再購入）	SaaS / PaaS への切替	独自開発の価値が低い場合	短〜中	○
Retire（廃棄）	不要なアプリを削除	使われていない・重複機能	短	◎
Retain（保留）	移行しない	移行リスク/コストが高い	—	—

6R の選定フロー

対象アプリケーションの分析
        │
        ├── 使用率が低い・重複機能がある → Retire
        │
        ├── ライセンス・規制・技術的負債で移行困難 → Retain（一時的）
        │
        ├── パッケージソフトで SaaS 代替あり → Repurchase
        │       例: オンプレ Exchange → Microsoft 365
        │           オンプレ CRM → Salesforce
        │
        ├── DB を RDS にするだけ / OS 変更不要 → Replatform
        │       例: Oracle → Aurora / Java EE → ECS Fargate
        │
        ├── コアビジネスロジック・競争優位の機能 → Refactor
        │       例: マイクロサービス化 / Lambda + API GW への再設計
        │
        └── それ以外（まず動かす必要がある場合） → Rehost
              例: Application Migration Service (MGN) で自動リホスト

2. 移行フェーズと主要タスク

Phase 1: アセスメント（評価）

[目標]
  移行対象を把握し、優先順位付けと波次計画を作成

[主要タスク]
  1. アプリケーションポートフォリオの棚卸し
     □ アプリ数・サーバー数・DB 数を把握
     □ 依存関係マップを作成（Application Discovery Service 活用）
     □ 技術スタック・ライセンス情報を収集

  2. 現状コストの把握
     □ オンプレのサーバー・ライセンス・運用コストを算出
     □ AWS Migration Evaluator でクラウド移行後のコスト試算

  3. 移行難易度の評価
     難易度低: ステートレスな Web/API サーバー
     難易度中: DB を持つモノリシックアプリ
     難易度高: オンプレ固有ミドルウェア / レガシーOS / ライセンス複雑

  4. 波次計画の策定
     Wave 1: パイロット（低難易度・低ビジネスインパクト）
     Wave 2: 主要アプリ（中難易度）
     Wave 3: 複雑なアプリ / DB 集約

Phase 2: 準備（Landing Zone 構築）

[目標]
  移行先となる AWS 環境の基盤を整備

[主要タスク]
  1. AWS Organizations 構成
     □ 管理アカウント / Log アカウント / Security アカウント
     □ Workloads OU（Prod/Staging/Dev）
     □ SCP でガードレール設定

  2. ネットワーク構成
     □ Direct Connect または Site-to-Site VPN の接続
     □ Transit Gateway でオンプレ ↔ AWS 間の共有ネットワーク
     □ IP アドレス設計（オンプレと重複しない CIDR）

  3. セキュリティ・ガバナンス
     □ CloudTrail 有効化（全アカウント・全リージョン）
     □ GuardDuty 有効化
     □ タグ戦略・命名規則の統一
     □ IAM Identity Center（SSO）の設定

  4. 移行ツールの準備
     □ AWS Application Migration Service（MGN）のレプリケーターインストール
     □ AWS DMS のレプリケーションインスタンス起動
     □ Migration Hub でトラッキング設定

[AWS Control Tower の活用]
  Landing Zone 構築を自動化する AWS サービス
  推奨: 新規 AWS 環境構築には Control Tower を使用
  → Organizations / CloudTrail / Config / SSO を自動設定

Phase 3: 移行実行

[サーバー移行（Application Migration Service）]

  1. ソースサーバーに MGN レプリケーションエージェントをインストール
  2. 継続的なデータレプリケーション（TLS 暗号化）
  3. テスト起動（本番トラフィックを切り替えない）
     → 機能確認 / 性能テスト
  4. カットオーバー
     → ソース停止 → ターゲット起動 → DNS 切替
  5. 移行後の確認期間（2週間）

[DB 移行（AWS DMS）]

  フルロード移行（ダウンタイムあり）:
    小規模 / 移行ウィンドウが取れる場合
    DMS フルロード → 停止 → 切替

  CDC（継続的変更データキャプチャ）移行（最小ダウンタイム）:
    本番稼働中にフルロード後、差分を継続同期
    同期が追いついたタイミングでカットオーバー
    ダウンタイム: 数分〜30分

[DMS がサポートする主な移行パターン]
  Oracle → Aurora PostgreSQL（Schema Conversion Tool 併用）
  SQL Server → Aurora MySQL
  MySQL → Aurora MySQL（ほぼそのまま）
  MongoDB → DocumentDB（互換性確認必要）
  オンプレ DB → RDS（同一エンジン、最も簡単）

Phase 4: 最適化・モダナイゼーション

[移行後の最適化ロードマップ]

  Month 1-3（安定化）:
    監視設定の強化（CloudWatch / X-Ray）
    コスト確認と Savings Plans 購入
    セキュリティ設定の最終化

  Month 4-6（リプラットフォーム）:
    EC2 → ECS Fargate 移行（コンテナ化）
    RDS パラメータチューニング
    ElastiCache 導入でレイテンシ改善

  Month 7-12（モダナイゼーション）:
    モノリスの段階的マイクロサービス化
    CI/CD パイプラインの整備
    サーバーレス化（Lambda / API Gateway）

3. 主要移行サービスの使い方

Application Migration Service（MGN）

[特徴]
  サーバーを AWS に自動でリホストするサービス
  エージェントをインストールするだけで継続レプリケーション開始

[対応ソース]
  物理サーバー / VMware vSphere / Microsoft Hyper-V
  オンプレ Linux/Windows / 他クラウド（Azure / GCP）

[移行手順]
  1. ソースサーバーにエージェントインストール
     curl -O https://aws-application-migration-service-ap-northeast-1.s3...
     sudo python3 install.py --region ap-northeast-1

  2. MGN コンソールでサーバーを確認
     → 「初期同期中」から「準備完了」になるまで待機

  3. ローンチ設定
     ターゲットインスタンスタイプ / ネットワーク / ストレージを設定

  4. テスト起動（Test Launch）
     本番には影響なし / 動作確認を実施

  5. カットオーバー（Cutover Launch）
     ソース停止 → ターゲット起動 → DNS を新 IP に変更

AWS DMS（Database Migration Service）

[主要コンポーネント]
  レプリケーションインスタンス: 移行処理を実行する EC2（サイズ選定が重要）
  ソースエンドポイント: 移行元 DB の接続情報
  ターゲットエンドポイント: 移行先 DB の接続情報
  レプリケーションタスク: フルロード / CDC の設定

[レプリケーションインスタンスのサイズ目安]
  テーブル数 < 100 / データ < 100GB: dms.t3.medium
  テーブル数 100〜1000 / データ 100GB〜1TB: dms.r5.xlarge
  大規模 / 高スループット: dms.r5.4xlarge

[Schema Conversion Tool（SCT）の活用]
  異種 DB 間の移行（Oracle → Aurora など）は SCT でスキーマを変換
  自動変換率: 60〜80%（残り 20〜40% は手動修正が必要）
  変換できないもの: ストアドプロシージャの一部 / DB固有関数

[よくあるつまずきポイント]
  LOB（大容量オブジェクト）カラムの移行は時間がかかる
  → DMS タスク設定で LOB の扱い（Full LOB mode）を指定

  CDC に必要な設定:
    Oracle: Archive Log, Supplemental Logging を有効化
    MySQL: Binary Log (binlog_format=ROW) を有効化
    PostgreSQL: Replication Slot を作成

Migration Hub と Migration Evaluator

[Migration Hub]
  全移行プロジェクトの進捗を一元管理
  MGN / DMS / Server Migration Service の移行状況を集約表示
  
  使い方:
    1. Migration Hub でホームリージョンを設定
    2. アプリケーションを定義（複数サーバーをグルーピング）
    3. 各移行ツールからの進捗が自動集約
    4. 移行ステータス（未開始/進行中/完了）を追跡

[Migration Evaluator]
  オンプレのコストと AWS 移行後コストの比較レポートを生成
  
  コレクターをオンプレにインストール → 2週間データ収集
  → AWS の TCO 比較レポート（移行前後のコスト試算）
  → Savings Plans / RI を適用した場合の節約額も算出

4. DB 移行パターン別ガイド

Oracle → Aurora PostgreSQL（ヘテロジニアス移行）

[課題]
  Oracle 固有の機能: ROWNUM / CONNECT BY / DB Link / Package
  Oracle ライセンスが高額 → コスト削減が主な動機

[移行手順]
  1. SCT でスキーマ変換（Oracle DDL → PostgreSQL DDL）
  2. 変換レポートで手動修正箇所を確認（ストアドプロシージャなど）
  3. DMS フルロードで初期データ移行
  4. アプリの接続文字列・SQL を PostgreSQL 対応に修正
  5. テスト（性能・機能）
  6. CDC で差分同期しながらカットオーバー準備
  7. メンテナンスウィンドウでカットオーバー

[注意点]
  Aurora PostgreSQL の max_connections:
    db.r5.large: 1700 接続
    db.r5.xlarge: 3400 接続
  Oracle と比較してデフォルト接続数が多いのでプール設定を確認

[コスト削減効果の試算例]
  Oracle EE ライセンス: 約$30,000/CPU/年
  Aurora PostgreSQL: 約$3,600/年（db.r5.large、On-Demand）
  → 4 CPU サーバーなら年間$116,400の節約（ライセンスのみ）

SQL Server → Aurora MySQL / PostgreSQL

[移行の難所]
  T-SQL 構文（SQL Server 固有）の変換
  Stored Procedure / Trigger / View の変換
  SQL Server Agent ジョブ → EventBridge Scheduler + Lambda

[SCT 変換率の目安]
  単純なテーブル: 95%以上自動変換
  複雑なストアドプロシージャ: 50〜70%（残りは手動）

[Babelfish for Aurora PostgreSQL]
  SQL Server の T-SQL を Aurora PostgreSQL がそのまま解釈
  → コード変更なしで移行できる場合もある（互換性確認が必要）

MySQL → Aurora MySQL（ホモジニアス移行）

[最も簡単な移行パターン]

  方法A: RDS DMS（シンプル）
    DMS フルロード + CDC でオンラインマイグレーション

  方法B: mysqldump + リストア（小規模）
    mysqldump --single-transaction db_name | mysql -h aurora-endpoint db_name

  方法C: Percona XtraBackup（大規模・ダウンタイム短縮）
    バイナリバックアップを S3 に転送 → Aurora にリストア
    差分レプリケーションで追いついたらカットオーバー

[注意点]
  Aurora MySQL はデフォルトで read_committed ではなく REPEATABLE_READ
  MyISAM テーブルは事前に InnoDB に変換
  文字コード: latin1 → utf8mb4 への変換が必要な場合がある

5. カットオーバー計画

カットオーバー手順テンプレート

[事前チェック（カットオーバー1週間前）]
  □ 本番同等データでの性能テスト完了
  □ アプリチームの動作確認完了
  □ 監視アラーム設定完了
  □ ロールバック手順の確認・演習
  □ 関係者への通知（ユーザー向けメンテナンスアナウンス）

[カットオーバー当日の手順]
  T-4h  メンテナンスモード開始・ユーザーへの通知
  T-3h  最終データ同期（DMS CDC が追いついていることを確認）
  T-2h  ソースシステムへの書き込みを停止（メンテナンスページ表示）
  T-1h  最終差分データ移行・整合性チェック
  T-0   DNS を AWS エンドポイントに切替（TTL を事前に短縮しておく）
  T+30m アプリの動作確認・主要機能の疎通確認
  T+1h  監視異常なければメンテナンスモード解除
  T+2h  ユーザーへの完了通知

[ロールバック判断基準]
  カットオーバー後 2時間以内:
    エラー率が移行前の 3倍以上 → 即時ロールバック
    主要機能の 5XX 継続 → 即時ロールバック
  
  ロールバック手順:
    DNS を旧システムに戻す（事前に旧エンドポイントを保存）
    ソースシステムの書き込み禁止を解除
    DMS CDC を再開（AWS → オンプレの逆同期）

6. 移行失敗パターンと対策

失敗パターン	問題	対策
依存関係の見落とし	移行後に連携先が壊れる	Application Discovery Service で依存マップを作成
性能テスト不足	移行後にパフォーマンス劣化	本番同等データ・トラフィックでテスト
DNS TTL が長い	カットオーバー後も旧環境にアクセス	1週間前に TTL を 300秒以下に変更
ロールバック手順未整備	問題発生時に元に戻せない	カットオーバー計画と同時にロールバック手順を作成
移行後の監視不足	問題の検知が遅れる	移行後 2週間はアラート閾値を厳しめに設定
ライセンス確認不足	移行後にライセンス違反	DB / ミドルウェアのライセンスを移行前に確認
移行スコープのクリープ	予定より長くなる	Wave あたりの対象を明確に限定する

7. 移行プロジェクトチェックリスト

[アセスメントフェーズ]
□ アプリケーションポートフォリオを棚卸しした
□ 依存関係マップを作成した
□ 移行難易度と優先順位を評価した
□ 波次計画（Wave Plan）を承認した
□ AWS Migration Evaluator で TCO 試算を実施した

[準備フェーズ]
□ Landing Zone（Organizations / Control Tower）を構築した
□ Direct Connect または Site-to-Site VPN を接続した
□ ネットワーク設計（CIDR / トランジットゲートウェイ）を完成した
□ CloudTrail / GuardDuty / SecurityHub を有効化した
□ 移行ツール（MGN / DMS）の準備が完了した

[移行実行フェーズ]
□ パイロット Wave で手順を確認した
□ 本番同等データでの性能テストを実施した
□ カットオーバー手順とロールバック手順を作成した
□ DNS TTL を事前に短縮した（300秒以下）
□ 関係者・ユーザーへの通知を完了した

[移行後フェーズ]
□ 監視設定を強化した（移行直後2週間は厳しめのアラート）
□ コスト確認と Savings Plans 購入計画を作成した
□ ポストモーテム（移行レビュー）を実施した
□ モダナイゼーションロードマップを策定した

目次

AWS移行戦略ガイド

1. 移行戦略 6R

6R の概要と選択基準

6R の選定フロー

2. 移行フェーズと主要タスク

Phase 1: アセスメント（評価）

Phase 2: 準備（Landing Zone 構築）

Phase 3: 移行実行

Phase 4: 最適化・モダナイゼーション

3. 主要移行サービスの使い方

Application Migration Service（MGN）

AWS DMS（Database Migration Service）

Migration Hub と Migration Evaluator

4. DB 移行パターン別ガイド

Oracle → Aurora PostgreSQL（ヘテロジニアス移行）

SQL Server → Aurora MySQL / PostgreSQL

MySQL → Aurora MySQL（ホモジニアス移行）

5. カットオーバー計画

カットオーバー手順テンプレート

6. 移行失敗パターンと対策

7. 移行プロジェクト チェックリスト

7. 移行プロジェクトチェックリスト