インスタンスの適格性が「オープン」のキャパシティ予約について、適用インスタンスを停止した際の挙動を確認してみた

はじめに

こんにちは。アノテーションの このみ です。

EC2 のオンデマンドキャパシティ予約をする際に、インスタンスの適格性に「オープン」か「対象」を選ぶ項目があります。
今回は「オープン」を選んだ場合の挙動について、気になっていた点を実際の環境で確認してみます。

検証結果

検証することと、その結果を先に記載します。

1. 自動で予約が割り当てられている EC2 インスタンスを停止したら、同じ条件で起動している他の EC2 インスタンスに予約が移動するのか

   ⇒結果：移動する

2. 「オープン」の予約 ID を指定した EC2 インスタンスを停止したら、同じ条件で起動している他の EC2 インスタンスに予約が移動するのか

   ⇒結果：移動する

検証

1. 自動で予約が割り当てられている EC2 インスタンスを停止したら、同じ条件で起動している他の EC2 インスタンスに予約が移動するのか

結果の予想

インスタンスの適格性が「オープン」の場合、インスタンスを停止すると予約の割り当てが外れます。¹

これによりキャパシティ予約の利用可能な数量が復活するため、以下のドキュメント ² のように、改めて予約の属性に一致する起動中のインスタンスに予約が自動で割り当てられます。

キャパシティーの予約 の操作 - Amazon Elastic Compute Cloud　

デフォルトでは、キャパシティーの予約 は、新しいインスタンスと、一致する属性 (インスタンスタイプ、プラットフォーム、およびアベイラビリティーゾーン) を持つ実行中のインスタンスを自動的に一致させます。つまり、一致する属性を持つインスタンスがキャパシティーの予約で自動的に実行されます。

そのため、結果としてインスタンスの停止により予約が移動するような動作をとると考えられます。

上記の通り、ドキュメントからも停止により予約が移動することが確認できてはいるのですが、実際の環境でも挙動を見てみたいと思います。

実際に確認してみる

下準備

インスタンスの適格性が「オープン」のキャパシティ予約を作成します。

現段階でキャパシティ予約の条件に該当するインスタンスはインスタンス A のみです。

やってみる
キャパシティ予約の条件に該当する EC2 インスタンス (以降、インスタンス B) をもう一つ起動します。
この時点でキャパシティ予約はインスタンス A に割り当たっているため、インスタンス B にはキャパシティ予約が割り当たっていません。

それでは、インスタンス A を停止してみます。

インスタンス A からはキャパシティ予約が消えています。

そして、キャパシティ予約はインスタンス B に割り当たっていました。

まとめ

初めにドキュメント等で確認した通り、インスタンスの停止により予約が別インスタンスに移動することが確認できました。　　 　　

---

2. 「オープン」の予約 ID を指定した EC2 インスタンスを停止したら、同じ条件で起動している他の EC2 インスタンスに予約が移動するのか

疑問に思ったこと

EC2 インスタンス側でキャパシティ予約を設定する際、「キャパシティーの予約の指定」に「オープン」で作成した予約 ID も指定できます。
この場合、インスタンス側で特定の予約のみを利用するように指定しているので、
指定したのが「オープン」の予約であっても、特定のインスタンスに予約が割り当てられ続けるのでは？と思いました。

結果の予想

しかしながら 1. で確認した通り、予約時のインスタンスの適格性が「オープン」の場合は、停止によって予約が外れます。
つまり、EC2 側で設定するキャパシティ予約の指定は、あくまで「EC2 インスタンス側が」特定の予約を使用して起動することを指定しているというだけで、
指定したのが「オープン」の予約の場合は、キャパシティ予約を割り当て続けるような効果はないと考えられます。

実際に確認してみる

下準備
インスタンスの適格性が「オープン」のキャパシティ予約を作成します。
現時点では 2 つのインスタンス (インスタンス A、インスタンス B) が作成されていますが、停止中のためどちらのインスタンスにも予約は割り当たっていません。


現在停止中のインスタンス A にて、EC2 インスタンス側のキャパシティ予約を「キャパシティーの予約の指定」に設定して、先ほど作成した予約 ID を指定します。

すると、インスタンスは停止していますが、インスタンスのコンソールから確認すると、予約 ID が表示されています。

しかしながら、この時点での利用可能なキャパシティの数が 1 となっているため、実際に予約が使用されているという訳ではないようです。
このことから、予約 ID を指定した場合にコンソールに表示されている予約 ID は、実際に使用している ID というわけではないことが確認できました。

やってみる
再度インスタンス A を起動します。

利用可能なキャパシティの数が 0 となっていることから、予約がインスタンス A によって消費されているようです。

それでは、インスタンス A を停止して、キャパシティ予約の条件に該当するもう一つの EC2 インスタンス (以降、インスタンス B) を起動してみます。
コンソール上の表示では、インスタンス A とインスタンス B 両方に予約 ID が表示されているため、両方に予約が割り当たっているようにも見えてしまいますね。
　　 　　

続けて、インスタンス B に予約が移っている状態で、インスタンス A を起動してみます。
「The requested reservation does not have sufficient compatible and available capacity for this request.」というメッセージで起動できませんでした。
使用可能なキャパシティの不足と出ているのは、インスタンス B で予約 (1 つ中の 1) を使いきっているため、インスタンス A がキャパシティ予約を利用できないためです。

まとめ

EC2 側で設定するキャパシティ予約の指定はあくまで「EC2 インスタンス側が」特定の予約を使用して起動することを指定しているだけなので、 予約側が「オープン」で作成されている限りは、自動で予約が割り当てられることが分かりました。
また、予約 ID を指定した時点ではその予約を使って起動できていても、停止によって予約の割り当ては外れるため、起動できなくなります。
このような設定を行う場合は予約の作成数について注意する必要がありそうです。

アノテーション株式会社について

アノテーション株式会社は、クラスメソッド社のグループ企業として「オペレーション・エクセレンス」を担える企業を目指してチャレンジを続けています。「らしく働く、らしく生きる」のスローガンを掲げ、様々な背景をもつ多様なメンバーが自由度の高い働き方を通してお客様へサービスを提供し続けてきました。現在当社では一緒に会社を盛り上げていただけるメンバーを募集中です。少しでもご興味あれば、アノテーション株式会社WEBサイトをご覧ください。

参考