公開日：
AWS移行戦略「7R」と5つの検討ポイント
この記事をシェア
AWS移行は、単なるインフラの置き換えではなく、運用の見直しや将来のモダナイゼーションを見据えた重要な判断です。しかし、「何から手をつけたらいいのか」「どのようなことを決めなければならないのか」と悩む企業も多いでしょう。
本記事では、AWSへの移行の基本的な道筋や戦略、成功させるために押さえておくべき検討ポイントについて解説します。
1. AWS移行とは
AWS移行（マイグレーション）とは、オンプレミス環境で稼働しているサーバーやアプリケーション、データなどのITシステムを、AWSのクラウド環境へ移すことを指します。単なるシステムの引っ越しではなく、運用の見直しや将来の最適化までを含む重要な取り組みです。
企業がAWS移行を検討する背景には、ハードウェアの老朽化やBCP（事業継続計画）対策、運用負荷の軽減、コスト最適化など多くの要因があります。近年ではリモートワークの普及やセキュリティ対策の強化が求められており、オンプレミスの限界を感じる企業が増加しています。
オンプレミスからAWSへ移行するメリット
オンプレミスからAWSへ移行することで、具体的に次のようなメリットが得られます。
サーバーの物理的制約から解放され、必要なときに必要なだけリソースを確保できる
ハードウェアの保守や障害対応といった運用負荷を軽減できる
可用性や災害耐性が強化される
初期投資が不要で、利用量に応じたコスト最適化が図れる
マネージドサービスの活用により、運用リソースを抑えてコア業務に集中できる
つまり、AWS移行は単なるインフラ刷新ではなく、業務の柔軟性向上や経営資源の最適配分を実現する有効な手段といえます。
2. AWSマイグレーションジャーニーとは
AWSマイグレーションジャーニーとは、オンプレミス環境からクラウド（AWS）へと移行していく一連のプロセスを旅に例えて表現したものです。AWSでは、このジャーニーを「リフト」「シフト」「モダナイゼーション」の3段階に分けて捉えています。
本章では移行順序のポイントと、各ステップで何を行うのかについて、解説します。
移行順序のポイント
一般的には「リフト」から始めて、「シフト」「モダナイゼーション」という順序で進むことが多いです。ただし、リフトを飛ばして、オンプレミスからいきなりシフトやモダナイゼーションに着手する場合もあります。
ステップ1：リフト
「リフト」は、オンプレミスの環境からクラウドの世界へ移ることを指し、マイグレーションジャーニーの最初のステップとされます。
クラウド事業者が提供するリソースを利用する形態へ変化させるため、オンプレミスのようにデータセンターやサーバーを資産として保有する必要がありません。そのため、データセンターの契約や管理、ハードウェアの老朽化対応などの業務から解放されます。
ステップ2：シフト
リフトの次の段階が「シフト」です。AWSが提供するマネージドサービスやクラウドネイティブの機能を活用することを指します。このフェーズでは、リフトよりも多くのクラウドメリットを活用でき、高可用性やスケーラビリティ、俊敏性の向上といった利点も期待できます。
ステップ3：モダナイゼーション
モダナイゼーションは、クラウド環境の活用をさらに最適化することを目指す段階です。クラウドネイティブ設計やサーバーレスアーキテクチャを取り入れることで、運用負荷の軽減や開発の柔軟性向上などが期待できます。
3. AWS移行戦略「7R」とは
「7R」とは、AWSが提唱する7つのクラウド移行戦略です。それぞれの戦略名が英語のRから始まることに由来します。7Rは、システムの特性や移行の目的に応じて適切な手法を選択する指針となります。
| 内容 | 説明 | 例 |
|---|---|---|---|
1 | リロケート | VMwareなどの仮想環境で動いているサーバーを、VMware互換のハイパーバイザーが稼働する別環境にそのまま移行 | ・オンプレミスのVMware仮想サーバー⇒VMware Cloud on AWS |
2 | リホスト | OSやアプリケーションに変更を加えず、クラウド環境に移行 | ・物理・仮想サーバー ⇒ EC2 |
3 | リプラットフォーム | アプリケーションに変更を加えず、プラットフォームのみ最適化の取り組みをして移行 | ・Windows Server 2008 ⇒ 2022 |
4 | リパーチェス | SaaSやパッケージの適用を伴って移行 | ・CRM ⇒ Salesforce.com |
5 | リファクタ | アプリケーションも含めた再設計をして移行 | ・OSの種類（AIX ⇒ Linux）変更 |
6 | リテイン | システムをAWSに移行せず、保持 | ― |
7 | リタイア | システムをAWSに移行せず、廃止 | ― |
リフトに該当するのはリロケートとリホストで、これらはOSやアプリケーションには変更を加えずに移行する方法を指します。本記事では、企業が採用しやすい「リフト」に焦点をあてて紹介します。
4. CTCの考えるAWSマイグレーションの進め方
CTCでは、AWSマイグレーションを「準備」「計画」「移行」「運用／最適化」の4つのフェーズに分けて進めることを推奨しています。
準備フェーズ：現状の整理や、先ほどの7Rの検討を行います。システムやサーバーごとに検討し、関係者で認識を合わせることが重要です。
計画フェーズ：クラウド推進組織を立ち上げ、AWS環境の設計や移行計画の立案、PoCを実施します。
移行フェーズ：環境構築や実際の移行作業、運用準備を行います。トレーニングなどの人材育成も必要です。
運用・最適化フェーズ：運用しながら設定やコストの最適化を行います。モダナイズ（コンテナ化やサーバーレス活用など）にも着手します。
ただし、移行にあたってこれらの作業をすべて行う必要はありません。移行対象の性質（業務上の重要度、停止許容時間など）によって、必要な作業をピックアップして行います。
5. AWSマイグレーションにおける5つの検討ポイント
ここからは、実際の移行時に検討すべきポイントについて具体的に解説します。
1.リフト移行ができるのか？
まずは、既存のシステムのリフト移行が可能かを確認しましょう。
対象システムはクラウド環境での利用がサポートされているか？
移行対象のシステムのOSやミドルウェア、パッケージ製品、業務アプリケーションがAWS環境のサポート対象かどうか、あるいはそのソフトウェアがAWSをサポートしているかを確認する必要があります。
特に注意すべきは、古いOSバージョンやUNIX系のOS（AIXやSolarisなど）です。これらはAWS上での動作保証がない、あるいは技術的に移行ができません。また、テープドライブなどハードウェアに依存したシステムは、クラウド環境には適合せず、構成そのものの見直しが求められる場合があります。
ライセンスに問題はないか？
ライセンスの問題も重要な観点です。商用OSやソフトウェアの多くは、利用許諾に制限があります。
クラウド上でもオンプレミスと同様に使用できるのか、別契約が必要になるのかをメーカー側に確認しましょう。条件付きで許可されるケースや、ライセンスの買い直し・買い足しが必要なケースもあります。
この場合、移行後のライセンスコストについても想定しておく必要があります。
2.AWSアカウントをどのような構成にするか？
クラウド環境ではアカウント構成が運用効率やセキュリティに大きな影響を与えるため、リフト先のAWSアカウント構成を検討することが重要です。
シングルアカウント構成にするか、マルチアカウント構成にするか？
AWSでは、一つのアカウントで複数のシステムを運用する「シングルアカウント構成」と、システムごとにアカウントを分離する「マルチアカウント構成」があります。
シングルアカウント構成：一元的な管理が可能です。システム間の区切りがないため、小規模な構成向きです。
マルチアカウント構成：現在主流になっている構成で、権限や請求ごとなどに分けて管理できます。運用におけるオペミスの防止にも有効です。
組織の権限体系や請求、運用体制に合わせて選択します。
マルチアカウントの場合、何の単位でアカウントを分けるか？
マルチアカウント構成にする場合、どのような単位でアカウントを分けるのかを決める必要があります。AWS環境に対して設けたい権限単位や、明示的に分けたい請求単位でアカウントを分けることが原則です。
また、マルチアカウントはシングルアカウントのデメリット（アクセス制御の煩雑さ、コスト把握の難しさ）を克服できますが、「アカウント数が増えると、誰がどのアカウントを管理／利用しているか分からなくなる」「各アカウントのユーザやユーザ権限を適切に管理できない」といった別の課題が発生することもあります。
この場合、「AWS Organizations」という複数AWSアカウントの一元管理を行うサービスを利用することで、請求やポリシー管理を効率化できます。
3.自社拠点とAWSをどうやって繋ぐか？
AWS上のシステムを社内から利用したい場合や、自社で契約しているデータセンターに置かれた別のシステムと連携したい場合には、拠点とAWS環境を接続する必要があります。代表的な選択肢は、「Direct Connect」という閉域で接続する方法と、「Site-to-Site VPN」というIPSec VPNで接続する方法です。
Direct Connectの方がレスポンスタイムやセキュリティ面で優れていますが、コストが高いというデメリットがあります。通信要件とコストのバランスで選択しましょう。
また、マルチアカウント構成においては、ネットワークを集約する「ハブアカウント」を設けて、そこを経由して各AWSアカウントを接続する構成が効率的です。
4.どんな手法で移行するか？
AWS移行には複数の手法があるため、自社の要件に合わせて適切なものを選択する必要があります。
どの移行方式を選ぶか？
AWSへの移行方法としては、大きく分けて新規構築とマイグレーションがあり、マイグレーションはさらにリフト（サーバーをそのまま移行）とデータ移行に分かれます。
さらに、リフトの方式としては以下の3つがあります。
仮想マシンのイメージを取得して移行する
レプリケーションを活用してリアルタイムで複製する
バックアップを取得してAWS上でリストアする
移行方式を決める上で、考慮すべきことは次のとおりです。
移行対象の規模やデータ量
移行の際の停止可能時間
移行元環境に対する作業制約 など
移行方式の選定は、技術的な制約と業務への影響のバランスをどう取るかが重要です。
AWSのマイグレーションツールを使用するか？
AWSには複数のマイグレーションツールが用意されています。中でも、AWSが提供するリフト移行用のAWS Application Migration Service（MGN）は、最小限のダウンタイムで移行できます。
ただし、すべてのケースに適用できるわけではありません。成功率や本番化の可否に注意が必要です。また、既存環境との重複や競合が、移行後の障害につながるリスクもあります。そのため、PoC（実現性検証）を行ったり、代替案を用意したりする必要があります。
5.AWS移行後のシステムをどのように運用するか？
AWSへ移行する場合、オンプレミスで必要だったハードウェア由来の運用負荷は減らせますが、OS以上のレイヤーは引き続き運用が必要です。
AWS上のサーバーの運用保守をするとき、どのようにアクセスするか？
AWS上のサーバー運用はすべてリモートで行う必要があります。主なアクセス方法は以下の4つです。
踏み台サーバー経由でのリモートログイン
AWS Client VPNを用いたSSL-VPN接続
Site-to-Site VPNを用いたIP-Sec VPN接続
Session Managerを用いたAWSコンソール経由の接続
どの方式を用いるかは、セキュリティ要件や体制に応じて選定する必要があります。
AWS上のサーバーの監視やバックアップはどうするか？
AWS移行後の監視・バックアップ運用は、既存システムの残し方や再構築方針により3つに分類できます。
①オンプレミスの仕組みを継続（リテイン）
②既存ツールをAWS上に移す（リホスト／リプラットフォーム）
③CloudWatchやAWS BackupなどAWSサービスに置き換える（リファクタ）
これらは7R戦略にも対応するため、マイグレーションジャーニー全体を見据えた上で、戦略的に決めるとよいでしょう。
まとめ
オンプレミスからAWSへの移行は、ハードウェアの老朽化や運用負荷の軽減といった課題解決だけでなく、可用性や柔軟性を高める戦略的な手段です。
また、マイグレーションジャーニーは今回解説したリフトだけでなく、その先のシフトやモダナイゼーションも含みます。より進んだマネージドサービスやサーバーレスの領域に進むことで、AWSに任せる領域が増え、ビジネス価値の創造やデジタルトランスフォーメーションに力を注げるようになるでしょう。
移行検討の具体的なステップや判断基準は、ホワイトペーパーで詳しく解説していますので、ぜひ参考にしてください。
当サイトに掲載されている情報（記事、資料、動画、テンプレート等）については、その正確性および妥当性の確保に努めておりますが、ご利用に際しては、利用者ご自身の責任においてご判断ください。なお、個別の事情に応じては、専門家へのご相談を含め、適切な対応をご検討いただくことを推奨いたします。
