AWSスポットインスタンス入門 EC2料金を最大90%削減する実践活用ガイド

「EC2の月額料金が高すぎる。開発環境やバッチ処理にオンデマンド料金を払い続けるのはもったいない」――クラウド移行後、多くのインフラエンジニアがこの壁にぶつかる。この記事では、EC2料金を最大90%削減できるスポットインスタンスの仕組みから実践的な使い方、中断対策まで体系的に解説する。

なぜスポットインスタンスなのか――オンプレにはなかった「余剰キャパシティ」という考え方

オンプレミスの世界では、サーバーリソースは「買い切り」だった。ラックに載せた物理サーバーは常時稼働し、余剰があっても他者に貸し出すことはない。AWSのスポットインスタンスは、この前提をひっくり返す仕組みだ。

AWSのデータセンターには、リザーブドインスタンスやオンデマンドインスタンスに割り当てられていない「余剰キャパシティ」が常に存在する。スポットインスタンスは、この余剰分を大幅な割引価格で利用できるサービスだ。割引率はインスタンスタイプやリージョン、時間帯によって変動するが、オンデマンド料金と比較して最大90%安くなるケースもある。

ただし、AWSがそのキャパシティを必要とした場合、2分前の通知で中断（回収）される可能性がある。この「中断リスク」がスポットインスタンスの最大の特徴であり、使い方を選ぶ理由でもある。

オンプレ経験者にとって近い概念を挙げるなら、データセンターの「空きラック」を格安で間借りするイメージだ。ただし、正規の入居者が来たら退去しなければならない。この制約を理解した上で使えば、クラウドのコスト最適化において非常に強力な武器になる。

スポットインスタンスの仕組み

スポットインスタンスの動作を正確に理解するために、主要な概念を整理する。

スポット料金の決まり方

スポット料金は、インスタンスタイプとアベイラビリティゾーン（AZ）の組み合わせごとに、需要と供給のバランスで自動的に決まる。以前は入札方式だったが、2017年以降は緩やかな変動制に移行しており、急激な価格変動は少なくなった。

現在のスポット料金はAWSマネジメントコンソールの「スポットインスタンスの料金履歴」から確認できる。

中断の仕組み（2分前通知）

AWSがスポットインスタンスの回収を決定すると、インスタンスメタデータとAmazon EventBridgeを通じて2分前に通知が届く。この2分間で、アプリケーションのグレースフルシャットダウンやチェックポイントの保存といった処理を実行できる。

中断時の動作は、起動時に以下の3つから選択する。

・terminate（終了）: インスタンスを完全に終了する。EBSボリュームは設定次第で削除
・stop（停止）: インスタンスを停止状態にする。EBSバックドインスタンスのみ選択可能
・hibernate（休止）: メモリ内容をEBSに保存して休止する。再開時にメモリ状態が復元される

スポット配置スコア

スポット配置スコア（Spot placement score）は、特定のインスタンスタイプと容量の組み合わせが、各リージョン・AZでどの程度確保しやすいかを1〜10のスコアで示す機能だ。スコアが高いほど中断リスクが低い。本番ワークロードでスポットを使う際は、このスコアを事前に確認しておくと安心だ。

基本的な使い方

1. マネジメントコンソールからの起動

EC2のインスタンス起動画面で、購入オプションを変更するだけでスポットインスタンスを起動できる。

手順は以下の通りだ。

1. EC2コンソールで「インスタンスを起動」をクリック
2. AMI、インスタンスタイプを選択
3. 「高度な詳細」セクションを展開
4. 「購入オプション」で「スポットインスタンスをリクエスト」にチェックを入れる
5. 中断時の動作（terminate/stop/hibernate）を選択
6. 最大料金（オプション）を設定する場合は入力
7. その他の設定を確認し「インスタンスを起動」をクリック

最大料金を設定すると、スポット料金がその金額を超えた場合にインスタンスが中断される。設定しなければ、オンデマンド料金が上限として適用される。

2. AWS CLIからの起動

AWS CLIを使えば、スクリプトや自動化パイプラインに組み込める。

# AWS CLI: スポットインスタンスのリクエスト
aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type m5.large \
  --instance-market-options '{"MarketType":"spot","SpotOptions":{"SpotInstanceType":"one-time","InstanceInterruptionBehavior":"terminate"}}' \
  --key-name my-key-pair \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0

run-instancesコマンドに--instance-market-optionsを追加するだけで、通常のEC2起動とほぼ同じ操作感でスポットインスタンスを起動できる。

3. 現在のスポット料金を確認する

起動前にスポット料金を確認しておくと、コスト感覚をつかみやすい。

# AWS CLI: 東京リージョンのm5.largeスポット料金履歴を確認
aws ec2 describe-spot-price-history \
  --instance-types m5.large \
  --product-descriptions "Linux/UNIX" \
  --region ap-northeast-1 \
  --start-time $(date -u +%Y-%m-%dT%H:%M:%SZ)

料金の仕組み――コスト感覚をつかむ

スポットインスタンスの料金感覚を、具体例で見てみよう。以下は東京リージョン（ap-northeast-1）での代表的なインスタンスタイプの料金比較だ（2026年4月時点）。

※スポット料金は需要と供給で変動するため、上記は参考値。最新の料金はAWSコンソールの「スポットインスタンスの料金履歴」で確認できる。

月間コストの差は大きい。例えば、m5.largeを24時間×30日稼働した場合を比較すると、オンデマンドで約$89.28/月、スポットなら約$28.80/月だ。年間に換算すると約$725の差額になる。開発環境で10台動かしていれば、年間$7,250の削減だ。

