025-AWS SAP AWS 「理論・実践・一問道場」 EC2 キャパシティ予約

type

status

date

slug

summary

理論

Amazon EC2 キャパシティ予約の整理

キャパシティ予約とは？

Amazon EC2 インスタンスの計算能力（キャパシティ）を特定のアベイラビリティゾーンで予約できる機能です。短期または長期の保証されたキャパシティが必要な場合に使用されます。

主な特徴

柔軟性のある期間設定

現在の利用向け：すぐに利用可能なキャパシティ予約。期間のコミットメントなし。

将来の利用向け：開始日時を指定して予約可能。ただし、指定した期間はコミットメントが必要。

キャンセルおよび変更

現在のキャパシティ予約：いつでもキャンセルまたは変更可能。

将来のキャパシティ予約：

コミットメント期間中はキャンセルや変更不可。
コミットメント期間終了後に変更やキャンセルが可能。

インスタンス属性との一致

自動一致: デフォルト設定では、インスタンスの属性（インスタンスタイプ、プラットフォーム、アベイラビリティゾーンなど）が一致すれば、自動的にキャパシティ予約が利用される。

明示的な指定: 特定のワークロードにキャパシティ予約を割り当て可能。

柔軟なリソース管理

リソースグループ管理: キャパシティ予約をリソースグループ単位で管理することも可能。

用途に応じた選択例

すぐに利用可能な場合

期間のコミットメントが不要。必要なときにいつでも利用可能。

将来の予約が必要な場合

開始日時とコミットメント期間を設定して予約。期間中は変更やキャンセル不可。

キャパシティ予約のメリット

ビジネスクリティカルなワークロードで、キャパシティ不足のリスクを回避。

アベイラビリティゾーン内でのキャパシティ保証。

注意点

属性が一致しないインスタンスではキャパシティ予約を使用できない。

将来の予約では、コミットメント期間中の柔軟性が制限される。

実践

参照元：

【ハンズオン】EC2のオンデマンドキャパシティ予約を行う方法 - Qiita

はじめにAWSはクラウドなので、使いたいときに使いたいだけのリソースを使用できます。とはいえ、AWSも物理リソースには限界があります。いざEC2を起動したいと思ったときに、キャパシティ不足で起動…

https://qiita.com/hamham/items/553424df17997e337289

はじめに

AWSはクラウド環境で「使いたいときに使いたいだけリソースを利用できる」サービスですが、物理的なリソースには限界があります。そのため、必要なときにリソースが不足してEC2インスタンスが起動できないリスクが存在します。

こうしたリスクに備える手段が 「オンデマンドキャパシティ予約」 です。この予約を事前に行うことで、リソース不足による障害を回避できます。

オンデマンドキャパシティ予約の特徴

1. メリット

リソース確保: 必要なときに確実にEC2インスタンスを利用可能。

ビジネスクリティカルなワークロード向け: 重要な業務におけるキャパシティ不足の回避。

2. デメリット

コストが発生: キャパシティを予約するだけで、EC2のオンデマンド料金と同額が発生します。実際にEC2インスタンスを起動していなくても課金されるため、慎重に計画する必要があります。

実施方法

以下では、オンデマンドキャパシティ予約の手順をスクリーンショットを交えて説明します。AWS管理コンソールでの操作に慣れていない方でもわかりやすく解説します。

公式情報へのリンク

詳細な仕様や注意点については、以下のAWS公式ページを参照してください。

AWS公式ページ – オンデマンドキャパシティ予約

内容が読みやすく、手順にフォーカスした構成になりましたが、さらに必要に応じて手順やスクリーンショットを補足してください！

キャパシティ予約の実施手順

まずはマネージメントコンソールにログインし、該当リージョンのEC2のページを開きます。

ここで 「キャパシティの予約」＞「キャパシティ予約の作成」 をクリックします。

インスタンスの詳細

以下を選択します

インスタンスタイプ

プラットフォーム(OS)

アベイラビリティーゾーン(AZ)

テナンシー

プレイスメントグループ

数量

インスタンスタイプ、OS、AZなどが多様だと、それごとに設定しなくちゃいけないので結構面倒です。

テナンシーやプレイスメントグループを利用していなければそのままでOKです。

今回は、試しに「t3.nano」「Linux/UNIX」「ap-northeast-3a(大阪リージョン)」で「1台」としてみます。

予約の詳細

「手動」 にすると、キャパシティ予約をキャンセルしない限りはずっと予約が維持されます。

「特定の時間」 にすると、未来の日時を設定しておけば、そのタイミングで自動で予約がキャンセルされます。

