SAP-C02 D4 移行と近代化 徹底解説（2025年最新）｜6R戦略・MGN・DMS/SCT・Snow Family試験対策

1. はじめに — D4「移行と近代化の加速」とは

本記事は「AWS SAP-C02 試験対策」シリーズの Vol4 です。
SAP-C02（AWS Certified Solutions Architect – Professional）は、AWSアーキテクチャの設計・最適化において高度な実務経験を持つプロフェッショナル向けの最難関資格です。

本記事が扱う D4「Accelerate Workload Migration and Modernization（移行と近代化の加速）」は出題比率20%、300問バンク換算60問 を占めます。

D4はAWS Professional試験の中でも「設計判断」と「トレードオフ評価」が最も色濃く出るドメインです。
単に移行ツールを暗記するのではなく、ビジネス要件・制約条件・リスク許容度を踏まえた上で、最適な移行アプローチを選定・設計する能力 が問われます。
オンプレミスのワークロードをAWSへ安全に、可能な限り低リスク・低コストで移行し、クラウドネイティブなアーキテクチャへと進化させていく — この一連のジャーニーがD4の核心です。

1-1. D4の出題範囲と公式タスクステートメント

SAP-C02 公式試験ガイド（v1.2）は D4 を次の2つのタスクステートメントで定義しています。

「どのツールで移行するか」だけでなく、「移行後にどうモダナイズするか」まで設計できることが求められます。
Professional試験らしく、複数のツールや戦略を組み合わせた複合シナリオが頻出です。

2. 移行戦略フレームワーク — 6R/7R と選定判断

2-1. 6R戦略の全体像

AWSが定義する移行戦略の基本フレームワークが 6R（またはそれを拡張した7R） です。
各「R」はワークロードに対するアプローチを表しており、コスト・時間・リスク・将来的な柔軟性のトレードオフを整理する軸になります。

7R は6R に「Relocate」を加えたもので、VMware環境の移行シナリオで登場します。

2-2. 選定の実践ロジック（Professional視点）

SAP試験では「このシナリオに最適なRはどれか」という選択判断問題が多く出ます。
実務的な選定ロジックは以下の通りです。

まず Retire と Retain を識別する: アプリケーションポートフォリオ全体を Assessment し、使われていないシステムはRetire、移行できない（規制・依存・コスト見合い）はRetain として除外します。これだけで移行対象を20〜30%削減できることが多く、全体TCOの改善につながります。

Rehost は速度優先・初回移行の出発点: 変更なしにAWSへ持ち込み、まずクラウド上で動かすことを優先します。MGN（Application Migration Service）を使えば継続ブロックレプリケーションで最小ダウンタイムのカットオーバーが可能です。移行後の段階的な近代化（Replatform / Refactor）への足場としても機能します。

Replatform はすぐに効果の出る中間点: データベースをオンプレのMySQL/PostgreSQLからAmazon RDSへ、アプリをEC2からElastic Beanstalkやコンテナ（Fargate）へ移す程度の変更です。アプリ本体の改修は最小限に抑えつつ、マネージドサービスの恩恵（パッチ適用・スケーリング）を得られます。

Refactor は最も時間とコストがかかるが最大の価値: モノリスをマイクロサービスへ、バッチをイベント駆動Lambdaへといった再設計です。初期投資は大きいが、スケーラビリティ・開発速度・コスト効率が長期的に最大化されます。

2-3. TCO計算と Migration Evaluator

移行戦略の意思決定を支えるのが コスト評価 です。
AWS Migration Evaluator（旧TSO Logic）はオンプレミス環境の実測データ（CPU/メモリ/ストレージ使用率）を取り込み、AWSへ移行した場合のTCO試算とビジネスケースを自動生成します。
SAP試験では「移行前後の総コスト比較・ビジネスケース根拠を作成するには何を使うか」という問いで Migration Evaluator が正解になるパターンが頻出です。

2-4. Cloud Adoption Framework（CAF）と移行準備度

AWS Cloud Adoption Framework（CAF）は、クラウド移行に必要な組織的能力を6つの観点（ビジネス・人材・ガバナンス・プラットフォーム・セキュリティ・運用）で整理したフレームワークです。
Migration Readiness Assessment（MRA） はCAFに基づく評価ツールで、組織の移行準備状態をスコア化します。
「移行を開始する前に何を評価すべきか」という問いではCAFとMRAが正解の軸になります。

3. 移行計画・アセスメントツール — Migration Hub エコシステム

