AWS 予約管理

リザーブド インスタンスについて

AWS リザーブド インスタンス (RI) では、年額コミットメントを Amazon に前払いする見返りとして、コンピューティング コストの割引を受けることができます。Amazon は、特定のインフラストラクチャを使用するというコミットメントをユーザーから得ることで、容量の管理を効率化して、節約したコストをユーザーに還元することができます。

RI のメリット

すべての RI タイプは、価格削減のメリットを提供します。一部の RI タイプでは、容量予約のメリットも併せて提供され、予約期間に所定のタイプのインスタンスを起動する権利が保証されます。

RI の属性

それぞれの予約分の構成は、これらの属性によって決まります。

• インスタンス タイプ（m3.large など）
• 範囲: アベイラビリティ ゾーンまたはリージョン
• 場所（us-east-1b など）
• 期間：通常は 1 年または 3 年。AWS Reserved Instance Marketplace では異なる期間を選択することが可能。
• 支払いオプション（「前払いなし」など）
• サービス クラス：標準またはコンバーティブル
• プラットフォーム（Linux など）
• テナント: 共有または専用

RI の適用方法

よくある誤解として、RI は特定の起動済みインスタンスに直接接続されるというものがあります。実際には、RI とは、簡単に言えば、特定のタイプの任意のインスタンス（たとえば、Linux を実行する us-east-1a の m3.large など）の使用に対して適用される価格割引のことです。

AWS では、まず、使用可能な予約の評価が行われ、インスタンスが 1 時間単位で実行されます。予約は、使用量にランダムに適用されます。インスタンスの 1 時間ごとの使用状況の評価が行われ、それをカバーするために適用できる予約があるかどうかが判断されます。適用対象は、一致するインスタンス タイプ（m2.2xlarge など）、場所（us-east-1a など）、およびオペレーティング システム（Linux など）によって決まります。複数の異なる予約タイプと購入を対応させることができるため、予約を選択することで、最も低い時間単価が最優先で適用されるようになります。予約には、購入に使用されたアカウントに対する親和性もあります。

たとえば、Linux を実行する us-east-1a の m3.large というように、特定のインスタンス タイプ、場所、およびオペレーティング システムに一致するインスタンスを起動するとします。そのインスタンスの使用の 1 か月後に、支払いプランのタイプ（前払いなし、一部前払い、または全額前払い）に応じた割引率で請求が行われます。したがって、同じインスタンス タイプをオンデマンドで使用する場合と比べて請求額が抑えられます。

RI は、非常に便利なサービスであると同時に、しばしば混乱をまねきます。多くの場合、混乱は、ユーザーが特定の対象（マーケティング部門など）のために RI を購入し、そのコストのメリットが他の場所で適用されるというような状況で発生します。

RI を管理する際の考慮事項

初めて RI を購入される場合は、手順が複雑になることがあります。RI の属性（インスタンス タイプ、範囲、期間、提供クラスなど）を決定することに加えて、チーム、アプリケーション、および機能領域全体の使用率を予測する必要があります。事前にある程度検討しておくと、RI 購入時の決定を簡素化することができます。

RI 購入のタイミング

2 つのメトリックに基づいて、RI を購入する時期を決めることができます。いずれのメトリックも RI の使用料に関連するものです。

実効レート

実行中のインスタンスに支払う実際の料金です。この料金は、さまざまな時間間隔（1 年、1 か月、1 時間など）を基準に適用されます。金額は次の式を使用して計算されます。

effective rate = upfront payment/reservation term/interval + recurring usage charges for interval

以下の表に us-east 中の Linux インスタンス m3.large の実効レートの例を示します。

	オンデマンド	前払いなし	一部前払い	全額前払い
Amazon への前払い	$0.00	$0.00	$443.00	$751.00
期間を通して 100% で適用される経常的なコスト	$1226.40	$876.00	$324.12	$0.00
合計実効コスト（月額）	$1226.40	$876.00	$767.12	$751.00
オンデマンドでの節約	n/a	29%	37%	39%

回収期間

RI が同じタイプのオンデマンド インスタンスに比較して、安価になるように、使用率 100% で利用する必要のある月の数。このメトリックは、予約の採算がとれるまでに必要な期間を理解するために役立ちます。

回収期間は、一部前払いまたは全額前払いのオプションに適用されます。いずれのオプションも Amazon に支払う頭金があるため、RI の点では以前よりも割高になります。前払いオプションには、オンデマンド インスタンスに比べ、安価になるため、回収期間はありません。回収期間はインスタンス タイプによって異なりますが、平均的に 1 年の予約で 6 か月、3 年の予約で 9 か月です。

回収期間とは、インスタンスをシャットダウンした後も引き続き、RI の購入からメリットが得られる時点までの期間のことです。回収期間は次のように計算できます。

1. 期間中の月ごとに生じるオンデマンド使用率に対する現金支出と提示されるサービスを比較します。
2. オンデマンド インスタンスの使用量に対するコストが、予約されているサービスのコストを超えていないかを確認します。

インスタンス グループごとのニーズの分析

手順 1：類似インスタンスのグループ分け

どのような合理的な規模であっても、インフラストラクチャの内部で個々のインスタンスに伴う、RI 購入の意思決定を下すのは容易ではありません。意思決定のプロセスは、各インスタンスを個別にグループ分けしたり、環境、機能、アプリケーションといったいくつかのパースペクティブ別にグループ分けしたりすることにより、簡素化することができます。最も一般的な方法は、MongoDB や Web サーバなど、アプリケーションまたは機能の目的に基づいてインスタンスをグループ分けすることです。

プラットフォームの種類（たとえば、Linux、Windows など）ごとに AWS の価格は異なるため、可能であれば、同じグループの中に種類の異なるイメージを入れないようにしてください。

手順 2：グループ別のコストの評価

RI への移行に伴う潜在的なメリットを評価する場合はまず、最も経費のかかるインスタンス グループ（MongoDB サーバなど）から始めます。さらに重要なのは、RI が「常時オン」のインフラストラクチャを対象としている点です。したがって、インスタンスが使用されている時間が 65% 未満のグループの評価はスキップすることができます。

各グループに対して、評価中に次の質問をしてみます。

• 現時点から 1 年後、および 3 年後に依然として運用されていると予想されるグループの比率はどの程度ですか。
• このグループ中のインスタンスが引き続き、現在のリージョンに残っている可能性はどの程度ですか（当面、場所は無視する）。
• このグループ中のインスタンスに対するインスタンス タイプ ファミリを変更する（たとえば m1 ファミリから m3 ファミリに切り替える）可能性はどの程度ですか。

手順 3：グループごとの予約の決定

現在のリージョンに含まれるグループ中のインスタンスについての既知の比率が、インスタンス タイプ ファミリを変更しないまま少なくとも 7 か月（RI の平均的な回収期間）は維持されると、ある程度の確信を持って予測される場合は、このグループが RI の候補となります。

この例で扱う個々のグループについて、各予約タイプで得られる価値と期間を評価します。

us-east リージョンに含まれる 10 個の m3.large インスタンスを 1 年間評価する例。

	オンデマンド	前払いなし	一部前払い	全額前払い
Amazon への前払い	$0.00	$0.00	$4,430.00	$7,510.00
期間を通して 100% で適用される経常的なコスト	$12,264.00	$8760.00	$3241.20	$0.00
合計実効コスト（月額）	$12264.00	$8760.00	$7671.20	$7510.00
オンデマンドでの節約	n/a	29%	37%	39%

オンデマンド利用による節約は、インスタンス タイプおよびリージョンによって異なり、この 2 つの間の差は 1% にまで低減できます。

この例では、全額前払いの予約は無視することができます。これは、一部前払いでわずか 2% の節約を得るために $3,080 の現金支出が追加されるためです。

新しいインスタンス タイプに比べ、一般にコストが割高で、パフォーマンスが低く、AWS Marketplace では販売の難しいレガシー タイプのインスタンスについて RI を購入するときは注意が必要です。レガシー タイプのインスタンスを購入する場合はまず、選択する予約サービスの損益分岐月が来る前に別のインスタンス タイプ ファミリにアップグレードする予定がないことを確認してください。損益分岐期間は通常、1 年間の予約で 6 か月、3 年間の予約で 9 か月です。一般の組織では、あるインスタンス タイプから別のタイプへの移行を予測した期間よりも長くかかる傾向があります。したがって、レガシー タイプのインスタンスについてリザーブド インスタンスの購入を決定する場合は、損益分岐月が効果的である場合があります。

手順 4：最高値ターゲットの選択

予算は、RI 購入を検討している組織の間で一般的に用いられる制限要因です。初めて RI を購入する場合は、予算に達するまで、上記の手順から RI サービスを限定的に選択します。

RI ビジネス ポリシーの確立

インフラストラクチャのいくつかの変更は、クラウド環境で定期的に実施されます。クラウド環境が拡大するにつれて、これらの変更の監視と管理がますます困難になっています。ビジネス ポリシーは、組織が予約を購入して変更を行う方法と時期を決めるブループリントを作成するための効果的な方法です。

RI 管理のポリシーを確立する際は、次の重要な側面について考慮してください。

• 予算：会計年度または暦年での RI 購入の予算額（暦年あたり 25 万ドルなど）
• 購入頻度：組織が計画する購入頻度（四半期ごとに購入するなど）
• 承認ワークフロー：提案された購入を承認するプロセスへの関与（CTO や CFO が承認した場合など）
• 予約率：ビジネス グループ別のターゲットの予約率（本番 = 75%、本番以外 = 50% など）
• 推奨期間：使用する期間と時期に関する組織のポリシー（インスタンス タイプ ファミリの変更による影響を最小限に抑えるために 1 年間のみコミットするなど）
• 目標のコスト節約：購入を行う前の、目標とする最低限の節約目標、または平均的な目標（たとえば、オンデマンド利用よりも 35% 以上の節約を維持）
• 予約タイプの使用：さまざまなタイプの予約を使用する時期に関する組織のガイドライン
• メンテナンスの頻度：組織が予約の使用状況を確認し、必要に応じて変更または販売を行う頻度

RI 属性の微調整

RI の購入を決定した後、個々の予約について主要な属性を決定します。

サービス クラス