また、インスタンスの利用資格に関して、「一致する詳細を持つ任意のインスタンス」 を選択すると、「インスタンスの詳細」で設定したインスタイプ・OS・AZのEC2を起動した場合、自動的にキャパシティ予約の内数としてカウントされます。

「この予約を指定するインスタンスのみを受け入れます。」 を選択すると、EC2を起動する際に、明示的に予約リソースグループのARNを指定する必要があります。

今回は「手動」、「一致する詳細を持つ任意のインスタンス」としてみます。

このまま 「作成」 を押すと確認画面が出てきますので、「確認」 を押すとキャパシティ予約完了です。

キャパシティ予約の確認

上記のように予約ができました。

利用可能が1インスタンスとなっています。

EC2の起動

ここで該当するインスタンスタイプ・OS・AZでEC2を起動してみます。

キャパシティ予約の画面から 「インスタンスの起動」 をクリックしてウィザードを進めます。

どうやら、t3.nanoを予約したのに、t2.microを起動しようとしてしまったみたいです。このように、パラメータを間違えると起動できないようにしてくれます。

インスタンスタイプを修正したところ無事起動しました。起動後のキャパシティ予約の画面は以下のとおりです。ちゃんと起動が1インスタンスとなり、利用可能は0インスタンスに減っています。

予約のキャンセル

キャパシティ予約をしたままだと料金がかかってしまうので不要であればキャンセルしましょう。

「予約をキャンセル」 をクリックします。

確認画面が出ますので

「予約をキャンセル」

をクリックします。

これでキャパシティ予約が解放され、料金がかからない状態にできます。

一問道場

質問 #25

トピック 1

ある企業がオンプレミスのデータ分析プラットフォームを使用しており、このシステムは、企業のデータセンター内にある12台のサーバーを使って高可用性を確保しています。

システムでは、定期的に実行されるジョブ（毎時・毎日のスケジュール）と、ユーザーからのリクエストに基づく一回限りのジョブがあります。

スケジュールされたジョブは、20分から2時間かかり、システム使用率の65%を占めており、厳しいSLA（サービスレベルアグリーメント）があります。

ユーザーのジョブは5分以内で完了し、SLAはありません。これらはシステム使用率の35%を占めています。

システム障害時には、スケジュールされたジョブはSLAを満たし続ける必要がありますが、ユーザーのジョブは遅延しても問題ありません。

システムをAmazon EC2インスタンスに移行し、コスト削減を目指すとともに、高可用性を維持しつつ、SLAに影響を与えないソリューションが求められています。

どのソリューションが最もコスト効率よく、要件を満たすでしょうか？

解答選択肢

12台のインスタンスを、選んだAWSリージョン内の2つのアベイラビリティゾーンに分け、

各アベイラビリティゾーンに2台のオンデマンドインスタンスをキャパシティ予約で実行し、

各アベイラビリティゾーンに4台のスポットインスタンスを実行する。

12台のインスタンスを、選んだAWSリージョン内の3つのアベイラビリティゾーンに分け、

1つのアベイラビリティゾーンに4台のオンデマンドインスタンスをキャパシティ予約で実行し、

残りのインスタンスをスポットインスタンスで実行する。

12台のインスタンスを、選んだAWSリージョン内の3つのアベイラビリティゾーンに分け、

各アベイラビリティゾーンに2台のオンデマンドインスタンスをSavings Plansで実行し、

各アベイラビリティゾーンに2台のスポットインスタンスを実行する。

12台のインスタンスを、選んだAWSリージョン内の3つのアベイラビリティゾーンに分け、

各アベイラビリティゾーンに3台のオンデマンドインスタンスをキャパシティ予約で実行し、

各アベイラビリティゾーンに1台のスポットインスタンスを実行する。

解説：

A: スポットインスタンスの数が少なく、SLAを満たすために重要なスケジュールされたジョブにはオンデマンドインスタンスが必要です。スポットインスタンスの割合が少ないため、最適な解決策ではありません。

B: 1つのアベイラビリティゾーンにリソースを集中させると、高可用性が損なわれ、災害時にシステム全体が影響を受けやすくなります。

C: Savings Planは長期契約に基づいてコストを削減するものであり、「消費ベースのモデル」という要件には合致しません。また、スポットインスタンスのリスクが高くなります。

D: 3つのアベイラビリティゾーンにリソースを分散し、オンデマンドインスタンスで高可用性を確保し、スポットインスタンスを使ってコスト削減。これにより、災害時の影響を最小化し、コスト効率の良い解決策が実現できます。

結論：

Dが最適な選択肢です。