技術記事 2026/7/3

AWS移行を"安全な順番"で設計する — 7R・Strangler Fig・ロールバック・二重運用コストの意思決定

AWS移行で失敗を分けるのは「何を使うか」より「どの順で戻せるか」です。棚卸し→7R割当→Strangler Figによる段階移行→データ移行→ロールバック→二重運用コストを、案件に当てはめて決める意思決定として整理します。現行の入口はAWS Transform、ロールバックの限界まで誠実に扱います。情報は2026年6月時点・公式準拠です。

#AWS
#クラウド移行
#移行戦略
#7R
#Strangler Fig
#ロールバック

AWS移行プロジェクトでつまずくのは、多くの場合「どのサービスを使うか」を選ぶ段階ではありません。決めた手法を「どの順番で適用し、問題が出たときにどこまで戻せるか」の設計が抜けているときに、移行は止まります。つまり、何を使うかより、どの順で戻せるかが先に効きます。本記事は、既存のモノリスやレガシーシステムをAWSへ移す設計を任されるアーキテクトに向けて、棚卸しから7R割当、段階移行、データ移行、ロールバック、二重運用コストまでを一連の意思決定として整理します。基礎用語の解説は最小限にとどめ、案件に当てはめて順番を決められる形に寄せます。情報は2026年6月時点で、サービス名や対応範囲は変動するため、適用前に公式の最新情報をあわせてご確認ください。

なぜ移行は「順番」で失敗するのか

一括移行（ビッグバン）は、切り替えの瞬間まで本番での挙動が読めず、問題が起きたときに戻す範囲が大きくなります。影響範囲が全体に及び、想定外の依存関係が本番で初めて表面化することも珍しくありません。これを避ける考え方が、リスクを段階に割り、各ステップで「進む」か「戻す」かを判断できる状態をつくることです。

全体像は、AWS公式の決定ガイド「Choosing AWS migration services and tools」が参考になります。このガイドは Understand（理解）→ Consider（検討）→ Choose（選択）→ Use（利用）→ Explore（探索）という章立てで移行サービスの選び方を地図化しています。本記事はその地図のうち、決定ガイドだけでは薄くなりがちな「順番・ロールバック・二重運用コスト」の意思決定に重心を置きます。

棚卸しと依存マッピングから7R割当、Strangler Figによる段階移行、データ移行、検証、切替とロールバック判断へと進む移行の意思決定フローを横長に示した図 — 図1: 移行の意思決定フロー（棚卸し→7R割当→段階移行→データ移行→検証→切替/ロールバック）

判断① 棚卸しと依存マッピングから7Rを割り当てる

順番を決める前提は、現状把握です。何がどこに依存して動いているかを可視化しないまま順番は決められません。そこで入口に置くのが、アプリケーションの在庫と依存関係の棚卸しです。

現行の入口は AWS Transform です。生成AIとエージェント型のアセスメントで、資産の把握・依存マッピング・移行戦略の検討を支援します。なお、従来この役割を担っていた Migration Hub Strategy Recommendations は、公式に「2025年11月7日以降、新規のお客様には提供しない」と告知されており、新規受付は終了しています。類似機能は AWS Transform を参照するよう公式が案内しているため、これから設計するなら AWS Transform を現行の入口として扱い、Migration Hub は「従来の道具・新規受付終了」と位置づけます。

棚卸しができたら、ワークロード単位で移行戦略（7R）を割り当てます。7Rは AWS Prescriptive Guidance が示す移行戦略の整理で、コスト・リスク・期待効果の3軸で判断します。「すべてをRefactor（クラウドネイティブへ刷新）する」のは、コストもリスクも最も高い選択を全体に広げることになり、罠になりやすい判断です。

戦略	概要	主なコスト・リスク	向くケース
Rehost（リフト＆シフト）	変更せずそのまま移行	低改修・移行後の最適化は別途	まず早く動かしたい
Relocate	ハイパーバイザレベルで再記述なしに移設	移設先の前提に依存	大量のVMをまとめて移す
Replatform（リフト＆リシェイプ）	一部最適化を加えて移行	中程度の改修	マネージド化の恩恵を一部得たい
Repurchase（ドロップ＆ショップ）	別製品・SaaSへ乗り換え	業務・データの移行作業	自前保守をやめたい
Refactor／Re-architect	クラウドネイティブ機能で刷新	高コスト・高リスク	競争差別化の中核
Retain（リビジット）	移行せず現状維持	塩漬け化のリスク	まだ移さない判断
Retire	不要なアプリを廃止	影響調査が必要	重複・不要の整理