各予約はそれぞれ特定のインスタンス タイプ ファミリ（m4 など）、支払いオプション（全額前払いなど）、ロケーション（us-east-1a など）、OS（Linux など）、およびテナント（共有など）に関連付けられています。組織は、時間の経過とともに、特定のワークロードに応じて実行するインスタンスのタイプに変更を加えることがあります。結果として、予約が未使用のままになったり、マーケットプレイスで再販されたりする状況が不可避になることがあります。また、Amazon がそのインスタンス タイプ ファミリ内で革新を続けるのに伴い、既存のアプリケーションが新しいインスタンス ファミリ上で非常に高いパフォーマンスとコスト効率で実行できる場合があります。パフォーマンスとコスト効率に対する懸念が、一部の組織にとって予約のコミットメントへの決断や 1 年を超えるコミットメントを躊躇させる要因となっていました。

標準 RI

• 1 年または 3 年の期間で購入できます。
• 期間中は、単一のインスタンス ファミリ、ロケーション、プラットフォーム、スコープ、およびテナントにのみ適用できます。
• 購入時に、インスタンスのスコープが特定のアベイラビリティ ゾーンまたはリージョンを対象に規定されます。購入後、アベイラビリティ ゾーンからリージョンまでのスコープを変更できます。容量の予約のメリットは、アベイラビリティ ゾーンにスコープが設定された予約だけに適用されます。
• 同じ構成が設定された別の標準 RI、または構成の異なる標準 RI に入れ替えることはできません。

コンバーティブル RI

コンバーティブル リザーブド インスタンス (RI) には、次の属性があります。

• 1 年間または 3 年間の契約で購入できます。
• さまざまな構成の異なるコンバーティブル RI（インスタンス ファミリ、プラットフォーム、テナント、スコープなど）を対象として交換できます。
• アカウントとリージョンはハード境界であり、変更できません。
• コンバーティブル RI を購入すると、特定のアベイラビリティ ゾーンまたはリージョンにスコープが限定されます。このスコープは、購入後に変更できます。
• コンバーティブル RI を他のコンバーティブル RI と交換できます。交換条件の詳細については、AWS のドキュメントの コンバーティブル リザーブド インスタンスの交換 を参照してください。

コンバーティブル RI は柔軟性に優れているため、若干高価です。また、それらを交換すると、クレジットを受け取ることができません。既存のコンバーティブル RI のコストと同等またはそれ以上のコストを有する新しいコンバーティブル RI の場合のみ、既存のコンバーティブル RI を交換できます。

支払いオプション

RI の支払いで利用できる各オプションは、予約に対して行う支払いの形式に違いがあります。次の 3 つのオプションがあります。

前払いなし

あるアカウントがこのオプションを通じて購入資格を得るには、まず適正な請求履歴がなければなりません。

金額	使用料を前払いしません
期間	標準については 1 年または 3 年、コンバーティブルについては 3 年のみ
割引	27～50%

[前払いなし] の支払いオプションを選択する理由は 2 つあります。

• 予算：翌年の予算で、特定のインスタンス タイプ（m3.large など）に対して一部前払いまたは全額前払いが許可されない場合は、前払いなしのオプションを検討します。オプションによって特定の予約期間に拘束される場合であっても、コスト削減のメリットが得られます。
• コスト削減：各組織がそれぞれ、RI 購入に伴うコスト削減と前払い料金の負担を比較するときに、さまざまな重みを付けて検討します。前払いなしと全額前払いの場合に想定される差がそれほど大きくない場合（5% 未満である場合）は、前払いなしの支払いオプションを検討します。

一部前払い

このタイプの RI は以前、重度予約と呼ばれていました。

金額	使用料の一部を前払いします。期間中で残っている時間が、使用量とは無関係に 1 時間当たりの割引料金で課金されます。
期間	1 年または 3 年
割引	1 年契約で 32～53%、3 年契約で 53～74%

全額前払い

このタイプの RI は以前、固定予約と呼ばれていました。

金額	使用料の全額を前払いします。使用時間には関係なく、期間中の残余時間に対して生じるコストはほかにありません。
期間	1 年または 3 年
割引	1 年契約で 34～53%、3 年契約で 56～75%

[全額前払い] 支払いオプションは、常に最も高いコスト節約を実現します。ただしこれらの節約は、前払い料金という形で追加の現金が支出されることを正当化するのに十分ではありません。以下に 1 年契約の us-east について予約する m3.large インスタンスの評価例を示します。この評価から、全額前払いの予約では、オンデマンド使用に比較して 2% の節約が可能になる一方、一部予約に比べ、追加の $308 の前払いが必要になることがわかります。

	オンデマンド	前払いなし	一部前払い	全額前払い
Amazon への前払い	$0.00	$0.00	$443.00	$751.00
期間を通して 100% で適用される経常的なコスト	$1,226.40	$876.00	$324.12	$0.00
合計実効コスト	$1,226.40	$876.00	$767.12	$751.00
オンデマンドでの節約	n/a	29%	37%	39%

全額前払いの予約は、経済的要因のほか、ときには無用な資産運用や低水準の節約効果といった理由から低く評価される傾向があります。それでも、ケースバイケースでインスタンスの要件を評価することが不可欠です。一方、全額前払いの予約により、最も魅力に富んだコスト削減が可能になると評価されることもあります。

サービス クラスと支払いオプションのマトリックス

サービス クラス	支払いオプション	期間
標準	前払いなし	1 年間
	一部前払い	1 年または 3 年
	全額前払い	1 年または 3 年
コンバーティブル	一部前払い	3 年間
	全額前払い	3 年間

スコープ

スコープの影響を理解するには、RI の種類によっては次の 2 つのメリットが得られることに注意する必要があります。（i）値下げ、（ii）容量の予約。値下げは、目に見えるメリットである一方、容量の予約では、予約期間を通じて指定した種類のインスタンスを起動する権利が保証されます。後者の場合は、クラウドベースのアプリケーションが契約済みの容量に依存していないという理由により、そのメリットが見落とされることがよくあります。RI のスコープはリージョンとアベイラビリティ ゾーンを対象とすることができます。いずれにも値下げが適用されます。詳細については、リージョンとアベイラビリティ ゾーンを参照してください。

アベイラビリティ ゾーン

RI のスコープをアベイラビリティ ゾーンに設定すると、予約したインスタンス タイプについて容量が保証されます。ただし、保証の対象は特定のゾーンで実行される当該タイプのインスタンスに限られます。

さらに容量の保証は、RI の購入時に使用された AWS アカウントだけに限定されます。たとえば、ある主要アカウントで RI を購入し、別のリンク アカウントでこの RI を利用している場合、容量の保証は適用されません。

リージョン

リージョンにスコープが設定された RI には容量の保証は適用されません。ただし、このリージョン スコープの RI は、選択されたリージョンで実行されている同タイプのインスタンスにはいずれについても自動的に適用されます。リージョン スコープの RI は、容量の保証が必要のない状況で効果的です。

リージョン スコープ予約で提供されるサイズの柔軟性

共有テナントと Amazon Linux を使用したリージョン予約には、サイズの柔軟性というメリットがあります。サイズ柔軟性のあるリージョン予約は、サイズやアベイラビリティ ゾーンには関係なく、リージョンで実行されている同じファミリのインスタンスにはすべて自動的に適用されます。

AWS は、リージョン スコープ予約に一定のサイズを割り当てます。サイズは、ユニット数で表されます。この数は、インスタンスのサイズに比例するため、AWS での予約管理が簡素化されます。

サイズの柔軟性によってどのように簡素化が図られるかを次の例で示します。

t2.small 予約を 40 とすると、40 ユニットが割り当てられます。たとえば、リージョン A で t2.small インスタンスを 1 つ、1 時間実行すると、1 ユニットを消費することになります。この消費により、未使用の 39 ユニットを含む予約が残されます。

同じリージョンで t2.medium インスタンスを 1 つ、1 時間実行すると、t2.small 予約の一部が当該の t2.medium 使用量に適用されます。ただしこの場合は、同じ比率に基づいて、t2.small 予約の 2 ユニット分が消費されます。

t2.medium : t2.small :: 1 : 2

この使用量により、t2.small 予約には未使用の 37 ユニットが残されます。ユニットはスケールアップとスケールダウンに対応します。たとえば、同じリージョンで実行する t2.micro インスタンスでは、t2.small 予約からのメリットも得られますが、消費するユニットは 0.5 で済みます。同様に t2.nano インスタンスでの消費は 0.25 ユニット、t2.32xlarge インスタンスでの消費は 256 ユニットになります。

このユニットベースの使用量という考え方は、AWS での正規化係数として説明されています。

リージョン スコープ予約を使用するときは、ユニット数で消費状況を追跡する必要があります。理論的には、大型のリージョン スコープ予約を 1 つ購入することにより、特定ファミリのすべてのインスタンスにこれを適用して、予約の変更はできなくなります。

リージョン スコープ予約は、サイズ制約のない予約であるため、ファミリ中の任意のインスタンスに適用できます。

アベイラビリティ ゾーンとリージョンの選択

次の 2 つの目標を考慮して、RI のスコープをリージョン、またはアベイラビリティ ゾーンのいずれに設定するかを判断します。

目標 1：コスト削減のためだけに予約を購入する。RI を購入する目的がコスト上のメリットだけに限定され、容量上のメリットが重要ではない場合は、予約のスコープをリージョンに設定します。

ポリシーを使用して RI を自動的に変更する場合は必ず、ポリシーで予約スコープが [リージョン] に変更されていることを確認してください。

目標 2：コスト削減と容量上のメリットのために予約を購入する。RI を購入し、容量上のメリットが重要である場合は、予約のスコープをアベイラビリティ ゾーンに設定します。

ポリシーを使用して RI を自動的に変更する場合は必ず、ポリシーの変更でスコープが保持されていることを確認してください。

アカウントと請求

単一の AWS アカウントしか持たない組織が多い一方、複数のアカウントを使用する組織もよく見られます。企業の規模が大きくなると、いくつもの一括請求書を使用したり、数多くのリンク アカウントやスタンドアローン アカウントを併用したりするきわめて複雑なアカウント設定を取り入れる傾向が強くなります。

ベスト プラクティスとして、特に複数のアカウントの間でアベイラビリティ ゾーンに不整合が生じている場合に、具体的なインスタンスの使用状況がはっきりとしたアカウントで予約を購入することが推奨されます。

統合アカウント

1 つ以上の追加アカウントをリンクさせた請求アカウントとしてユーザーにより指定されたアカウントのことです。統合アカウントの請求先コンタクトには、リンクされたすべてのアカウントに対する課金を総計した取引明細書が送付されます。

