移行とデータ転送
7R 戦略、Application Migration Service、DMS、DataSync、Transfer Family、Storage Gateway、Snow Family: サーバー、データベース、データを AWS へ移すための手段。
- 分野弾力性のあるアーキテクチャ
- 分野高性能なアーキテクチャ
- 分野コスト最適化
- 図 9
- 出題パターン 10
- サービス 11
5 分で押さえる要点
- 7 つの戦略（7R）: Retire、Retain、Rehost、Relocate、Repurchase、Replatform、Refactor。試験ではシナリオを示して戦略を問われます。アプリをそのまま EC2 へ = rehost、マネージドサービスへ切り替え = replatform、クラウドネイティブに書き換え = refactor、SaaS へ移行 = repurchase。
- 大量のサーバーを最速で移す Rehost（lift and shift）は、Application Migration Service（MGN）がブロックレベルで継続的にレプリケーションし、数分でカットオーバーします。MGN は CloudEndure Migration の後継で、現在は AWS Transform（「AWS Transform MGN」）に含まれます。
- Replatform の例: 自前の SQL Server を Amazon RDS for SQL Server へ、アプリをコード修正なしでコンテナへ。変更が少なく運用負荷を減らせます。アーキテクチャを再設計しない点が refactor との違いです。
- DMS はデータベースのデータを移行し、移行中もソースは稼働し続けます。タスクは 3 種類: full load、full load + CDC、CDC only。ダウンタイムをほぼゼロにするには、full load + CDC を実行し、ターゲットが追いついたらカットオーバーします。
- エンジンを変更する場合（Oracle → Aurora PostgreSQL）は、先に DMS Schema Conversion または AWS SCT でスキーマを変換し、その後 DMS でデータを移行します。DMS は、他のエンジン向けのストアドプロシージャやコードを自動では書き換えません。
- DataSync: ネットワーク経由でファイル / オブジェクトをコピーします（NFS、SMB、HDFS、オブジェクトストレージ → S3、EFS、FSx）。TLS 暗号化、整合性チェック、スケジュール実行に対応し、変更分のみをコピーします。オンプレミスのソースには DataSync agent（VM）が必要です。同一アカウント内の AWS サービス間のコピーには agent は不要です。
- Transfer Family: SFTP、FTPS、FTP、AS2 をマネージドで提供し、S3 または EFS に直接保存します。取引先が SFTP でファイルを送っていて、先方には何も変更させたくない場合は Transfer Family です。
- Storage Gateway は長期利用のハイブリッド接続です。S3 File Gateway（NFS/SMB → S3）、FSx File Gateway、Volume Gateway（iSCSI、cached / stored）、Tape Gateway（テープの代替）があります。DataSync（1 回限り / スケジュール転送）との違いは、オンプレミスのアプリが使い続けられ、ローカルにキャッシュがある点です。
- ネットワークが足りない場合はオフライン転送です。SAA 試験では今も Snowball Edge が出題されます。実際には Snowball Edge は新規顧客の受付を終了しており、AWS は DataSync（オンライン）または Data Transfer Terminal（ドライブを AWS のデータ転送拠点に持ち込む）を推奨しています。概算: 100 Mbps 回線で 100 TB を転送すると約 3 か月かかります。その場合は、機器を持ち込む方が通常は速くなります。
- 移行前のアセスメント: Application Discovery Service がオンプレミスのマシンの構成、使用状況、ネットワーク接続を収集し、Migration Hub がデータを集約して進捗を追跡します。どちらも新規顧客の受付を終了しています（Migration Hub は 2025 年 11 月 7 日から）。新規顧客は AWS Transform を使います。SAA-C03 では、アセスメント工程の正解として ADS + Migration Hub が出題される可能性があります。
- 大規模で長期にわたる移行のネットワーク経路: Direct Connect（安定）または VPN（すぐ構築できる）。DataSync、DMS、MGN は Direct Connect / VPN と VPC endpoint 経由で実行でき、パブリックインターネットを通らずに済みます。
構成図
Application Migration Service: 継続レプリケーションからカットオーバーへ
ステップ
- agent がソースマシンのディスクをステージングサブネットにレプリケーションし、その後は変更を継続的に送ります。
- テスト用のインスタンスを起動して、アプリが正しく動くか確認します。その間もソースマシンはサービスを続けます。
- カットオーバー: ソースの書き込みを止め、最新のレプリカからインスタンスを起動し、DNS を AWS に向けます。ダウンタイムは数分です。
エンジン変更: 先にスキーマ変換、その後 DMS でデータ移行
ステップ
- スキーマとコード（PL/SQL → PL/pgSQL）を Aurora PostgreSQL 向けに変換します。自動変換できない部分はレポートに出力され、手作業で修正します。
- DMS が全データをロードし、続いて Oracle の redo log から読み取った変更（CDC）を適用します。
DMS full load + CDC: ほぼ無停止のカットオーバー
DataSync: Direct Connect 経由で NAS を EFS / S3 にコピー
ステップ
- agent が NAS のファイルを読み取り、Direct Connect（またはインターネット / VPN）経由で TLS 暗号化して送信します。VPC endpoint を経由することもできます。
- DataSync が EFS または S3 に書き込み、checksum を検証します。2 回目以降は変更されたファイルのみコピーします。
ネットワークが足りない場合のオフライン転送
ステップ
- ネットワーク経由の所要時間を計算します。期限に間に合いません。
- 現地でデバイスにコピーし、輸送すると、AWS がデータを S3 に取り込みます。
Storage Gateway: オンプレミスのアプリが AWS 上のストレージを利用
ステップ
- File Gateway: NFS / SMB のファイル共有で、各ファイルが 1 つの S3 オブジェクトになり、最近使ったファイルはキャッシュされます。
- Tape Gateway: バックアップソフトが仮想テープに書き込み、アーカイブされたテープは S3 Glacier に移ります。
- Volume Gateway: iSCSI ボリューム（cached または stored）で、EBS スナップショットとしてバックアップされます。
Transfer Family: マネージドの SFTP で S3 に直接保存
ステップ
- 取引先は従来どおり（SFTP、AS2 など）接続し、SSH キーまたはカスタムの identity provider で認証します。
- ファイルは S3 に保存され、イベントが処理を起動します。
アプリケーションごとの 7R 戦略の選び方
ステップ
- 誰も使わず価値もない場合は retire し、コストとセキュリティリスクを減らします。
- 同等の SaaS がある場合は repurchase（drop and shop）。
- 自前の SQL Server を Amazon RDS for SQL Server に移す場合は replatform。
- 何も変更せずマシンごと移す場合は、Application Migration Service（MGN）で rehost。
アセスメントと移行の追跡: Discovery Service、Migration Hub、AWS Transform
ステップ
- VMware の VM: Agentless Collector を vCenter 経由で 1 回導入すれば、構成と CPU、RAM、ディスクの使用率を収集します。
- どのマシンがどのマシンと通信しているか（アプリケーションのグループ化用）を知る必要がある場合は、各マシンに Discovery Agent をインストールします。
- 移行中は MGN と DMS が Migration Hub にステータスを報告し、アプリケーションごとの進捗を確認できます。
- 新規顧客: 上記 2 サービスは新規登録を終了しているため、同様のアセスメントと追跡には AWS Transform を使います。
比較表
7 つの移行戦略（7R）
| 戦略 | 意味 | 例 / ツール |
|---|---|---|
| Retire | 価値のないアプリケーションを廃止 | 90 日間誰も使っていないアプリ |
| Retain | 現状維持で、まだ移行しない | 特殊なハードウェアへの依存、アップグレード直後、SaaS 版の登場待ち |
| Rehost | そのまま移行（lift and shift） | Application Migration Service、VM Import/Export |
| Relocate | 基盤ごとクラウド版へ移行。新規ハードウェア購入なし、アプリ修正なし | VMware を Elastic VMware Service へ、インスタンスを別の VPC / アカウントへ移動 |
| Repurchase | 旧アプリを廃止し、別の製品（多くは SaaS）を購入 | 自前の CRM → SaaS の CRM |
| Replatform | 移行しつつ部分的に最適化（lift, tinker and shift） | SQL Server → RDS for SQL Server、VM → コンテナ |
| Refactor | クラウドネイティブな設計に作り直す | モノリス → マイクロサービス、サーバーレス |
データ転送ツールの選び方
| 移したいもの | ツール | 備考 |
|---|---|---|
| サーバー（VM、物理、他クラウド）をそのまま | Application Migration Service | ブロックの継続レプリケーション、数分でカットオーバー |
| データベースのデータ、ソースは稼働したまま | DMS（full load + CDC） | エンジンが異なる場合: 先に Schema Conversion / SCT |
| ネットワーク経由のファイル / オブジェクト（1 回限りまたはスケジュール） | DataSync | NFS、SMB、HDFS、オブジェクトストレージ、他クラウド |
| SFTP / FTPS / FTP / AS2 でファイルを受信 | Transfer Family | S3 または EFS に保存 |
| オンプレミスのアプリが AWS 上のストレージを長期利用 | Storage Gateway | ローカルキャッシュあり |
| ネットワークが足りない数百 TB | 物理デバイス（試験では Snowball Edge、新規顧客は Data Transfer Terminal） | 暗号化は必須 |
DataSync と Storage Gateway
| DataSync | Storage Gateway | |
|---|---|---|
| 目的 | データの移行 / コピー | オンプレミスのアプリが日常的に AWS のストレージを利用 |
| 動作方式 | 1 回限り、またはスケジュール実行のタスク | 常時稼働、NFS / SMB / iSCSI / VTL |
| ローカルキャッシュ | なし | あり |
| 試験での例 | 50 TB の NAS を EFS に移行して NAS を廃止 | テープライブラリの代わりに仮想テープへバックアップ、ファイルサーバーの裏側に S3 |
DMS: 3 種類のタスク
| 種類 | 動作 | 使う場面 |
|---|---|---|
| Full load | 既存データを 1 回コピー | 移行中の書き込み停止が許容される |
| Full load + CDC | 全件コピー後、新しい変更を継続して適用 | ダウンタイムをほぼゼロにしたい |
| CDC only | ある時点からの変更のみ適用 | 別の方法でデータをロード済み（例: ネイティブバックアップ） |
よく出る出題パターン
1800 台の VMware サーバーを 6 か月で AWS に移行します。アプリは修正せず、各サーバーのダウンタイムは最小限にします。
答えを見る
正解: AWS Application Migration Service（MGN）で rehost する
ブロックの継続レプリケーション、テスト起動、数分でのカットオーバーが可能で、サーバーをアプリケーションや wave 単位でグループ化できます。
不正解: 各アプリをサーバーレスアーキテクチャで書き直す
Refactor は 800 台では遅くリスクも高く、「修正しない」という要件にも反します。
不正解: 各サーバーの AMI を手作業で作成する
継続的なレプリケーションがなく、ダウンタイムが大きく、スケールしません。
2オンプレミスの Oracle を Aurora PostgreSQL に移行します。アプリケーションの停止は数分までです。
答えを見る
正解: DMS Schema Conversion（または SCT）でスキーマを変換し、DMS の full load + CDC を実行して、レプリケーション遅延がほぼ 0 になったらカットオーバーする
ソースは移行中も稼働し続け、停止するのは接続を切り替える間だけです。
不正解: DMS の full load だけを使う
コピーしている間ずっと書き込みを止める必要があります。
不正解: スキーマを変換せず DMS だけを使う
エンジンが異なるため、ストアドプロシージャやデータ型の変換が必要です。
3オンプレミスの MySQL を、同じエンジンの Amazon RDS for MySQL に低ダウンタイムで移行します。
答えを見る
正解: DMS の full load + CDC（または MySQL ネイティブのレプリケーション）
同種（homogeneous）の移行なので、データの移行と変更への追いつきだけで済みます。
不正解: SCT でスキーマを変換する
同じエンジンなので、スキーマ変換は不要です。
4毎晩、オンプレミス NAS（NFS）の新しいフォルダーを Direct Connect 経由で Amazon EFS に同期し、整合性チェックも行う必要があります。
答えを見る
正解: AWS DataSync（オンプレミスに agent、スケジュール実行のタスク、変更分のみコピー）
TLS 暗号化、整合性チェックがあり、DX / VPC endpoint 経由で実行できます。
不正解: 毎週 Snowball Edge を使う
ネットワーク回線がすでにある場合、物理デバイスは日次の同期に向きません。
不正解: EC2 上で自作の rsync スクリプトを動かす
並列化、リトライ、暗号化、整合性チェックをすべて自前で用意する必要があります。
5取引先が毎日 SFTP で注文ファイルを送ってきます。自前管理の SFTP サーバーを廃止し、ファイルを S3 に保存したいが、取引先には何も変更させたくありません。
答えを見る
正解: AWS Transfer Family（SFTP）で S3 に保存し、既存のドメイン名 / SSH キーを引き続き使う
SFTP がマネージドで提供され、受信後のファイル処理は managed workflow や S3 イベントで行えます。
不正解: 取引先に AWS CLI で S3 へアップロードしてもらう
取引先側の手順を変えることになります。
6600 TB のデータを S3 に移す必要があります。インターネット回線は 200 Mbps しかなく、3 週間以内に完了させなければなりません。
答えを見る
正解: 物理デバイスによるオフライン転送（試験での正解: 複数台の Snowball Edge）。実際には新規顧客は Data Transfer Terminal またはパートナーを利用
期限内に必要な帯域をネットワークで確保できない場合は、デバイスでデータを運びます。
不正解: インターネット経由の DataSync
200 Mbps はおよそ 2 TB/日で、約 9 か月かかります。
7テープライブラリが老朽化しています。現行のバックアップソフトは変えずに、バックアップを AWS に低コストで置きたい。
答えを見る
正解: Storage Gateway の Tape Gateway（仮想テープ → S3、長期アーカイブは S3 Glacier へ）
バックアップソフトからは仮想テープライブラリに見えるため、変更は不要です。
不正解: DataSync でバックアップファイルを S3 にコピーする
バックアップソフトはファイルではなくテープ（VTL）に書き込んでいます。
8オンプレミスのアプリが SMB でファイルを書き込み、データは分析用に S3 に置きたい。最近のファイルへのアクセスは高速である必要があります。
答えを見る
正解: S3 File Gateway（SMB / NFS、ローカルキャッシュ、ファイルは S3 オブジェクトになる）
アプリは通常のファイル共有として使え、データは S3 上にあります。
不正解: インターネット経由で S3 を直接マウントする
S3 は SMB のファイル共有ではありません。
9社内アプリケーションが過去 6 か月間誰にも使われておらず、サポート切れの OS 上で動いています。どの戦略を取りますか。
答えを見る
正解: Retire
廃止すれば、コストとセキュリティリスクを減らせます。
不正解: EC2 に rehost する
価値のないものを動かすために費用がかかります。
10300 台を移行する前に、どのマシンがどのマシンに依存しているか、実際の使用状況を把握して EC2 のサイズを選びたい。
答えを見る
正解: 試験では Application Discovery Service（agent または agentless collector）+ Migration Hub。現在の新規顧客は AWS Transform
依存関係の把握、wave の分割、EC2 サイズの選定には、実際の使用状況とマシン間のネットワーク接続が必要です。ADS と Migration Hub は新規顧客の受付を終了しており、AWS は同等の機能として AWS Transform を推奨しています。
不正解: 現在のハードウェア構成で EC2 のサイズを決める
たいていは大幅に過剰になります。
早見表
何を移行しますか。
| やりたいこと | 使うもの |
|---|---|
| 多数のサーバー、アプリは修正しない | Application Migration Service（rehost） · 図を見る |
| 同じエンジンのデータベース、低ダウンタイム | DMS full load + CDC · 図を見る |
| 異なるエンジンのデータベース | DMS Schema Conversion / SCT + DMS · 図を見る |
| ネットワーク経由のファイル / オブジェクト（1 回限りまたは定期） | DataSync · 図を見る |
| 取引先が SFTP / FTPS / AS2 でファイルを送る | Transfer Family · 図を見る |
| オンプレミスのアプリが AWS 上のファイル共有 / ボリューム / 仮想テープを長期利用 | Storage Gateway · 図を見る |
| 数百 TB で、ネットワークでは期限に間に合わない | デバイスによるオフライン転送（試験では Snowball Edge） · 図を見る |
| アセスメント、依存関係の把握、wave の分割 | 試験では Application Discovery Service + Migration Hub、新規顧客は AWS Transform · 図を見る |
| 誰も使っていないアプリケーション | Retire · 図を見る |
| 自前のアプリを SaaS に置き換える | Repurchase · 図を見る |
落とし穴
- 「速く、コード修正なし」という要件なのに refactor を選ぶ（正解は rehost）。
- エンジンが異なるデータベースで、スキーマ変換（Schema Conversion / SCT）を飛ばして DMS を使う。
- ダウンタイム最小という要件なのに DMS の full load を選ぶ（full load + CDC が必要）。
- 1 回限りのデータ移行で、ソースを廃止するのに Storage Gateway を使う（正解は DataSync）。
- オンプレミスのアプリが、キャッシュ付きで AWS 上のファイルに日常的にアクセスするのに DataSync を使う（正解は Storage Gateway）。
- Transfer Family の SFTP を構築せず、取引先に手順の変更を求める。
- 帯域の計算で期限に間に合わないと分かっているのに、ネットワーク経由の転送を選ぶ。
- オンプレミスの DataSync には、データソースの近くで動く agent（VM）が必要なことを忘れる。
- Snowball Edge が新規顧客を受け付けていると思い込む（現在は既存顧客のみ。ただし古い試験問題では Snowball が正解の場合がある）。
- 実際の使用状況のデータではなく、旧ハードウェアに合わせて EC2 のサイズを選ぶ。
このモジュールのサービス
MGNサーバーの AWS への lift-and-shift
DMSデータベースの移行・レプリケーション
DataSyncオンラインのファイルデータ転送
Transfer Familyマネージド SFTP/FTP
Storage GatewayオンプレミスとAWSのストレージ連携
Snowball Edgeエッジ向けストレージ・計算デバイス
Data Transfer Terminal物理的なデータアップロード拠点
Migration Hub移行の進捗ダッシュボード
Application Discovery Service移行前のインフラ調査
Direct ConnectAWSへの専用回線
Transformアプリのモダナイゼーション AI agent
変わりやすい数値 (AWS ドキュメントで確認済み)
- Snowball Edge は新規顧客には提供されていません。AWS は DataSync（オンライン）、Data Transfer Terminal（デバイス持ち込み）、またはパートナーを推奨しています。Snowball Edge Storage Optimized は 210 TB、ネットワークは最大 100 Gbit/s です。 2026-10-16 確認 ↗
- Data Transfer Terminal: 予約を取り、ストレージデバイスを AWS の拠点に持ち込み、高速接続で S3 または EFS にアップロードします。デバイスは作業中ずっと手元に置いたままです。 2026-10-16 確認 ↗
- DataSync は NFS、SMB、HDFS、オブジェクトストレージ、S3、EFS、各種 FSx、他クラウドのストレージに対応しています。 2026-10-16 確認 ↗
- DataSync: オンプレミスのソースには agent（VM）が必要です。データは転送中 TLS で暗号化され、整合性チェックは常に行われます。同一アカウント内の AWS サービス間のコピーには agent は不要です。 2026-10-16 確認 ↗
- Transfer Family は SFTP、FTPS、FTP、AS2 とブラウザー経由の転送に対応し、S3 または EFS に保存します。 2026-10-16 確認 ↗
- Application Migration Service（現 AWS Transform MGN）: 物理サーバー、仮想マシン、他クラウドをブロックレベルで継続的にレプリケーションし、カットオーバーは通常数分です。 2026-10-16 確認 ↗
- DMS は 1 回限りのデータ移行、または継続的な変更レプリケーションを伴う移行を行います。異なるエンジン間のスキーマ変換は DMS Schema Conversion または AWS SCT で行います。 2026-10-16 確認 ↗
- DMS には full load + CDC と CDC only のタスクがあります。CDC はソースのトランザクションログを読み取るもので、リアルタイムのレプリケーションではありません（遅延が数分になることがあります）。 2026-10-16 確認 ↗
- 7 つの戦略: retire、retain、rehost、relocate、repurchase、replatform、refactor / re-architect。 2026-10-16 確認 ↗
- Storage Gateway には S3 File Gateway、FSx File Gateway、Tape Gateway、Volume Gateway（cached と stored）があります。 2026-10-16 確認 ↗
- AWS Migration Hub は 2025 年 11 月 7 日から新規顧客の受付を終了しています。AWS は同等の機能として AWS Transform を推奨しています。 2026-10-19 確認 ↗
- AWS Application Discovery Service は新規顧客の受付を終了しており、AWS は AWS Transform を推奨しています。Agentless Collector は vCenter 経由で動作し（VMware の VM のみ）、Discovery Agent は各マシンにインストールして、ネットワーク接続とプロセスも追加で記録します。 2026-10-19 確認 ↗
- 7R は retire、retain、rehost、relocate、repurchase、replatform、refactor / re-architect です。refactor は最も複雑で、大規模移行には推奨されません。 2026-10-19 確認 ↗
- Application Discovery Service は新規顧客の受付を終了しており、AWS は AWS Transform を推奨しています。 2026-10-19 確認 ↗