BroadcomによるVMware買収以降、ライセンス体系がサブスクリプションへと切り替わり、「更新見積もりが数倍に跳ね上がった」という声が製造業の情シスからも相次いでいます。長年使ってきたvSphere基盤を、コストのためだけに手放すのは怖い——けれど、このまま値上げを飲み続けるのも現実的ではない。そんな板挟みの状況ではないでしょうか。

本記事では、Broadcomのライセンス高騰を起点に、VMwareの仮想化基盤からAWSへ移行する方法を、SIer目線で整理します。なぜ今VMware資産の脱出を検討すべきかという背景から、AWSでの移行先の選択肢（EC2へのリホスト・コンテナ化・マネージド化）、移行方式の比較、ライセンス費削減のTCO試算フレーム、プロジェクトの進め方、失敗回避、そして自社移行と外注支援の判断ポイントまで、順を追って解説します。「移行したいが、どの方式で、いくら下がるのかがわからない」という疑問に答えていきます。

想定読者

本記事は、次のような方を想定しています。

• Broadcom買収後のVMwareライセンス値上げで、更新可否を判断しなければならない情シス・インフラ担当者
• vSphere基盤の移行先としてAWSを検討しているが、移行方式の違いがわからない方
• 「移行すると本当にコストが下がるのか」をライセンス費まで含めて試算したい方
• 老朽化した仮想化基盤の更改タイミングで、オンプレ更改かクラウド移行かを迷っている製造業の担当者
• 自社リソースで移行するか、SIerに支援を頼むかの判断材料がほしい方

Broadcom買収でVMwareのライセンス費用はなぜ高騰したのか

まず、なぜ今これほど多くの企業がVMwareからの脱出を検討しているのか、背景を整理します。

2023年11月に完了したBroadcomによるVMware買収を境に、ライセンスの提供形態が大きく変わりました。Broadcomは買収完了直後の2023年12月に永続ライセンスの新規販売を終了すると発表し、従来の「買い切り型の永続ライセンス＋年間サポート」からサブスクリプション（期間契約）への一本化を進めました。あわせて製品が個別ライセンスから複数機能を束ねた「バンドル（VMware Cloud Foundation・vSphere Foundation など）」中心の販売へと再編されています。

この変更が実務にもたらした影響は、主に次の3点です。

• 必要な機能だけを買えなくなった：これまで単体で使っていた機能が上位バンドルに組み込まれ、使わない機能まで含めて契約せざるを得なくなったケースがある
• 課金単位の変更：CPUソケット単位から物理コア単位の課金へと移行し、さらにCPUあたり最低コア数（一般に16コア）が適用されるため、コア数の多いサーバーほど費用が膨らみやすくなった
• 永続ライセンスの実質的な終了：買い切りで使い続けるという選択肢が狭まり、更新のたびに費用が発生し続ける構造になった

結果として、更新見積もりが従来の数倍になる事例が国内でも珍しくなくなりました。とりわけ、少数の仮想マシンを堅実に動かしてきた中堅・製造業の情シスにとっては、「使っている規模に対して費用が見合わない」という不満が生じやすい構造です。

重要なのは、これは単なる一時的な値上げではなく、ライセンスの提供思想そのものの転換だという点です。次回以降の更新でも同じ論理で費用がかかり続けるため、「今回はなんとか払う」で先送りしても、根本的な負担は消えません。だからこそ、更新のタイミングは仮想化基盤そのものを見直す好機になります。

なぜ今、VMware資産の脱出を検討すべきか

「値上げは痛いが、動いているものを触るのはリスク」——その慎重さは正しいものです。しかし、次のような条件が重なっているなら、脱出の検討を先送りするデメリットのほうが大きくなります。

• ライセンス更新の期限が近い：更新時は追加費用なしで移行に踏み切れる数少ないタイミング。契約を更新してしまうと、次の更新まで移行の動機とタイミングを失う
• ハードウェアの保守期限（EOSL）も近い：サーバー老朽化の更改とライセンス更改が重なるなら、オンプレを買い替える投資をそのままクラウド移行に振り向けられる
• 仮想マシンの多くがWebシステムや業務アプリで、可搬性が高い：ハイパーバイザーに強く依存していないワークロードは、AWSへ載せ替えやすい

一方で、急いで移行すべきでないケースもあります。特殊なハードウェア（産業機器の制御PC、専用ボードを挿したサーバーなど）に密結合した仮想マシンや、極端に低遅延が求められる工場現場の制御系は、無理にクラウドへ持ち出すと運用が破綻します。こうしたワークロードはオンプレに残し、汎用的な業務システムだけをクラウドへ切り出すハイブリッド構成が現実解になることも多いです。