3-1. AWS Application Discovery Service（ADS）

移行の第一歩は 現状把握（Discovery） です。
AWS Application Discovery Service はオンプレミス環境の構成・依存関係・パフォーマンスデータを収集します。

収集データはすべて Migration Hub に集約され、ウェーブ計画（移行の順序グループ）の策定に使用します。

3-2. AWS Migration Hub

AWS Migration Hub は移行プロジェクト全体の「司令塔」です。
複数の移行ツール（MGN・DMS・Snow Family 等）の進捗を一元ダッシュボードで追跡し、ポートフォリオ単位でのステータス管理を実現します。

SAP試験では「複数ツールを使った大規模移行プロジェクトの進捗を一元管理するサービス」という問いで Migration Hub が正解になります。

3-3. Migration Hub Orchestrator

Migration Hub Orchestrator は移行ワークフローの自動化ツールです。
SAP on AWS や Windows Server 移行など、事前定義されたテンプレートに沿って移行手順を自動実行・ステータス追跡します。
「大規模な移行ウェーブを繰り返し実行する場合の自動化」というシナリオでは Orchestrator が正解です。

3-4. Migration Hub Strategy Recommendations（移行戦略推奨）

ADS で収集したデータと実際のアプリケーションを分析し、各アプリに対する 推奨移行戦略（7Rの分類） を自動生成します。
Migration Evaluator がコスト試算に特化するのに対し、Strategy Recommendations はアプリケーション単位の移行戦略策定を支援します。

4. アプリケーション移行 — MGN と DRS の継続レプリケーション

4-1. AWS Application Migration Service（MGN）

MGN（Application Migration Service） は Rehost（Lift & Shift）移行の主軸ツールです。
旧称「CloudEndure Migration」の後継で、物理・仮想・クラウド上のサーバーをAWSへ移行します。

MGN の動作原理:
1. レプリケーションエージェント をソースサーバーにインストール
2. ブロックレベルの 継続レプリケーション でAWSのレプリケーションサーバーにデータをリアルタイム同期
3. テスト起動 でAWSでの動作を事前検証（本番には影響なし）
4. カットオーバー 時にレプリケーションを完了させ、本番トラフィックを切り替え

MGN の特長:
– ダウンタイムを最小化（カットオーバー時のみ）
– OS・アプリの変更不要でそのまま移行
– 大量VM（数十〜数千台）の並列移行に対応
– 移行後の段階的なリプラットフォーム・リファクタへの足場になる

SAP試験では「最小ダウンタイムで大量サーバーをAWSに移行」→ MGN、「アプリ改修なしでEC2に移行」→ MGN という対応が基本です。

4-2. AWS Elastic Disaster Recovery（DRS）

DRS（Elastic Disaster Recovery） は元々DRサービスですが、MGNと同様の継続ブロックレプリケーション機能を持つため 移行ツールとしても機能 します。

DRS と MGN の判断軸:
– 「移行後もDRが必要」「移行とDR構築を同時に」→ DRS
– 「まず移行を完了させ、その後クラウド最適化」→ MGN

5. データベース移行 — DMS・SCT・Fleet Advisor

5-1. AWS Database Migration Service（DMS）

DMS はデータベースをAWSへ移行するマネージドサービスです。
同種DB間（MySQL→MySQL、Oracle→Oracle）と異種DB間（Oracle→Aurora、SQL Server→RDS PostgreSQL）の両方に対応します。

DMS の移行フローは2段階で構成されます。

① 全ロード（Full Load）: ソースDBの全データをターゲットDBにコピーします。大量データの場合は数時間〜数日かかります。

② CDC（Change Data Capture / 継続的データレプリケーション）: 全ロード完了後、ソースDBへの差分変更をリアルタイムでターゲットに適用し続けます。CDCが動いている間、アプリはソースDBを使い続けられます。カットオーバー時に差分が追いついた段階でアプリの接続先をターゲットDBに切り替えます。

この「全ロード + CDC」の組み合わせが、本番移行での最小ダウンタイムパターン です。

5-2. AWS Schema Conversion Tool（SCT）

SCT は異種DBの移行で活躍する変換ツールです。
ソースDBのスキーマ・ストアドプロシージャ・ビュー・トリガーを解析し、ターゲットDBの構文に自動変換します。

SCT の主要機能:
– アセスメントレポート: 自動変換可能な割合と、手動対応が必要な箇所を一覧化
– 拡張パック（Extension Pack）: 変換できないストアドプロシージャや組み込み関数を代替実装するパッケージ

