はじめに
本記事は「2026 Japan AWS Jr. Champions 真夏のQiitaリレー」の7日目の記事です！
下記URLから他の方の記事を確認できます。ぜひご覧ください！
さて、本題に移ります。
最近仕事をしていて、開発・検証環境は、稼働時間が意外と長くなるなーと感じました。
私なりに考えてみましたが、本番環境と違って利用時間が管理されにくく、立てっぱなしのまま放置されるケースも珍しくないのかなと思いました。
その結果、検証環境のコストは積み重なりやすくなります。
一方で、検証環境には本番ほど高い可用性は求められないことも多いです。
そこで Spot Instance が使えるのではないかと考えました。
本記事では、検証環境にSpot Instanceは本当に適しているのかを、コストと可用性の両面から考えます。
Spot Instanceとは
Spot Instance は、AWSが保有する未使用のコンピューティングキャパシティを利用する購入オプションです。
On-Demand Instanceと比較して、最大90%程度安価に利用できます。
その代わり、AWS側の容量都合によって、いつでも中断される可能性があります。
中断が発生する場合、最大2分前に中断通知が届きます。
つまりSpot Instanceは単なる「安いEC2」ではなく、「安さと引き換えに、中断される責任を利用者側が引き受けるEC2」だと言えるでしょう。
この性質が、どのワークロードに向くかを考えてみます。
【参考】Amazon EC2 スポットインスタンス：https://aws.amazon.com/jp/ec2/spot/
検証環境というワークロードの性質
Spot Instanceの向き不向きは、単価の話ではなく、ワークロードが中断にどう耐えるかで決まります。
検証環境は、多くの場合で次の性質を持ちます。
- コンテナやAMI、IaCで再現できる
- 実行中の状態を長時間保持し続ける必要がない
- 作業が途中で止まっても、やり直せば結果は同じになる
これらをまとめると、検証環境は「停止を許容できる」ワークロードだと言えます。
中断されても実害が小さく、再作成すれば元通りになるということです。
Spot Instanceの弱点は「いつ中断されるかわからないこと」です。
検証環境の強みは「中断されても困らないこと」です。
この二つが噛み合うからこそ、検証環境とSpot Instanceは相性が良いと言えます。
逆に言えば、この噛み合わせが崩れる環境では、Spot Instanceは適しません。
どのような環境が該当するかは、後の節で扱います。
Spotを実際に起動してみる
ここでは、実際にコンソールからSpot Instanceを起動してみます。
まずEC2の起動画面を開き、通常のインスタンス作成と同じ手順でAMIやインスタンスタイプを選びます。
次に購入オプションの項目で「スポットインスタンス」を選択します。
)
設定はこれだけで、あとは通常のOn-Demand Instanceと同じ流れで起動できます。
起動直後にスポットリクエストの画面を確認すると、リクエストが「fulfilled」の状態になり、インスタンスが実際に動いていることがわかります。
購入オプションを切り替えるチェックボックス一つで起動できるので、操作は想像以上に簡単でした。
中断への備え（後述する終了時の処理など）を別にすれば、Spot Instanceを使い始めるだけなら学習コストはほとんどかかりません。
検証環境でSpotを使うメリット
検証環境でSpot Instanceを使う利点は、単価が安いことだけではありません。
コスト：On-Demand Instanceに比べて利用料金を大きく抑えられます。
検証環境は稼働時間が長くなりがちなぶん、単価差の影響がそのまま累積コストに跳ね返ります。
検証用途との相性：検証環境は壊れても作り直せる前提で運用されることが多い印象です。
中断されて消えても、検証に影響しないなら実害はないと考えます。
IaC：TerraformやCloudFormationで環境を定義していれば、中断後の再作成も定義通りに再現できます。
手作業で環境を組み直す必要がないぶん、中断のコストがさらに下がります。
Auto Scaling：Auto Scaling Groupと組み合わせれば、中断で減った分のキャパシティを自動的に補充できます。
人が気付く前に復旧するため、中断そのものを意識せずに済む場面も増えます。
逆に使わない方がいいケース
Spot Instanceが向かないのは、「中断されると実害が出るワークロード」です。
具体的には、次のようなケースが該当します。
デモ環境：デモの最中に中断されると、その場でやり直しがききません。
再現性より、その瞬間に確実に動いていることが求められるためです。
長時間の性能試験：数時間から数日かけて実行するベンチマークは、途中で中断されると計測が最初からやり直しになります。
経過時間そのものが結果に組み込まれる試験ほど、中断の影響が大きくなります。
ライセンス認証が絡む作業：インスタンスの起動ごとにライセンス認証が必要な製品を使っていると、中断のたびに認証作業が発生します。
認証のたびに人手や時間がかかるなら、その手間がSpotの単価差を打ち消してしまいます。
中断されたら困る作業全般：やり直しに時間がかかる、あるいはやり直し自体ができない作業は、中断のリスクをコストで受け止められません。
これらに共通するのは、「停止を許容できない」という性質です。
検証環境の中でも、この性質を持つワークロードにはSpot Instanceを使うべきではありません。
つまり判断基準は「検証環境かどうか」ではなく、「そのワークロードが中断に耐えられるかどうか」にあります。
実務ならどう設計するか
ここまでの整理を踏まえると、実務での設計は環境ごとに一律の購入オプションを当てはめるのではなく、環境が持つ中断耐性に応じて使い分ける形になります。
- 本番：On-Demand Instance + Savings Plans
- 検証：Spot Instance
- 開発：Spot Instance
さらに開発・検証環境をAuto Scaling Groupで運用するなら、Spot Instanceを優先的に使い、キャパシティが不足したときだけOn-Demand Instanceで補う構成にできます。
これにより、通常時のコストはSpotの単価で抑えつつ、Spotの供給が逼迫した場合でも環境自体は維持できます。
AWS Well-Architected FrameworkのSustainability（持続可能性）の柱でも、ビルド環境やプレプロダクション環境の利用率を上げる方法として、必要なときだけ環境を起動する運用と並べてSpot Instanceの活用が挙げられています（SUS06-BP03 Increase utilization of build environments）。
検証環境の設計は、コストだけでなく、こうした観点からも根拠づけられます。
この整理から、もう一つの設計判断が見えてきました。
本番環境のベースラインをOn-Demand Instanceで確保したまま、Auto Scaling Groupのスケールアウト分だけをSpot Instance優先にする構成です。
ベースラインの可用性はOn-Demand Instanceが担保するため、Spot Instanceの中断が起きても最低限のキャパシティは失われません。
その上で、負荷増加時に追加されるインスタンスだけを安価なSpot Instanceでまかなうことで、可用性を落とさずにスケール分のコストだけを圧縮できると考えます。
まとめ
Spot Instanceは「安いEC2」ではなく、中断される可能性と引き換えに安さを得る購入オプションです。
向き不向きを決めるのは環境の種類そのものではなく、そのワークロードが中断を許容できるかどうかにあると考えます。
検証環境は多くの場合この条件を満たすため、Spot Instanceは有力な選択肢になります。
一方で、デモや長時間の性能試験のように中断が実害につながる作業には向きません。
本番でも、ベースラインをOn-Demand Instanceで確保し、スケール分だけSpot Instanceに寄せることで、可用性を保ったままコストを抑える設計ができると考えます。
今回は起動の手順と、Spot Instanceが適用できる場面を確認しました。
今後はAWS Fault Injection Service（FIS）を使い、Spot Instanceの中断をシミュレーションして、中断時の挙動と対策を検証したいと思います。(本当はここまでやりたかったです、、、)
最後までお読みいただきありがとうございました！
初めて技術が絡んだブログを書いたので不十分なところもあるかと思います。
お気づきの点等ありましたら暖かいコメントいただけると嬉しいです！
明日以降のJr.Championsの投稿もチェックしていただけると嬉しいです！