AWS側は見通しを予測しながらサーバ増強を頑張っているのでしょうけど、時期や時間によっては、リソース不足でEC2を開始・起動できないことがあります。なお、AWS側の都合で容量不足のため、緩和申請とかは関係ないためご注意ください。
We currently do not have sufficient c6a.medium capacity in the Availability Zone you requested (ap-northeast-1a). Our system will be working on provisioning additional capacity. You can currently get c6a.medium capacity by not specifying an Availability Zone in your request or choosing ap-northeast-1d.本記事では「Insufficient capacity.」（容量不足）となった時の一般的な対処法などを書いていきます（InsufficientInstanceCapacityとも表示されます）。
では早速！
代表的な対処方法
AWS公式サイト上の情報は次の通りです。
対処方法と抜粋すると、次の通りです。
- 数分待ってから再実行する。
- リクエスト数が同時多量の場合は減らしてみる。
- 別のAZを指定する。
- インスタンスタイプを変更する。
・・・予想通りというか、やっぱそうするしかないかないのかって感じ。
なお、対処ではなく、予防措置になりますが、「キャパシティ予約」を利用して、リソースを予約しておくという手もあります。
対処方法の深堀
先に書いた対処方法に対するコメントです。
- 数分待ってから再実行する。
⇒ 数分どころか日中は数時間待ってもダメなこともあります・・・。 - リクエスト数が同時多量の場合は減らしてみる。
⇒ 1個でもダメ・・・。 - 別のAZを指定する。
⇒ 初回起動ならいいけど「開始」はAMI経由するから手間かかりすぎだし、プライベートIPアドレスを変えたくない場合は選択肢にならない・・・。 - インスタンスタイプを変更する。
⇒ やっぱりこれしかないのか・・・・。
あと、キャパシティ予約（事前予約）はEC2稼働予定が明確であれば十分使えると思います。けど、開始や起動が昼間に限定される場合はイマイチ使えません。
そうなると、インスタンスタイプの変更になりますけど、簡単に出来ないのだろうか。
欲をいえば、AWS側で自動リトライ出来て、リトライ上限の場合に、別のインスタンスタイプ候補に自動で切り替えて、再度リトライ・・・とか。
ないんだな、それが。
というわけで、現状（2022年9月）は利用者側で工夫するしかありません。
なお、こういった事象が年に1回とかであれば、仕方ないね、でスルーするかもしれませんが、連日起こることもあります。サーバ故障を疑うレベル。（もしもAWS使い始めで、こんなんばっかりだったらオンプレ回帰しそう。）
まとめ
色々な方法がありますが、最終手段はインスタンスタイプの変更が無難です。もちろん確実な稼働を保証したいのであれば、キャパシティ予約を活用する案もあります。
AWSは確実に利用できるわけではないというのも考えて運用を組まないと、痛い目にあうかもしれません（だからこそマルチAZが推奨されているんですね）。
最後までお読みいただきありがとうございました！
コメント