AWS移行とは？7R戦略と移行ツール・費用と見送り判断を発注者視点で解説

オンプレミスのサーバーをAWSへ移す判断は、移送作業そのものより「どの資産をどの方式で移し、どれを移さないか」の割り当てで決まります。AWSは移行方式を7R（Rehost・Replatform・Refactor・Relocate・Repurchase・Retire・Retain）として規範ガイダンスに定義し、廃止判定には平均CPU使用率5%未満という客観的なしきい値まで示している。この記事では7Rの割り当て基準、AWS MGN・DMSなど純正ツールの守備範囲、費用の読み方、AWSに載せない条件を発注する側の視点で整理します。

まとめ：AWS移行で先に決める7R戦略とツール選定・移行しない範囲

AWS移行の成否は、移送の技術ではなく割り当ての精度で決まります。最初にやるのは資産の棚卸しと7Rの割り当てで、Retire（廃止）とRetain（残す）に振り分けた数だけ後工程の費用が減る。AWSの規範ガイダンスは平均CPU・メモリ使用率5%未満をゾンビアプリケーションと定義しており、数値で廃止候補を切り出せます。

方式が決まればツールはほぼ一意です。サーバーはAWS MGN、データベースはAWS DMS、ファイルはDataSync、回線が細ければSnowデバイス。費用はMigration Evaluatorで現行コストとAWS換算額を並べ、稼働が安定した本番サーバーからSavings PlansとGravitonで単価を下げます。そしてメインフレームや特殊ハードウェア依存の資産は移さない。割り当ての条件と段階移行の損益分岐は本文で順に見ていきます。

オンプレミスからAWSへ移す範囲とAWS移行が汎用クラウド移行と分かれる論点

AWS移行という言葉は、単一サーバーのリフトアンドシフトから基幹システムの全面刷新までをまとめて指します。クラウド全般の料金モデルとIaaS・PaaS・SaaSの前提は、クラウドとは何かをAWSの仕組みと料金から整理した記事で確認できます。

AWS移行で決める対象範囲とEC2・RDS・S3への受け皿の考え方

移行対象は、サーバー・データベース・ファイル・ネットワーク・ライセンスの5つに分けて棚卸しします。AWS側の受け皿と移送ツールがこの単位で変わるためです。物理サーバーや仮想マシンはAmazon EC2が受け皿になり、OSとミドルウェアの構成を保ったまま移せる。データベースはAmazon RDSに載せ替えると、バックアップ・パッチ適用・冗長化を自社から切り離せます。共有ファイルはAmazon S3かAmazon EFSに分かれます。

棚卸しの粒度は、サーバー1台ごとではなくシステム1つごとに揃えます。Web・DB・バッチの3台で1つの業務システムを構成するなら、その3台は同時に移す前提で1件と数える。台数で数えると依存関係が見えなくなり、切り替え当日に片方だけ動かない事故につながります。ライセンスは持ち込めるか買い直しかという契約側の確認事項として別枠で管理してください。

汎用のクラウド移行手順とAWS固有の判断が分かれる二つの分岐点

目的設定、資産棚卸し、リハーサル、本番切り替えという骨格は移行先がAWSでもAzureでも変わりません。この共通部分はクラウド移行の進め方を整理した記事にまとめています。AWS指名になって分かれる論点は2つです。

1つ目は移行方式の粒度。一般的な解説は6Rと書くことが多い一方、AWSの規範ガイダンスはRelocateを加えた7Rで定義しています。Relocateは既存の仮想基盤やRDSインスタンスを時点指定でまとめて移す戦略で、書き換えも機材の新規購入も伴わない。6Rで検討すると、この選択肢が視界に入りません。

2つ目はツールと課金がセットで決まること。移送をAWS純正で揃えると作業費は抑えられる一方、レプリケーション中のEC2・EBS料金が並行して発生します。移行元と移行先の両方に費用がかかる二重コストの期間を見積もれるかどうかで、費用の精度が変わります。