統合アカウントを使用することにより、RI の購入や管理が簡素化されます。ただし、予約が別のアカウントを使用して行われた場合は、リンクされたアカウントの予約に基づいてインスタンスの起動を保証する能力が失われます。

リンクされたアカウント

一括請求アカウントにリンクされたアカウント。1 つのアカウントがリンクできる一括請求書は 1 つに限られます。

このアカウントを使用すると、RI の購入や管理が煩雑になります。ただしこのアプローチでは、RI に伴う減額と容量の保証が同時に得られます。

スタンドアローン アカウント

個別の取引明細書を受け取るアカウントのことで、一括請求アカウントにはリンクされません。

GovCloud アカウント

このアカウントは、統合アカウント、またはスタンドアローン アカウント（「商用アカウント」）のいずれかに関連付けられていなければなりません。関連付けられると、請求額と使用量がすべて同じアカウントからの請求であるようにまとめて報告されます。

一括請求書

組織は、複数のアカウントを一括請求書にリンクさせて、RI に各アカウントの間で「浮動」させる機能を確保する傾向があります。

1 つの統合アカウント、または統合アカウントにリンクされたアカウント（請求ファミリ）のいずれかを使用して、RI を購入する場合を考えてみます。一定の時間内で、アカウントに RI の使用状況が表示されない場合、この予約は、一括請求を通じてリンクされた別のアカウント内で対応するインスタンスの使用量に浮動している可能性があります。

デフォルトの場合、予約にはこれが購入されたアカウントに対するアフィニティが生まれます。予約が浮動するのは、当該の予約から利益が生じるはずのアカウントでインスタンスの利用が見られない場合に限られます。RI による減額のメリットも、一括請求書内の各アカウントで浮動しますが、容量の予約は浮動しません。アカウント A で利用可能な予約がある場合、AWS ではアカウント B で同等のインスタンスを起動できます。ただし、これらのアカウントが同じ一括請求アカウントにリンクされている場合のみです。

アベイラビリティ ゾーンの不整合

アベイラビリティ ゾーンは、アカウントの作成時に特定のアカウントに割り当てられます。複数のアカウントを使用している場合は、すべてのアカウントが同じアベイラビリティ ゾーンを共有しているとは限りません。たとえば A、B、C のアカウントがある場合、us-east リージョンのアベイラビリティ ゾーンは次のようになります。

アベイラビリティ ゾーン	アカウント A	アカウント B	アカウント C
us-east-1a	✓	✓
us-east-1b	✓		✓
us-east-1c	✓	✓	✓
us-east-1d	✓	✓	✓
us-east-1e		✓	✓

使用するアカウントが 1 つの場合、またはスタンドアローン アカウントだけの場合、この不整合によって生じる影響はありません。ただし、1 つの一括請求アカウントに複数のアカウントがリンクされている場合は、この不整合によりアカウント間の浮動に影響が生じることがあります。上の例で、アカウント A と C が同じ統合アカウントにリンクされている場合を考えてみます。アカウント A で us-east-1a の予約を購入した場合、この予約は、us-east-1a のアベイラビリティ ゾーンがないアカウント C に浮動することはありません。

RI アクションの承認プロセスの設定

RI の購入、維持、販売は複雑なプロセスです。RI の属性（インスタンス タイプ、範囲、期間、提供クラスなど）を決定することに加えて、チーム、アプリケーション、および機能領域全体の使用率を予測する必要があります。

VMware Aria Cost powered by CloudHealth は、実装される前に承認プロセスを通じて実行されるアクションを通じて、RI の購入を自動化するのに役立ちます。このアプローチにより、認証とセキュリティを損なうことなく、手間がかかり、ミスが発生しやすい RI 管理のプロセスを自動化できます。

承認者と権限付与者の定義

VMware Aria Cost で承認プロセスによって実行されるアクションを構成して、RI 管理のさまざまな側面を自動化することができます。アクションは、以下のユーザーの少なくとも 1 人の承認を通る必要があります。

• 承認者：要求されたアクションが許容可能であることを検証する責任があります。アクションがトリガされると、アクションを承認する必要があることを知らせる E メール通知を受信します。承認すると、アクションは、次の順番の承認者に渡されます。
• 認証者：すべての承認者がアクションに対して署名した後、要求は、一時的な最小特権トークンをプロビジョニングするために認証者に送信されます。このトークンにより、トークン ベアラーが AWS Security Token Service を使用して要求を作成できるようになります。VMware Aria Cost は、このトークンを使用してユーザーに代わってアクションを実行します。

アクションの設定

1. セットアップ > ガバナンス > アクション を選択して、事前構成済みのアクションを表示します。また、独自のアクションを作成することもできます。EC2 RI 管理に対して事前構成された次の 2 つのアクションが提供されます。
   • Amazon EC2 リザーブド インスタンスを変更する
   • Amazon EC2 リザーブド インスタンスを購入する。更新 をクリックすると、これらの事前構成されたアクションに 1 人以上の認証者を追加できます。
2. または、独自のアクションを作成して、承認者と認証者のチェーンを作成します。アクションを作成 をクリックします。
3. アクションを作成する一連のイベントを作成します。例：
   • RI 変更の承認を取得する
   • RI 変更の権限を取得する
   • Amazon EC2 リザーブド インスタンスを変更する

EC2 RI オプティマイザを使用した RI 購入決定の簡素化

正確で効率的な RI 購入を決定することは大変な作業で、時間と手間がかかる、間違いが発生しやすい分析が必要になることがよくあります。

EC2 RI オプティマイザは、AWS インスタンスを評価して、RI の使用によるメリットを得られるかどうかを判断します。評価の際に、オプティマイザは以前の使用量を分析し、指定された予算での最適な購入を特定します。

VMware Aria Cost は制約ベースのアルゴリズムを使用します。これにより、従来の「ナップサック問題」に対して欲張り法を採用して推奨を行うことができます。この分析は、一定期間にわたる時間単位のオンデマンドの使用量を確認することで実行されます。このアルゴリズムでは、予算の制約内で最適な予約購入を行うために、1 つまたは複数のそれほど効率的ではないオプションを効率的なオプションとトレードオフします。ここでの目標は、予算、購入日、フィルタなど、指定した制約に対して最適な推奨事項を提供することです。

前提条件: コストと使用状況レポート (CUR) の有効化

AWS のコストと使用量レポート (CUR) は、製品、価格設定、使用量などのコストに関する包括的なデータを提供します。詳細については、AWS のコストと使用状況レポートを参照してください。

EC2 RI オプティマイザを使用してオンデマンドの使用量を評価する前に、CUR を有効にします。

CUR が有効になっていない場合はどうなりますか

RI オプティマイザによって提示される推奨事項は、使用率の低い、サイズに柔軟性のある予約を持つ EC2 インスタンス ファミリに対しては不正確になる場合があります。

CUR には何日分のデータが必要ですか

30 日以上のデータが必要です。CUR を最近構成したばかりで、30 日未満のデータしかない場合、VMware Aria Cost は、その部分的な履歴に基づいて適切な分析と推奨事項を提示します。このプラットフォームでは、サイズに柔軟性のある RI に関係しないデータで入力された古いレポートを表示するオプションを提供する警告も表示されます。

手順 1：見積もりの作成

EC2 RI オプティマイザは、ユーザーが作成した見積もりに基づいてインスタンスの使用量と要件を分析します。既存の見積もりを変更または削除し、見積もり内で購入を実行することもできます。

1. 推奨事項 > 予約 > EC2 RI オプティマイザ を選択します。

2. アクション > 新規見積もり を選択します。

   CUR を有効にしていない場合、オプティマイザで指定したアカウントと期間について、VMware Aria Cost は完全な予約履歴を受信しません。結果として、オプティマイザの推奨事項が不完全な情報に基づくもので、不正確となる可能性があります。デフォルトでは、VMware Aria Cost は予算に制限を設けることなく、インスタンスの 100% に近いカバレッジを提供する RI 購入を提案します。提案は、インスタンスの現在および過去のオンデマンド使用量に対する 1 時間単位の分析に基づいています。

   VMware Aria Cost は、見積もりに対する変更を自動保存しません。変更を行うたびに、見積もりの右上隅で アクション > 保存 の順にクリックして、変更内容を保持します。

手順 2：見積もりオプションの構成

見積もりを作成するときに VMware Aria Cost が設定するデフォルトのオプションを確認します。オプションを変更するときは、クラウド環境に最適な設定を検討します。

• 分析する期間：オンデマンドの使用量を分析する期間を指定します。今後予想される使用量を最も反映した期間を選択します。ベスト プラクティスとして直近 1 か月の使用量を分析することをお勧めします。より動的な環境を実現する場合は期間を短縮し、より静的な環境を実現するには長めの期間を使用します。現在 を選択すると、オプティマイザは最新の使用可能な使用量データのみを参照し、それに基づいて推奨事項を作成します。
• 推奨期間：3 年間の契約では、コストを大幅に削減できますが、ユーザーは期間中に新しいインスタンス タイプを利用できるようになる可能性に備えて 1 年の期間を選択する傾向があります。
• ターゲット カバレッジ：推奨事項を制約するために使用する最大有効カバレッジを指定します。カバレッジは、予約によってカバーされる使用量の割合として定義され、次のように計算されます。

  Coverage = Reserved hours / (Reserved hours + On-demand hours)
  

ほとんどの使用量パターンでは、100% のカバレッジは経済的に最適化されていません。

• 購入予定日：この日付は、予定されている購入の前に期限切れとなる既存の予約がある場合に重要です。日付を選択すると、オプティマイザは期限切れとなる予約を考慮し、更新が予算の制約の対象に含まれるようになることが保証されます。
• 購入アカウント：統合アカウントを選択するか、すべて を選択して、使用量があるアカウントで購入を行います。
• サービス タイプ：分析に使用しない支払いオプションをオフにします。たとえば、一部の組織では、すべて先行 の支払いオプションを使用しないことを考えている場合があります。
• 節約量が X% 未満の場合はより低い前払い予約タイプを選択：この設定は、支払いオプション間の節約量の差異が指定された割合より小さい場合に、支払いオプションをダウングレードします。たとえば、「先行なし」RI に対して、「部分的な先行」RI の購入による節約量が 3 % 未満である場合、推奨事項のダウングレードとして、「部分的な先行」RI よりも前払い金額が少ない「先行なし」RI の購入を提案します。
• キャパシティの予約：アベイラビリティ ゾーンでのキャパシティを確保する場合に選択します。このオプションがオンになっている場合、オプティマイザは、アベイラビリティ ゾーンをスコープとしている RI の購入を推奨します。それ以外の場合、オプティマイザはリージョンをスコープとしている RI の購入を推奨します。
• コンバーティブルを使用：コンバーティブル RI オプションのみを検索する場合にオンにします。

