概要
オンプレミスのシステムを AWS に移すとき、移す対象は 1 種類ではありません。サーバーそのもの、データベース、ファイル、そして取引先とやり取りしているファイル転送の仕組みなど、対象によって使うサービスが変わります。さらに、移したあとに「もし東京リージョンで障害が起きたら」という災害対策（DR）の考え方も、移行とセットで問われます。
AWS Certified Cloud Practitioner（CLF）では第 1 分野「クラウドのコンセプト」の「AWS クラウドへの移行の利点と戦略」、Solutions Architect – Associate（SAA）では移行・DR の設計として、これらのサービスの使い分けが出題されます。
この記事では、移行戦略の「7 つの R」、サーバー・データベース・ファイルごとの移行サービス、オンライン転送とオフライン転送の違い、災害対策の 4 つの戦略と RPO / RTO を、比較表を中心に整理します。どのサービスも 1 人で本格的に試すには移行元の環境や費用が必要なため、実践はコンソールの入口を確認する範囲にとどめます。
なお、この分野は 2025 年に提供状況が大きく変わりました（AWS Migration Hub・AWS Application Discovery Service・AWS Snowball Edge の新規受付終了、Application Migration Service の名称変更など）。この記事では 2026 年 10 月時点の公式ドキュメントで確認した内容を書いています。
クラウドおさる移行のサービスは名前が似ていて覚えにくいでござるが、「何を、どこから、どこへ」で並べれば迷わぬはずでござる。猿山の引っ越しでも、バナナ倉庫と長老の書類と見張り台では運び方が違うのでござるよ。
—
この記事のメリット
- 移行戦略の 7 つの R（リタイア・保持・リホスト・リロケート・再購入・リプラットフォーム・リファクタリング）を区別できるようになります
- 「サーバー」「データベース」「ファイル」のどれを移すかで、使うサービスを選べるようになります
- オンライン転送とオフライン転送（物理デバイスの輸送）の違いと、Snow Family の現在の提供状況を把握できます
- 災害対策の 4 つの戦略を、RPO / RTO とコストのトレードオフで説明できるようになります
- 2025 年以降に新規受付を終えたサービスと、その後継として案内されているサービスを把握できます
—
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
移行戦略の 7 つの R
クラウドおさるとひさん、AWS への移行というと、サーバーをそのまま AWS に持っていくことでござるか？
土肥それも 1 つのやり方だね。でも実際の移行では、アプリケーションごとに「どう移すか」を決めるんだ。AWS の規範ガイダンスでは、その選択肢を 7 つの R として整理しているよ。
| 戦略 | 別名 | 何をするか |
|---|---|---|
| リタイア（Retire） | ― | 使われていない・価値のないアプリケーションを廃止またはアーカイブする |
| 保持（Retain） | ― | 移行せずソース環境に残す（まだ準備ができていない、データの所在要件があるなど） |
| リホスト（Rehost） | リフトアンドシフト | アプリケーションを変更せずにそのまま AWS に移す |
| リロケート（Relocate） | ― | 複数のサーバーを、オンプレミスのプラットフォームからそのクラウド版へまとめて移す。ハードウェアの購入やアプリケーションの書き換えは不要 |
| 再購入（Repurchase） | ドロップアンドショップ | 別の製品・バージョン（SaaS など）に置き換える |
| リプラットフォーム（Replatform） | リフト、ティンカー、シフト | 移しながら一部を最適化する（例: SQL Server を Amazon RDS for SQL Server に移す） |
| リファクタリング / リアーキテクト（Refactor / Re-architect） | ― | クラウドネイティブの機能を活かすようにアーキテクチャを作り変える |
クラウドおさる「何もしない」の保持や、「捨てる」のリタイアまで戦略に入っているのでござるな。
土肥そうそう。移行の前に棚卸しをすると、もう誰も使っていないシステムが見つかることもあるからね。試験では「アプリケーションを変更せずに、できるだけ早く移したい」ならリホスト、「データベースだけマネージドサービスに替えたい」ならリプラットフォーム、という対応で選ばせることが多いよ。
クラウドおさる猿山の引っ越しで言えば、壊れた見張り台は捨てる（リタイア）、バナナ倉庫はそのまま運ぶ（リホスト）、古い木箱は冷蔵庫に替える（リプラットフォーム）、ということでござるな。
土肥うまいね！ その例えで合ってるよ。冷蔵庫に替えても中のバナナ（データ）は同じ、っていうのがリプラットフォームの感じだね。
「何を」移すかでサービスを選ぶ
クラウドおさる戦略が決まったら、実際に移すのはどのサービスでござるか？
土肥ここが試験でいちばん問われるところだよ。「何を」「どこから」「どこへ」移すかで選ぶんだ。まとめるとこんな感じだね。
| 移すもの | サービス | どこから → どこへ | ポイント |
|---|---|---|---|
| サーバー（OS ごと） | AWS Application Migration Service（MGN） | 物理・仮想・他クラウドのサーバー → Amazon EC2 | ソースサーバーをブロックレベルで継続的にレプリケーションし、AWS 上で起動できる形に変換する。リホスト向け |
| データベース | AWS Database Migration Service（DMS） | オンプレミス・クラウドのデータベース → AWS のデータベース | 1 回限りの移行のほか、変更を継続的にレプリケーションしてソースとターゲットを同期できる |
| データベースのスキーマ | DMS Schema Conversion / AWS Schema Conversion Tool（SCT） | 異なるエンジン間（例: Oracle → PostgreSQL） | スキーマやコードを変換する。SCT は PC にダウンロードして使う |
| ファイル・オブジェクト | AWS DataSync | NFS・SMB・HDFS・オブジェクトストレージ・他クラウド → Amazon S3・Amazon EFS・Amazon FSx | オンラインでの一括・定期的な転送。オンプレミスからはエージェントを使う |
| SFTP などのファイル転送 | AWS Transfer Family | 取引先などの SFTP・FTPS・FTP・AS2 クライアント → Amazon S3・Amazon EFS | ファイル転送サーバーをフルマネージドで用意する。クライアント側の設定はそのまま使える |
クラウドおさるDMS は、移行しているあいだ元のデータベースを止めなくてよいのでござるか？
土肥そう、そこが DMS のいいところなんだ。全体をコピーしたあとも、ソース側の変更を継続的にターゲットに反映できるから、ソースを動かしたまま移行を進めて、最後に切り替えればいい。それから DMS は、同じエンジン同士だけじゃなく、異なるエンジン間の移行（異種移行）にも対応しているよ。異種移行のときはスキーマの変換が要るから、DMS Schema Conversion や SCT を使うんだ。
クラウドおさるなるほど、データを運ぶのが DMS、箱の形（スキーマ）を作り直すのが SCT でござるな。
土肥その通り！ もう 1 つ、DataSync と Transfer Family の違いも押さえておこう。DataSync は「こちらから AWS へまとめて運ぶ」もの、Transfer Family は「外部の相手が SFTP などで送ってくる受け口を AWS に用意する」ものなんだ。
クラウドおさる猿山の倉庫を AWS へ引っ越すなら DataSync、隣の山の猿がバナナの伝票を送ってくる窓口を用意するなら Transfer Family でござるな。
AWS Application Migration Service は、公式ドキュメント上で AWS Transform MGN に名称が変わっています。略称の MGN はそのままです。試験や既存の資料では旧名で書かれていることが多いので、両方の名前で覚えておくと迷いません。
移行を計画・追跡するサービスと、2025 年の提供状況の変化
クラウドおさる移行の前に「どんなサーバーがあるか」を調べるサービスもあると聞いたでござる。
土肥うん、試験範囲にはこの 3 つが入っているね。ただ、2025 年 11 月 7 日に提供状況が変わったものがあるから、表の右端も一緒に見てほしいんだ。
| サービス | 役割 | 提供状況（公式ドキュメントで確認） |
|---|---|---|
| AWS Application Discovery Service | オンプレミスのサーバー・データベースの構成や使用状況、ネットワーク接続を収集する（エージェントレス / エージェントベース） | 2025 年 11 月 7 日に新規顧客の受付を終了。既存顧客は継続利用できる |
| AWS Migration Hub | 移行の計画と、各アプリケーションの移行状況を 1 か所で追跡する | 2025 年 11 月 7 日に新規顧客の受付を終了。既存顧客は継続利用できる |
| Migration Evaluator | オンプレミスの資産データをもとに、AWS に移した場合のコスト（TCO）を見積もり、移行のビジネスケースを作る。無料で利用できる | ― |
クラウドおさる新しく使い始めることはできなくなっているのでござるか…。では、これから移行する猿はどうすればよいのでござる？
土肥新規のお客さんには、後継として AWS Transform が案内されているよ。Migration Hub の機能や、Application Discovery Service の検出・評価の機能は AWS Transform で提供されているんだ。とはいえ CLF・SAA の試験ガイドには従来のサービス名が載っているから、「検出なら Application Discovery Service、追跡なら Migration Hub、コストの見積もりなら Migration Evaluator」という役割の対応は今でも覚えておこう。
オンライン転送とオフライン転送（Snow Family）
クラウドおさるデータがものすごく多いと、ネットワークで送るだけで何週間もかかりそうでござる。
土肥そういうときの選択肢が、物理的なデバイスにデータを入れて運ぶオフライン転送だよ。ネットワーク経由で送るオンライン転送と比べるとこうなるね。
| 方式 | 代表的なサービス | 向いている場面 |
|---|---|---|
| オンライン転送 | AWS DataSync、AWS Transfer Family | ネットワーク帯域が十分にある、継続的・定期的に転送したい |
| オフライン転送（物理デバイス） | AWS Snowball Edge（Snow Family） | 帯域が足りない・ネットワークが不安定な場所から、大量のデータを一度に移したい |
| オフライン転送（持ち込み拠点） | AWS Data Transfer Terminal | 自分のストレージデバイスを AWS の物理拠点に持ち込んでアップロードしたい |
クラウドおさるSnow Family は、デバイスを AWS から送ってもらって、データを入れて送り返す仕組みでござるな。
土肥そう、考え方はそれで合っているよ。ただ、ここが一番注意してほしいところなんだ。AWS Snowball Edge は 2025 年 11 月 7 日から新規顧客には提供されていないんだよ。既存のお客さんは引き続き使えるけど、新しく使い始めることはできない。
クラウドおさるなんと！ 試験に出る代表選手が、もう新しくは使えないのでござるか。
土肥公式ドキュメントでは、新規のお客さんにはオンライン転送なら DataSync、物理的な転送なら AWS Data Transfer Terminal かパートナーのソリューション、エッジコンピューティングなら AWS Outposts を検討するよう案内されているね。それから、以前あった超大容量向けの AWS Snowmobile は、2024 年 3 月 14 日にサポートが終了しているよ。
土肥今のドキュメントに載っている Snow Family のデバイスと、提供状況をまとめるとこうなるよ。
| デバイス | 内容 | 提供状況 |
|---|---|---|
| Snowball Edge ストレージ最適化 | 210 TB。大量データの移行向け | 既存顧客のみ（2025 年 11 月 7 日に新規受付を終了） |
| Snowball Edge コンピューティング最適化 | 現地でのコンピューティング処理向け | 既存顧客のみ（同上） |
| Snowmobile | エクサバイト規模の移行向けだったトラック型の転送手段 | 2024 年 3 月 14 日にサポート終了 |
土肥試験対策としては「ネットワークでは時間がかかりすぎる大量データを、物理デバイスで運ぶのがオフライン転送」という考え方そのものを押さえておけば大丈夫。実務で新しく選ぶときは、今の提供状況を必ず確認してね。
災害対策の 4 つの戦略と RPO / RTO
クラウドおさる災害対策では、どんなことを決めるのでござるか？
土肥まず 2 つの目標を決めるんだ。RPO（目標復旧時点） と RTO（目標復旧時間） だよ。
| 指標 | 意味 | 問いかけにすると |
|---|---|---|
| RPO（Recovery Point Objective） | 最後の復旧ポイントから障害発生までの間で、許容できるデータ損失の最大時間 | 「どこまでさかのぼったデータで戻れば許されるか」 |
| RTO（Recovery Time Objective） | サービスが止まってから復旧するまでに許容できる最大の時間 | 「どれだけの時間止まっていても許されるか」 |
クラウドおさるRPO はデータを「どこまで失ってよいか」、RTO はサービスを「どれだけ止めてよいか」でござるな。どちらも短いほうがよさそうでござるが…。
土肥短くすればするほど、待機させておく環境が大きくなってコストも複雑さも上がるんだ。だから AWS のホワイトペーパーでは、4 つの戦略をコストと復旧の速さのトレードオフで並べているよ。
| 戦略 | 待機側の状態 | RPO / RTO | コスト・複雑さ |
|---|---|---|---|
| バックアップと復元 | バックアップだけを別リージョンなどに保管し、障害時にインフラを再デプロイして復元する | RPO はバックアップの頻度次第、RTO は最も長い | 最も低い |
| パイロットライト | データベースなどのコア部分は常に稼働・複製し、アプリケーションサーバーなどは止めておく | 中程度 | 中程度 |
| ウォームスタンバイ | 本番環境を縮小した、完全に機能するコピーを常に動かしておく | 短い（スケールアップするだけ） | 中〜高 |
| マルチサイト アクティブ / アクティブ | 複数のリージョンで本番環境を同時に動かす | ほぼゼロ | 最も高い |
クラウドおさるパイロットライトは、ガスコンロの種火のように最小限だけ点けておく、ということでござるな！ 猿山の見張り台でいえば、夜も 1 匹だけ起きておいて、何かあったら仲間を起こす形でござる。
土肥いい例えだね。ウォームスタンバイとの違いは「アプリケーションまで動いているかどうか」だよ。パイロットライトはアプリケーションサーバーを止めているけど、ウォームスタンバイは小さいながら全部が動いているんだ。
AWS Elastic Disaster Recovery と MGN の関係
クラウドおさる災害対策のためのサービスもあるのでござるか？
土肥AWS Elastic Disaster Recovery（DRS） だね。オンプレミスやクラウドのサーバーのデータを、選んだ AWS リージョンのステージングエリアにレプリケーションしておいて、ドリル（訓練）や復旧のときに AWS 上でサーバーを起動するサービスなんだ。待機側では安価なストレージと最小限のコンピューティングだけを使うから、コストを抑えながら、最新の状態か過去の特定時点の状態で数分で復旧インスタンスを起動できるよ。
クラウドおさるレプリケーションして AWS 上で起動する…それは MGN とそっくりでござるな？
土肥鋭いね！ 仕組みはよく似ているんだ。違いは目的で、MGN は「AWS に移す」ための一方通行、DRS は「障害に備えて待機させておく」ためのものなんだよ。DRS は、元の環境が復旧したあとにそこへ戻すフェイルバックができるけど、MGN にはこの機能がないんだ。
| 観点 | AWS Application Migration Service（MGN） | AWS Elastic Disaster Recovery（DRS） |
|---|---|---|
| 目的 | AWS への移行（リホスト） | 障害時の復旧 |
| 使い方 | テスト用・カットオーバー用のインスタンスを起動して切り替える | 平常時はステージングエリアに複製しておき、ドリルや障害時に復旧インスタンスを起動する |
| 元の環境へ戻す | できない | フェイルバックできる |
クラウドおさる移すなら MGN、備えるなら DRS。名前は違っても、どちらもサーバーをまるごと複製して AWS で起動する仲間でござるな。
土肥そうそう。それと、バックアップと復元の戦略を AWS で組むなら AWS Backup も使えるよ。AWS Backup の基本は別の記事で手を動かしながら確認できるから、あわせて読んでみてね。
—
実践
移行サービスや DRS を実際に動かすには、移行元のサーバーにエージェントを入れたり、レプリケーション用のリソースを起動したりする必要があり、料金が発生します。この記事の実践ではリソースを作成せず、東京リージョンのコンソールで、技術解説に出てきたサービスの入口を確認するだけにとどめます。
前提条件
- AWS マネジメントコンソールにログイン済みであること
- リージョン:
ap-northeast-1（東京） - この実践ではリソースを作成しません。料金は発生しません
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| （なし） | ― | 各サービスのコンソールの入口を確認するだけで、リソースは作成しません |
AWS Application Migration Service と AWS Elastic Disaster Recovery は、コンソールで初期設定（初期化）を始めると、サービス用の IAM ロールやデフォルトのレプリケーション設定がアカウントに作成されます。この実践では、サービスの紹介ページに表示される設定・初期化のボタンは押さずに、画面を確認するだけにします。
手順 1: Application Migration Service の入口を確認する
AWS マネジメントコンソールにログインし、右上のリージョンが アジアパシフィック (東京) ap-northeast-1 であることを確認します。
上部の検索バーに MGN と入力し、表示された Application Migration Service を選択します。コンソールでは新しい名前の「AWS Transform MGN」と表示されます。
初めて開くアカウントでは、サービスの紹介ページが表示されます。ここで「物理・仮想・クラウドのサーバーを AWS に移す（リホストする）」サービスであることを確認します。「移行を開始」の「使用を開始」ボタンは押しません。
手順 2: Database Migration Service の入口を確認する
上部の検索バーに DMS と入力し、表示された「Database Migration Service」を選択します。
サービスのトップページに、データベースの移行や、スキーマ変換（DMS スキーマ変換）・同種データ移行に関する案内が並んでいることを確認します。「今すぐ始める」は押さず、移行タスクやレプリケーションインスタンスも作成しません。
手順 3: Elastic Disaster Recovery の入口を確認する
上部の検索バーに Elastic Disaster Recovery と入力し、表示された「Elastic Disaster Recovery」を選択します。
サービスの紹介ページで、ソースサーバーを AWS にレプリケーションしておき、障害時に復旧するサービスであることを確認します。手順 1 の MGN と見比べ、どちらもソースサーバーを AWS へレプリケーションするサービスであることにも注目します。ここでも「設定と初期化」ボタンは押しません。
クラウドおさる弊猿が MGN と DRS の入口を見比べると、どちらも「ソースサーバーを複製して AWS で起動する」流れでござった。移すのか、備えるのか。目的で使い分けるのでござる。
さらに手を動かしたい場合
災害対策の「バックアップと復元」戦略を、実際にバックアップを取って試したい場合は、次の記事で AWS Backup の基本を体験できます。
クラウドおさる試験では「何を移すのか」と「どれだけ止めてよいか」を読み取って、サービスや DR 戦略を選ぶ観点が問われるでござる。サーバーとデータベースとファイルの取り違え、パイロットライトとウォームスタンバイの取り違えに気をつけるでござるぞ。
—
まとめ
| 観点 | 押さえるポイント |
|---|---|
| 移行戦略 | 7 つの R。変更せずに移すのがリホスト、一部最適化がリプラットフォーム、作り直しがリファクタリング |
| サーバーの移行 | Application Migration Service（MGN、現在の名称は AWS Transform MGN）。ブロックレベルの継続的レプリケーション |
| データベースの移行 | DMS。ソースを動かしたまま継続的にレプリケーションできる。異種移行のスキーマ変換は DMS Schema Conversion / SCT |
| ファイルの移行 | DataSync はこちらから AWS へ転送、Transfer Family は SFTP などの受け口をマネージドで用意 |
| オフライン転送 | 物理デバイスで大量データを運ぶ考え方。Snowball Edge は 2025 年 11 月 7 日に新規受付を終了、Snowmobile はサポート終了 |
| 移行の計画・追跡 | Application Discovery Service（検出）、Migration Hub（追跡）、Migration Evaluator（コスト見積もり）。前の 2 つは新規受付を終了し、後継は AWS Transform |
| 災害対策 | バックアップと復元 → パイロットライト → ウォームスタンバイ → マルチサイトの順に RPO / RTO が短く、コストが高くなる |
| DRS | 障害に備えてサーバーを複製しておき、AWS 上で復旧する。MGN と違いフェイルバックできる |
—
参照先
- 移行戦略について – AWS 規範ガイダンス
- What Is AWS Transform MGN? – AWS Transform MGN
- General questions – AWS Transform MGN
- AWS Database Migration Service – AWS データベース移行サービス
- とは AWS DataSync – AWS DataSync
- AWS DataSync の仕組み – AWS DataSync
- とは AWS Transfer Family – AWS Transfer Family
- AWS Application Discovery Service とは – AWS Application Discovery Service
- AWS Application Discovery Service 可用性の変更 – AWS Application Discovery Service
- AWS Migration Hub availability change – AWS Migration Hub
- Migration Evaluator – AWS 規範ガイダンス
- Snowball Edge とは – AWS Snowball Edge デベロッパーガイド
- AWS Snowball Edge 可用性の変更 – AWS Snowball Edge デベロッパーガイド
- データ転送ターミナルとは – AWS データ転送ターミナル
- フルシャットダウンのサービス – AWS 全般のリファレンス
- クラウド内での災害対策オプション – でのワークロードのディザスタリカバリ AWS: クラウドでのリカバリ
- Business Continuity Plan (BCP) – Disaster Recovery of Workloads on AWS: Recovery in the Cloud
- What is Elastic Disaster Recovery? – AWS Elastic Disaster Recovery
- Elastic Disaster Recovery initialization and permissions – AWS Elastic Disaster Recovery
