Azure Spot VMs実践入門｜VM料金を最大90%削減するバッチ処理と開発環境への適用ガイド

「Azureのクラウドコストが思ったより高い。どこから削れるのかわからない」——バッチ処理やCI/CDジョブ、開発環境を通常価格のVMでまとめて動かしているなら、確実に料金を払いすぎている可能性がある。

Azure Spot VMsは、Azureが余剰コンピューティング容量を最大90%割引で提供する課金モデルだ（2026年9月時点）。ただし需要が増えたとき、Azureが2分前通知でVMを停止（割り込み）できる、という条件付きの価格だ。

この記事では、Azure Spot VMsの仕組みと料金体系を整理し、バッチ処理・開発環境への具体的な適用パターンと、割り込みに備えた設計を実務視点で解説する。

Azure Spot VMsとは何か

クラウドプロバイダーは、データセンター全体のVM需要が最大値に達することはほとんどないため、常に余剰の物理サーバー容量を抱えている。Azureはその余剰容量を割引価格でユーザーに解放する仕組みがSpot VMsだ。

オンプレミスに例えると、「社内の検証機が使われていない時間帯だけ借りられる」に近い。ただしクラウドのSpotは規模が桁違いで、数百台規模での一時確保も可能だ。

AWSのスポットインスタンスと概念は同じだが、AzureではEviction Policyの設定方法と通知の仕組みに独自の特徴がある。AWSスポットインスタンス入門も合わせて読むと、両クラウドの違いが見えてくる。

割り込み（Eviction）の仕組みを理解する

1. Eviction Policyの2択

Spot VMを作成する際、割り込み時のVMの動作を2種類から選ぶ。

・Deallocate（停止・割り当て解除）: VMが停止状態になり、ディスクとIPは保持される。割り込み後に再起動して処理を再開できる。停止中もディスク料金は発生し続ける点に注意が必要だ。
・Delete（削除）: VMとディスクが完全に削除され、ディスク料金も止まる。処理データを外部ストレージ（Azure Blob Storage・NFSマウント等）に書き出す設計であれば、こちらが適している。

2. 2分前通知（Scheduled Events）

Azureは割り込みの2分前に、VMのメタデータサービス（IMDS）を通じてScheduled Eventsを通知する。アプリケーション側でこのイベントを定期ポーリングし、チェックポイントの書き出しや処理中断を実装することで、割り込み後の再実行コストを最小化できる。

# メタデータエンドポイントでScheduled Eventsを確認する（Linux VM内から実行）
curl -s -H Metadata:true \
  "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01" \
  | python3 -m json.tool

# レスポンス例（EventType が Preempt なら割り込み予告）
# {
#   "Events": [
#     {
#       "EventId": "...",
#       "EventType": "Preempt",
#       "ResourceType": "VirtualMachine",
#       "NotBefore": "2026-09-06 10:00:00Z"
#     }
#   ]
# }

EventType が Preempt になっていれば割り込み予告のサインだ。ワーカープロセスにこのポーリングを組み込んでおくと、割り込み前にグレースフルシャットダウンができる。

3. 上限価格（Max Price）の設定

Spot VMには、支払う最大価格（USD/時間）を設定できる。現在のスポット価格が上限価格を超えた場合も割り込みが発生する。上限価格を -1（デフォルト）に設定すると、価格による割り込みは発生しない（容量不足による割り込みのみ）。

バッチ処理用途では基本的に -1 のままで問題ない。「いかなる場合でも通常価格を超えて支払いたくない」という場合のみ、上限価格を明示的に設定する。

向くワークロード・向かないワークロード

本番サービスのベースラインはオンデマンドVMやReserved VMで確保しつつ、スケールアウト分をSpot VMで賄う「ハイブリッド構成」もある。Azure Virtual Machine Scale Sets（VMSS）のMixed Instances PolicyでSpot VMと通常VMを混在させると、最低台数のSLAを維持しながらコストを下げられる。

料金の仕組みとコスト試算

1. Spot VMの価格はリアルタイムで変動する

Spot VMの価格は、リージョン・VMサイズ・その時点の需要によってリアルタイムに変動する。Azureポータルの「Spot Eviction Rate」列では、過去の割り込み率の目安が確認できる（0～5%・5～10%・10～20%のような帯域表示）。割り込み率が低いリージョン・VMサイズを選ぶことで、より安定した運用ができる。

2. 削減率の概算例

例として、Standard_D4s_v5（4 vCPU・16 GB）を東日本リージョンで使う場合の概算（2026年9月時点）：

・オンデマンド: 約$0.276/時間
・Spot VM（割り込み率5%帯の相場）: $0.03～$0.08/時間程度
・削減率の目安: 約70～89%

上記はあくまで概算であり、実際の料金はAzureポータルの最新料金ページで確認すること。

Spot VMと組み合わせて検討したい購入オプションとして、常時稼働が必要なワークロードにはAzure Reserved VM Instancesで年間コストを最大72%削減する方法もある。両者を役割に応じて使い分けることで、トータルのクラウド料金を大幅に圧縮できる。

Spot VMの作成手順（Azure CLI）