手順 3：インフラストラクチャのサブセットへの見積もりの制限

EC2 RI オプティマイザを使用すると、見積もりをインフラストラクチャのサブセットに限定できます。たとえば、特定のアカウント、リージョン（us-east など）、インスタンス タイプ（m3 インスタンス タイプなど）、機能（Elasticsearch クラスタなど）、またはビジネス グループ（マーケティング部門など）に対して、RI の購入が必要になる可能性があります。

拡張オプション セクションの フィルタ 機能を使用して、RI 見積もりについてインフラストラクチャの特定のサブセットをターゲットにします。

インフラストラクチャのサブセットに対して複数の RI 購入を行う場合は、重複するインフラストラクチャをターゲットにすることについて注意してください（たとえば、同じアカウントの使用量を 2 回含む見積もりを作成することなど）。この操作により、予約の購入過多が発生する可能性があります。

アカウント フィルタの影響

請求ファミリ内で RI を購入すると、EC2 オプティマイザは、分析期間の開始から RI 購入日までの期間の EC2 使用量データをバックフィルします。このバックフィルにより、該当する期間の請求ファミリにおける EC2 インスタンスの使用量に対して、RI が正しく適用されます。

追加のアカウント フィルタを適用しない場合、バックフィル プロセスは分析期間の RI のニーズを正確に反映します。

アカウント フィルタを適用しても、VMware Aria Cost は、請求ファミリに関連付けられているすべての新しい RI を考慮して、EC2 使用量データをバックフィルします。ただし、バックフィルのプロセスでは、フィルタリングで除外したアカウントの使用量のみが考慮されます。実際には、VMware Aria Cost は、使用量が低いインスタンスに対して同じ数の RI を適用します。このプロセスにより、RI の購入が推奨未満となる可能性があります。

オプション および フィルタ を設定した後で、オプティマイザの実行 をクリックします。

手順 4：推奨事項の確認

評価を実行した後、オプティマイザは RI 購入の推奨事項を返します。推奨事項には、概要および詳細なサマリの両方が含まれます。

概要のサマリを確認する

このセクションでは、次の情報について説明します。

• インスタンス：推奨事項として、実行中インスタンスの時間単位の平均数を示します。
• 購入する予約：オプティマイザが購入を推奨する新しい予約の数を示します。
• カバレッジ：推奨される予約で、環境が享受する有効なカバレッジ。[ターゲット カバレッジ] フィールドで 100% を指定したのに、カバレッジが 100% を下回る理由は何ですか
  カバレッジは、「予約時間数/（予約時間数 + オンデマンド時間数）」として計算されます。ほとんどの使用パターンでは、100% のカバレッジは経済的に最適ではありません。予算上の制約が適用されていない場合にオプティマイザが提供する推奨事項は、現在の使用パターンについての、完全に最適化の予約購入です。この一連の推奨事項では、いくつかのレベルのカバレッジが提供されますが、100% 未満になる可能性があります。完全に最適化された推奨セットによって提供される有効なカバレッジの割合は、オプティマイザが特定の環境と使用パターンに対して提案する最大カバレッジです。
• 初期コスト: 推奨事項に対する、先行支払いの合計金額
• 損益分岐点：回収を達成する月数
• コスト節約：この推奨購入によって実現される追加のコスト節約。
• 月単位のコスト節約：償却される前払いなど、この推奨購入によって実現される月単位のコスト節約。
• 年単位のコスト節約：償却される前払いなど、この推奨購入によって実現される年単位のコスト節約。

詳細なサマリを確認する

このセクションでは、各固有の推奨事項に関する情報を提供します。各アカウントの情報に加えて、このセクションには各提案の概要が示されます。

サイズに柔軟性のある推奨事項のみがインスタンス ファミリごとにグループ化され、サイズに柔軟性のあるファミリの各インスタンス タイプは別の行に記載されます。推奨事項のサマリの各行には、次の情報が含まれています。

• インスタンス タイプ: 予約のファミリおよびサイズ
• アカウント: この予約が購入されるアカウント
• OS：リザーブド インスタンスのオペレーティング システム
• テナント: リザーブド インスタンスのテナント
• インスタンス：実行中インスタンスの時間単位の平均数
• 正規化されたインスタンス：インスタンス サイズで正規化された実行中インスタンスの時間単位の平均
• 現在：既存の予約の数
• 購入：購入するために推奨される新しいインスタンスの数
• 前払い：予約に対する、合計の前払い金額
• カバレッジ：推奨される予約での有効なカバレッジ
• 現在の月単位：オンデマンド インスタンスおよび既存の予約の現在の月単位コスト
• 月単位の予測：予約や、その他のオンデマンド コストを含む、予測された購入後の月単位コスト
• 現在の年単位：オンデマンド インスタンスおよび既存の予約の現在の年単位コスト
• 年単位の予測：予約や、その他のオンデマンド コストを含む、予測された購入後の年単位コスト

提案された予約がレガシー インスタンス タイプ用の場合、レガシー インスタンス タイプから移行することを推奨する警告メッセージが表示されます。

%VPC 列は、最適化されている使用量のうち、Virtual Private Cloud (VPC) 内で実行されていると判断された使用量の割合を示します。予約を購入する場合は、予約を VPC または従来（非 VPC）のインスタンス用とするべきかどうかを指定します。従来のインスタンスと VPC インスタンスの両方で、価格削減のメリットが得られます。VPC 予約を購入したときに、特定の時間内に同等のインスタンスが実行されていない場合、その予約は、従来の（非 VPC）インスタンスを実行している同等のものに適用できます。ただし、キャパシティ予約の保証は、起動するインスタンスのタイプ（従来または VPC）によって異なります。このため、従来の予約を作成した場合、同様の VPC インスタンスを起動すると、キャパシティの保証はありません。その逆の操作についても同様です。詳細については、Amazon VPC に関するよくある質問 を参照してください。

手順 5：推奨事項の変更

EC2 RI オプティマイザは、設定するオプションに基づいて推奨事項を提示します。ただし、これらの推奨事項を変更することもできます。

たとえば、us-east-1a での Linux を実行している m3.large の使用量に対して 10 個の一部前払い予約の購入をオプティマイザが推奨した場合は、このインスタンス タイプに影響を与える負荷が将来的に軽減されることが予想される場合、7 個のみを購入することを選択できます。

ファミリ レベル（サイズに柔軟性のある予約の場合）またはインスタンス タイプ別に変更を加えることができます。見積もりから特定の行を削除することもできます。推奨事項のサマリで任意の行をクリックして、変更します。

[推奨される使用量] ビューには、タイプ別の推奨される RI 使用量に重なる形でオンデマンド使用量が表示されます。このビューは、現在の使用量を確認し、VMware Aria Cost がこの費用を RI 購入でどのように管理することを推奨しているかを確認するのに役立ちます。

さらに、このビューには推奨事項の次の主要な属性が表示されます。

• 価格設定：使用可能なサービス タイプに応じて購入したユニットあたりの初期コスト、月次コスト、および有効コストです。初期費用と月次コストは、ユーザー固有の価格設定に基づいています。これは、階層化された割引やカスタム価格設定プランによる影響を受けます。VMware Aria Cost は、すべての使用量について、AWS からの時間単位のコストの概要を提供する詳細請求レコード (DBR) からこの価格設定を導出します。ユーザーの価格設定が利用できない場合は、オンデマンドの価格が表示されます。
• オンデマンドでの節約：予約の 100% の使用量についてのオンデマンドの使用量に対する節約量の割合です。
• 数量：各サービス タイプごとに予約の数を調整できる、編集可能なフィールドです。
• コスト：[価格設定] 列と [数量] 列を掛けた値です。
• 月単位のコスト節約：提案された予約購入を完全に活用した場合に予想される月単位の請求の削減額です。
• 期間コスト：この予約について、すべての使用量に基づき支払う合計金額です。このコストには、初期費用と定期的な月次コストの両方が含まれます。

手順 6：注文を行う

見積もりをカスタマイズしたら、注文をエクスポートできます。

リザーブド インスタンスを購入する方法は 3 つあります。

• VMware Aria Cost の使用：リザーブド インスタンスを購入するための承認ワークフローを構成します。次に、[見積もりのサマリ] ページの 購入 ボタンをクリックします。

  この操作により、予約購入の承認に対する要求が開始されます。承認者と権限付与者の両方が要求を確認すると、購入が実行されます。

• Amazon アカウントの担当者経由：見積もりを確認し、アクション > 注文のエクスポート を選択して、Amazon アカウントの担当者と共有できるファイルをダウンロードします。

• AWS コンソール経由：AWS コンソールから購入を行うには、[注文] タブの情報を使用します。予約を使用しているアカウントで購入することを選択した場合は、各アカウントの AWS コンソール内で購入を行う必要があります。

EC2 RI Modifier を使用した予約の変更

VMware Aria Cost では、次の方法（複数も可）を使用して、設定済みの予約や特定のサブセットに関連付けられたすべてのインスタンスに対するカバー範囲を変更することができます。

• 同じリージョン内のアベイラビリティ ゾーンを切り替える
• EC2-VPC と EC2-Classic を切り替える
• 同じインスタンス ファミリの中でインスタンス タイプを変更する

EC2 RI Modifier は、リザーブド インスタンスやインスタンスの使用量を分析し、コストの節約のための変更を検討すべき推奨事項を提示します。

使用量計算の基準の指定

1. 推奨事項 > 予約 > EC2 RI Modifier の順に選択します。

2. 基準を指定するときに VMware Aria Cost で設定されるデフォルトのオプションを確認します。オプションを変更するときは、クラウド環境に最適な設定を検討します。

   • 使用量の計算期間：使用量の分析の対象とする期間を指定します。[現在]、[昨日]、[過去 7 日間]、[過去 30 日間]、[1 か月前から今日まで] の各オプションがあります。
   • 最小変更節約：節約のしきい値を指定します。どのような変更を行っても、この値を下回る節約はレポートには記載されません。
   • キャパシティの予約：アベイラビリティ ゾーンでのキャパシティを確保する場合に選択します。