AWSが定義する7R戦略の中身とオンプレミス資産ごとの割り当て基準

7Rは、既存資産をどこまで作り替えるかで並べた7つの選択肢です。1つの方式に統一する必要はなく、棚卸しした単位ごとに割り当てます。AWSの規範ガイダンスは各戦略の該当ケースを列挙しており、判断の根拠に使えます。

Rehost・Replatform・Refactorの改修量とAWSの受け皿

Rehostは「リフトアンドシフト」とも呼ばれ、アプリケーションを変更せずAWSへ移す方式です。AWS公式は自動化手段としてAWS MGN、AWSクラウド移行ファクトリーソリューション、VM Import/Exportを挙げています。物理・仮想・別クラウドが混在する環境に向きます。

Replatformは移しながら一部だけ手を入れる方式。AWS公式が挙げる例は、フルマネージド・サーバーレスへの寄せ替え、OSを最新版へ上げること、AWS Gravitonプロセッサへの切り替え、Windows から Linux への移行、.NET Framework から .NET Core へのポーティング、仮想マシンからコンテナへの移行です。.NET向けにはPorting Assistant for .NET、コンテナ化にはAWS App2Containerが用意されています。

Refactor（Rearchitect）はアーキテクチャそのものを作り替える方式です。AWS公式の該当例は、事業の要求に追随できないレガシーメインフレーム、提供速度を妨げるモノリス、保守方法が分からずソースコードも手に入らないもの、テストが困難でカバレッジが低いもの。いずれも「移すだけでは問題が解けない」状態です。現状で困っていない資産をRefactorに振るのは投資の無駄になります。

RelocateとRepurchase・Retire・Retainを選ぶ実務条件

Relocateは、複数サーバーを特定時点でまとめてクラウド版のプラットフォームへ転送する戦略です。AWS規範ガイダンスはAmazon RDSのDBインスタンスを別VPCや別AWSアカウントへ移す例を挙げています。VMware環境向けにはAmazon EVS（Amazon Elastic VMware Service）が2025年8月5日に一般提供を開始しました（AWS What’s New・一般提供時点で6リージョン）。仮想基盤の全面刷新を前提に置く必要はありません。

Repurchaseは、自社保守しているアプリケーションをSaaS製品へ置き換える判断です。AWS公式は移行後の作業としてチームとユーザーの教育、データ移行、認証サービスとの統合、安全なネットワーク設定を挙げます。ライセンス費が下がっても、この4つの工数を見込まない見積もりは崩れる。

Retireは廃止です。AWSの規範ガイダンスは判定に数値を置いており、平均CPU・メモリ使用率5%未満をゾンビアプリケーション、90日間の平均5〜20%をアイドルアプリケーション、過去90日間インバウンド接続がないことも該当条件に挙げます。初期にこの3条件で機械的に洗い出すと、移行対象そのものが減ります。

Retainは移さず現行環境に残す判断です。AWS公式は、他システムの移行が先行依存になっているものやSaaS版のリリース待ちも該当例に挙げています。どの資産をRetainに振るかは投資額に直結するため、後半の見送り条件の章で条件を示します。

7Rの割り当てで失敗する典型パターンと社内で見直す起点の作り方

最も多い失敗は、最初からRefactorに寄せすぎることです。作り替えたほうが長期の効果は大きい。ただし工数が数倍になり、1年の予定が2年に延びれば削減効果は移行期間中の二重コストで相殺されます。

2つ目の失敗は、Retireの判定を担当部署の申告に任せること。「使っていますか」と聞けば、ほぼ全部門が「使っている」と答える。稼働メトリクスで機械的に切り出し、例外だけを申告してもらう順序にすると廃止候補が残ります。

見直しの起点は、1件目を移し終えた時点に置きます。最初のRehost案件で実測の移送時間・停止時間・移行後の月額が出る。この実測と当初見積もりの差を見て、残る資産の割り当てを引き直します。つまずきやすい論点はクラウド移行の課題と失敗パターンを整理した記事にまとめています。

