大きなメリットと特殊なデメリットあるAWS
メリットを打ち消すレベルではないけど、それなりに深刻なトラブルは発生してしまうAWS
私の前職では古くからの慣習に縛られている関係でAWSなどのクラウドサービスに手を出すことができず、実際のメリット・デメリットを把握できてませんでした。
転職した会社では入社直後からAWSを活用した業務システム構築プロジェクトを任せていただくことができました。
が、そのAWSエンジニアがAWSの特性を全く理解していない普通のサーバエンジニアで全く役に立たず、プロジェクトリーダーのはずの私自身がサーバ構築をすることになるという大変ありがたい（？）機会に恵まれました。
色々経験した事を自分への備忘含めまとめていきます
アベイラビリティゾーンのキャパシティ不足でサーバを起動できない
利用していない時間は停止して利用料金を抑えようとしていると陥るトラブル。各AZ別にAWSが用意しているキャパシティがありオーバーするとサーバ起動できなくなるというリソース共有しているが故のトラブル。
対策案１：リザーブドインスタンスに切り替える
リソースをリザーブ（予約）の設定にしておけば別利用者にリソースを奪われることがなくなるので、コレが一番堅実そうです。ただ、課金額にも影響するのでそのへんは要計算ですね。
確実なのはこの「案１」ですが同一タイプのインスタンスが複数ある場合、指定したいインスタンスではなく同タイプの別インスタンスがリザーブドとなってしまう可能性があります
（例：t2.largeのインスタンスを5台構築。3台分のリザーブドインスタンスを指定。
→稼働した順にリザーブドの対象となります。そのため、4台目以降はインスタンスリソースが保証されません）
正直、私自身もまだ勉強中です。オフィシャル見ても色々パターンがあり把握しきれておりません。。。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/ec2-reserved-instances.html
また、
対策案２：別のアベイラビリティゾーン（AZ)へ移動する
かなり確実に解決すると思われますが、同一AZ内のサーバとの通信やDirectConnectを利用したネットワーク通信がある場合は設定作業が色々大変です。
内部IPでの通信がクリティカルではないサーバならこの対応はアリかと思います。
対策案３：インスタンスタイプを変更する
対応としては３が一番簡単。停止しているインスタンスを選択してから
「設定」ボタン→「インスタンスタイプの変更」で別のタイプへ変更するだけ。
ただ公式アナウンスとしてはリソース不足が原因のトラブル。この対応で完全解決するかというと少し微妙です。
サーバの重要度に応じて対応を検討ということになるかと思います
対策案４：オンデマンドキャパシティー予約を利用する
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/capacity-reservations-pricing-billing.html
オンデマンドのインスタンスを指定してキャパシティーが予約できるという隙間を埋めるソリューション。・・・ですが！
キャパシティ予約をしている期間は課金されるとのこと。
ということは料金安く済ませようとした場合、サーバの自動停止・起動とあわせてキャパシティー予約の設定変更も同時にしないといけないという事でしょうか・・・面倒すぎてリザーブド選びたい・・・
まだまだ勉強不足なので精進します