SAA マイグレーション戦略 6R（7R）の理解｜リホスト・リプラットフォーム・リファクタを要件文で即断する
AWS SAA-C03 でオンプレミスから AWS への移行（マイグレーション）は、コスト最適化・弾力性・セキュアな設計を横断して問われる頻出テーマだ。本記事は移行戦略の 6R——Rehost（リホスト）・Replatform（リプラットフォーム）・Repurchase（リパーチェス）・Refactor（リファクタリング）・Retire（リタイア）・Retain（リテイン）——を「移行にかける労力（そのまま⇔作り直す）」と「得られるクラウド最適化（低⇔高）」の2軸で体系化する。さらに現在 AWS が採用する 7R（Relocate 追加）、移行を支える Application Migration Service・DMS・DataSync・Snow Family、3フェーズ移行プロセス（評価→準備→移行と最新化）まで、SAA 本番で要件文のキーワードから正解の戦略を一意に引くための反射を作る。結論は「移行問題は戦略名の暗記ではなく、労力と最適化のトレードオフを2軸で読む」こと。
移行戦略の問題を「とりあえず EC2 に持っていく（リホスト）」で片づけようとすると、コスト最適化や運用負荷削減を問う設問で足をすくわれる。 SAA-C03 でオンプレミスから AWS への移行（マイグレーション）は、コスト最適化（ドメイン4）・弾力性（ドメイン2）・セキュア設計（ドメイン1）を横断して顔を出す頻出テーマだ。だが問われるのは「戦略名の暗記」ではなく、どれだけの労力をかけ、その見返りにどれだけクラウドの恩恵を引き出すかというトレードオフの判断である。攻略の鍵は、6つの移行戦略（6R）を「移行にかける労力（そのまま⇔作り直す）」と「得られるクラウド最適化（低⇔高）」の2軸マップに畳み、要件文のキーワード——『最短で移行』『DB の運用負荷を下げたい』『クラウドネイティブに作り直す』『使っていないサーバー』——から正解の R を一意に引く反射を作ること。本記事では、SAA 本番でそのまま選択肢を絞れる粒度で、6R（および現在の 7R）と移行を支える AWS サービスを整理する。読み終えれば、「最も適切な移行戦略はどれか」という問いに、迷わず正解を当てられるようになる。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：移行戦略は「労力 × 最適化」の2軸で解く
- 6R 前半：Rehost・Replatform・Repurchase（持っていく系）
- 6R 後半：Refactor・Retire・Retain（作り直す／やめる系）と 7つ目の Relocate
- 移行を支える AWS サービス（MGN・DMS・DataSync・Snow）
- 移行プロセス 3フェーズ（評価→準備→移行と最新化）
- 頻出ひっかけパターンと打ち手の整理
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：移行戦略は「労力 × 最適化」の2軸で解く
SAA-C03 の移行戦略問題を最短で解く骨格は、**「要件文が『移行にかける労力の少なさ（スピード）』を優先しているのか、『クラウド最適化の深さ（コスト削減・運用負荷削減・スケーラビリティ）』を優先しているのかを見極め、その位置に対応する R を選ぶ」**ことだ。これが本記事の結論である。
理由は明快で、6R はどれもこの2軸マップ上の異なる座標を占める道具だからだ。Rehost（リホスト）は「労力ほぼゼロ・最適化も浅い」左下、Refactor（リファクタリング）は「労力最大・最適化も最大」右上、その間に Replatform が位置する。要件文が「とにかく速く・最小の変更で」と言えばマップ左下（Rehost）へ、「運用負荷を下げ、マネージドの恩恵を得たい」と言えば右へ（Replatform〜Refactor）ずれていく。つまり要件文のキーワードがマップ上の座標を指し示し、座標が正解の戦略を一意に決める構造になっている。
具体例で見よう。「データセンター閉鎖の期限が迫り、最短でアプリを AWS に移したい」——スピード優先だから Rehost（リフト＆シフト）。「移行のついでに、自前管理の MySQL を運用負荷の低い RDS に載せ替えたい」——小さな最適化を伴うから Replatform。「モノリスを分解してサーバーレスに作り直し、スケーラビリティを最大化したい」——大きな作り直しだから Refactor。「もう誰も使っていないサーバーが見つかった」——Retire（廃止）。ここで「移行＝とりあえず EC2 に載せる」と短絡すると、コスト最適化や運用負荷を問う設問で誤答する。2軸マップ上のどこを問われているかで解く——この一点が移行戦略問題の攻略法だ。
2. 6R 前半：Rehost・Replatform・Repurchase（持っていく系）
まず「既存アプリを AWS に持っていく」方向の3つの R を、労力の小さい順に押さえる。
R1：Rehost（リホスト／リフト＆シフト）— そのまま載せ替える
アプリケーションを一切改変せず、オンプレミスのサーバー構成をそのまま AWS（主に EC2）へ移す戦略。「リフト＆シフト（Lift and Shift）」とも呼ばれる。
- メリット：移行が最速・最小リスク。アプリの改修が不要なので、大量サーバーを短期間で移せる。
- デメリット：クラウドのマネージド機能やスケーラビリティの恩恵は薄い（あくまで「載せただけ」）。
- 代表シーン：データセンター閉鎖の期限が迫る／まず AWS 上に移してから段階的に最適化したい。
- 主なツール：AWS Application Migration Service（MGN）（サーバーを自動で EC2 へ複製）。
R2：Replatform（リプラットフォーム／リフト・ティンカー＆シフト）— 少し手を入れて載せる
アーキテクチャの根幹は変えず、一部だけをマネージドサービスに載せ替えて最適化する戦略。「リフト・ティンカー＆シフト」とも言う。
- 典型例：自前管理の DB を Amazon RDS や Aurora に載せ替える／OS・ミドルウェアのバージョンアップ／ファイルサーバーを S3 に置き換える。
- メリット：小さな変更で運用負荷削減・可用性向上などのクラウド恩恵を得られる。Rehost と Refactor の中間で、コスパが良い。
- SAA での狙われ方：「移行を機にDB の運用負荷（バックアップ・パッチ）を下げたい」→ EC2 上の DB ではなく RDS へ Replatform が正解。
R3：Repurchase（リパーチェス／ドロップ＆ショップ）— 別製品・SaaS に乗り換える
既存アプリを捨て、別の製品（多くは SaaS）に乗り換える戦略。「ドロップ＆ショップ」とも呼ぶ。
- 典型例：自前の CRM をやめて Salesforce に／自前メール基盤をやめて Amazon SES やマネージド SaaS に／ライセンス製品をサブスクリプション型へ。
- メリット：保守から解放され、ライセンスコストを変動費化できる。
- SAA での狙われ方：「既存の商用ソフトを保守せず SaaS に切り替えたい」といった文脈で登場する。
| 評価項目 | 戦略 推奨 | 移行の労力 | クラウド最適化 | 移行スピード |
|---|---|---|---|---|
| Rehost（リホスト） | 最小（無改修） | 低（載せただけ） | 最速 | |
| Replatform（リプラットフォーム） | 小（一部変更） | 中（マネージド化） | 速い | |
| Repurchase（リパーチェス） | 中（乗り換え） | 中（SaaS化） | 中 | |
| Refactor（リファクタリング） | 最大（作り直し） | 最高（クラウドネイティブ） | 遅い | |
| Retire（リタイア） | —（廃止） | —（対象外化） | — | |
| Retain（リテイン） | —（据え置き） | —（現状維持） | — |
3. 6R 後半：Refactor・Retire・Retain と 7つ目の Relocate
R4：Refactor / Re-architect（リファクタリング）— クラウドネイティブに作り直す
アプリを根本から再設計し、クラウドネイティブなアーキテクチャに作り替える戦略。最も労力がかかるが、最も深いクラウド最適化が得られる。
- 典型例：モノリスを分解して Lambda ＋ API Gateway ＋ DynamoDB のサーバーレス構成に／ECS・EKS でコンテナ化してマイクロサービス化。
- メリット：スケーラビリティ・弾力性・コスト効率が最大化。サーバーレス設計の恩恵をフルに受けられる。
- デメリット：時間・コスト・スキルの要求が最も高い。ビジネス上の強い動機（大幅なスケール要件・機能追加）があるときに選ぶ。
R5：Retire（リタイア）— 廃止する
使われていない・不要になったアプリやサーバーを、移行せずに廃止する戦略。移行プロジェクトの棚卸しで「実は誰も使っていなかった」システムを見つけ、コストを削減する。移行対象を減らすこと自体が最適化になる。
R6：Retain（リテイン／リビジット）— そのまま残す
今は移行せず、オンプレミスに据え置く戦略。「リビジット（後で見直す）」とも呼ばれる。
- 典型例：法規制・データ主権で移行できない／減価償却が終わっていない設備／移行の投資対効果が薄いレガシー。
- ポイント：これも立派な「戦略的判断」。SAA では「まだ移行すべきでないワークロード」の選択肢として登場することがある。
4. 移行を支える AWS サービス（MGN・DMS・DataSync・Snow）
戦略（どの R か）を決めたら、次はそれを実現するツールだ。SAA では「この移行要件に最適なサービスはどれか」が単体で問われることも多い。役割を取り違えないよう、用途で区別する。
- AWS Application Migration Service（MGN）：サーバー（OS・アプリ丸ごと）を EC2 へ自動複製する。Rehost の主役。旧 CloudEndure Migration の後継。
- AWS Database Migration Service（DMS）：データベースを移行する。稼働中 DB を止めずに継続レプリケーション（CDC）でき、異種 DB 間（例：Oracle → Aurora）は Schema Conversion Tool（SCT/DMS SC）と組み合わせる。Replatform の DB 移行で頻出。
- AWS DataSync：大量のファイル／オブジェクトデータをオンプレ ↔ AWS（S3・EFS・FSx）間で高速・自動転送する。ネットワーク経由の継続的なデータ移行に向く。
- AWS Snow Family（Snowball / Snowcone）：**ネットワークでは現実的でない超大容量（TB〜PB 級）**を、物理デバイスに書き出して郵送する「オフライン移行」。回線が細い／データが巨大なときの選択肢。
- AWS Direct Connect / Site-to-Site VPN：移行中・移行後のハイブリッド接続。安定帯域が要るなら Direct Connect、即時・低コストなら VPN。
- AWS Migration Hub：複数ツールの移行状況を一元的に可視化・追跡するダッシュボード。
5. 移行プロセス 3フェーズ（評価→準備→移行と最新化）
AWS の移行プロセス（Migration Acceleration Program の考え方）は、大きく3つのフェーズで進む。SAA では「移行のどの段階で何をするか」の順序が問われることがある。
- 評価（Assess）：現状のポートフォリオを棚卸しし、各アプリに 6R のどれを当てるかを判断する。移行の準備状況・コスト・ビジネス価値を見極めるフェーズ。ここで **Retire（廃止）**対象も洗い出す。
- 準備（Mobilize）：移行基盤（ランディングゾーン＝Organizations・ネットワーク・セキュリティの土台）を整え、パイロット移行でノウハウを蓄積する。セキュアな土台をこの段階で作る。
- 移行と最新化（Migrate & Modernize）：実際に各アプリを選んだ R で移行し、移行後にさらなる最適化（モダナイゼーション）を進める。
6. 頻出ひっかけパターンと打ち手の整理
SAA 本番でそのまま判断できるよう、移行戦略の「要件キーワード → 正解」の対応を整理する。
| 評価項目 | 要件文のキーワード | 正解 | 理由 |
|---|---|---|---|
| データセンター閉鎖・最短で移行・無改修 | Rehost（MGN） | スピード最優先・改修不要 | |
| 移行を機に DB の運用負荷を下げたい | Replatform（RDS/Aurora） | 小変更でマネージド化 | |
| 自前製品をやめて SaaS に乗り換え | Repurchase | 保守解放・変動費化 | |
| クラウドネイティブに作り直し・最大スケール | Refactor | 再設計で最適化最大 | |
| 誰も使っていないサーバー | Retire | 廃止でコスト削減 | |
| 規制・償却で今は動かせない | Retain | 戦略的に据え置き | |
| 稼働中 DB を止めず異種 DB へ移行 | DMS（＋SCT） | 継続レプリケーション | |
| 大量ファイルをネットワークで継続同期 | DataSync | オンライン高速転送 | |
| PB 級・回線が細い・郵送が速い | Snow Family | オフライン物理移送 |
7. 次のアクション チェックリスト
移行戦略 6R を、今日からの学習に落とし込むための具体アクションをまとめる。
8. 関連記事
- SAA 試験完全ガイド｜SAA-C03 の出題範囲・難易度・3ヶ月合格戦略 — 本シリーズの上位ガイド
- SAA 試験範囲：4ドメイン詳細解説 — ドメイン1〜4の全体像
- SAA ドメイン4：コスト最適化アーキテクチャの設計 — 移行後のコスト最適化
- SAA ドメイン2：弾力性のあるアーキテクチャの設計 — 移行後の可用性設計
- SAA：高可用性設計のパターン集（Multi-AZ/Multi-Region） — モダナイゼーションで効く設計
- SAA：Lambda・サーバーレス設計の頻出パターン — Refactor の到達点
- SAA：VPC 設計問題の頻出パターン10選 — 移行先ネットワークの設計
- Amazon RDS とは？マネージド DB の基本 — Replatform の代表的な移行先
- AWS Snowball / Snowmobile / Snowcone の違い — オフライン大容量移行
- AWS Direct Connect とは？専用線接続の仕組み — ハイブリッド接続
- Site-to-Site VPN の設定と Direct Connect との違い — 低コストな接続オプション
- CLF 試験：Well-Architected Framework 6 つの柱 — 移行後の設計品質の指針
9. 関連サイト
AWS 公式
- AWS クラウド移行（公式）
- 移行戦略について — AWS 規範ガイダンス（公式）
- AWS Application Migration Service（公式）
- AWS Database Migration Service（公式）
- AWS DataSync（公式）
- AWS Snow Family（公式）
- AWS Migration Hub（公式）
- AWS Certified Solutions Architect – Associate（公式）
- SAA-C03 試験ガイド（公式 PDF）