AWS純正の移行ツールの守備範囲とサーバー・データベース別の使い分け

7Rの割り当てが決まれば、使うツールはほぼ一意です。AWSは移送対象ごとに専用サービスを用意しており、サーバー、データベース、ファイルで担当が分かれます。

AWS MGNで進めるサーバー移行のレプリケーションとカットオーバー

AWS Application Migration Service（AWS MGN）は、Rehostを担う中心的なサービスです。AWS公式ページが挙げる対応ソース環境は、物理サーバー、VMware vSphere、Microsoft Hyper-V、他のパブリッククラウド、AWSリージョン間の移行。移行元にエージェントを入れてレプリケーションを続け、本番切り替え時に移行先インスタンスを起動する流れです。

料金ページにはこう書かれています。「無料期間中を含め、ソースサーバーが活発にレプリケーションを行っている間は、データレプリケーションを促進するためにAWS Application Migration ServiceによってプロビジョニングされたAWSインフラストラクチャの料金が発生します」。MGNの無料枠があっても、レプリケーション用のEC2とEBS、テスト・カットオーバーインスタンスは別に請求されます。

そこで、レプリケーション開始からカットオーバーまでの期間を資産ごとに区切り、確認が済んだものから順に切り替えて止めます。並行して走らせるサーバー数を絞ることが、そのまま費用の抑制になります。

AWS DMSで分けるデータベース移行の同種・異種と停止時間の見積もり

AWS Database Migration Service（AWS DMS）は、同種および異種のデータベース移行に対応します。AWS公式ページはソースとターゲットの例としてOracle、SQL Server、PostgreSQL、MySQL、MongoDB、MariaDBを明記し、150万以上の移行実績を掲げています。

判断が分かれるのは同種か異種かです。製品を変えない同種移行はスキーマもSQLもそのまま通る。製品をまたぐ異種移行では、データ型・ストアドプロシージャ・独自関数の書き換えが発生します。AWSはこの部分にルールベースのスキーマ変換と生成AI支援のコード変換を用意していますが、変換後の動作確認は自社側の工数として残ります。

停止時間は、データ量ではなく整合性の取り方で決まります。一括でダンプして流し込むなら、その所要時間がそのまま業務停止時間になる。移行元を稼働させたまま差分を送り続ける構成なら、当日の停止は最終差分の反映と接続先変更だけに縮みます。実装手順はクラウドデータ移行の手順と整合性検証の記事で扱っています。

DataSync・Snow・Direct Connectで変わるデータ移送手段の選び方

ファイルやオブジェクトの移送は、判断軸が「ネットワーク経由で許容時間内に送り切れるか」の一点に絞られます。

• AWS DataSync：回線経由でファイル・オブジェクトを送る。既存回線に余力があり、数TB規模までを移す場合の第一候補
• Snowデバイス：物理デバイスに書き出して郵送する。回線が細い拠点や、送り切るのに何週間もかかる大容量データで検討する
• AWS Direct Connect：AWSと専用線で接続する。移行時の帯域確保に加え、移行後もハイブリッド構成を続ける場合に効く

実務では、まずDataSyncで一部を試験的に送り、実測の転送速度から全量の所要時間を割り出します。その時間が許容できないと分かってから、初めて物理デバイスや専用線の検討に入る。手段を先に決めると、不要な専用線契約や輸送の手配コストを抱え込みます。

AWS移行の費用試算とMAPの3フェーズで区切る工程管理の進め方

AWS移行の費用は、移行作業の一時費用と移行後のAWS利用料に分かれます。この2つを混ぜて見積もると、移行直後は予算内でも半年後に超過します。

移行作業費とAWS利用料を分けるMigration Evaluatorでの現状把握

Migration Evaluatorは移行前の現状把握と費用比較を行うAWSの仕組みです。公式ページによれば、Agentless Collectorの導入か既存インベントリのアップロードでデータを集め、依存関係マッピング、複数の移行シナリオ、予測クラウドコストを出力します。