3. オプションを指定した後、更新 をクリックします。

推奨事項の確認

Modifier は、分析を実行した後、RI の変更に関する推奨事項を提示します。月間予測節約合計 フィールドは、基準を満たすすべての推奨事項の合計を表します。

1. 推奨事項の行項目をクリックすると、提案された変更に関する追加の詳細が表示されます。
2. リザーブド インスタンス購入の承認ワークフローをまだ設定していない場合は、ここで行ってください。
3. 1 回の変更で複数の予約を同時に変更する場合は、アクション > Amazon EC2 リザーブド インスタンスの変更 の順にクリックします。別の方法として、行項目の横のボックスをクリックし、一括操作 > Amazon EC2 リザーブド インスタンスの変更 の順に選択しても、複数の変更を実行できます。このアクションにより、予約変更の承認に対する要求が開始されます。Approver と Authorizer の両方が要求を確認すると、変更が開始します。

コンバーティブル リザーブド インスタンスの交換

コンバーティブル リザーブド インスタンスについて

コンバーティブル リザーブド インスタンス (RI) には、次の属性があります。

• 1 年または 3 年の期間で購入できます。
• さまざまな構成の異なるコンバーティブル RI（インスタンス ファミリ、プラットフォーム、テナント、スコープなど）を対象として交換できます。
• アカウントとリージョンはハード境界であり、変更できません。
• コンバーティブル RI を購入すると、特定のアベイラビリティ ゾーンまたはリージョンにスコープが限定されます。このスコープは、購入後に変更できます。
• コンバーティブル RI を他のコンバーティブル RI と交換できます。交換条件の詳細については、AWS のドキュメントの コンバーティブル リザーブド インスタンスの交換 を参照してください。

コンバーティブル RI は柔軟性に優れているため、若干高価です。また、コンバーティブル RI を交換するときにクレジットを受け取ることはありません。既存のコンバーティブル RI のコストと同等またはそれ以上のコストを有する新しいコンバーティブル RI の場合のみ、既存のコンバーティブル RI を交換できます。

コンバーティブル RI の管理における主な課題

コンバーティブル RI を使用する VMware Aria Cost ユーザーにとって最大の課題は、コンバーティブル RI が正常に活用されていることを確認することです。これらの課題は以下の特定の領域に集中しています。

• 使用率の低いコンバーティブル RI を特定する。
• コンバーティブル RI の移行への最適な候補となる、オンデマンドで実行されているインスタンスを特定する。
• コンバーティブル RI に最も効率的に移行する候補を選択する。ここで重要なのは、追加投資を抑えながらコストを最大限削減することです。
• これらの候補が特定されたら、交換見積もりを作成し、AWS コンソールを使用して交換を手動で実行します。

コンバーティブル リザーブド インスタンス エクスチェンジャについて

コンバーティブル リザーブド インスタンス エクスチェンジャは、追加投資を抑えながら、AWS インフラストラクチャ内の使用率の低いコンバーティブル RI からのコスト回収を支援するツールです。この場合の投資は次のように定義されています。

Investment = True-up cost + Additional hourly commit charges

調整コストは、旧（交換前）と新（交換後）のコンバーティブル予約の差について、日割り計算された初期コストです。

エクスチェンジャは次の操作を実行します。

• 使用率の低いコンバーティブル リザーブド インスタンスを特定する
• オンデマンド使用の候補を特定する
• 最も効率的な候補を選択する
• AWS コンソールを使用して手動で交換を行うために使用できる見積もりを作成します。

Compute Savings Plan とエクスチェンジャ

エクスチェンジャは、Compute Savings Plan の対象となる使用率ではなく、オンデマンドの使用率を対象とすることに重点を置いています。Compute Savings Plan はどちらも非常に動的で、コンバーティブル RI に同等の割引を提供します。そのため、エクスチェンジャは、RI が使用されなくなる別の推奨事項を作成する場合があります。

Compute Savings Plan の対象となる使用率が多い場合は、評価期間の開始を最新の CRI 交換後に設定し、交換の推奨事項が Compute Savings Plan を補完するようにすることをお勧めします。

エクスチェンジャの仕組み

エクスチェンジャの目的は、最小の投資で最大のコスト削減額を提供する交換を推奨することです。つまり、エクスチェンジャは交換による ROI を最大化し、コストを削減する一連の交換に関する推奨事項を生成します。以下はエクスチェンジャの仕組みです。

1. 使用率が低いためにコストを損失しているアクティブなコンバーティブル RI をすべて特定し、それらを交換の機会として示します。使用率が低い RI について知りたい場合は、EC2 の使用率の低い RI レポート（プラットフォーム内の レポート > 使用率 > EC2 の使用率が低い RI）をご覧ください。EC2 使用率が低い RI レポートには、標準 RI とコンバーティブル RI の両方が表示されます。結果として、エクスチェンジャに表示される推奨事項は、レポートに表示される情報と直接的には一致しません。ただし、このレポートを使用して、推論を行うことができます。
2. 交換の機会を最小の ROI から最大の ROI までランク付けします。
3. RI を使用してカバーするオンデマンドの使用パターンを特定します。それらをコスト削減の機会として示します。オンデマンドの使用パターンを理解するには、EC2 インスタンス レポート（プラットフォーム内の レポート > 使用率 > EC2 インスタンス）をご覧ください。
4. コスト削減の機会を最大の ROI から最小の ROI までランク付けします。
5. 最高のコスト削減の機会をインテリジェントに選択し、交換の機会を最も効率的に組み合わせてそれをカバーします。RI のサイズ フレキシビリティ プロパティを使用してコスト削減の機会を変更する場合、エクスチェンジャによっても変更が提案されます。最も効率的な組み合わせにより、調整コストを削減しながら、コスト削減を最大化できます。
6. 交換推奨事項によってコストが削減されることを確認します。

エクスチェンジャの操作

交換見積もりの作成

推奨事項 > 予約 > EC2 CRI エクスチェンジャ の順に移動して、選択します。エクスチェンジャは直ちに実行され、コスト削減と交換の両方の機会を特定します。予算を指定し、フィルタを使用して推奨事項を制約することができます。

見積もりの作成時に選択したアカウントの一部で、推奨事項が表示されない理由

見積もりの作成時、交換推奨事項を提示する際に、エクスチェンジャが考慮すべきアカウントを指定できます。アカウントが推奨事項で表示されない場合、以下の条件の 1 つ以上が満たされていない可能性があります。

(a) VMware Aria Cost は、エクスチェンジャの [評価期間] に指定した期間全体について、アカウントのコストと使用状況レポート (CUR) のデータにアクセスすることはできません。

(b) VMware Aria Cost には、アカウントから EC2 予約情報を読み取るための IAM 権限がありません。

過去 30 日の期間ではなく、評価期間が 7 日または月初来である場合にのみ結果が表示される理由

このシナリオは、VMware Aria Cost が、コストと使用状況レポート (CUR) から 30 日未満のデータにアクセスできる場合に発生します。

交換推奨事項について詳しく見ていく

詳細な推奨事項セクションで明細項目のいずれかをクリックすると、モーダルにその推奨事項が表示されます。

最後の行を除き、モーダルの各行には、交換を検討すべき既存のソース予約注文の一部が記載されています。最後の行には、推奨される交換が表示されます。

ソース予約について説明する 2 バリアントの行があります。

バリアント 1：ソース予約を現状で交換する

このバリアントでは、既存のソース予約注文を現状のままで交換します。交換の終了時には、注文の RI は残りません。

バリアント 2：交換前にソース予約を変更する

このバリアントでは、既存のソース予約注文を変更します。交換後に、その注文の一部の RI はインベントリに残ります。この変更を提案する際、エクスチェンジャは、残りの RI を別の交換に対して使用する機会を探します。

残りの値： (Remaining upfront cost + Remaining commitment) 月単位の浪費：予約の非収益性の測定。これは、オンデマンドでインスタンスを実行する場合と比較して、予約を取ることの高価さの程度として計算されます。

交換推奨事項のエクスポート

エクスチェンジャが生成する推奨事項を CSV としてエクスポートできます。次に、CSV の情報を使用して、AWS コンソールで交換を実行します。

VMware Aria Cost は、ユーザーが AWS コンソールで交換操作を実行できるように、2 つの CSV ファイルを生成します。

• 最初の CSV ファイルには、すべての交換推奨事項が一覧表示されます。
• 2 番目の CSV ファイルには、交換を有効にするために必要なすべての変更が一覧表示されます。

ファイルには、必要な変更と交換の詳細が含まれています。交換前に変更が必要となる各予約注文の ID は特に重要です。AWS コンソールを使用して交換を処理する場合にはこれらの ID が必要です。

VMware Aria Cost を介した交換の自動化

交換の見積もりを作成すると、VMware Aria Cost を使用して、見積もり内の 1 つ以上の交換を自動化できます。VMware Aria Cost が交換を実行することを許可するか、認証ワークフローを利用して交換を開始することができます。

コンバーティブル RI を交換するための自動化レベルの選択

選択できる自動化には 2 つのタイプがあります。

オプション	要件
交換アクションを組織内の権限付与者に委任する	交換アクションを有効にして、認証者を選択します。認証者はアクションの要求が承認されると、AWS Security Token Service を使用して一時的な最小権限トークンをプロビジョニングします。VMware Aria Cost は、このトークンを使用して認証者に代わってアクションを実行します。
VMware Aria Cost による交換の実行を許可する	コンバーティブル RI を交換するための VMware Aria Cost IAM ポリシー権限を更新します。

オプション 1：交換アクションを認証者に委任する

このオプションでは、VMware Aria Cost を使用して、IAM ポリシーを介して権限を交換の実行を許可する AWS ユーザーに提供します。

交換を自動化するアクションの構成