アプリ	主な依存関係	現状・制約	割当戦略	優先順位
例: 受注Web	認証基盤・受注DB	改修容易・標準構成	Rehost	高
例: 帳票バッチ	共有ファイル・旧OS	共有FS依存	Replatform	中
例: 旧管理画面	受注DB	利用低・代替あり	Retire	低

判断② Strangler Fig で段階的に移行する

段階移行の代表的なパターンが Strangler Fig（絞め殺しの木）です。旧システムの前段にプロキシ層を置き、呼び出しを傍受して旧と新へ振り分けます。機能を1つずつ新環境へ切り出し、すべての機能の移行が終わった時点で旧モノリスを安全に廃止します。一度に全部を置き換えないため、各機能の切り出しごとに「進む・戻す」を判断できます。

ただし公式は注意点も挙げています。プロキシ層は全呼び出しが通る要所のため、単一障害点や性能のボトルネックになり得ます。また、モノリスの深部や上流に強い依存があり、きれいに切り出せない部分には、Strangler Fig ではなく Branch by abstraction（抽象化による分岐）パターンが推奨されます。すべてを Strangler Fig で割り切らず、切り出しにくい箇所は別パターンに切り替える前提で設計します。

プロキシ層が旧モノリスと新サービスへ呼び出しを振り分け、機能を順次新環境へ切り出していくStrangler Figの構造を横長に示した図 — 図2: Strangler Fig の構造（プロキシ層で旧/新へルーティングし、機能を順次切り出す）

判断③ データ移行とダウンタイムの最小化

移行の道具は、対象によって使い分けます。アプリケーションやサーバーそのものは AWS Transform MGN（旧 Application Migration Service／MGN）が中心です。ブロックレベルで複製し、移行元をネイティブに動かせる形へ変換します。データベースは AWS DMS が中心で、論理レベルで異種間の移行に対応し、CDC（継続的なデータ変更の取り込み）による継続レプリケーションでダウンタイムを最小化します。

スキーマ変換の現行入口は DMS Schema Conversion です。DMSに統合されたweb版で、テーブルやビュー、ストアドプロシージャなどの大半を自動変換し、変換できないものは明確にマークして手動変換へ回します。さらに assessment report（評価レポート）が「自動化できる割合と手動工数の見積り」を出すため、移行難度を事前に把握できます。東京リージョン（ap-northeast-1）に対応しています。

ツール	主な対象	ダウンタイム	主な制約（2026-06時点）
AWS Transform MGN	アプリ・サーバー（OSごと）	カットオーバー時のみ短時間	x86のWindows/Linux対象。ARM・IBM系・共有FSは非対応、高I/OのDBは非推奨
AWS DMS	データベース（異種間）	CDC継続レプリで最小	論理レベルの移行
DMS Schema Conversion	スキーマ＋コードオブジェクト	移行前の準備工程	web版で対応範囲が限定。変換不能はマーク。東京対応
スタンドアロン AWS SCT	DWH・ビッグデータ・アプリSQL・ETL	移行前の準備工程	web版で不足する範囲を補完

制約には正直に向き合う必要があります。DMS Schema Conversion はAWS SCTのweb版で、対応プラットフォームや機能が限定されます。データウェアハウスのスキーマやビッグデータ、アプリケーション内のSQLコード、ETLは、スタンドアロンの AWS SCT を使います。変換できない機能は extension pack でエミュレートできますが、メール送信やジョブスケジュールのためのLambdaは含まれないため、その部分は別途の手当てが要ります。

判断④ 「戻せる」ロールバック設計