この出力で見るべきはBYOL（ライセンス持ち込み）とLI（ライセンス込み）のコスト比較です。Windows ServerやSQL Serverを使う環境では、既存ライセンスを持ち込めるかどうかで月額が変わる。持ち込みには専有ホストの利用が条件になる場合があり、その費用を含めた比較でないと判断を誤ります。

AWS利用料そのものの見積もり方と変動要因はAWSの見積もりと料金計算ツールの記事で扱っています。移行作業費は台数と7Rの割り当てで決まるため、見積もりを取る順序は棚卸し、7R割り当て、作業費です。

Savings PlansとGravitonで下げる移行後の月額とBYOLの扱い

単価側の代表がSavings Plansで、1年または3年の利用を約束する代わりに時間単価が下がる仕組みです。移行直後は稼働が読めないため従量のまま様子を見て、負荷が安定した本番サーバーから順に切り替えます。

構成側では、AWS Gravitonプロセッサへの切り替えがAWS規範ガイダンスにReplatformの例として挙げられています。ARM系プロセッサに載せ替えて同等性能あたりの費用を下げる狙いですが、コンパイル済みバイナリや商用ミドルウェアの対応可否を先に確認してください。

下げる順序は、削除、停止、単価の順です。使っていないリソースを消し、夜間や休日に止められる開発環境を停止し、それでも残る常時稼働ぶんに予約割引をかける。逆にして先に3年契約を結ぶと、不要なリソースの費用を3年間払い続けることになります。

評価・モビライズ・移行の3フェーズで区切る社内の合意形成と体制

AWSは移行支援の枠組みとしてMigration Acceleration Program（MAP）を提供しており、評価（Assess）、モビライズ（Mobilize）、移行とモダナイズ（Migrate and Modernize）の3フェーズで構成されます。評価フェーズでは、AWSクラウド導入フレームワークの6つの視点から機能ギャップを洗い出し、移行のTCOモデルを作ります。

この3フェーズは社内の意思決定の区切りとしても使えます。評価の終わりで「移すかどうか」を決裁し、モビライズの終わりで「どの資産をどの順で移すか」を確定させ、移行フェーズは実行に専念する。境目に判断を置くと、実行中に方針が揺れる事態を避けられます。

体制の組み方も同じ区切りで考えます。評価フェーズは現行システムを知る自社側が主導し、モビライズ以降は移行先の設計知識を持つ側の比重が上がる。委託先の選び方や内製との損益分岐はAWS構築代行の依頼範囲と費用の記事で扱っています。

AWS移行を見送るべき条件と自社に残すシステムを先に決める線引き

すべての資産を移すことが正解ではありません。移さない範囲を先に確定させるほうが、計画の規模が現実的な水準に収まる。ここは条件を示して言い切ります。

メインフレーム・特殊ハードウェア依存でAWSに載せない判断条件

第一に、メインフレーム・ミッドレンジ（IBM AS/400、Oracle Solaris）・非x86のUnixで動くアプリケーション。AWS公式もこれらをRetainの該当例に挙げています。移すにはRefactorによる全面的な作り替えが要り、期間も費用も別プロジェクトの規模になる。移行プロジェクトの一部として扱うと全体が停滞します。

第二に、製造ラインの機械制御や計測装置のように、クラウドに等価なサービスが存在しないハードウェア依存の資産。第三に、データの所在地に法令上の制約があり、要件を満たすリージョン構成が取れない資産。データレジデンシー要件はAWS公式もRetainの筆頭に挙げます。

直近1年以内に更新した資産や、数年内に刷新・廃止が決まっている資産も、移行を急ぐ理由がありません。前者は減価償却が残り、後者は移行費を投じても回収前に役目を終える。移行しない判断を先に確定させると、対象台数が減って見積もりの精度が上がります。

一括移行を避けて段階移行を選ぶ損益分岐と切り戻し可能な期間設計

一括移行は推奨しません。理由は費用ではなく切り戻しの実効性です。100台を一度に切り替えると、問題が起きたときに原因を切り分けられず、戻すにも全台を戻す判断が要る。切り戻しの単位が大きいほど、実際には戻せなくなります。