1. 左側のメニューから セットアップ > ガバナンス > アクション の順に選択します。
2. 右側の 使用可能 アクション リストをナビゲートします。Amazon EC2 リザーブド インスタンスを交換する アクションを探して、セットアップ をクリックします。
3. 表示される セットアップ ダイアログ ボックスで、認証者の名前を入力します。認証者が、交換を開始したときに通知を受け取ります。その後、権限付与者は自動化された交換を開始するために通知に付随するプライベート キーを提供する必要があります。認証者の名前を入力しない場合は、アカウントに関連付けられている IAM ポリシーに正しい権限が存在することを条件として、VMware Aria Cost が代わりに交換を実行します。
4. 調整費用のしきい値 を指定します。これはデフォルトで 5% に設定されています。このしきい値を指定する必要がある理由 ベスト プラクティスとして、見積もりの生成時間に可能な限り近いところで、交換アクションに対する承認を取得します。このアプローチにより、調整費用における差異を大幅に削減できます。コンバーティブル RI の交換における調整費用は、トランザクションの動的な性質上、一時的なものとなります。VMware Aria Cost が見積もりを生成してから交換を実行するまでの間に、実際の調整費用は見積もりで指定されているものと差異が生じる場合があります。その差異が指定したしきい値を超えると、VMware Aria Cost は交換アクションの実行を許可しません。
5. アクションを保存 をクリックします。

IAM ポリシーの更新

認証者に関連付けられた IAM ポリシーがある場合は、そのポリシーにこれらの権限を追加して、VMware Aria Cost が認証者の代わりに交換を実行できるようにします。

1. 管理者として AWS コンソールにログインします。サービス > IAM の順に移動し、左側のメニューから ポリシー を選択します。
2. 認証者の権限を管理するために使用するポリシーを特定します。

3. 次のセクションをコピーして、[ポリシー ドキュメント] フィールドに貼り付けます。

   {  
      "Effect": "Allow",  
      "Action": [  
          "ec2:ModifyReservedInstances",  
          "ec2:DescribeReservedInstancesOfferings",  
          "ec2:GetReservedInstancesExchangeQuote",  
          "ec2:AcceptReservedInstancesExchangeQuote"  
      ],  
      "Resource": "*"  
   }
   

4. ポリシーの適用 をクリックします。

自動化された交換の開始

1. 左側のメニューから、推奨事項 > 予約 > EC2 CRI エクスチェンジャ を選択します。選択した評価期間に基づく見積もりが表示されます。
2. 見積もりから 1 つ以上の交換を選択し、交換 をクリックします。すでに進行中の交換がある場合は、新しい交換を開始することはできません。
3. VMware Aria Cost によって交換のトランザクションがキューに入り、認証者に通知されます。認証者は、VMware Aria Cost が交換を実行するために使用する最小権限トークンを提供する必要があります。認証フローに対してプロビジョニングされる STS トークンは 60 分間有効です。交換は、承認/認証から完了までに約 15 分から 60 分かかります。

4. ステータスと履歴 タブをクリックして、交換アクションのステータスを確認します。
   交換アクションにより、以下のステータスが循環します。
   保留中：アクションがキューに登録されました。
   失敗：バッチ内の 1 つ以上の交換に失敗しました。
   完了：アクションが正常に完了した、またはバッチ内の交換の部分的な障害が発生した状態です。

   該当のアクションをクリックして詳細を確認します。

オプション 2：VMware Aria Cost による交換アクションの実行を許可する

このオプションでは、プラットフォームで AWS アカウントに対して構成した IAM ロールに関連付けられているポリシーを編集します。

IAM ポリシーの更新

1. 左側のメニューから セットアップ > アカウント > AWS を選択し、ユーザーの代わりに VMware Aria Cost による交換の実行を許可するアカウントを編集します。
2. [自動化] セクションに移動し、Amazon EC2 リザーブド インスタンスを交換する のオプションをオンに切り替えます。

3. アカウントの設定ページの一番下までスクロールし、ポリシーの生成 をクリックします。次のセクションがポリシーに追加されます。

   {  
      "Effect": "Allow",  
          "Action": [  
              "ec2:ModifyReservedInstances",  
              "ec2:DescribeReservedInstancesOfferings",  
              "ec2:GetReservedInstancesExchangeQuote",  
              "ec2:AcceptReservedInstancesExchangeQuote"  
          ],  
          "Resource": "*"  
   }
   

4. ポリシーをコピーして貼り付けます。
5. 管理者として AWS コンソールにログインします。サービス > IAM の順に移動し、左側のメニューから ポリシー を選択します。
6. IAM の管理に使用しているポリシーを見つけます。更新されたポリシーを ポリシー ドキュメント フィールドに貼り付けます。次に ポリシーの適用 をクリックします。

交換を自動化するアクションの構成

1. 左側のメニューから セットアップ > ガバナンス > アクション の順に選択します。
2. 右側の 使用可能 アクション リストをナビゲートします。Amazon EC2 リザーブド インスタンスを交換する アクションを探して、セットアップ をクリックします。
3. 表示される セットアップ ダイアログ ボックスで、認証者の名前を入力します。認証者が、交換を開始したときに通知を受け取ります。その後、権限付与者は自動化された交換を開始するために通知に付随するプライベート キーを提供する必要があります。
   認証者の名前を入力しない場合は、アカウントに関連付けられている IAM ポリシーに正しい権限が存在することを条件として、VMware Aria Cost が代わりに交換を実行します。
4. 調整費用のしきい値 を指定します。これはデフォルトで 5% に設定されています。

   このしきい値を指定する必要がある理由 ベスト プラクティスとして、見積もりの生成時間に可能な限り近いところで、交換アクションに対する承認を取得します。このアプローチにより、調整費用における差異を大幅に削減できます。コンバーティブル RI の交換における調整費用は、トランザクションの動的な性質上、一時的なものとなります。VMware Aria Cost が見積もりを生成してから交換を実行するまでの間に、実際の調整費用は見積もりで指定されているものと差異が生じる場合があります。その差異が指定したしきい値を超えると、VMware Aria Cost は交換アクションの実行を許可しません。

5. アクションを保存 をクリックします。

自動化された交換の開始

1. 左側のメニューから、推奨事項 > 予約 > EC2 CRI エクスチェンジャ を選択します。選択した評価期間に基づく見積もりが表示されます。
2. 見積もりから 1 つ以上の交換を選択し、交換 をクリックします。すでに進行中の交換がある場合、新しい交換を開始することはできません。 
3. VMware Aria Cost は交換トランザクションをキューに入れます。AWS アカウントに関連付けられている IAM ポリシーに適切な権限が存在する場合、VMware Aria Cost は交換を実行します。交換は、承認/認証から完了までに約 15 分から 60 分かかります。
4. ステータスと履歴 タブをクリックして、交換アクションのステータスを確認します。
   交換アクションにより、以下のステータスが循環します。
   保留中：アクションがキューに登録されました。
   失敗：バッチ内の 1 つ以上の交換に失敗しました。
   完了：アクションが正常に完了した、またはバッチ内の交換の部分的な障害が発生した状態です。
   該当のアクションをクリックして詳細を確認します。

予約されたインスタンスの使用量の分析

リザーブド インスタンスの使用率の定期的な分析が重要である理由

インスタンスをオンデマンドで実行するアプローチは柔軟性を提供しますが、コストを押し上げる可能性もあります。AWS のリザーブド インスタンス (RI) を使用すると、コンピューティング コストの割引と引き換えに、AWS に前払いの金銭的コミットメントを行うことができます。「リザーブド インスタンスについて」を参照してください。

クラウド インフラストラクチャは非常に変化が激しいため、ユーザーの RI の使用率は、時間の経過につれて「ドリフト」になることがよくあります。たとえば、us-east-1a で Linux 用に 10 個の m3.large 予約を購入するとします。その後、チームはインスタンスを他のアベイラビリティ ゾーンに移動して、一部の RI を未使用にすることを決定する場合があります。環境が動的であればあるほど、RI の有効な使用率全体でドリフトが発生する可能性が高くなります。監視されないままにしておくと、使用率のドリフトにより、RI が実現に役立つコストの節約が大幅に削減される可能性があります。

ドリフトを管理するためのベスト プラクティスの 1 つとして、事前定義された間隔（週 1 回など）で、RI の使用率の効果を継続的に評価することが挙げられます。RI が十分に活用されていないことを早期に特定した場合は、環境に最も費用対効果の高い RI を購入して維持できます。VMware Aria Cost は、RI Analyzer と呼ばれるレポートを提供して、複雑なクラウド環境での RI 使用率の時間がかかり、エラーが発生しやすい分析を簡素化します。

RI Analyzer について

RI Analyzer は、EC2 インスタンス タイプごとの予約使用率の概要を提供するレポートです。レポートはインスタンスのアクティビティに基づいており、その主な目的は、インスタンスが予約で十分にカバーされているかどうかの理解を助けることにあります。このレポートは、予約使用率や予約インベントリを示すことを目的としてはいません。

このレポートを作成するために、プラットフォームはまず、Amazon の詳細な請求レコード (DBR) の情報に基づいて、1 時間ごとの使用率を分析します。結果のレポートには、インスタンスと予約使用率が月初来 (MTD) または現在の平均として表示されます。

インスタンスごとに、レポートには次の情報が表示されます。

• 場所、インスタンス タイプ、OS、テナント
• 購入したすべての RI が効率的に使用されているかどうか
• コスト最適化のための RI をさらに購入する機会

このレポートには、予約のインベントリが表示され、実行中のインスタンスと所有している予約を比較することで、節約の可能性を特定できます。逆に、多数の予約を所有していて、実行されているインスタンスが少ない場合、Analyzer は過払い額を示します。

レポートは、ソート、CSV にエクスポートおよびフィルタリングできます。レポートの列をカスタマイズすることもできます。

使用率レポートをコンパイルするために、Analyzer は予約購入のインベントリを作成します。したがって、1 つ以上の一括請求アカウントがある場合は、関連するすべてのリンクされたアカウントをプラットフォームに追加します。1 つまたは複数のリンクされたアカウントがない場合は、レポートでの予約数が不足している可能性があり、不正確さにつながります。

RI Analyzer レポートについて

分析期間の影響

分析期間 ドロップダウンで、2 つの値のいずれかを設定できます。各設定により、一部のレポート列の計算方法が若干異なります。

• 当月: インスタンス数、リザーブド インスタンス数、未使用のリザーブド インスタンス数 は、当月の初めから現在までの期間の平均です。さらに、1 か月あたりの実効コスト と 1 か月あたりの予約の節約額 は、当月の初めから 1 か月までの推定金額を表します。
• 現在：インスタンス数 と リザーブド インスタンス数 は、特定の時点（つまり、現在）のインベントリから取得されます。すべてのコストは 1 か月で計算されます。

レポート サマリ

レポートの上部にある青いバーには、分析期間 の予約使用率が表示されます。これは、当月 または 現在 を選択できます。

