要件が満たせるのならFargateとかの方が好ましいケースが多いとは思いますが、EC2を触る機会も多く且つスポットインスタンスを触ったことが無かったので雑に備忘録として記事にメモしつつスポットインスタンスの起動回りについて触れていこうと思います。また、割引率や中断率のデータの見方に関しても軽く触れておきます。
インフラ・クラウド回りは初心者なので知識が荒い点などはご容赦ください。
個人的にはAWSの画面は（翻訳精度などの面で）英語表示の方が好みなので画面のスクショも英語表示のままにしてあります。
起動前にスポットインスタンスの料金について調べる
大雑把な料金に関しては以下のページで対象のリージョンを選択して必要なインスタンスタイプを検索すれば確認することができます。
ただしスポットインスタンスに関しては日々値段が変動する点、アベイラビリティゾーン（以下AZ）ごとに料金がずれたりもします。そのため過去の一定期間の各AZごとの料金を確認したいところですが、そちらはAWSを確認するにはAWSのマネジメントコンソールから確認することができます。
まずはEC2の左のメニューからSpot requestsを選択します。
Spot requestsのページにあるPricing historyのボタンを押すと過去の料金の推移などを表示することができます。
例としてInstance typeでg6.xlarge、Data rangeに3 monthsを選択してみます。3ヵ月分の各AZにおけるg6.xlargeの料金推移が確認できます（グラフのグレーの線が通常のオンデマンドの料金となっています）。
青や赤などの線は各AZの料金となっています。また、下の方を見ると期間中のスポットインスタンスの平均料金やオンデマンドと比較した場合の割引率、どのAZが一番安いのかなどが表示されます。
起動前にスポットインスタンスの中断率について調べる
料金と共に中断率に関しても事前に調べておくと有益なケースがあるかもしれません。
中断率に関してはスポットインスタンスアドバイザーというものが公開されており、各リージョンの各インスタンスでどのくらいの頻度でスポットインスタンスが中断されているのかが確認できます（よく利用されてリソースが不足しがちなインスタンスタイプほど中断されやすいといった形になっている？ようです）。
例えばオレゴンでg6インスタンスを見てみると以下のように一番小さいg6.xlargeが一番中断率が高い形になっていることが本記事執筆時点では確認することができます。
※基本的に中断率が低い方が長時間中断されずにインスタンスを起動したままになりますが、ただし運用しているシステムで利用する際にはオートスケーリングとスポットプール数を20辺りまで確保して中断リスクを抑えたり・・・といった形となるため参考程度でも良いのかもしれません。
スポットインスタンスの起動をしてみる
メインのスポットインスタンスの起動に関して進めていきます。
まずはEC2のページにアクセスします。
Launch instanceを選択します。
名前やOSなどは今回は適当にtest-instance、Ubuntu、t4g.nanoと選択と選択をしていきます（この辺は本題から逸れるので今回は適当に設定していきます）。ネットワーク設定なども外部から繋がらない形の最小設定で進めておきます。
スポットインスタンス関係の設定はAdvanced detailsの部分にあるようなのでそちらを展開して設定していきます。
Purchasing optionという項目にSpot instancesという選択肢があるのでそちらを選択していきます。
また、Customize Spot instance optionsをクリックするとスポットインスタンスの詳細設定が出てくるのでそちらをクリックします。
表示される設定でMaximum priceはスポットインスタンスの上限価格設定となります。No maximum priceの方を選択したら特に上限価格は設けられず、オンデマンド時の料金以下の範囲で扱われます。
詳しくないのですが基本的にはオンデマンドと同じ価格まで上がったり・・・などは過去あった感じでしょうか・・・？基本的には大体50％オフくらいにはなっている印象ですがその辺りは過去の歴史とかはよく分かっていません（色々なインスタンスの過去の金額とかを見ている感じでは基本的にはオンデマンドに近い極端な料金の高さにはならないイメージではいます）。
Request typeはOne-timeもしくはPersistentを選択することができます。軽く調べてみた感じ、One-timeは1回だけのスポットリクエスト、Persistentに関しては中断された際に再びスポットリクエストを再実行するか・・・といった挙動になるようです。
Valid toの方はSet your request expiry dateを選択するとPersistent選択時のスポットリクエストの再実行処理をこの設定で指定した日時で停止できるようです。ずっとスポットリクエストを続けて欲しければNo request expiry dateの方を選択する形で問題なさそうです。
Interuption behaviorに関してはHibernate、Stop、Terminateの3種類が選択しとしてあるようです。前の設定でOne-timeを選択している場合にはTerminate（インスタンスの終了とディスクなどの破棄）のみが選択できるようです。
Stopに関してはスポットインスタンスが中断された際にインスタンスは停止し、ディスクなども残った形となるようです。Hibernateとはなんぞや・・・？という感じですが、軽く調べてみたところどうやらメインメモリの内容をディスクとかに保存して停止してくれるようです。Windowsのスリープとかに近い感じだろうか？という印象です。メモリをたくさん使うケースではStopの状態から再開するよりも短時間で元の状態に戻すことができる（コールドスタートのようなケースが発生しにくい）といったところでしょうか。
参考 :
なお、Persistentを選択していてStopもしくはHibernateが選択されている場合にはスポットインスタンスが中断された後に再び確保できる（上限金額などを超えていないなど）タイミングでインスタンスが再開されるようです（Terminateが選択されていればまたインスタンスの作成から実行される形になると思われます）。
あとはそのままの設定でLanuch instanceをクリックしてインスタンスを起動してみます。
問題なく起動してくれたようです。インスタンス一覧とかも通常のEC2インスタンスのように表示されています。
設定したスポットリクエスト関係の設定はどこに表示されるのだろう・・・と思ったのですが、InstancesのページではなくSpot Requestsのページの方に表示されるようです。インスタンスタイプやステータス、One-timeかどうかなども表示されています。
また、ページの下部の方にはスポットインスタンスでの節約状況などのサマリーが表示されるようです。
とりあえずこれで手動で起動する際の設定などを確認することができました。CloudFormation対応やAuto Scaling周りの対応などは機会があれば別の記事で色々触れてみようと思います。
参考文献・参考サイト
※その他公式のマネジメントコンソール上で表示される公式のヘルプドキュメントや理解の補助用にCopilot Chatを利用しています。