段階移行の損益分岐は移行元の維持費で計算できます。ハードウェア保守と電気代の月額に、想定する移行期間の月数を掛けた金額が二重コストの総額です。これが数か月ぶんに収まるなら段階移行が有利で、移行期間が1年を超える見込みなら対象の絞り込みから見直します。

切り戻し可能な期間も同じ枠組みで決めます。移行元の環境は切り替え後すぐに消さず、月次バッチを含む全処理が一巡するまで残す。月次処理が動くのは切り替えの翌月であり、この一巡を見ずに廃棄すると、月次でしか出ない不具合に対して戻す先がなくなります。逆に一巡を確認したら速やかに止めてください。

移行の設計と実行を自社だけで抱えると、切り戻し不能な事故や、費用がかさむ構成のまま固定される事態を招きます。AWS・Google Cloud・Azureのインフラ構築を受託するサービスのように設計から切り替えまで一貫して任せられる先を確保すると、自社は7Rの割り当てと移行しない範囲の決定に集中できます。

よくある質問

AWS移行の検討段階で寄せられる質問に答えます。

AWS移行にはどのくらいの期間がかかりますか？

対象規模と7Rの割り当てで変わります。改修のないRehostで単一システム（Web・DB・バッチの3台程度）を移すなら、棚卸しからカットオーバーまで1〜2か月が目安。Refactorを含めて複数システムを移す場合は数か月から1年規模になります。まずRetireとRetainで移さない資産を外し、残りをRehostから着手すると期間を縮められます。

6Rと7Rはどちらが正しいのですか？

AWSの規範ガイダンスはRelocateを含む7Rで定義しています。6Rという表記はRelocateが加わる前の分類で、いまも一般的な解説では広く使われている。実務上の違いは、仮想基盤やRDSインスタンスを時点指定でまとめて移す選択肢が検討対象に入るかどうかです。VMware環境ではこの差が効くため、7Rで検討してください。

AWS MGNを使えば移行費用は無料になりますか？

なりません。AWSの料金ページには、無料期間中を含め、ソースサーバーがレプリケーションを行っている間はMGNがプロビジョニングしたAWSインフラストラクチャの料金が発生すると明記されています。レプリケーション用のEC2とEBS、テスト・カットオーバーインスタンスの費用が別途かかる構造です。並行して動かすサーバー数と、開始からカットオーバーまでの日数を絞ってください。

オンプレミスのデータベースはそのままAWSへ移せますか？

同じ製品へ移す同種移行であれば、スキーマとSQLをそのまま持ち込めます。Oracle から Amazon RDS for Oracle のような組み合わせがこれに当たる。製品をまたぐ異種移行、たとえば Oracle から PostgreSQL へ移す場合は、データ型・ストアドプロシージャ・独自関数の書き換えが発生します。AWS DMSには変換支援がありますが、変換結果の動作確認は自社側の工数として残る前提で見積もってください。

AWS移行の事例はどう読めばよいですか？

公開されている事例は、削減率や期間の数字だけを見ても自社に当てはまりません。読むべきは3点です。移行前の環境（物理か仮想か、OSとミドルウェアの版）、7Rのどの方式を選んだか、そして移さなかった資産があるかどうか。特に3点目は事例に書かれないことが多く、全面移行に見えて実は基幹系が残っている例も珍しくない。移行前の環境が自社と近い事例だけを選んで読んでください。

関連記事

• オンプレミスとクラウドの違い：コスト・セキュリティ・拡張性のどの軸で比べるかを整理
• AWS・Google Cloud・Azureの比較：移行先をAWSに決める前段の使い分け
• クラウド移行の課題と失敗パターン：移行前に潰しておくリスクの判断軸
• システム移行とは：クラウドに限らない移行方式の種類と失敗を防ぐ基準
• クラウドデータ移行の手順：移送ツールの選定と整合性検証を実装者向けに解説