AzureのSpot VMで開発・検証環境のコストを削減する方法｜eviction policyの設定とAWS Spot Instanceとの比較

Azure Spot VMとは？（通常VMとの違い）

Spot VMは、Azureのデータセンターで一時的に余剰となっているコンピューティングリソースを活用する仮想マシンです。余剰リソースを割安に提供する代わりに、Azureがリソースを必要とした時点でVMを強制排除（evict）する権利をAzureが持ちます。

通常VMとの違いをまとめます。

Spot VMが向いているのは「動いていなくても困らない、または再起動で復旧できる」ワークロードです。Webアプリの本番環境やDBサーバーのようなステートフルなワークロードには適しません。

具体的な活用例としては以下が代表的です。
・PRごとの一時的な検証環境：開発者が立ち上げてテストし、終わったら削除する使い捨て環境
・CIパイプラインのビルドエージェント：GitHubアクションやAzure PipelinesのセルフホストランナーをSpot VMで動かすとビルドコストを大幅に削減できる
・機械学習のバッチ学習ジョブ：チェックポイントを外部ストレージに保存しながら学習を進める設計にすれば、排除されても直前の状態から再開できる
・夜間バッチ処理：翌朝の集計処理など、多少の遅延が許容されるバッチに使うと通常VMより大幅にコストを削減できる

Spot VMの価格を確認する

作成前に、対象リージョン・VMサイズのSpot VMの現在価格を確認します。az vm list-skusとaz vm get-spot-placement-scoreが使えますが、価格確認にはaz vm list-sizesよりもAzure Portalの「スポット価格の表示」または価格APIが便利です。

azコマンドで現在のSpot価格履歴（価格は変動するため参考値）を確認するには、次のようにします。

# East Japanリージョンで Standard_B2s のSpot価格を確認する
az rest --method get   --url "https://prices.azure.com/api/retail/prices?api-version=2023-01-01-preview&\$filter=serviceName eq 'Virtual Machines' and armRegionName eq 'japaneast' and skuName eq 'B2s Spot'"   --query "Items[0].{retailPrice:retailPrice, unitOfMeasure:unitOfMeasure}"

# 出力例（価格はリアルタイムで変動）
{
  "retailPrice": 0.00944,
  "unitOfMeasure": "1 Hour"
}

Standard_B2s（2 vCPU・4 GiB RAM）の場合、通常価格が約0.0944ドル/時なのに対し、Spot価格は約0.00944ドル/時となっており、90%割引の水準です。月720時間で計算すると、通常VMが約68ドル/月のところSpot VMは約7ドル/月になります。

「どのリージョン・VMサイズでSpot VMが起動しやすいか」を数値で確認したい場合は、az vm get-spot-placement-scoreを使います。スコアが高いほど排除されにくいリージョン・サイズの組み合わせです。

# Standard_B2s と Standard_D2s_v5 のSpotプレイスメントスコアを確認する
az vm get-spot-placement-score   --location japaneast   --vm-sizes Standard_B2s Standard_D2s_v5   --availability-zones false   --desired-count 1   --output table

# 出力例（スコアは1低～5高の5段階）
Name              Score
----------------  -------
Standard_B2s      2
Standard_D2s_v5   4

スコア3以上を目安にVMサイズを選択すると、排除頻度を抑えやすくなります。Spot VMを初めて使う場合は、プレイスメントスコアの確認をVMサイズ選定の習慣にするとよいでしょう。

Spot VMを作成する手順

実際にazコマンドでSpot VMを作成します。基本的な手順は通常VMと同じで、--priority Spotオプションを追加するだけです。

1. リソースグループとVNetを準備する

Spot VMを配置するリソースグループとVNetを作成します。既に作成済みの場合はスキップしてください。

# リソースグループを作成する（Japaneastリージョン）
az group create   --name rg-spot-demo   --location japaneast

# VNetとサブネットを作成する
az network vnet create   --resource-group rg-spot-demo   --name vnet-spot-demo   --address-prefixes 10.2.0.0/16   --subnet-name snet-default   --subnet-prefixes 10.2.0.0/24

# 出力（抜粋）
{
  "newVNet": {
    "name": "vnet-spot-demo",
    "addressSpace": {"addressPrefixes": ["10.2.0.0/16"]},
    "subnets": [{"name": "snet-default", "addressPrefix": "10.2.0.0/24"}]
  }
}

2. Spot VMを作成する

--priority Spotと--eviction-policyを指定してVMを作成します。