リザーブドインスタンス・Savings Plansとの使い分け

コスト削減の手段はスポットインスタンスだけではない。リザーブドインスタンスやSavings Plansとの使い分けを簡潔にまとめる。詳しくは「EC2コスト削減 リザーブドインスタンスとSavings Plansの違いと選び方」を参照してほしい。

・リザーブドインスタンス / Savings Plans: 1年〜3年の利用コミット。常時稼働するワークロード向け。割引率は最大72%程度
・スポットインスタンス: コミット不要。中断を許容できるワークロード向け。割引率は最大90%
・オンデマンド: コミットなし・中断なし。柔軟性が最も高いが料金も最高

実務では「ベースラインはリザーブド/Savings Plans + ピーク分はスポット + 予備はオンデマンド」という組み合わせが定番だ。

応用・実務Tips

中断対策の基本パターン

スポットインスタンスを実務で使う際、中断対策は必須だ。以下のパターンを組み合わせて対応する。

1. 中断通知の監視

インスタンスメタデータのエンドポイントをポーリングして、中断通知を検出する。

# インスタンス内部から中断通知を確認（HTTPレスポンスコードで判定）
TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/spot/instance-action

通知がない場合は404、中断が予定されている場合はJSON形式のレスポンスが返る。これをcronやデーモンで定期チェックし、検出時にグレースフルシャットダウンスクリプトを実行する設計が一般的だ。

2. Amazon EventBridgeとの連携

EC2 Spot Instance Interruptionイベントを、Amazon EventBridge（旧CloudWatch Events）でキャッチし、AWS LambdaやAmazon SNSに通知を飛ばす方法もある。チーム全体に中断状況を共有したい場合に有効だ。

3. チェックポイント設計

バッチ処理の場合、処理の途中結果をAmazon S3やAmazon EFSに定期的に保存しておく。中断されても、新しいスポットインスタンスで途中から再開できる。オンプレのバッチジョブ管理（JP1やTivoli）でチェックポイントリスタートを実装した経験があれば、同じ発想だ。

スポットフリート（EC2 Fleet）を使う

単一のインスタンスタイプに依存すると、そのタイプの余剰キャパシティが不足した際に起動できない、あるいは中断されやすくなる。スポットフリート（またはEC2 Fleet）を使えば、複数のインスタンスタイプ・AZにまたがってスポットインスタンスを分散配置できる。

# AWS CLI: EC2 Fleetの作成例（JSON設定ファイルを使用）
aws ec2 create-fleet \
  --cli-input-json file://fleet-config.json

fleet-config.jsonでは、m5.large、m5.xlarge、m4.large、c5.largeなど複数のインスタンスタイプと複数のAZを指定する。AWSの配分戦略として「capacity-optimized」を選べば、中断リスクが最も低い組み合わせを自動で選択してくれる。

Linuxベースのバッチ処理基盤を構築する場合、LinuxMaster.JPでLinuxの基礎をおさえておくと、シェルスクリプトでの中断対策やジョブ管理の自動化がスムーズに進む。

スポットインスタンスに向いているワークロード

・CI/CDパイプライン: ビルド・テストの実行環境。中断時はジョブを再投入すればよい
・ビッグデータ処理: Amazon EMRやApache Sparkのワーカーノード
・コンテナワークロード: Amazon ECSやAmazon EKSのノードグループ
・機械学習のトレーニング: チェックポイント対応のトレーニングジョブ
・開発・テスト環境: 本番と同じ構成を安価に再現
・Webアプリのスケールアウト: ELB配下でスポットとオンデマンドを混在させる

逆に、単一インスタンスで停止が許されないワークロード（RDBのプライマリなど）には向かない。

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

起動できない（InsufficientInstanceCapacity）

指定したインスタンスタイプ・AZでスポットキャパシティが不足している状態だ。対処法は以下の通り。

・インスタンスタイプを複数指定する（m5.large → m5.large + m5a.large + m4.large）
・AZを複数指定する
・時間帯をずらして再試行する

中断が頻発する

特定のインスタンスタイプに中断が集中する場合は、スポット配置スコアを確認し、スコアの高いインスタンスタイプ・リージョンに切り替える。また、スポットフリートで分散させることで、特定タイプへの依存を減らせる。

中断通知を見逃した

メタデータのポーリング間隔が長すぎると、2分の猶予を有効に使えない。ポーリング間隔は5秒以下を推奨する。また、EventBridgeによる通知を併用すれば、外部からも中断を検知できる。

スポット料金が想定より高い

特定のインスタンスタイプに需要が集中するタイミング（月末、年度末、re:Inventの時期など）は料金が上昇することがある。describe-spot-price-historyコマンドで過去の価格推移を確認し、料金が安定しているインスタンスタイプを選定するのがよい。

本記事のまとめ

スポットインスタンスの要点を整理する。

スポットインスタンスは「中断される可能性がある」という一点だけ許容できれば、EC2コストを劇的に削減できる手段だ。オンプレ時代に「予備機の活用」「夜間バッチの空きリソース利用」を工夫してきた経験があるなら、スポットインスタンスの設計思想はすんなり理解できるだろう。

まずは開発環境やバッチ処理から試してみて、中断対策のノウハウを蓄積しながら、徐々に適用範囲を広げていくのが現実的なアプローチだ。クラウドのコスト管理全体を見直したい場合は、「AWS Cost ExplorerとAWS Budgets入門」もあわせて確認してほしい。