段階移行の各ステップは、戻せて初めて意味を持ちます。デプロイ単位の自動ロールバックには CodeDeploy が使えます。CodeDeployのロールバックは「最後に成功したリビジョンを、新しいデプロイとして再デプロイする」動作です。元の状態を復元するのではなく、新規のデプロイIDで再展開する点に注意します。トリガーはデプロイの失敗、または指定したCloudWatchアラームのしきい値到達で、自動ロールバック時にはSNSで通知できます。あわせて blue/green や canary などのトラフィックシフトで切替を段階化すると、失敗時の影響を局所化できます。これは Well-Architected のREL（信頼性）が示す「変更を安全にデプロイし、失敗時に元へ戻す」原則に沿います。

移行ならではの戻し方もあります。判断②のStrangler Figのプロキシ層は、前進だけでなく後退の経路にもなります。新機能で問題が出たら、プロキシのルーティングを旧系へ戻すことで切り戻せます。プロキシ層を、進む道であると同時に戻る道として設計しておくのが要点です。

ここで最も重要な限界を誠実に押さえます。CodeDeployのロールバックで戻せるのは、ファイルやコードまでです。デプロイ中に実行したスクリプトの副作用、つまりデータの変更は自動では戻りません（公式の挙動として、ロールバックはスクリプトのアクションを取り消したり整合させたりしません）。したがって「ボタン一つで全部戻る」とは設計できません。だからこそ、データ層は別途、切り戻せるように設計します。具体的には、旧DBを一定期間温存する、一方向の破壊的なマイグレーションを避ける、二重書き込みや読み取り先の切替で段階的に移すといった手立てを、コードのロールバックとは別建てで用意します。

新系への切替後に検証し、OKなら進む、NGならCodeDeployで再デプロイしStranglerプロキシで旧系へ切り戻すが、データ層は別途温存する流れを横長に示した図 — 図3: 切替と検証（OKで進む／NGで戻す。コードは再デプロイ、データ層は温存で別途切り戻す）

判断⑤ 二重運用コストと「いつ終わらせるか」

段階移行はリスクを下げる一方で、旧環境と新環境が並行して動く期間を生みます。この間は、二重のインフラ費と運用工数がかかります。ここで効くのが、並行期間の長さが直接コストを決めるという事実です。段階移行は安全ですが、並行期間が延びるほど二重運用コストは積み上がります。リスクとコストはトレードオフの関係にあるため、「いつまでに切り終えるか」という終了条件を、移行計画の最初に織り込みます。

二重運用コストは、固有の削減率や移行期間の統計をあてにせず、自分の環境で試算するのが確実です。アプリ数や依存、技術的負債の量で結果は大きく変わります。次のテンプレートに自環境の値を入れて、終了条件とあわせて見積もります。並行期間中のFinOps（コスト可視化と最適化）の自動化については、FinOpsをエージェントで自動化する解説も参考になります。

費目	内容	試算の視点
旧環境費	廃止までのインフラ・ライセンス	並行期間（月数）× 月額
新環境費	移行先の稼働費	段階移行とともに逓増
データ転送	移行・同期に伴う転送	一時的に増える分を見込む
運用工数	二重の監視・障害対応・教育	人月で見積る
並行期間	旧新が同時稼働する月数	終了条件が総額を左右する

まとめ：移行設計チェックリストと明日の第一歩

移行は、新しいサービスの選定ではなく、安全な順番と「戻せる」設計の意思決定です。設計時に確認する観点を1枚にまとめます。

棚卸しと依存マッピングを終えたか（現行入口は AWS Transform）
ワークロードごとに7Rを割り当てたか（全部Refactorにしていないか）
段階移行の単位とプロキシ層の設計があるか（切り出しにくい箇所は別パターンか）
データ移行の道具を対象別に選んだか（MGN／DMS／DMS Schema Conversion／SCT）
ロールバック経路があるか（コードの再デプロイ＋データ層の別建て切り戻し）
二重運用コストに終了条件を切ったか

明日からの第一歩は、小さく1機能または1アプリから始めることです。棚卸し→7R割当→PoCを1本→ロールバックの確認→二重運用コストの試算、という最小ループを一度通すと、案件全体の順番が見えてきます。意思決定の根拠を言語化して顧客と共有する進め方はアーキテクトの意思決定を言語化する解説が、移行後を含む構成全体の選定と費用試算は構成選定とTCO比較の解説が参考になります。仕様や料金、対応リージョンは改定されうるため、設計の適用前に公式の最新情報をご確認ください。