DEVELOPER’s BLOG

技術ブログ

VMwareからAWSへの移行の手順と選択肢の紹介

2024.10.24 竹中 涼香
AWS
VMwareからAWSへの移行の手順と選択肢の紹介

VMwareからAWSへの移行について

  1. 導入
  2. 移行のステップ
  3. 移行戦略のパターン
  4. 移行後のアーキテクチャ
  5. 移行の成功事例
  6. まとめ


本記事では、VMware環境からAWSへの移行手順・移行の進め方・構成決定方法・成功事例について紹介します。


1. 導入

近年、クラウド移行を検討する企業が増える中で、VMware環境からAWS(Amazon Web Services)への移行が特に注目されています。特に、2024年に実施されたVMwareのライセンス料金改定が移行の大きな動機になっているケースが増加しています。多くの企業が、VMwareのライセンスやサポート料金の上昇に直面し、よりコスト効率の良いAWSへの移行を検討するようになりました。

VMwareからAWSへの移行は、単にコスト削減だけでなく、AWSのスケーラビリティや柔軟性、そしてクラウドネイティブのサービスを最大限に活用できる点でも有利です。本記事では、VMware環境からAWSへ移行するための具体的な手順と、移行後の最適化について詳しく解説します。


2. 移行のステップ

クラウドへの移行は、単にシステムを移すだけではなく、移行後の最適化と運用の効率化が重要です。以下のステップに分けて、移行プロセス全体を進めることが推奨されます。

移行のステップ


2-1. 現状(クラウド移行決定前)評価

移行を検討する際は、まず現状のオンプレミス環境やVMware環境をしっかりと評価する必要があります。この評価では、移行候補となるアプリケーションやシステムがクラウド環境に最適かどうか、またどの移行戦略(Rehost、Replatform、Refactor)が最も適切かを判断します。

特に考慮すべき点は以下の通りです

  • アプリケーションの互換性:AWS上で問題なく動作するかどうか
  • コスト試算:オンプレミスとクラウドのコスト比較
  • セキュリティ要件:クラウド移行後のデータ保護やコンプライアンス対応


2-2. 移行計画

次に、評価結果に基づいて詳細な移行計画を立てます。この段階では、各ステークホルダーとのコミュニケーションが重要です。移行に伴うダウンタイムや、システムの変更点、各チームの役割分担を明確にする必要があります。


2-3. 移行実施と最適化

移行の実施では、計画通りにリフト&シフト、またはリファクター等のアプローチに従ってシステムをAWSに移行します。移行後は、AWSのサービスを最大限に活用し、システムのパフォーマンスやコストの最適化を行うことが重要です。

移行後の最適化には、次のような具体的な作業があります。

  • リソースのモニタリング:AWSのCloudWatchなどを使用して、システムのパフォーマンスやリソース使用率を常時監視し、必要に応じて調整を行います。
  • コスト管理の最適化:AWS Cost ExplorerやTrusted Advisorを活用して、不要なリソースやコスト削減の余地を特定し、運用コストの削減を図ります。
  • セキュリティ強化:AWSのセキュリティツール(AWS Identity and Access Management、AWS Shieldなど)を使い、移行後のデータ保護やアクセス管理を強化します。


3. 移行戦略のパターン

移行を進める前に、まずいくつかの移行戦略を把握する必要があります。

VMwareからAWSへの移行にはいくつかのアプローチがあります。

3-1. Rehost(リホスト、リフト&シフト)

Rehostは、リフト&シフトとして知られ、既存のVMware環境で稼働している仮想マシンをAWS上にそのまま移行する方法です。この方法では、仮想マシン(VM)をほぼそのままAWSのEC2インスタンスに移すため、アプリケーションのコードやアーキテクチャを変更する必要がありません。

メリットとしては、移行が比較的簡単かつ迅速に行えることや、移行中のリスクが低いことが挙げられます。一方で、デメリットとしては、AWSのスケーラビリティやコスト最適化機能を最大限に活用できない場合があるため、クラウドに最適化されていない構成になりやすい点があります。


3-2. Replatform(リプラットフォーム)