典型的な使い分け: Oracle → Aurora PostgreSQL の移行では、SCTがスキーマ・ストアドプロシージャを変換し、DMSでデータを移送するという組み合わせが標準です。

5-3. DMS Fleet Advisor

DMS Fleet Advisor は移行前のアセスメントツールです。
オンプレミスやクラウド上のデータベースインベントリを自動収集し、移行の複雑度・推奨ターゲットDB・コスト見積もりを提示します。
大規模な多数DB移行プロジェクトの初期計画フェーズで使用します。

5-4. 大規模データ移行 — Snowball Edge との組み合わせ

ネットワーク経由でのデータ転送が現実的でない大容量DB（数十TB以上）の場合は、DMS + Snowball Edge の組み合わせが有効です。

1. SCTとDMSを使ってローカルのSnowball Edgeにデータをエクスポート
2. Snowball Edgeをデータセンターから物理輸送
3. AWSでSnowball EdgeのデータをS3にインポートし、DMSでターゲットDBへロード

SAP試験では「ネットワーク帯域不足・転送時間が長すぎる」シナリオで Snowball Edge + DMS が正解になります。

6. データ転送・ストレージ移行 — Snow Family・DataSync・Transfer Family・Storage Gateway

6-1. AWS Snow Family の使い分け

Snow Family は物理デバイスを使ったオフラインデータ転送サービス群です。

Snow vs DataSync の判断軸:
– ネットワーク経由転送に数週間以上かかる → Snow
– 数日以内に転送可能 or 継続的な増分同期が必要 → DataSync

6-2. AWS DataSync

DataSync はオンプレミス（NFS/SMB/S3互換）またはクラウド間のデータを 高速・自動・継続的に同期 するマネージドサービスです。

DataSync の特長:
– エージェントをオンプレに配置、自動並列転送で最大10Gbps スループット
– ネットワーク帯域の自動スロットリング（業務影響を抑えながら転送）
– 転送前後のデータ整合性チェック（チェックサム検証）
– タスクスケジューリングで定期的な増分同期

DataSync の転送先:
S3・EFS・FSx for Windows・FSx for Lustre・FSx for NetApp ONTAP 等

SAP試験では「Snowcone で収集したエッジデータをDataSyncでS3へ送る」という組み合わせシナリオも出題されます。

6-3. AWS Transfer Family

Transfer Family はSFTP/FTP/FTPSプロトコルのサーバーをフルマネージドで提供します。
オンプレのSFTPサーバーからの移行で、クライアント側のプロトコルを変更せずにS3やEFSへデータを転送できます。

主要プロトコルサポート:
– SFTP（SSH File Transfer Protocol）
– FTPS（TLS暗号化FTP）
– FTP（非暗号化・内部ネットワーク専用推奨）
– AS2（Applicability Statement 2 — B2B EDI取引での標準プロトコル）

SAP試験では「現行のSFTPワークフローを変更せずS3へ移行」→ Transfer Family、「EDI/AS2ベースのB2B取引をクラウド移行」→ Transfer Family AS2 コネクタが正解です。

6-4. AWS Storage Gateway の使い分け

Storage Gateway はオンプレミスとAWSストレージをシームレスに統合するハイブリッドストレージサービスです。

DataSync vs Storage Gateway の判断軸:
– 一括移行・高速転送・移行完了後は不要 → DataSync
– 常時ハイブリッド接続・移行後も継続使用 → Storage Gateway

7. アプリモダナイゼーション — コンテナ化・サーバーレス化・Strangler Fig

7-1. App2Container によるコンテナ化

AWS App2Container（A2C） は既存のJava/.NETアプリケーションを自動的にコンテナ化するツールです。

移行フロー:
1. app2container discover でサーバー上のアプリを検出・分析
2. app2container extract でアプリのコンテナイメージを生成（Dockerfileも自動作成）
3. app2container containerize でECRへPushし、ECS/EKSまたはApp Runner向けのデプロイメント設定を生成

A2C の位置づけ: Rehost（MGNで移行）したEC2上のアプリを、次のReplatformステップとしてコンテナ化する際に活用します。コードの書き換えなしにコンテナ化できる点が強みです。

7-2. Strangler Fig パターン

Strangler Fig パターン は、モノリシックアプリを段階的にマイクロサービスへ移行するアーキテクチャパターンです。
名前の由来はイチジク（Strangler Fig）の木が宿主の木を覆って置き換えていく様子にあります。

