オンプレミス(自社データセンターなど)で運用しているアプリケーションやデータを、クラウド環境へ移行するときに活用されるフレームワークが「7R」です。AWSが提唱しており、以下7つの手法を指します。
- Rehost(リホスト)
- Replatform(リプラットフォーム)
- Refactor(リファクタ)
- Relocate(リロケート)
- Repurchase(リパーチェス)
- Retire(リタイア)
- Retain(リテイン)
大まかにいうと「どの程度、既存システムを改修してAWSに適合させるか」によって手法が異なります。ここでは7つすべての概要を解説していきます。
目次
Rehost(リホスト)
「リフト&シフト」とも呼ばれ、もっともシンプルかつ移行速度を重視した方法です。オンプレ側のアプリケーションを可能な限り変更せず、AWSの仮想マシン(Amazon EC2など)へ移行します。
移行の流れ
- アセスメント
- オンプレミスのサーバー群を棚卸し、移行優先度や依存関係を整理
- 移行ツール選定
- AWS Application Migration Service(MGN)などのツールで、サーバーイメージをAWSへ転送
- 新規にAmazon EC2を構築しデータ移行
- テスト&切り替え
- EC2上で動作確認を行い、問題なければ本番運用を移す
メリット
- アプリケーション改修コストや期間を最小限に抑えられる
- ハードウェア更改を急ぐ場合など、早期にクラウド移行したいケースに最適
- 移行後にReplatform(リプラットフォーム)するなど、段階的に最適化を進めることも可能
デメリット
- オンプレと同じ構成になるため、クラウド特有の機能(オートスケールやサーバーレスなど)を活かしにくい
- OSやミドルウェアのパッチ対応・運用負荷が大幅に減るわけではない
代表的なAWSサービス
- Amazon EC2:リフト先の主要な計算リソース(仮想サーバー)
- AWS Application Migration Service (MGN):オンプレのサーバーを停止時間少なくクラウドへ複製
- AWS Database Migration Service (DMS):データベース移行専用サービス
Replatform(リプラットフォーム)
「リフト&リシェイプ」と呼ばれ、オンプレのアプリケーションを部分的にクラウド向けに修正してから移行する手法です。例えば、データベースだけAWSのマネージドサービスに置き換えるなど、一定の改修を行うことで運用負荷を軽減できます。
移行の流れ
- アプリケーションの分析
- どこを変更すればクラウド化のメリットを得られるかを洗い出す(DB、OSバージョン、ミドルウェアなど)
- プロトタイプ作成
- 例えばオンプレのDBをAmazon RDSに移行してテストする
- 性能や互換性を評価し、問題点を洗い出す
- 移行実施
- AWS DMSやMigration Hubを活用して本番データ移行
- ダウンタイムを最小限に抑えつつ切り替え
メリット
- リホストよりクラウドの利点(可用性や自動バックアップなど)を得られる
- 完全な再構築(Refactor)ほど大掛かりでなく、比較的導入しやすい
- OSパッチやDBアップグレードなどの保守負荷が大幅に削減される可能性
デメリット
- 一部改修や検証が必要なため、リホストより時間とコストがかかる
- 使いたいマネージドサービスの機能要件に合わせる必要がある
- 大がかりなアプリ変更ではないが、移行後の動作検証は入念に行う必要がある
代表的なAWSサービス
- Amazon RDS:主要DBエンジンをマネージドで提供
- Amazon ElastiCache:RedisやMemcachedをクラウドで運用
- AWS Migration Hub:移行対象システムの管理やステータス把握に便利
Relocate(リロケート)
オンプレミスの仮想化基盤(例:VMware)をそのままVMware Cloud on AWSへ移す手法です。OSレベルの改修はほぼ不要で、慣れた管理ツールやネットワーク設定を継続利用できます。
移行の流れ
- VMware環境の把握
- vCenterで管理中のVMやネットワーク、ストレージ構成などを調査
- VMware Cloud on AWS環境準備
- 必要なクラスターを作成し、オンプレ環境と接続(Direct ConnectやVPNなど)
- vMotionなどで仮想マシン移動
- HCXなどのツールを用いて、大規模かつ短時間に移行することも可能
メリット
- 既存のVMwareノウハウを生かせる
- 運用ツールや管理手順がほぼ同じため、移行期間を短縮できる
- 大量のVMを一斉に移行しやすい
デメリット
- VMware Cloud on AWSの追加コストが発生
- リフト&シフトに近く、クラウドネイティブな恩恵は限定的
- 専用ライセンスや構成管理の最適化など、初期の調整作業は必要
代表的なAWSサービス
- VMware Cloud on AWS:AWS上にVMware環境を立ち上げる
- AWS Direct Connect / VPN:オンプレとのネットワークを安定接続
Refactor(リファクタ)
既存アプリケーションをクラウドネイティブな形で全面刷新する移行手法です。サーバーレス(AWS Lambda など)やマイクロサービス、コンテナ技術(Amazon EKS など)を使い、高い可用性と拡張性を実現します。一方、既存アプリとの互換性が低くなる場合も多いため、再設計コストと開発工数を考慮した上で選択する必要があります。
移行の流れ
- モノリシックアプリの分解
- アプリケーションを小さなマイクロサービスに切り出し、それぞれをクラウド向けに最適化
- 例:データ処理部分をAWS Lambdaへ、認証機能をAmazon Cognitoへ、といった形で再設計
- 完全な再構築
- サーバー管理をほぼ手放しにする「サーバーレスアーキテクチャ」へ移行
- 新機能追加や将来の拡張を見据え、DBやネットワーク構成も大きく変える場合が多い
- 移行ステップ(例)
- PoC(概念実証):クラウドネイティブ技術でのパフォーマンス・保守性を試験
- 段階的リリース:機能ごとにRefactorを実施、新旧システムを並行稼働しながら少しずつ切り替え
メリット
- クラウドの強みを最大限活用:オートスケーリング、サーバーレス、イベントドリブンなどでリソース無駄を削減
- 開発・リリースサイクルが高速化:マイクロサービス化で、機能ごとに独立アップデート可能
- 長期的なコスト最適化:初期は工数がかかるが、運用負荷軽減によりトータルでコストメリットを得やすい
デメリット
- 最も移行工数が大きい:アプリを作り直すほどの作業になる
- 新技術の習得が必須:クラウドネイティブの設計知識が不足すると、スムーズに進まない
- レガシー連携が複雑化:既存システムとの橋渡しに追加アーキテクチャが必要になる
代表的なAWSサービス
- AWS Lambda:サーバー不要でコードを実行できるサービス
- Amazon API Gateway:API公開・管理を効率化するゲートウェイ
- Amazon DynamoDB:スケーラブルなNoSQLデータベース
- Amazon EKS / ECS:コンテナオーケストレーションサービス
Repurchase(リパーチェス)
既存のアプリケーションをSaaS(ソフトウェアのクラウドサービス)やパッケージ製品に置き換える手法です。オンプレ独自開発のシステムをやめ、AWSまたは他社SaaSで必要機能を賄うイメージになります。
移行の流れ
- 機能要件の再定義
- 既存アプリで行っている機能をリストアップし、必要な部分だけSaaSに移行
- 不要機能を削ぎ落とせば、運用もシンプル化
- SaaS製品選定
- AWS公式サービス(WorkMail, WorkDocsなど)やサードパーティSaaSから最適なものを探す
- ライセンス費用やサポート、データ保持ポリシーを比較
- 移行(データ/ユーザーなど)
- メールやファイル、設定情報をSaaS側へ移す
- ユーザーに新サービスを周知し、切り替えタイミングを調整
メリット
- サーバー管理から解放:インフラはSaaSベンダーが面倒を見る
- 常に最新バージョン:パッチや機能追加を自動で受け取れる
- 導入がスピーディー:SaaSはソフトインストール不要で、アカウント発行後すぐ使える
デメリット
- カスタマイズ性の制限:SaaS仕様に合わせる必要があり、自社専用機能は実装できない場合がある
- ベンダーロックインのリスク:サービス仕様変更や値上げの影響を受けやすい
- 既存データ移行の手間:フォーマットや権限設定の違いを埋める必要がある
代表的なAWSサービス
- Amazon WorkMail:クラウド型メールサービス
- Amazon WorkDocs:クラウドでドキュメント管理・コラボレーション
- Salesforceなどの外部SaaS:AWS以外のクラウドサービス全般を含む
Retire(リタイア)
役目を終えたり、ほとんど使われていないシステムや機能を廃止する手法です。AWSに移す労力すら無駄と判断する場合に選択されます。移行プロジェクト全体をシンプルにでき、不要コストの削減にもつながります。
移行の流れ
- 対象システムの調査
- 本当に使われていないのか?関連する業務やユーザーがいないかをヒアリング
- バックアップ・アーカイブ
- 法的要件や将来の監査に備え、必要なデータだけAmazon S3やGlacierに保管
- 廃止作業
- 関連システムに影響しないことを確認し、サーバーやライセンス、ネットワーク設定を削除
メリット
- コスト削減:稼働し続けていたサーバーや保守契約の費用をカット
- 移行範囲が減少:結果として移行プロジェクトがシンプルになる
- システムの断捨離効果:冗長な資産を整理するいい機会
デメリット
- 依存関係の見落とし:実は部分的に他システムが呼び出していた、というリスク
- 必要データの誤消去:廃止前に十分な検証が不可欠
代表的なAWSサービス
- Amazon S3 / S3 Glacier:アーカイブ目的のクラウドストレージ
- AWS Backup:バックアップを一元管理し、必要分だけ長期保存
Retain(リテイン)
技術的・コスト的・法的な理由などで、オンプレミス運用を継続するシステムを残す選択肢です。「クラウドに移すメリットが薄い」「専用ハードウェアが不可欠」といったケースではリテインが妥当となります。
移行の流れ
- リテイン要件の洗い出し
- 規制や契約条件でオンプレ外に出せないデータ・アプリかどうか
- レガシーハードウェア依存(メインフレームなど)を使っているか
- ハイブリッド構成の導入
- Retainする部分をオンプレに残しつつ、他はAWSへ移行
- VPNやAWS Direct Connectでセキュアに相互通信
- 将来的な再検討
- 再度ハードウェア更改やOSサポート切れのタイミングでクラウド移行を検討する可能性あり
メリット
- リスク低減:無理にクラウド化しないため、安定運用を維持しやすい
- 既存投資の有効活用:高額なオンプレ機器やライセンスを無駄にしない
- 導入コスト軽減:改修しないので目先の移行費用はかからない
デメリット
- クラウドメリットを得られない:スケーラビリティや運用軽減は期待できない
- オンプレ運用コストが継続:データセンター費、ハード保守などは減らない
- 長期的には二重管理:オンプレとAWSを併用するハイブリッド環境は管理の手間が増える
代表的なAWSサービス
- AWS Direct Connect / VPN:クラウドとのネットワーク連携
- AWS Storage Gateway:オンプレサーバーとAWSストレージのハイブリッド化
- AWS DataSync:オンプレからクラウドへファイル転送を自動化
まとめ
ここまで7つの移行手法「7R」を順に見てきました。
- Rehost / Replatform / Relocate
- 既存システムをなるべく生かしつつAWSへ移行
- 移行速度や工数を抑えたい場合や、運用負荷を軽減したい場合に有効
- Refactor
- クラウドネイティブ設計でアプリを全面的に再構築
- 移行コストは高いが、最大限のクラウドメリットを得やすい
- Repurchase
- SaaSやパッケージ製品に置き換え、サーバー管理から解放
- Retire
- 不要システムを廃止し、無駄な資産を整理
- Retain
- オンプレミスに留めておく必要があるものをそのまま保持
それぞれ狙うメリットやコスト、必要な技術レベルなどに大きな違いがあります。大規模移行の場合、システムごとに「リホスト」「リタイア」「リテイン」などを組み合わせて、段階的かつ効率的にAWSへ移行するケースも珍しくありません。
最適な移行戦略を練るためには、まず自社システムのアセスメント(目的・優先度・リスク分析など)を丁寧に行い、AWSが提供する各種サービスと7Rの手法をうまく連携させることが成功のポイントです。ぜひ自社の状況に合わせた最適な移行計画を立ててみてください。