1. Spot VMの作成コマンド

# Azure CLI: Spot VMの作成例（Ubuntu 22.04）
az vm create \
  --resource-group myResourceGroup \
  --name mySpotVM \
  --image Ubuntu2204 \
  --size Standard_D4s_v5 \
  --priority Spot \
  --eviction-policy Deallocate \
  --max-price -1 \
  --vnet-name myVNet \
  --subnet mySubnet \
  --admin-username azureuser \
  --generate-ssh-keys

3つのパラメーターが肝だ。--priority Spot でSpot VMとして作成し、--eviction-policy でDeallocateかDeleteを選ぶ。--max-price -1 は価格による割り込みを無効にする設定だ。

2. 割り込みシミュレーション（動作確認）

# Spot VMの割り込みをシミュレートする（本番適用前の動作確認用）
az vm simulate-eviction \
  --resource-group myResourceGroup \
  --name mySpotVM

このコマンドで割り込みイベントをシミュレートできる。Scheduled Eventsのポーリング実装が正しく動くか、本番環境への適用前に必ずテストすること。

3. 既存VMをSpotに変更できないことに注意

通常のVMをSpot VMにインプレースで変更することはできない。Spot VMとして使いたい場合は、最初からSpot VMとして作成する必要がある。既存の通常VMを置き換える場合は、VMを削除してSpot VMとして再作成する手順になる。

バッチ処理・開発環境への適用パターン

1. バッチ処理の設計パターン

バッチ処理にSpot VMを使う際の安定運用ポイントは次の3点だ。

・チェックポイントの定期書き出し: 処理の区切りごとに進捗をAzure Blob StorageやAzure Queue Storageへ書き出す。割り込み後に再起動したVMが続きから処理を再開できる。
・冪等な処理設計: 同じデータを2回処理しても結果が変わらない（重複しない）設計にする。再試行で同一データが2回処理されるリスクを排除するためだ。
・ジョブキューの活用: Azure Queue StorageやAzure Service Busでタスクを管理し、VM起動時にキューからタスクを取得する構成にすると、VM台数のスケールアウトにも自然に対応できる。

2. 開発・テスト環境での活用

開発環境へのSpot VM適用には、Eviction PolicyをDeallocate（停止・割り当て解除）にするのがポイントだ。割り込みが発生してもディスク（OSやインストール済みパッケージ）は保持されるため、翌朝ポータルから再起動するだけで作業を再開できる。

注意点として、停止（Deallocated）状態でもディスク料金は発生し続ける。週末など長期間使わない場合は、スナップショットを取ってディスクを削除するか、VMごと削除して必要なときに再作成する運用の方がコスト効率がよい。

3. VMSSとのSpot混在構成

大規模なバッチ処理や、スケーラブルなCI/CD基盤では、VMSSのSpotインスタンスプールを使うと複数台のSpot VMをまとめて管理できる。VMSSはSpot VMが割り込みで停止したとき、別の容量がある場所で補完しようとするため、単体VMよりも安定した処理を維持しやすい。

よくあるトラブルと対処法

【注意1】容量不足でSpot VMが起動できない

Spot VMは余剰容量を使うため、特定のリージョン・VMサイズが需要ピーク時に枯渇して作成が失敗することがある。

・複数のVMサイズに対応できるよう、ワークロードを特定サイズに依存させない
・東日本リージョン（japaneast）で取れない場合は西日本（japanwest）で試す
・Azureポータルの割り込み率表示で、低い帯域のサイズを優先して選ぶ

【注意2】Deallocate後のパブリックIP変更

パブリックIPにBasic SKUを使っている場合、停止・割り当て解除（Deallocated）状態のVMは再起動時にパブリックIPが変わることがある。Static設定のStandard SKUパブリックIPを使うか、プライベートIPとAzure Private DNSゾーンで内部からアクセスする構成にすることで回避できる。

【注意3】コスト可視化の設定を忘れずに

Spot VMのコストは通常VMと同じリソースグループに混在するため、Azure Cost Managementでフィルタリングしないと全体像が見えにくい。VMPriority: Spot のようなタグをリソースに付けておくと、Spot VMだけのコストを分離して把握できる。

本記事のまとめ

Azure Spot VMsは、「止まっても再試行できる」ワークロードに絞って使えば、VMコストを最大90%削減できる強力な手段だ。活用のポイントを整理する。

・バッチ処理・ETL・エンコード: チェックポイント設計を整えてSpot VMを積極的に使う
・開発・テスト環境: Eviction Policy = Deallocateでディスクをキープしつつコストを削減する
・本番Webサービス・DB: Spot VMは使わず、Reserved VMやオンデマンドVMでSLAを確保する
・大規模バッチ: VMSSのSpotプールで複数台を管理し、割り込み復元力を高める
・Scheduled Eventsのポーリング: 2分前通知を活用したグレースフルシャットダウンをアプリに実装する

オンデマンド・Reserved・Spotのどれが向くかを体系的に整理したい場合は、クラウドの購入モデル完全比較も参考にしてほしい。また、FinOpsの観点でクラウドコスト全体を管理する方法については、FinOps実践入門で詳しく解説している。