つまり「全部AWSへ」ではなく、「値上げの影響が大きく、かつ移しやすいワークロードから優先的に脱出する」という考え方が、リスクとコストのバランスを取るうえで重要になります。

VMware基盤の移行先：AWSでの3つの選択肢

VMwareの仮想マシンをAWSへ移すとき、「AWSに載せる」といっても方式は一つではありません。移行のしやすさとコスト最適化の度合いには、大きく次の3つの段階があります。手前ほど速く安全に移せて、奥へ行くほど手間はかかるがクラウドのメリットを引き出せる、という関係です。

EC2へのリホスト（そのまま載せ替え）

最も現実的で、多くの移行の入口になるのがこの方式です。VMware上で動いている仮想マシン（OS・ミドルウェア・アプリ一式）を、ほぼそのままAWSの仮想サーバー「EC2」に載せ替えます。俗に「リフト＆シフト」とも呼ばれます。

• メリット：アプリの改修がほぼ不要で、移行期間が短くリスクが低い。まずライセンス費の重いVMware基盤から離脱することを最優先できる
• デメリット：仮想マシンの構成をそのまま持ち込むため、クラウドならではのコスト最適化（マネージド化・自動スケールなど）の恩恵は限定的
• 向くワークロード：改修余力のない業務アプリ、パッケージソフト、まず「脱VMware」を急ぎたいシステム

AWSにはVMwareや物理サーバーからEC2へ移行を半自動化する仕組み（AWS Application Migration Serviceなど）があり、稼働中のサーバーを継続的に複製しながら切り替える方式を取れます。これにより、停止時間を短く抑えた移行が可能です。

コンテナ化（ECS/EKSへのリファクタ）

仮想マシン単位ではなく、アプリケーションをコンテナとして再構成し、AWSのコンテナ実行基盤（ECS／EKS）へ載せる方式です。OS丸ごとではなくアプリと必要な依存関係だけを持ち運ぶため、リソースを無駄なく使えます。

• メリット：サーバー1台単位の無駄がなくなり、集約率が上がる。デプロイの自動化やスケールもしやすくなる
• デメリット：アプリの作り替え（コンテナ化）に工数がかかり、既存の運用手順も見直しが必要
• 向くワークロード：内製で改修できる自社開発アプリ、更新頻度が高くスケールさせたいシステム

一度に全システムをコンテナ化する必要はありません。まずリホストで脱VMwareを済ませ、更新頻度の高いアプリから順にコンテナ化していく、という段階的な進め方が現実的です。

マネージドサービス化（RDS等への置き換え）

仮想マシン上で自前運用しているミドルウェア（データベース、メール、認証基盤など）を、AWSのマネージドサービスに置き換える方式です。代表例が、自前運用のデータベースをAWS RDSへ移すケースです。

• メリット：バックアップ・冗長化・パッチ適用などの運用作業をAWS側に任せられ、運用工数とヒューマンエラーが減る。可用性も上げやすい
• デメリット：製品固有機能を使っている場合は互換性の確認が必要。設計と検証に相応の工数がかかる
• 向くワークロード：DBサーバー、ファイルサーバー、共通基盤系など「運用が重いのに差別化にならない」領域

実際のプロジェクトでは、これら3つを排他的に選ぶのではなく、システムごとに使い分けるのが定石です。「業務アプリはリホスト、DBはRDSへマネージド化、更新の速い自社アプリはコンテナ化」といった具合に、システム単位で最適な方式を割り当てます。

移行方式の比較とライセンス費削減のTCO試算

方式ごとの特徴を一覧で押さえたうえで、「結局いくら下がるのか」を試算する考え方を示します。

移行方式の比較

補足として、「VMware Cloud on AWS」のようにVMwareのままAWSインフラ上へ載せる選択肢もあります。移行はもっとも速い一方、VMwareライセンスを使い続けるためライセンス費の高騰という根本課題は解決しません。あくまで一時退避・時間稼ぎの手段と位置づけ、恒久策としてはEC2以降の方式を目指すのが基本です。

VMwareライセンス費削減のTCO試算フレーム

移行の投資判断は、目先のインフラ費用だけでなく、数年間の総保有コスト（TCO：Total Cost of Ownership）で比較するのが正しい進め方です。VMware継続の場合とAWS移行の場合で、次の項目を3〜5年分並べて比較します。

VMware継続シナリオで積み上げる費用は、次のとおりです。

1. VMwareサブスクリプション費用（コア数×年数、更新ごとの値上げも見込む）
2. サーバー・ストレージのハードウェア更改費用（EOSL到来分）
3. データセンター/自社ラックの設置・電力・空調費用
4. ハイパーバイザーと物理基盤の運用工数（人件費）

AWS移行シナリオで積み上げる費用は、次のとおりです。