実装アプローチ:
1. ファサードの導入: API GatewayまたはApplication Load Balancerをモノリスの前に配置
2. 機能単位の切り出し: ビジネス機能を1つ選んで新しいマイクロサービス（Lambda/ECS）として実装
3. ルーティング切り替え: APIゲートウェイのルーティングルールで対象機能のトラフィックを新サービスへ切り替え
4. 繰り返し: 全機能が移行完了するまでステップ2〜3を繰り返す

DDD（Domain-Driven Design）との組み合わせ: ドメイン境界（Bounded Context）に沿って切り出す単位を決めることで、凝集度の高いマイクロサービス設計になります。

Migration Hub Refactor Spaces: Strangler Figパターンの実装を支援するAWSサービスです。環境（Environment）とアプリケーション（Application）を定義し、マイクロサービスへの段階的ルーティング切り替えをサービスが管理します。

7-3. コンテナ移行 — ECS・EKS・Fargate

Elastic Beanstalk → ECS/EKS への移行 は Replatform の典型例です。

Beanstalkはアプリのデプロイを自動化する一方で、コンテナオーケストレーション・細かいスケーリング制御・マルチサービス管理の柔軟性に限界があります。
ECS（Elastic Container Service） はAWSネイティブなコンテナオーケストレーターで、Fargateを使えばEC2管理も不要です。
EKS（Elastic Kubernetes Service） はKubernetesのマネージドサービスで、オンプレのKubernetesクラスターからの移行や、マルチクラウド一貫性が求められる場合に選択されます。

Fargate の採用判断: EC2インスタンスのプロビジョニング・パッチ管理・キャパシティ管理を排除したい場合はFargateが最適です。コンテナの実行時間・CPU/メモリ量のみ課金となるため、ワークロードが断続的な場合はコストも最適化されます。

ECS Anywhere: オンプレまたは他クラウドのサーバーをECSクラスターに登録し、同じECS APIとツールで管理できる機能です。「オンプレのコンテナ環境とAWS ECSを統一した管理基盤で運用」というシナリオで登場します。

7-4. サーバーレス移行 — Lambda・Fargate

レガシー REST API のサーバーレス化 は Refactor の代表例です。

EC2上のアプリを段階的にサーバーレスに移行する場合:
– API Gateway + Lambda: HTTPリクエストを受け付け、ビジネスロジックをLambda関数として実装
– イベント駆動化: SQSキューやEventBridgeイベントをトリガーにLambdaを実行

リレーショナルDBからDynamoDBへの再設計 もRefactorの典型例です。
RDSのようなスキーマ固定型から、DynamoDBのキー・バリュー/ドキュメントモデルへの移行は、アクセスパターンを先に定義してテーブル設計（シングルテーブル設計）を行う必要があります。
スキャン操作を避け、GSI（Global Secondary Index）で補完するアクセスパターン設計が核心です。

7-5. AWS Proton — プラットフォームチームのインフラ標準化

AWS Proton は、プラットフォームエンジニアリングチームがインフラテンプレートを一元管理し、開発チームがセルフサービスでデプロイできる環境を提供するサービスです。

Proton の2つの主要概念:
– 環境テンプレート（Environment Template）: VPC・サブネット・IAMロールなどの共有インフラを定義
– サービステンプレート（Service Template）: アプリのデプロイ方法（ECS/Lambda）とCI/CDパイプラインを定義

「近代化後のアプリを標準的なインフラに乗せて開発者がセルフサービスでデプロイ」というシナリオでProtonが正解になります。

8. 専門領域の移行シナリオ

8-1. SAP on AWS / RISE with SAP

SAP on AWS は、SAPのエンタープライズアプリケーション（S/4HANA・ERP・BW等）をAWSで稼働させる構成です。
AWSはSAPの認定クラウドパートナーであり、特定のインスタンスタイプ・ストレージ構成・ネットワーク設計が認定済み要件として定められています。

認定構成の主要要件:
– インスタンス: SAP認定済みインスタンスタイプ（例: x1e・u-6tb1・r6i等）
– ストレージ: gp3/io2 EBS（IOPS・スループット要件を満たすこと）
– HA構成: マルチAZでの冗長化（SAP High Availabilityガイドラインに準拠）
– バックアップ: AWS BackupまたはSAP BackIntエージェント連携

RISE with SAP はSAP自体がマネージドサービスとして提供するS/4HANAのSaaS型移行プログラムです。

