Spot インスタンス実践 — 最大 90% 割引の条件と中断対応の設計
EC2 のコストを下げる軸は 3 つです。コミットで下げる RI・Savings Plans、アーキテクチャで下げる Graviton、そしてこの記事の主題である Spot です。結論を先に書くと、Spot は中断を受け入れられるワークロードに限って、オンデマンド比で最大 90%(実務の体感では 40〜70%)の割引をコミットなしで与える契約で、判断基準は価格ではなく「2 分の通知の後に消えてもよいか」です。 この質問にはいと答えられるワークロードで Spot を使わないのは損で、いいえと答えるべきワークロードに使うのは障害の予約です。料金は us-east-1 基準です。
一目でわかる比較 #
| 項目 | オンデマンド | Spot |
|---|---|---|
| 割引 | なし(基準) | 最大 90%、プールごとに変動 |
| コミット | なし | なし |
| 中断 | なし | 2 分通知の後に回収されうる |
| 容量の保証 | 高い | なし(プール状況により未充足もある) |
| SLA・安定性要求のワークロード | 適合 | 不適合 |
| バッチ・CI・ステートレスの拡張分 | 可能(高い) | 最適 |
| 組み合わせ | RI・SP の対象 | RI・SP とは別枠、変動分の担当 |
契約の実体 — 余った容量を安く、ただし返せるように #
Spot は AWS の余った EC2 容量を市場価格で使う方式です。価格はインスタンスタイプ × AZ 単位のプールごとに需給で緩やかに動き、おおむねオンデマンドの 10〜30% の水準で形成されます。対価は 2 つです。AWS が容量を取り戻す必要があるとき、2 分の通知の後にインスタンスが回収され、そもそもプールに容量がなければリクエスト自体が満たされないことがあります。
中断は例外ではなく契約の一部です。通知はインスタンスメタデータ(IMDS)と EventBridge で届きます。それより先にリバランス勧告(rebalance recommendation)という早期のシグナルが届くことが多く、このシグナルで新しいインスタンスを先に立ち上げて作業を移す余裕を稼げます。つまり Spot 運用の実力は安いプールを選ぶことではなく、2 分以内に片付けて退出する手順を自動化しておくことです。
どこに使うか — 中断耐性が基準です #
よく合うワークロードは、状態を外に置いて再試行が自然なものです。CI のビルド・テストランナー、バッチ・データ処理(チェックポイント前提)、コンテナオーケストレーター上のステートレスサービスの拡張分、レンダリング・シミュレーション、開発環境です。K8s や ECS の上では中断が「ノード 1 台の離脱」として吸収されるため、特によく合います。
避けるべきワークロードは、状態が中にあるか中断のコストが大きいものです。データベース、単一インスタンスのサービス、チェックポイントのない長時間ジョブ、そしてライセンスがインスタンスに紐づく商用ソフトウェアです。「本番だからだめ」ではなく「中断耐性がないからだめ」が正確な基準です。中断耐性を備えた本番サービスの拡張分は、Spot の正当な持ち場です。
実務の標準構成は混合です。下限の容量はオンデマンド + コミットで固定し、トラフィック変動で増える部分を Spot で埋めます。 Auto Scaling グループの混合インスタンスポリシーがこの構成を標準サポートし、オンデマンドの比率をパーセントで指定できます。
中断頻度を下げる設計 — 多様化と割り当て戦略 #
中断頻度は運任せではなく設計で下げます。
- インスタンスの多様化: プール(タイプ × AZ)ごとに容量事情が違うため、使えるタイプを広く開けておくほど深いプールで実行される確率が上がります。「m7i.large だけ」ではなく m・c・r の複数世代とサイズを候補に入れるのが基本です。タイプ選択の基準はインスタンスファミリー比較に従いつつ、幅を広げます。
- 割り当て戦略は price-capacity-optimized: 現在の推奨デフォルトです。最安のプールではなく、容量が深くて安いプールを選ぶため、lowest-price 戦略に比べて中断が目に見えて減ります。最安だけを追う戦略は浅いプールに集まり、中断で払い戻す構成です。
- コンテナなら Fargate Spot も選択肢: Fargate のタスクにも Spot があり、オンデマンド比で約 70% の割引を受けられます。ただし EC2 Spot のようにタイプの多様化で中断確率を調整する手段はないため、短いバッチタスクや中断許容のサービスに使います。
価格面でもう 1 つ書くと、Spot の割引と RI・SP は重なりません。コミットはオンデマンド料金に掛かる割引で Spot は別の市場なので、コミットのカバレッジは下限の使用量に合わせ、Spot 使用分はその計算から除外するのがカバレッジ設計の基本です。
判断の手順 #
- 中断シナリオを先に書きます: このワークロードのインスタンスが 2 分通知の後に消えたら何が起きるかを書いてみます。答えが「再試行されて終わり」なら Spot 候補、「データ消失・障害」なら除外です。
- 状態を外に出します: 作業キュー、チェックポイント、外部ストレージに状態を分離すると Spot 可能な領域が広がります。Spot 導入がアーキテクチャを健全にする順序でもあります。
- 多様化の幅と割り当て戦略を設定します: タイプ候補を広げて price-capacity-optimized を指定します。中断通知・リバランス勧告のハンドラー(ドレイン自動化)までがワンセットです。
- 下限と変動分を分けます: 下限はオンデマンド + コミット、変動分は Spot という混合ポリシーを Auto Scaling に入れます。
- 中断率を観測して調整します: 中断の多いプールは候補から外し、Spot の充足率が低いときにオンデマンドへのフォールバックが動くか確認します。Spot は設定して終わりではなく、観測しながら運用する対象です。
まとめ #
- Spot はコミットなしで最大 90% の割引を与える代わりに、2 分通知の後に回収されうる契約です。判断基準は価格ではなく中断耐性です。
- CI、バッチ、ステートレスの拡張分が最適で、DB とチェックポイントのない長時間ジョブは除外です。本番かどうかではなく状態の位置が基準です。
- 中断頻度は設計で下げます。タイプの多様化 + price-capacity-optimized 割り当て + 通知ハンドラーの自動化が 3 点セットです。
- 標準構成は混合です。下限はオンデマンド + RI・SP で固定して変動分を Spot で埋め、コミットのカバレッジ計算から Spot 使用分は除外します。
- コンテナは Fargate Spot(約 70% 割引)も選択肢です。これでコミット、Graviton、Spot のコスト 3 軸が完成します。