1. AWS利用料（EC2・ストレージ・通信など。リザーブドインスタンスやSavings Plansで圧縮可能）
2. 移行プロジェクトの一時費用（設計・構築・データ移行・並行運用の検証）
3. 移行後の運用工数（マネージド化した分だけ減る）

ここで見落としがちなのが、VMwareの費用は「ライセンス＋ハード＋電力＋運用」の合算だという点です。ライセンス費だけを見て「AWSと大差ない」と判断すると誤ります。物理サーバーの更改・電力・空調・ハイパーバイザーの運用工数まで含めると、AWSへ移すことで消える費用は想像より大きくなります。特にマネージド化した領域は、運用の人件費という「見えにくいコスト」を継続的に削減します。

一方で、AWS利用料は使い方次第で膨らむため、リザーブドインスタンス等の割引購入や、不要な仮想マシンの停止・適正サイジングを前提に試算することが重要です。「オンプレのスペックをそのままEC2で常時起動」した楽観試算では、削減効果が正しく出ません。

なお、AWSへ移した後の純粋な構築費用の相場観や、運用を外部に委託する場合の費用感は、それぞれ専門記事にまとめています。本記事では移行方式の判断に集中するため、詳細は次の記事をご参照ください。

• 構築費用の相場：AWS構築代行の費用相場｜初期費用の内訳・見積の見方・会社の選び方
• 運用の外部委託：AWSに強い運用代行会社14選を比較｜利用するメリットやデメリットを解説

移行の全体像や進め方の基本は、基幹システムのクラウド移行ガイドでも解説しています。

「自社のVMware基盤だと、どの方式でいくら下がるのか」を具体的に試算したい場合は、現行構成の棚卸しから一緒に整理するのが近道です。

VMwareの値上げ対策やAWS移行のTCO試算でお困りでしたら、c3index にお気軽にご相談ください。

---

VMwareからAWSへの移行プロジェクトの進め方

方式が見えたら、実際のプロジェクトをどう進めるかです。VMware基盤の移行は、次の5ステップで進めるのが基本形です。

ステップ1：現行仮想基盤の棚卸し

まず、vCenterから仮想マシンの一覧・スペック・OS・ミドルウェア・稼働状況を洗い出します。この段階で「実は誰も使っていない仮想マシン」や「停止していい検証環境」が見つかることが多く、移行対象を減らすだけでコストが下がることもあります。あわせて、システム間の通信（依存関係）と、外部ハードウェアへの依存の有無を整理します。

ステップ2：移行方式の割り当て（波分け）

棚卸し結果をもとに、システムごとに前述の3方式（リホスト／コンテナ化／マネージド化）を割り当て、移行の順番（波：ウェーブ）を決めます。依存関係が少なく、可搬性が高く、影響範囲の小さいシステムを第1波に置くのが鉄則です。いきなり基幹システムから始めてはいけません。

ステップ3：AWS環境の設計・構築

移行先となるAWS側のネットワーク（VPC）、セキュリティ、バックアップ、監視の土台を設計・構築します。オンプレに残す資産があるなら、この段階でオンプレとAWSをつなぐ接続方式（VPN／専用線）も設計します。

ステップ4：移行と並行運用（現行とAWSの二重稼働）

第1波のシステムをAWSへ移行し、一定期間は現行のVMware環境とAWS環境を並行稼働させて、性能・整合性・運用手順を検証します。ここで問題がないことを確認してから、本番トラフィックをAWS側へ切り替えます。並行期間を設けることが、切り戻せる安全網になります。

ステップ5：切り替えとVMware基盤の縮退

検証が済んだシステムから順にAWSへ切り替え、移行完了後は該当分のVMwareライセンスと物理サーバーを縮退させます。ライセンスを減らして初めてコスト削減が実現するため、「移したのにVMware側も残したまま」にならないよう、縮退までを計画に含めます。全システムを一度に切り替えるのではなく、波ごとにこの流れを繰り返します。

移行で失敗しないための注意点と、自社移行か外注かの判断

最後に、つまずきやすいポイントと、体制の判断について整理します。

VMware→AWS移行でよくある失敗は、次のようなものです。

• ライセンスを縮退させず二重コストになる：AWSへ移したのにVMware契約を丸ごと更新してしまい、削減どころか費用が増える。移行と縮退はセットで計画する
• オンプレ前提の設計をそのまま持ち込む：常時フルスペック起動のまま載せ替え、AWS利用料が想定より膨らむ。適正サイジングと停止運用、割引購入を前提にする
• ハードウェア依存の見落とし：専用機器に密結合した仮想マシンを無理にクラウド化し、運用が破綻する。棚卸し段階で依存を洗い出し、残すべきものはオンプレに残す
• 並行運用を省いて一発切り替え：検証不足のまま本番切り替えし、切り戻せずトラブルが長期化する。波分けと並行運用を守る
• 移行だけで満足し、運用体制を用意しない：移行後のAWS運用（監視・コスト管理・セキュリティ）の担い手を決めておらず、移行後に運用が回らない