Replatformは、「リフト、ティンカー、アンドシフト」とも呼ばれ、既存のアプリケーションをAWSのクラウドサービスに最適化するアプローチです。この方法では、アプリケーションの基本的なアーキテクチャを維持しつつ、データベースをAmazon RDSに移行するなど、一部のサービスやコンポーネントをクラウドネイティブなものに置き換えます。

メリットとして、完全にアプリケーションを再設計する必要がないため、ある程度効率的にクラウド最適化が行え、クラウド特有の利点を享受できます。デメリットは、変更箇所によってはある程度のコストや時間がかかること、特に検証やテストに手間がかかる点です。


3-3. Refactor(リファクター、再アーキテクチャ)

Refactorは、アプリケーションを完全にクラウド向けに再設計する移行アプローチです。アプリケーション全体を再アーキテクチャし、クラウドネイティブな技術(例えばサーバーレスアーキテクチャやマイクロサービス)を導入することで、AWSの柔軟性やコスト効率を最大限に活用します。

メリットは、アプリケーションのパフォーマンス向上やコスト削減、可用性の向上が期待できる点です。また、AWSの豊富なサービスを活用して、アプリケーションのスケーラビリティを高めることができます。デメリットとしては、アプリケーションの再設計や再開発が必要になるため、時間とコストが大幅にかかる可能性がある点です。

移行戦略を検討する際には、以下の観点を考慮して決定する必要があります。

  • Rehostは、最も簡単なアプローチで、迅速に移行を行いたい場合に適していますが、クラウドの特性を最大限に活かすには限界があります。
  • Replatformは、最低限の変更でクラウドのメリットを部分的に享受でき、よりバランスの取れた選択肢です。
  • Refactorは、クラウドネイティブな技術をフル活用できる最も柔軟で効率的な方法ですが、移行の複雑さが増します。


4. 移行後のアーキテクチャ

移行を決めると、どのようなアーキテクチャにするべきか検討します。移行先を選択する際には、大まかに下記のフローで考えることもできます。

移行検討のフロー

図にあるサービスをひとつずつ説明します。

Amazon EC2

ユースケース例: 既存のアプリケーションをほぼそのまま移行し、コスト削減したい

選択理由

  • 最小限の変更で既存のワークロードを移行したい
  • OSのバージョンを変えたくない、特定のOSやソフトウェアバージョンへの依存がある
  • ダウンタイムを最小化して移行したい
  • 段階的なクラウド移行を行いたい


移行ツール: AWS Application Migration Service (AWS MGN)、AWS Backup、VM Import/Export など


Amazon RDS

ユースケース例:データベース管理の負担を軽減したい、コストを最適化したい

選択理由

  • フルマネージドによる運用工数・コストの削減
  • ライセンスコストの最適化
  • データベースエンジンを変更せずに移行したい
  • ダウンタイムを最小化して移行したい


移行ツール: AWS Database Migration Service (AWS DMS)、Oracle Data Pump などのネイティブツール


Amazon WorkSpaces / Horizon + WorkSpaces Core

ユースケース例: 仮想デスクトップ環境 (VDI) を移行したい

選択理由

  • フルマネージドによる運用工数・コストの削減
  • 仮想デスクトップ管理を簡素化
  • コスト効率の高い料金設定
  • Horizon のユーザー体験のまま移行したい(Horizon + WorkSpaces Core)


AWS Outposts Family

ユースケース例: データレジデンシー対応、低レイテンシーが必要な場合

選択理由

  • データの所在地に厳しい規制がある
  • オンプレミスのアプリケーションと低レイテンシーでの接続、リアルタイム処理が必要
  • オンプレミス環境とAWSの一貫した管理を行いたい


移行ツール:AWS Elastic Disaster Recovery (AWS DRS) など


NC2 on AWS / ROSA

ユースケース例:仮想環境の運用体制やオペレーションを極力変えたくない

選択理由

  • 既存環境との親和性
  • 最小限の変更で既存のワークロードを移行したい
  • OSのバージョンを変えたくない、特定のOSやソフトウェアバージョンへの依存がある
  • 段階的なクラウド移行を行いたい


