EC2はメンテナンスなどでStop/StartまたはAMIからのインスタンス作り直しが必要になることがままあります。
手軽さから、なるべく前者で済ませたいところ。
ただ、無対策でやっちゃうと、StopしたもののAWS側のキャパシティ不足によってStartできないってことも。。。
そこで、自分流オンデマンドキャパシティー予約について基本的な使い方↓
1: オンデマンド予約の作成 （終了は手動。targeted。）
2-a: 予約が成功したらインスタンス立ち上げ。立ち上げ確認後、予約登録をキャンセル。
2-b: 予約が失敗したら別のインスタンスタイプにするかなどの検討
要するにStop/Startする前にキャパシティチェックをする使い方です。
上記はあくまで、作業直前のタイミングでのキャパ確認です。
「キャパ予約できる＝キャパあり」って考えです。
完全性を求めるなら、キャパ予約からインスタンスを立ち上げ（AMIから立ち上げ）する必要があります。
キャパ予約したものがラスイチで、stop/startに失敗するリスクはゼロではないです。
その場合は、キャパ予約を使ってインスタンス起動することになるかと。
なお、常時Stop/Startできるようにする場合は予約をキャンセルしないなど、上記のフローは要件によってカスタマイズが必要です。
これまで、通常起動と同じ料金が課金されるオンデマンドキャパシティ予約の使いどころがピンと来ていませんでしたが、上記では活用できそうだなと思いました。
東京リージョンにおける旧版インスタンスの枯渇は結構深刻っぽいです。
上記のキャパ予約やAMIなどの事前対策とらずに、Stop/Startやっちゃうとサービス断の時間を長引かせてしまう可能性高いです。
ご注意を！