# Spot VMを作成する（eviction policy: Deallocate）
az vm create   --resource-group rg-spot-demo   --name vm-spot-01   --image RedHat:RHEL:9-lvm:latest   --size Standard_B2s   --admin-username azureuser   --generate-ssh-keys   --priority Spot   --eviction-policy Deallocate   --max-price -1   --vnet-name vnet-spot-demo   --subnet snet-default   --public-ip-sku Standard

# 作成完了後の出力（抜粋）
{
  "powerState": "VM running",
  "publicIpAddress": "52.185.xxx.xxx",
  "privateIpAddress": "10.2.0.4",
  "resourceGroup": "rg-spot-demo",
  "id": "/subscriptions/xxxxxxxx/resourceGroups/rg-spot-demo/providers/Microsoft.Compute/virtualMachines/vm-spot-01"
}

主なオプションの意味をまとめます。
・--priority Spot：Spot VMとして作成する（省略すると通常VMになる）
・--eviction-policy Deallocate：排除時にVMを停止・割り当て解除する（次節で詳説）
・--max-price -1：-1はSpot価格の上限を設けない設定。通常価格まで許容する意味で排除されにくい
・--generate-ssh-keys：~/.ssh/id_rsa（秘密鍵）と id_rsa.pub（公開鍵）を自動生成する。既存の鍵がある場合はそのまま使われる

az vm createはデフォルトでSSH（22番ポート）を許可するNSG（ネットワークセキュリティグループ）を自動作成します。セキュリティポリシーに応じて、作成後に送信元IPを制限するルールを追加してください。

3. 作成したSpot VMの設定を確認する

VMの優先度とeviction policyが正しく設定されているか確認します。

# VMの詳細情報からSpot設定を確認する
az vm show   --resource-group rg-spot-demo   --name vm-spot-01   --query "{priority:priority, evictionPolicy:evictionPolicy, billingProfile:billingProfile}"   --output json

# 確認できる出力
{
  "priority": "Spot",
  "evictionPolicy": "Deallocate",
  "billingProfile": {
    "maxPrice": -1.0
  }
}

priorityがSpot、evictionPolicyがDeallocateになっていれば正しく設定されています。

SSH接続して動作を確認します。SSHポートが開いているかはLinux ポート確認の全コマンドも参照してください。

# PC側からSpot VMにSSH接続する
ssh -i ~/.ssh/id_rsa azureuser@52.185.xxx.xxx

# Spot VM上でホスト情報を確認する
[azureuser@vm-spot-01 ~]$ hostname
vm-spot-01

[azureuser@vm-spot-01 ~]$ cat /etc/redhat-release
Red Hat Enterprise Linux release 9.4 (Plow)

# VM上でazコマンドの動作を確認する（Managed Identity不使用の場合はスキップ）
[azureuser@vm-spot-01 ~]$ curl -s -H Metadata:true   "http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01" | python3 -m json.tool
{
  "DocumentIncarnation": 1,
  "Events": []
}

Eventsが空配列なら排除スケジュールはありません。排除予定がある場合はPreemptイベントが現れます（次節で詳説）。

eviction policy（削除ポリシー）の設定

Spot VMが強制排除される時の動作は、--eviction-policyで2種類から選べます。どちらを選ぶかによって、排除後のコストと復旧方法が変わります。

1. Deallocate（割り当て解除）とDelete（削除）の違い

Deallocateは個人の開発・検証環境でよく使います。排除されてもディスクとデータが残るため、Azureのキャパシティが回復した後にaz vm startで再起動して作業を続けられます。Standard_B2s（30GiBディスク）の場合、停止中のストレージ料金は約1.3ドル/月程度です。

Deleteはコストを最小化したい場合に有効です。ビルド完了後に自動削除されるCI/CDエージェントや、スクリプトで毎回新規作成するステートレス環境に向いています。ただし排除のたびにOSディスクも削除されるため、データは事前にAzure Blob StorageやAzure Filesに退避する設計が必要です。

2. max-price（最大価格）で排除頻度をコントロールする

--max-priceに金額（ドル/時）を指定することで、Spot価格がこの値を超えた時点でVMを排除させることができます。

・--max-price -1：価格上限なし。Spot価格がどれだけ上昇しても、Azureのキャパシティ不足時のみ排除される（最も排除されにくい）
・--max-price 0.05：Spot価格が0.05ドル/時を超えたら排除される（価格ベース排除）

開発・検証環境では--max-price -1の設定が一般的です。価格上限を設けると、混雑時に意図せずVMが停止するリスクが増します。価格ベースの排除を意図的に使うケースは、予算上限を厳守しなければならないCI/CDパイプラインなど「この価格以上で動かすくらいなら止めてよい」という明確な要件がある場合に限定するのが実務の判断です。