8-2. VMware Cloud on AWS + HCX

VMware Cloud on AWS はVMwareとAWSが共同提供するサービスで、VMwareのvSphere/vSAN/NSXスタックをAWSのベアメタルサーバー上で動かします。
オンプレのVMwareワークロードをそのままAWSに「Relocate」できるため、アプリの変更が一切不要です。

HCX（Hybrid Cloud Extension） はVMware環境とVMware Cloud on AWSの間でワークロードをライブマイグレーションするツールです。
「VMware環境を段階的にAWSへ移行しながら、一時的にオンプレとAWSをハイブリッドで運用する」シナリオで利用します。

VMware Cloud on AWS vs MGN の判断軸:
– VMware vSphereのまま移行したい（OS/アプリ変更なし）→ VMware Cloud on AWS + HCX（Relocate）
– EC2インスタンスとして移行し、クラウドネイティブ化を目指す → MGN（Rehost）

8-3. AWS Mainframe Modernization（M2）

AWS Mainframe Modernization（M2） はメインフレーム（IBM z/OS・Unisys等）のワークロードをAWSへ移行・近代化するサービスです。

2つのアプローチを提供します:
– リプラットフォーム: COBOLコードをそのままAWSで実行（Blu Age・Micro Focus等のエンジンを活用）
– 自動リファクタ（Refactor）: COBOLからJavaへの自動変換

COBOLバッチの段階的リファクタ: ミッションクリティカルなバッチジョブを一気に再実装するリスクを避け、Strangler Figパターンと同様、段階的に置き換える手法です。

8-4. AWS Outposts によるハイブリッド移行

AWS Outposts はAWSのインフラ（サーバー・スイッチ）をオンプレミスに物理配置し、AWSサービスをオンプレで実行するハイブリッドサービスです。

段階的移行への活用:
1. Outpostsをオンプレに設置し、レイテンシ要件の高いアプリをOutposts上で動かしながら
2. 他のワークロードをAWSリージョンへ段階的に移行
3. 最終的にOutpostsからリージョンへ完全移行、またはOutpostsの継続運用を選択

「データをオンプレに残しながら一部だけクラウドで処理したい」「規制でデータをオンプレに置かなければならないが、AWSサービスは使いたい」というシナリオでOutpostsが登場します。

8-5. 他クラウドからの移行

GCP・AzureからAWSへの移行でも MGN が活用できます。
MGN は物理・仮想・VMware・他クラウドサーバーのすべてに対応しており、OS・アプリを変更せずにEC2インスタンスとして再現します。

AWS Managed Services（AMS）への移行 は、AWS環境の運用管理をAWSが代行するサービスで、移行後の継続的な運用負荷を削減したい企業に選択されます。AMS はパッチ適用・バックアップ・セキュリティ監視・コスト管理を含む運用タスクをSLAベースで提供します。

8-6. オンプレHadoopからEMRへの移行

オンプレミスのHadoopクラスターをAWSに移行する場合、Amazon EMR（Elastic MapReduce）+ Amazon S3 のデータレイクアーキテクチャへの移行が標準パターンです。

• 処理エンジン（Hadoop/Spark）: オンプレのHadoopクラスター → EMRクラスター
• HDFS（データストレージ）: HDFS → S3（S3をデータレイクとして活用・EMRはステートレスに）

S3を永続ストレージに分離することで、EMRクラスターを処理ごとに起動・停止でき、コストを大幅に削減できます。

9. CertTrend LMS で300問演習

D4「移行と近代化の加速」の学習をさらに深めるには、実際の試験形式（Multiple Choice / Multiple Response）で繰り返し演習することが不可欠です。
CertTrend LMSでは、SAP-C02対応の300問問題バンクを提供しています。

10. 実務で深掘り — 移行・近代化本番運用記事

試験合格後に現場でD4の知識をさらに活用したい方向けに、DMS・MGN・移行ストレージの本番運用を詳解した記事を用意しています。

まとめ — D4「移行と近代化の加速」の学習ポイント

SAP-C02 D4「移行と近代化の加速」は、単一サービスの知識だけでなく 複数ツールの組み合わせによる設計判断 が問われるドメインです。

D4で扱う移行・近代化の知識は、実際のエンタープライズAWS移行プロジェクトで直接活用できるものです。
本記事と CertTrend LMS の300問演習を組み合わせ、Professional レベルの設計判断力を磨いてください。

シリーズ全体ナビ — SAP-C02 試験対策