これらの多くは、AWS移行一般の失敗パターンと共通します。より詳しい失敗事例とチェックリストは、次の記事にまとめています。

そのうえで、「自社リソースで移行するか、SIerに支援を頼むか」の判断です。目安は次のとおりです。

• 自社移行が向くケース：仮想マシン数が少なく、対象が可搬性の高いWebシステム中心で、社内にAWSの設計・運用経験者がいる
• 外注支援が向くケース：基幹システムを含む、依存関係が複雑、停止できる時間が限られる、社内にAWS移行の実績がない、コスト削減が目的なのに移行作業で本業が止まっては本末転倒になる

「値上げ対策のための移行なのに、移行の内製で情シスが疲弊してコストが下がった実感が持てない」という事態を避けるためにも、規模が大きい場合や知見が不足している場合は、設計・構築・並行運用の検証まで支援できるパートナーの活用が有効です。外注する場合の選び方や費用感は、外部委託の判断記事もあわせてご覧ください。

よくある質問

Q. VMwareからAWSへ移行すると、どのくらいコストが下がりますか？

ワークロードの構成と移行方式によって幅がありますが、判断の要点は「ライセンス費だけで比べない」ことです。VMwareのサブスクリプション費に加え、物理サーバーの更改費・電力・空調・ハイパーバイザーの運用工数まで含めた3〜5年のTCOで比較すると、削減効果が正しく見えます。特にマネージド化した領域は運用の人件費を継続的に削減します。逆に、オンプレのスペックをそのまま常時起動する前提だとAWS利用料が膨らむため、適正サイジングと割引購入を前提に試算してください。

Q. すべての仮想マシンをAWSへ移す必要がありますか？

いいえ。専用ハードウェアに密結合した仮想マシンや、低遅延が必須の制御系はオンプレに残し、汎用的な業務システムだけをAWSへ切り出すハイブリッド構成が現実解になることも多いです。値上げの影響が大きく、かつ移しやすいものから優先的に脱出するのが基本です。

Q. アプリを改修せずにVMwareからAWSへ移せますか？

多くの業務アプリは、EC2へのリホスト（載せ替え）方式であれば大きな改修なしに移行できます。まずリホストで脱VMwareを済ませ、更新頻度の高いアプリから段階的にコンテナ化やマネージド化を進める、という順序が安全です。

Q. ライセンス更新の期限が迫っていますが、間に合いますか？

対象システムの規模によります。更新までに全システムを移すのが難しい場合は、影響の小さいワークロードから第1波として移行し、残りを次のフェーズで移す波分けが有効です。どうしても時間が足りない場合の一時退避策としてVMware Cloud on AWSも選択肢になりますが、ライセンス費の根本解決にはならない点に注意してください。まずは現行構成の棚卸しから着手すると、現実的な移行計画が立てられます。

まとめ

Broadcom買収後のVMwareライセンス高騰への対応を、要点で振り返ります。

• 値上げはライセンス思想の転換であり、先送りしても負担は消えない。ライセンス更改とハード更改のタイミングは、仮想化基盤を見直す好機
• AWSへの移行先は、EC2へのリホスト・コンテナ化・マネージド化の3方式。システムごとに使い分けるのが定石
• 投資判断は、ライセンス費だけでなくハード・電力・運用工数まで含めた3〜5年のTCOで比較する
• 進め方は、棚卸し→方式の割り当て→AWS設計構築→並行運用→切り替えとVMware縮退の5ステップ。縮退まで含めて初めてコストが下がる
• 全部を一度に移さず、可搬性の高いものから波分けで進める。専用機器依存や制御系は無理に移さない
• 規模が大きい・社内に知見がない場合は、外注支援を活用して本業を止めずに移行する

VMwareの値上げは、単なるコスト問題ではなく、自社の仮想化基盤をあるべき姿に見直すきっかけにもなります。焦って更新を飲む前に、まず現行構成を棚卸しし、TCOで比較してみることをおすすめします。

---

c3index に相談する

c3index は、製造業の基幹システム・保守・クラウド移行を専門とするシステム会社です。AWSパートナーとして仮想化基盤の移行設計・構築・運用を数多く手がけており、VMwareからAWSへの移行によるライセンス費削減を、現行構成の棚卸しからTCO試算・設計構築・並行運用の検証・運用定着まで一貫してご支援します。「まず自社の基盤でどのくらいコストが下がるのか試算したい」という段階からのご相談も歓迎です。まずはお気軽にお問い合わせください。