# max-priceをVM作成後に変更する場合（停止状態から変更可能）
az vm stop --resource-group rg-spot-demo --name vm-spot-01

az vm update   --resource-group rg-spot-demo   --name vm-spot-01   --max-price 0.05

az vm start --resource-group rg-spot-demo --name vm-spot-01

3. Scheduled Events APIで排除予告を検知する

Azureは排除の30秒前に、VMのメタデータサービス（169.254.169.254）経由でイベントを通知します。VMの内部からポーリングして、排除前にデータを保存する仕組みを実装できます。

# VM内部からScheduled Eventsをポーリングするスクリプト例
# /usr/local/bin/spot-drain.sh として保存する

#!/bin/bash
METADATA_URL="http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01"

while true; do
  EVENTS=$(curl -s -H "Metadata:true" "${METADATA_URL}" | python3 -c "
import sys, json
data = json.load(sys.stdin)
events = data.get('Events', [])
preempt = [e for e in events if e.get('EventType') == 'Preempt']
print(len(preempt))
")
  if [ "${EVENTS}" -gt 0 ]; then
    echo "[$(date)] Preempt event detected. Starting drain..."
    # ここにデータ保存・ジョブ停止の処理を記述する
    sync
    break
  fi
  sleep 5
done

このスクリプトをsystemdサービスとして常駐させておくと、排除直前にデータを同期したりジョブを安全に終了させたりできます。

重要なのは「30秒以内に完了できる処理しか書かない」点です。DBのチェックポイントやrsyncによる大量ファイル同期など30秒以上かかる処理はドレインスクリプトに頼らず、定期バックアップで担保するのが現実的な設計です。

AWS Spot InstanceとAzure Spot VMの比較

AWSのSpot Instanceを使い慣れているLinuxエンジニアがAzureに移行する際に、最も混乱しやすいのが排除の仕組みの違いです。主な差異を比較します。

最も注意すべき違いは通知時間です。AWSは2分前に通知するため、ある程度の猶予があります。AzureのSpot VMは30秒前通知なので、シャットダウン処理に2分以上かかる処理（DBのチェックポイント等）は間に合いません。Spot VMを本格活用するなら、30秒以内に完了できる軽量なドレイン処理のみを実装し、それ以上のデータ保護は事前に定期バックアップで対処するのが現実的です。

もう一つの特徴はAzureのDeallocateポリシーです。AWSのSpot Instanceには排除=削除（terminate）またはhibernateのみで、Deallocate相当の動作はありません。Azureの場合、DeallocateポリシーであればOSディスクが残るため、排除後に別のVMサイズで再起動するなど柔軟な対処が取りやすい点が特徴です。

Spot VMが強制排除された後の対処

Spot VMが排除されると、eviction policyに応じてVMの状態が変わります。

1. Deallocate後の再起動手順

eviction policyがDeallocateの場合、VMは停止・割り当て解除状態になります。Azureのキャパシティが回復すれば再起動できます。

# VMの現在の状態を確認する
az vm show   --resource-group rg-spot-demo   --name vm-spot-01   --show-details   --query "{powerState:powerState, provisioningState:provisioningState}"

# 排除後の状態（割り当て解除）
{
  "powerState": "VM deallocated",
  "provisioningState": "Succeeded"
}

# VMを再起動する（キャパシティが空いていれば起動する）
az vm start   --resource-group rg-spot-demo   --name vm-spot-01

キャパシティが逼迫したリージョン・VMサイズではaz vm startがエラーになる場合があります。その場合は別のサイズへ変更してから再起動します。

# VMサイズを変更する（停止中のVM）
az vm resize   --resource-group rg-spot-demo   --name vm-spot-01   --size Standard_D2s_v5

# サイズ変更後に再起動する
az vm start   --resource-group rg-spot-demo   --name vm-spot-01

2. Spot VMのeviction履歴を確認する

VMがいつ排除されたかは、Activity Logから確認できます。

# Activity LogからSpot VMのevictionイベントを確認する
az monitor activity-log list   --resource-group rg-spot-demo   --start-time "2026-07-01"   --query "[?operationName.value=='Microsoft.Compute/virtualMachines/deallocate/action'].{time:eventTimestamp, status:status.value}"   --output table

# 出力例
Time                          Status
----------------------------  ---------
2026-07-25T04:17:32.141983Z   Succeeded

実務Tips（Spot VM活用のベストプラクティス）

現場でSpot VMを安全に活用するためのポイントをまとめます。

・ステートレス設計を徹底する：OSディスクにデータを持たせない。アプリケーションの作業データはAzure Blob StorageやAzure Filesに書き出す設計にする
・VMSSのSpotモードを使う：スケールセット（VMSS）でもSpot VMを使える。複数VMを管理する場合はVMSSの--priority Spotで一括管理する方が効率的。VMSSは排除時に自動で別サイズへフォールバックする設定も組み合わせられる
・複数VMサイズを許容する：特定のVMサイズに固執するとキャパシティ不足で起動できない時間が増える。同等スペックの複数サイズを候補にすると起動率が上がる
・夜間・週末はDealloc：検証環境は業務時間外に手動またはAzure Automationで停止しておくと、Spot割引と組み合わせてさらにコスト削減できる。Azure Automation + Runbookでスケジュール停止・起動を自動化するのが実務でよく使う構成
・タグで本番とSpotを区別する：az vm create --tags env=spotのようにタグを付けておくと、コスト分析やAutomation処理で通常VMと区別しやすい
・az vm get-spot-placement-scoreで事前確認する：VMサイズを選ぶ前に配置スコアを確認し、スコア3以上のサイズを優先することで排除頻度を抑えられる

トラブルシュート（Spot VMが起動しない・排除が多い時）

1. SkuNotAvailable（サイズが利用不可）エラー

「The requested VM size is not available in the current region.」というエラーが出る場合、対象リージョン・VMサイズのSpotキャパシティが枯渇しています。

# japaneastでSpot VMとして使えるVMサイズを確認する
az vm list-skus   --location japaneast   --size Standard_B   --all   --query "[?restrictions[?type=='Zone' || type=='Location'] | length(@) == \`0\`].name"   --output tsv | head -10

# 出力例（Spotで利用可能なBシリーズ）
Standard_B1ls
Standard_B1ms
Standard_B1s
Standard_B2ms
Standard_B2s
Standard_B4ms

制限（restrictions）が空のサイズはSpot VMとして利用可能です。エラーが出たら別のサイズ（例：Standard_B2s → Standard_B2ms）に切り替えます。

2. 排除頻度が高い場合

特定のVMサイズで排除が頻発する場合、そのサイズのSpot需要が高い状態です。次の対策を試します。
・VMサイズを変更する：Dシリーズ、Eシリーズなど汎用性の高いサイズは競合が少ない場合がある
・リージョンを変更する：JapanEast → JapanWest など、同一データセンター圏内の別リージョンを試す
・max-priceを上げる：価格ベースの排除が発生している場合は上限を引き上げるか、-1（上限なし）に設定する
・az vm get-spot-placement-scoreで代替サイズを探す：スコアの高いサイズへ変更すると排除頻度が下がることが多い

3. VMが起動直後に排除される

作成直後にすぐ排除される場合はキャパシティ不足が深刻な状態です。az vm get-instance-viewのステータスで確認します。

# VMのインスタンスビューで詳細ステータスを確認する
az vm get-instance-view   --resource-group rg-spot-demo   --name vm-spot-01   --query "instanceView.statuses[].displayStatus"   --output tsv

# 通常稼働中の出力
Provisioning succeeded
VM running

# 排除後の出力
Provisioning succeeded
VM deallocated

起動直後に排除が繰り返される場合、そのリージョン・VMサイズは慢性的なキャパシティ不足の状態です。az vm get-spot-placement-scoreでスコアを確認し、スコアが1や2のサイズは避けて別のサイズやリージョンへ切り替えてください。

本記事のまとめ

Azure Spot VMでコストを削減するための主要な操作をまとめます。

Azure Spot VMはaz vm createに--priority Spotを追加するだけで、通常VMと同じ操作で最大90%割引のコンピューティングリソースを使えます。eviction policyをDeallocateにすれば排除後もデータが残り、Deleteにすれば完全ステートレス運用でコストをゼロに近づけられます。

AWSのSpot Instanceに慣れているエンジニアは「30秒通知」のスピード感に注意して、Spot VMの排除に備えた設計（データの外部化・ドレイン処理の簡素化）を事前に組み込むことが実務での安定運用につながります。開発・検証環境のコスト削減から始めて、ステートレスなCI/CDエージェントへの展開と段階的に活用範囲を広げていくのがおすすめです。

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

無料マニュアルを受け取る

姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら

この記事を書いた人

宮崎 智広（みやざき ともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

• 次のページへ：AzureのFirewallでVNet通信を一元管理する方法｜NSGとの役割分担とポリシールール設定の実践
• 前のページへ：AzureのNAT GatewayでLinux VMのアウトバウンドIPを固定する方法｜az network nat gateway createとSNATポート管理の実践
• この記事の属するカテゴリ：Azureへ戻る