結論：メモリだけを見てホスト数を減らしてはいけない
AWSは2026年8月21日、Amazon Elastic VMware Service（Amazon EVS）でVMware Cloud Foundation（VCF）9.1のMemory Tieringを有効化する構成を公開しました。頻繁に使うメモリページをDRAM、低頻度のページをローカルNVMeへ置き、メモリ容量がボトルネックのクラスタで密度を高める考え方です。
しかし、これは「VMware移行費用が必ず下がる機能」ではありません。NVMeはvSANのデータストアにも使われます。Memory Tieringへ割り当てるほどストレージ容量が減り、アクセス頻度、vMotion、DRS、障害時の余力によっては性能影響も出ます。
この記事を読むべきなのは、オンプレミスのVMware/VCFを運用し、更新、クラウド移行、脱VMwareを検討している売上10億〜100億円規模の経営者、CIO、情シス責任者、インフラ責任者です。移行会社の「ホスト数を減らせます」という提案に対し、TCO試算の前提を確認できる状態を作ります。
RETAIL & EC DX
実店舗とECの在庫分断、1本のOMSで解消しませんか？
POS／自社EC／モールを統合するオムニチャネル基幹。同規模小売・D2Cの概算費用・導入期間・事例をその場で確認できます。
公式発表から確認できる範囲
横にスクロールして確認できます
| 項目 | AWS公式記事の内容 | 判断時の注意 |
|---|---|---|
| 対象 | Amazon EVS上のVCF 9.0/9.1。記事の有効化手順はVCF 9.1 | すべてのVMware環境やクラウドに当てはまらない |
| 対応ホスト | 記事公開時点でi4i.metal、i7i.metal-24xl | 将来の対応、リージョン、価格は導入時に再確認 |
| 階層 | Tier 0はDRAM、Tier 1はローカルNVMe | NVMeはDRAMより遅く、性能差がある |
| 動作 | ホットページをDRAM、コールドページをNVMeへ配置 | ワークロードのアクティブメモリ特性で効果が変わる |
| 開始目安 | メモリ消費が約80%に達するとコールドページの移動を開始 | 常時高負荷で性能要件が厳しい環境は要検証 |
| 容量例 | 1:1の構成では有効メモリ容量を増やせる設計例 | ワークロード数や性能が一律2倍になる意味ではない |
| 競合資源 | Tier 1がローカルNVMeを使うため、vSAN容量から差し引かれる | メモリ最適化とストレージ不足を同時に起こし得る |
| 運用影響 | vMotionやDRSに時間がかかる可能性 | 保守時間、障害復旧、退避時間に反映する |
公式記事は、アクティブメモリをDRAMのおおむね50%未満に保つ設計上の目安も示しています。これは、消費メモリが多いことと、常に使われるメモリが多いことを分けて測る必要がある、という意味です。
「メモリ使用率が高い」だけでは採用判断できない
Memory Tieringが候補になりやすいのは、CPUやストレージではなく、メモリ容量の都合でホストを追加している環境です。一方、次の状態では単純な削減は危険です。
- データベースやインメモリ処理で、割り当てメモリの大半が常時アクティブ
- vSANの空き容量が少なく、NVMeをメモリ階層へ回せない
- 障害時に1台分を退避できる余力がない
- バッチや月末処理でアクティブメモリが急増する
- vMotionの完了時間に厳しい保守条件がある
- 現行の性能指標がなく、移行後の劣化を判定できない
経営会議で見るべきなのは平均使用率だけではありません。平常時、月末、障害時の三つについて、CPU、消費メモリ、アクティブメモリ、ストレージ使用量、IOPS、遅延を並べます。
採用可否を決める8項目スコアカード
各項目を0〜2点で採点します。0点は不適合または未計測、1点は要検証、2点は条件が明確です。
横にスクロールして確認できます
| 評価軸 | 0点 | 1点 | 2点 |
|---|---|---|---|
| ボトルネック | 不明／CPU・I/Oが先 | 複数資源が逼迫 | メモリ容量が主因と計測済み |
| アクティブメモリ | 未計測／DRAM比が高い | ピーク時に高い | 平常・ピークとも余力あり |
| vSAN余力 | 空き・冗長性が不足 | Tier 1後の余力が小さい | 障害時を含む余力あり |
| 性能基準 | 現行値なし | 一部のみ計測 | 遅延・IOPS・処理時間を計測済み |
| ピーク特性 | 月末・バッチが不明 | 一時的に急増 | 12カ月または代表期間を把握 |
| 可用性 | 退避・再同期が未検証 | 手順のみ | 障害・保守試験済み |
| 費用比較 | ホスト料金だけ | 一部運用費を含む | 3年TCOと移行・撤退費を含む |
| 代替案 | 比較なし | 現状維持と比較 | 右移行・再構築・他クラウドも比較 |
0〜6点なら、製品選定前の資産棚卸しが必要です。7〜11点なら、本番相当の負荷で検証し、削減台数を確定させない見積りにします。12〜16点なら候補ですが、vSAN、障害時余力、移行後の測定を契約条件へ入れてください。
TCO試算へ含める費目
横にスクロールして確認できます
| 費目 | 確認する内容 |
|---|---|
| ホスト | 台数、最低クラスタ数、予備、増減単位 |
| VMware | VCF/関連ライセンス、サポート、更新条件 |
| ストレージ | Tier 1へ回すNVMe、vSAN容量、外部ストレージ、バックアップ |
| ネットワーク | 接続、転送、冗長化、監視 |
| 移行 | 調査、テスト、停止、データ同期、切り戻し |
| 運用 | 監視、パッチ、障害、性能改善、月次報告 |
| DR | 別拠点・別リージョン、復旧試験、保管 |
| 撤退 | 他基盤へ出すデータ、構成変換、契約終了時の費用 |
ホスト数が減っても、ストレージ、ライセンス、移行、運用が増えれば総額は下がりません。逆に、ホスト削減が小さくても、更新期限までに安全に移行し、運用を標準化できれば、事業上の価値が出る場合があります。
3案を同じ条件で比較する
VMware移行では、最初からAmazon EVSだけを前提にしないことが重要です。
横にスクロールして確認できます
| 案 | 向いている状況 | 主なリスク |
|---|---|---|
| 現行更新 | アプリ変更を避ける必要があり、契約条件が許容できる | 延命費用、将来の再移行 |
| VMware互換クラウドへ移行 | 短期間で移し、運用手順を維持したい | クラウド固有条件、ライセンス、退出費用 |
| 再ホスト／再構築 | 中長期でVMware依存を減らし、クラウド機能を使いたい | 初期の改修、テスト、業務影響 |
Memory Tieringは二つ目の案のTCOを変える一要素です。レガシー刷新の目的が、単なる設備更新なのか、運用人材不足の解消なのか、アプリ改修なのかで選択は変わります。
ベンダーへ確認する10の質問
- 現行環境で、メモリ容量がホスト追加の主因だと示す計測値は何か
- 消費メモリとアクティブメモリを、平常・ピークでどう測ったか
- Memory Tieringへ割り当てるNVMe容量と、減少するvSAN容量はいくらか
- 1台故障時もストレージとメモリに余力があるか
- データベース、VDI、バッチごとの性能試験条件は何か
- vMotion、DRS、再同期、保守時間の許容値は何か
- 削減可能なホスト数は保証値か、試算値か。前提が外れた際の追加費用は誰が負担するか
- 3年TCOにライセンス、接続、バックアップ、運用、退出費用を含めたか
- 機能を無効化する条件と切り戻し手順はあるか
- 現状更新、別クラウド、再構築と同じ条件で比較したか
回答を議事録ではなく、計測期間、計算式、除外条件付きの資料として受け取ってください。
90日で行う移行判断
横にスクロールして確認できます
| 期間 | やること | 成果物 |
|---|---|---|
| 1〜2週 | VM、CPU、メモリ、ストレージ、契約、保守期限を棚卸し | 資産台帳、期限表 |
| 3〜4週 | 平常・ピーク・障害時の性能を計測 | ベースライン、ボトルネック判定 |
| 5〜6週 | 3案を同一条件で試算 | 3年TCO、リスク比較 |
| 7〜10週 | 候補構成を本番相当負荷で検証 | 性能、vSAN余力、復旧試験 |
| 11〜12週 | 採用、条件付き採用、見送りを判断 | 稟議資料、移行計画、切り戻し条件 |
ホスト数を先に決めず、計測結果から段階的に決めることが、追加費用と性能問題を避けます。
GXOの支援と商談へのつながり
この記事の8項目で自己点検
↓
VMware・オンプレ資産棚卸し
↓
現状更新／互換クラウド／再構築のTCO比較
↓
本番相当の性能・復旧PoC
↓
AWS／Azure移行・レガシー刷新
入口を有償の資産棚卸し・TCOセカンドオピニオンにすることで、大規模な移行見積りを無償で作り込むリスクを減らせます。計測に基づいて適合案件を選び、移行設計、実装、運用へ進めるため、受注後の追加作業を抑えて粗利を守れます。
VMware移行のホスト数とTCOを第三者視点で確認しませんか
利用率、アクティブメモリ、vSAN余力、ライセンス、保守期限を確認し、現状更新・クラウド移行・再構築の比較条件を整理します。
FAQ
Memory Tieringでワークロードを2倍にできますか
一律には言えません。1:1構成で有効メモリ容量を増やす設計例はありますが、CPU、アクティブメモリ、NVMe性能、vSAN容量、可用性が制約になります。容量が増えることと、性能を保ったままVM数を2倍にできることは別です。
メモリ使用率が80%なら適していますか
使用率だけでは判断できません。コールドページの移動開始目安とされる水準ですが、消費メモリとアクティブメモリを分け、ピーク時のアクセス頻度と遅延を測る必要があります。
VMwareをそのままクラウドへ移すべきですか
更新期限や業務停止の許容度によります。短期の右移行が合理的な場合もありますが、中長期のライセンス、運用、退出費用を含め、再ホスト・再構築と比較してください。
最初に用意する資料は何ですか
VM一覧、12カ月程度のCPU・メモリ・ストレージ実績、ネットワーク構成、バックアップ・DR、ライセンスと保守期限、障害・月末処理の記録があると判断が速くなります。
関連記事・サービス
参考情報
- AWS: Increase your cluster density with Memory Tiering in Amazon Elastic VMware Service（2026年8月21日、一次情報）
本記事は2026年8月23日時点の公開情報を基にしています。対応するVCF・インスタンス、利用可能なリージョン、料金、性能上の推奨値は変更される可能性があります。実際の採用判断では、AWSとVMwareの最新公式文書、契約条件、本番相当の計測結果を再確認してください。