移行ツール:NC2 on AWS: Nutanix Move、ROSA: Migration Toolkit for Virtualization (MTV)


5. 移行の成功事例

5-1.コスト削減とパフォーマンス向上

A社では、VMware環境のライセンスコスト上昇を受けてAWSへの移行を決定しました。リフト&シフト戦略を採用し、既存のアプリケーションをAWS EC2インスタンスに移行しました。結果として、初期移行コストを抑えつつ、AWSのスケーラビリティを活用して、システムパフォーマンスを向上させることに成功しました。


5-2.リファクターで大規模なアーキテクチャ改革

B社は、クラウドネイティブな技術をフルに活用するため、既存のアプリケーションを完全にリファクターし、サーバーレスアーキテクチャに移行しました。移行後、運用効率が大幅に向上し、コスト削減と同時にアプリケーションのパフォーマンスが飛躍的に向上しました。


6. まとめ

VMwareからAWSへの移行は、コスト削減や運用効率の向上、スケーラビリティの獲得といった多くのメリットをもたらします。Rehost、Replatform、Refactorという移行戦略を適切に選び、移行後の最適化を行うことで、AWSの強力なクラウドサービスを最大限に活用することができます。

企業のITインフラを次世代にシフトさせるための一手段として、AWSへの移行をぜひ検討してみてください。




X(旧Twitter)・Facebookで定期的に情報発信しています!

関連記事

AWS Network Firewall:シンプルな非機能要件に対して、過剰な設計をしていませんか?

はじめに シナリオ:ネットワーク制御要件を満たすための設計 適材適所の判断をする コスト最適化の視点 まとめ はじめに AWSでは、あらゆるユースケースを支える豊富なサービス群が提供されています。 しかし、その選択肢の多さゆえに「本当に必要な要件以上のサービスを導入してしまう」ケースも少なくありません。 特に、非機能要件に対して、必要以上に複雑な構成を採用してしまうと、以下のようなデメリットにつながることがあります。 AWSコ

記事詳細
AWS Network Firewall:シンプルな非機能要件に対して、過剰な設計をしていませんか?
AWS SRE
5分で分かる。Amazon CloudFrontによるAWSコスト削減術

はじめに 1. EC2 × ALB × CloudFront でインフラコストを削減 2. API Gateway × Lambda × CloudFront で動的コンテンツでもコスト最適化 3. 単一リージョン × CloudFront でグローバル配信をシンプルに まとめ:CloudFrontは単なる「CDN」ではない! はじめに AWSでシステムを構築する時、「とりあえずEC2インスタンスを建てて終わり」としていませんか?もし

記事詳細
5分で分かる。Amazon CloudFrontによるAWSコスト削減術
AWS SRE
AWSマルチアカウント環境でのOS・パッチ・証明書の統合管理

はじめに SSM統合コンソールによる一元管理 OSなど構成情報の可視化 Patch Managerによるパッチ運用の標準化 証明書有効期限の集中監視と自動通知 導入効果と業務改善イメージ 導入時の設計上の留意点 継続的改善を支える「運用の仕組み化」 1.はじめに クラウド活用が拡大し、AWS環境が複数アカウントで利用されたり、複数システムにまたがって利用されることは、システム運用における構成の一貫性を維持することの難易度を

記事詳細
AWSマルチアカウント環境でのOS・パッチ・証明書の統合管理
AWS SRE コラム
AWSの可用性設計を考える:AZ・リージョン・事業継続計画(BCP)のバランス

はじめに 可用性設計の基礎:リージョンとAZの仕組みを理解する 止まらない設計を妨げる単一点障害:単一AZ構成の限界 マルチAZ構成:同一リージョン内での止まらない仕組み マルチリージョン構成:事業継続(BCP)のための冗長化 まとめ:設計段階で「どこまで止めないか」を決めよう 1. はじめに AWSは、数クリックで仮想サーバー(EC2)を立ち上げられるなど、手軽にサービスを構築できるクラウドです。システム企画や開発の初期段階では

記事詳細
AWSの可用性設計を考える:AZ・リージョン・事業継続計画(BCP)のバランス
AWS コラム

お問い合わせはこちらから