• インスタンス数：1 時間ごとのデータに基づく平均インスタンス使用量。
• 予約数：1 時間ごとのデータに基づく平均予約使用量。
• RI（合計時間の %）：予約でカバーされた 1 時間あたりの合計インスタンス使用率。
• 予約削減：リザーブド インスタンスを使用した場合の 1 か月あたりの削減額。このパーセンテージは、すべてのインスタンスの使用率のオンデマンド コストと、現在の予約価格に基づく予約によるコストとの差を表します。この列の負の値は、未使用の RI があることを示しています。

レポートの列

レポートには、分析期間 に実行されているすべてのインスタンス タイプの行が表示されます。デフォルトの列は、各インスタンス タイプの使用方法を理解するのに役立つ追加の詳細情報を提供します。

フィルタ ドロップダウンを使用して、アカウント、オペレーティング システム、テナント、または インスタンス タイプ によってレポートを絞り込むことができます。

推奨事項

分析期間の現在の使用率に基づいて、このインスタンス タイプを最適化するのに最適な方法についての、VMware Aria Cost の推奨事項。詳細な推奨事項とその他のオプションについては、EC2 RI Modifier を使用した予約の変更を参照してください。

• 推奨事項は、リージョン レベルではなく、ゾーン レベルでのみ行われます。VMware Aria Cost は、推奨事項を提示する際にリージョンの予約を考慮しますが、特定のゾーンに対してのみ機会を評価します。したがって、リージョンまたはアベイラビリティ ゾーンをスコープとする予約を購入するかどうかを決定できます。詳細については、以下を参照してください。

  このレポートの例を参考にしてください。このレポートは、インスタンス数 と リザーブド インスタンス数 が 7 に等しいことを示しています。ただし、このレポートでは、4 つの予約を販売、変更、または変換することが確認されています。

  3 番目の行に表示されているリザーブド インスタンスのスコープは us-west-1 アベイラビリティ ゾーンになります。これには、4.0 の未使用のリザーブド インスタンスが含まれています。Analyzer は、これら 4 つのアベイラビリティ ゾーンをスコープとするインスタンスを、それらを販売または変更することを提案するときに参照します。

  さらに、レポートは、リージョンをスコープとする未使用の予約がある場合にのみ、リージョン スコープの RI を表示します。

• 分析期間 が 当月 に指定されている場合、インスタンス数 および リザーブド インスタンス数 は一定期間にわたって平均化されます。

  その結果、次の例に示すように、未使用の RI があるときに追加の RI を購入するように勧められる場合があります。または、リージョンをスコープとする未使用の RI がある場合、アベイラビリティ ゾーンをスコープとする RI を追加購入するようにという推奨事項が表示されることがあります。インスタンスが RI によってどのようにカバーされているかは、2 つの数値を比較しても直接確認することはできませんが、分析期間中の使用率の内訳と RI の内訳を比較することによってのみ確認できます。それらの RI または既存の RI が十分に使用されていない場合でも、追加の RI を購入することで、コスト削減を確認できます。

インスタンスの属性

• 場所: インスタンスのスコープとなるリージョンまたはアベイラビリティ ゾーン。
• インスタンス タイプ: インスタンス タイプ（m2.2xlarge など）。
• オペレーティング システム: インスタンス タイプのオペレーティング システム（Linux など）。
• テナント: インスタンス タイプが実行されているハードウェアの種類（共有、専用、デフォルトなど）。
• アカウント: インスタンス使用率が関連付けられているアカウント。

RI 使用率の属性

• インスタンス数：分析期間中に実行されているこのタイプのインスタンスの平均数。
• リザーブド インスタンス数：分析期間中のこのインスタンス タイプの平均予約数。

レポートを効果的に使用するための鍵となるのは、(a) インスタンス数 と (b) リザーブド インスタンス数 の共通部分です。これら 2 つの列を比較して、次の質問に答えることができます。

• このインスタンス ファミリに未使用または使用率の低い予約がありますか
• 予約を追加で購入することによってコストを削減するチャンスはありますか

比較結果	解釈
(a > b)	さらにコストを削減できる可能性があります。
(b > a)	使用率の低いインスタンスがあります。
(a ~= b)	予約は十分に使用されています。

コストの属性

• 1 か月あたりの実効コスト：アベイラビリティ ゾーンでそのインスタンスに支払うコスト。これは、次の点を考慮して計算されます。
  • そのゾーンのオンデマンド使用率（もしあれば）
  • ゾーン内のアベイラビリティ ゾーン スコープの RI のコスト（使用済みおよび未使用の両方の RI を含む）
  • ゾーンにフロートしたリージョン スコープの RI のコスト

• 1 か月あたりの予約の節約額：RI の購入による節約額。次のように計算されます。

  (Cost of running instances on-demand per month – Current Effective Cost Per Month)
  

RDS RI オプティマイザを使用した RDS 予約見積もりの管理

正確で効率的な RI 購入を決定することは大変な作業で、時間と手間がかかる、間違いが発生しやすい分析が必要になることがよくあります。

VMware Aria Cost の RDS RI オプティマイザは、RDS インスタンスを評価して、RI の使用によるメリットを得られるかどうかを判断します。評価の際に、オプティマイザは以前の使用量を分析し、指定された予算での最適な購入を特定します。

VMware Aria Cost は制約ベースのアルゴリズムを使用します。これにより、従来の「ナップサック問題」に対して欲張り法を採用して推奨を行うことができます。この分析は、一定期間にわたる時間単位のオンデマンドの使用量を確認することで実行されます。このアルゴリズムでは、予算の制約内で最適な予約購入を行うために、1 つまたは複数の効率的なオプションをそれほど効率的ではないオプションとトレードオフします。ここでの目標は、予算、購入日、フィルタなど、指定した制約に対して最適な推奨事項を提供することです。

前提条件: コストと使用状況レポート (CUR) の有効化

AWS のコストと使用量レポート (CUR) は、製品、価格設定、使用量などのコストに関する包括的なデータを提供します。詳細については、AWS のコストと使用状況レポートを参照してください。

EC2 RI オプティマイザを使用してオンデマンドの使用量を評価する前に、プラットフォームで CUR を有効にします。

CUR が有効になっていない場合はどうなりますか

RDS RI オプティマイザによって提示される推奨事項は、使用率の低い、サイズに柔軟性のある予約を持つ RDS インスタンス ファミリに対しては不正確になる場合があります。

CUR には何日分のデータが必要ですか

30 日以上のデータが必要です。CUR を最近構成したばかりで、30 日未満のデータしかない場合、プラットフォームは、その部分的な履歴に基づいて適切な分析と推奨事項を提示します。このプラットフォームでは、サイズに柔軟性のある RI に関係しないデータで入力された古いレポートを表示するオプションを提供する警告も表示されます。

手順 1：見積もりの作成

RDS RI オプティマイザは、作成した見積もりに基づいてインスタンスの使用量と要件を分析します。既存の見積もりを変更または削除し、見積もり内で購入を実行することもできます。1.推奨事項 > 予約 > RDS RI オプティマイザ を選択します。2.新規見積もり をクリックします。

CUR を有効にしていない場合、オプティマイザで指定したアカウントと期間について、VMware Aria Cost は完全な予約履歴を受信しません。結果として、オプティマイザの推奨事項が不完全な情報に基づくもので、不正確となる可能性があります。

デフォルトでは、VMware Aria Cost は予算に制限を設けることなく、インスタンスの 100% に近いカバレッジを提供する RI 購入を提案します。提案は、インスタンスの現在および過去のオンデマンド使用量に対する 1 時間単位の分析に基づいています。

VMware Aria Cost は、見積もりに対する変更を自動保存しません。変更を行うたびに、見積もりの右上隅で アクション > 名前を付けて保存 をクリックして、変更内容を保持します。

手順 2：見積もりオプションの構成

見積もりを作成するときに VMware Aria Cost が設定するデフォルトのオプションを確認します。オプションを変更するときは、クラウド環境に最適な設定を検討します。

• 分析する期間を選択：オンデマンドの使用量を分析する期間を指定します。今後予想される使用量を最も反映した期間を選択します。ベスト プラクティスとして直近 1 か月の使用量を分析することをお勧めします。より動的な環境を実現する場合は期間を短縮し、より静的な環境を実現するには長めの期間を使用します。
• 推奨期間を選択：3 年間の契約では、コストを大幅に削減できますが、ユーザーは期間中に新しいインスタンス タイプを利用できるようになる可能性に備えて 1 年の期間を選択する傾向があります。
• 購入予定日：この日付は、予定されている購入の前に期限切れとなる既存の予約がある場合に重要です。日付を選択すると、オプティマイザは期限切れとなる予約を考慮し、更新が予算の制約の対象に含まれるようになることが保証されます。
• 購入アカウント：統合アカウントを選択するか、すべて を選択して、使用量があるアカウントで購入を行います。
• 予約タイプ：分析に使用しない支払いオプションをオフにします。たとえば、一部の組織では、すべて先行 の支払いオプションを使用しないことを考えている場合があります。
• 節約量が X% 未満の場合はより低い前払い予約タイプを選択：この設定は、予約タイプ間の節約量の差異が指定された割合より小さい場合に、支払いオプションをダウングレードします。たとえば、「先行なし」RI に対して、「部分的な先行」RI の購入による節約量が 3% 未満である場合、推奨事項のダウングレードとして、「部分的な先行」RI よりも前払い金額が少ない「先行なし」RI の購入を提案します。

手順 3：インフラストラクチャのサブセットへの見積もりの制限

RDS RI オプティマイザを使用すると、見積もりをインフラストラクチャのサブセットに限定できます。たとえば、特定のアカウント、リージョン（US East (Northern Virginia) Region など）、インスタンス タイプ（db.m3 インスタンス タイプなど）、機能（Elasticsearch クラスタなど）、またはビジネス グループ（マーケティング部門など）に対して、RI の購入が必要になる可能性があります。

拡張オプション セクションの フィルタ 機能を使用して、RI 見積もりについてインフラストラクチャの特定のサブセットをターゲットにします。

インフラストラクチャのサブセットに対して複数の RI 購入を行う場合は、重複するインフラストラクチャをターゲットにすることについて注意してください（たとえば、同じアカウントの使用量を 2 回含む見積もりを作成することなど）。この操作により、予約の購入過多が発生する可能性があります。

オプション および フィルタ を設定した後で、オプティマイザの実行 をクリックします。

手順 4：推奨事項の確認

評価を実行した後、オプティマイザは RI 購入の推奨事項を返します。推奨事項には、概要および詳細なサマリの両方が含まれます。

概要のサマリを確認する

このセクションでは、次の情報について説明します。

• RI 購入による月単位および年単位の節約の可能性
• 節約を達成するために購入する RI の数とタイプ
• 節約を達成するために必要な初期 Amazon 支払い
• 先行支払いを差し引いての効果的なコスト節約
• 購入後に得られる予約カバレッジの割合
• 回収を達成する月数

詳細なサマリを確認する

このセクションでは、各固有の推奨事項に関する情報を提供します。各アカウントの情報に加えて、このセクションには各提案の概要が示されます。

手順 5：推奨事項の変更

RDS RI オプティマイザは、設定するオプションに基づいて推奨事項を提示します。ただし、これらの推奨事項を変更することもできます。

たとえば、mysql DB エンジンを使用して db.m4.large に対して 10 個の一部前払い予約の購入をオプティマイザが推奨した場合は、このインスタンス タイプに影響を与える負荷が将来的に軽減されることが予想される場合、7 個のみを購入することを選択できます。

歯車 アイコンをクリックして、推奨事項を変更します。

[推奨される使用量] ビューには、タイプ別の推奨される RI 使用量に重なる形でオンデマンド使用量が表示されます。このビューは、現在の使用量を確認し、VMware Aria Cost がこの費用を RI 購入でどのように管理することを推奨しているかを確認するのに役立ちます。

さらに、このビューには推奨事項の次の主要な属性が表示されます。

• 価格設定：使用可能なサービス タイプに応じて購入したユニットあたりの初期コスト、月次コスト、および有効コストです。初期費用と月次コストは、ユーザー固有の価格設定に基づいています。これは、階層化された割引やカスタム価格設定プランによる影響を受けます。VMware Aria Cost は、すべての使用量について、AWS からの時間単位のコストの概要を提供する AWS 請求書からこの価格設定を導出します。ユーザーの価格設定が利用できない場合は、オンデマンドの価格が表示されます。
• オンデマンドでの節約：予約の 100% の使用量についてのオンデマンドの使用量に対する節約量の割合です。
• 数量：各サービス タイプごとに予約の数を調整できる、編集可能なフィールドです。
• コスト：[価格設定] 列と [数量] 列を掛けた値です。
• 月単位のコスト節約：提案された予約購入を完全に活用した場合に予想される月単位の請求の削減額です。
• 期間コスト：この予約について、すべての使用量に基づき支払う合計金額です。このコストには、初期費用と定期的な月次コストの両方が含まれます。

手順 6：購入後のインフラストラクチャの確認

RDS RI オプティマイザの サマリ タブは、推奨事項に基づいて購入した場合に、インフラストラクチャがどのようになるかを可視化するのに役立ちます。

このレポートでは、上下の矢印を使用して、さまざまな提供サービスの使用量の変化や、コストと予約のレートの変化を表示します。この情報を使用して、主要な関係者と確認してから、購入前に合意を形成することができます。

手順 7：注文を行う

注文 タブには、提案された予約の注文と、購入に必要な詳細が表示されます。

購入を行う方法は 3 つあります。

• VMware Aria Cost の使用：リザーブド インスタンスを購入するための承認ワークフローを構成します。次に、[見積もりのサマリ] ページの 購入 ボタンをクリックします。

  この操作により、予約購入の承認に対する要求が開始されます。承認者と権限付与者の両方が要求を確認すると、購入が実行されます。

• Amazon アカウントの担当者経由：注文を確認し、アクション > 注文のエクスポート を選択して、Amazon アカウントの担当者と共有できるファイルをダウンロードします。

• AWS コンソール経由：AWS コンソールから購入を行うには、[注文] タブの情報を使用します。予約を使用しているアカウントで購入することを選択した場合は、各アカウントの AWS コンソール内で購入を行う必要があります。

AWS コスト節約計画に関するよくある質問

リリースの内容

2019 年 11 月、AWS は Savings Plan と呼ばれる新しいサービスを発表しました。Savings Plan は、最大限の柔軟性を維持しながら EC2 と Fargate のコストを削減する新しい方法です。Savings Plan の詳細については、ブログを参照してください。

これらの変更が VMware Aria Cost に及ぼす影響

Savings Plan を購入した場合、VMware Aria Cost は、Savings Plan のコスト、および Savings Plan が RI とともにどのように適用されているかなどの詳細を視覚的に把握するためのレポートを提供します。また、VMware Aria Cost パースペクティブを使用して、この分析をビジネスのコンテキストでグループ化することもできます。

コスト履歴レポート

EC2 Compute コストと Fargate のコストは、次のように更新されます。

• EC2 - コンピューティング：これは、Savings Plan や RI などの EC2 インスタンスの割引メカニズム後の正味コストを反映し、パースペクティブごとに正確にグループ化できます。
• Savings Plan - 未使用：これは、使用量に適用されていない Savings Plan の比例費を反映しています。これは、再割り当て可能な間接費項目です。
• Savings Plan - 前払い費用：Savings Plan 購入時の前払い費用。「一部前払い」および「全額前払い」の支払いタイプ向けです。これは、再割り当て可能な間接費項目です。
• Amazon EC2 Container Service：ECS と Fargate の間接費は正味費用（Savings Plan 割引を含む）として表示されます。
• EC2 - Savings Plan の無効化クレジット：これは、Savings Plan でカバーされていたオンデマンド費用の一部を無効にする AWS 請求書の追加の測定項目です。VMware Aria Cost はこれらのクレジットを直接 EC2 - コンピューティング明細項目に組み込み、顧客はこれらのクレジット金額を使用量に直接関連付けることができます。その結果、EC2 - Savings Plan の無効化クレジットは $0 の値として表示されます。

EC2 インスタンスの使用量と EC2 インスタンスの費用レポート

費用履歴レポートと同様に、EC2 インスタンスの費用と使用量に関するレポートでは、RI と Savings Plan の割引が考慮されます。さらに、オンデマンドの使用量、Savings Plan でカバーされる使用量、予約インスタンスでカバーされる使用量の全体像が把握できる「カバレッジ タイプ」と呼ばれる新しい測定項目が導入されました。この測定項目は、コストと使用量をEC2 Savings Plan、Compute Savings Plan、スタンダード RI、コンバーティブル RI、オンデマンド、およびスポットに分類します。[予約タイプ] には、リザーブド インスタンス カバレッジに加えて、Savings Plan カバレッジが含まれるようになりました。たとえば、[全額前払い] は [全額前払い RI] と [Savings Plan] のカバレッジを表示し、インスタンス ファミリごとにカバレッジ タイプなどの新しいビューをロック解除したり、カバレッジ タイプごとに既存のレポートをフィルタリングします。

[EC2 インスタンス時間]

[EC2 インスタンス時間] レポートが更新されました。これにより、Savings Plan が EC2 の使用量にどのように適用されるか、さらに、Savings Plan と RI の両方の料金の償却をより詳細に分析できるようになりました。

更新された列：* RI 固有の測定項目である 平均償却コスト は 平均 RI 償却コスト に名前変更されました。

新しい列：

• EC2 Savings Plan 時間：このインスタンスが EC2 Instance Savings Plan によってカバーされた時間数
• Compute Savings Plan 時間：このインスタンスが Compute Savings Plan によってカバーされた時間数
• Savings Plan のカバレッジ率：Savings Plan（EC2 Instance Savings Plan または Compute Savings Plan）でカバーされるこのインスタンスの使用量の割合
• SP 償却コスト：このインスタンスのカバレッジに使用された Savings Plan の量に基づいて、このインスタンスに割り当てられた Savings Plan 料金（前払いおよび定期料金）の割合。
• RI 償却コスト：このインスタンスのカバレッジに使用された RI の量に基づいて、このインスタンスに割り当てられた RI 料金（前払いおよび定期料金）の割合。
• 償却コストの合計：このインスタンスの SP 償却コストと RI 償却コストの合計。

Savings Plan の資産レポート

Savings Plan には、ユーザーが自分の Savings Plan の概要、そのステータス、関連する料金などを表示できる独自の資産レポートが追加されました。他の資産レポートと同様に、このレポートを有効にするには、AWS IAM ポリシーを更新する必要があります。

Convertible RI Exchanger

Convertible RI Exchanger は、正確な推奨事項を引き続き提示し、すべての顧客が活用しなければなりません。Savings Plan によってカバーされる使用量は、推奨事項から除外されます。AWS は最初に RI を適用し、次に Savings Plan を適用するため、VMware Aria Cost は RI 投資から最大限の価値を引き出すことを推奨します。Savings Plan の割引は、予約でカバーされないオンデマンドの使用量に適用されます。使用量が Savings Plan でもカバーされている場合、予測される節約量が実際よりも多くなる可能性があることに注意してください。

RI パルス レポート

Savings Plan がない場合、これらのレポートは期待どおりに機能します。Savings Plan を購入した場合、Savings Plan でカバーされる使用量は一時的にオンデマンドの使用量として考慮され、使用量が Savings Plan でカバーされる場合、RI Saving（合計金額が増えます）、予約の機会（Savings Plan でカバーされるインスタンスが表示されます）、および RI 変更により過大評価されるコスト節約に影響します。

EC2 RI Analyzer

RI Analyzer は Savings Plan を考慮しないため、これらのケースでは不正確な推奨事項を行う可能性があります。Savings Plan でカバーされる使用量は、オンデマンドの使用量として解釈されます。

EC2 RI Optimizer

選択した評価期間内に Savings Plan を購入していない場合、RI の推奨事項は正確になります。選択した評価期間内に Savings Plan を購入した場合、RI Optimizer は不正確な推奨事項を行う可能性があります。

EC2 RI Modifier

EC2 RI Modifier は、引き続き正確な推奨事項を提供しますが、使用量が Savings Plan でもカバーされている場合は、節約量を過大に評価することもあります。Savings Plan でカバーされる使用量は、オンデマンドの使用量として解釈されます。

ポリシー

ポリシーは期待どおりに動作します。Savings Plan の割引は、EC2 インスタンス、AWS 請求明細、およびマルチクラウド支出リソース タイプのポリシー評価に含まれています。

パートナー プラットフォーム

パートナーとその顧客は、それぞれ Savings Plan を購入し、VMware Aria Cost 請求エンジン内の適切なレベルで節約を適用することができます。