AWS リザーブド インスタンス (RI) では、年額コミットメントを Amazon に前払いする見返りとして、コンピューティング コストの割引を受けることができます。Amazon は、特定のインフラストラクチャを使用するというコミットメントをユーザーから得ることで、容量の管理を効率化して、節約したコストをユーザーに還元することができます。
すべての RI タイプは、価格削減のメリットを提供します。一部の RI タイプでは、容量予約のメリットも併せて提供され、予約期間に所定のタイプのインスタンスを起動する権利が保証されます。
それぞれの予約分の構成は、これらの属性によって決まります。
m3.large
など)us-east-1b
など)よくある誤解として、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 購入時の決定を簡素化することができます。
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 の購入からメリットが得られる時点までの期間のことです。回収期間は次のように計算できます。
どのような合理的な規模であっても、インフラストラクチャの内部で個々のインスタンスに伴う、RI 購入の意思決定を下すのは容易ではありません。意思決定のプロセスは、各インスタンスを個別にグループ分けしたり、環境、機能、アプリケーションといったいくつかのパースペクティブ別にグループ分けしたりすることにより、簡素化することができます。最も一般的な方法は、MongoDB や Web サーバなど、アプリケーションまたは機能の目的に基づいてインスタンスをグループ分けすることです。
プラットフォームの種類(たとえば、Linux、Windows など)ごとに AWS の価格は異なるため、可能であれば、同じグループの中に種類の異なるイメージを入れないようにしてください。
RI への移行に伴う潜在的なメリットを評価する場合はまず、最も経費のかかるインスタンス グループ(MongoDB サーバなど)から始めます。さらに重要なのは、RI が「常時オン」のインフラストラクチャを対象としている点です。したがって、インスタンスが使用されている時間が 65% 未満のグループの評価はスキップすることができます。
各グループに対して、評価中に次の質問をしてみます。
現在のリージョンに含まれるグループ中のインスタンスについての既知の比率が、インスタンス タイプ ファミリを変更しないまま少なくとも 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 か月です。一般の組織では、あるインスタンス タイプから別のタイプへの移行を予測した期間よりも長くかかる傾向があります。したがって、レガシー タイプのインスタンスについてリザーブド インスタンスの購入を決定する場合は、損益分岐月が効果的である場合があります。
予算は、RI 購入を検討している組織の間で一般的に用いられる制限要因です。初めて RI を購入する場合は、予算に達するまで、上記の手順から RI サービスを限定的に選択します。
インフラストラクチャのいくつかの変更は、クラウド環境で定期的に実施されます。クラウド環境が拡大するにつれて、これらの変更の監視と管理がますます困難になっています。ビジネス ポリシーは、組織が予約を購入して変更を行う方法と時期を決めるブループリントを作成するための効果的な方法です。
RI 管理のポリシーを確立する際は、次の重要な側面について考慮してください。
RI の購入を決定した後、個々の予約について主要な属性を決定します。
各予約はそれぞれ特定のインスタンス タイプ ファミリ(m4
など)、支払いオプション(全額前払いなど)、ロケーション(us-east-1a など)、OS(Linux など)、およびテナント(共有など)に関連付けられています。組織は、時間の経過とともに、特定のワークロードに応じて実行するインスタンスのタイプに変更を加えることがあります。結果として、予約が未使用のままになったり、マーケットプレイスで再販されたりする状況が不可避になることがあります。また、Amazon がそのインスタンス タイプ ファミリ内で革新を続けるのに伴い、既存のアプリケーションが新しいインスタンス ファミリ上で非常に高いパフォーマンスとコスト効率で実行できる場合があります。パフォーマンスとコスト効率に対する懸念が、一部の組織にとって予約のコミットメントへの決断や 1 年を超えるコミットメントを躊躇させる要因となっていました。
コンバーティブル リザーブド インスタンス (RI) には、次の属性があります。
コンバーティブル RI は柔軟性に優れているため、若干高価です。また、それらを交換すると、クレジットを受け取ることができません。既存のコンバーティブル RI のコストと同等またはそれ以上のコストを有する新しいコンバーティブル RI の場合のみ、既存のコンバーティブル RI を交換できます。
RI の支払いで利用できる各オプションは、予約に対して行う支払いの形式に違いがあります。次の 3 つのオプションがあります。
あるアカウントがこのオプションを通じて購入資格を得るには、まず適正な請求履歴がなければなりません。
金額 | 使用料を前払いしません |
---|---|
期間 | 標準については 1 年または 3 年、コンバーティブルについては 3 年のみ |
割引 | 27~50% |
[前払いなし] の支払いオプションを選択する理由は 2 つあります。
m3.large
など)に対して一部前払いまたは全額前払いが許可されない場合は、前払いなしのオプションを検討します。オプションによって特定の予約期間に拘束される場合であっても、コスト削減のメリットが得られます。このタイプの 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 に伴う減額と容量の保証が同時に得られます。
個別の取引明細書を受け取るアカウントのことで、一括請求アカウントにはリンクされません。
このアカウントは、統合アカウント、またはスタンドアローン アカウント(「商用アカウント」)のいずれかに関連付けられていなければなりません。関連付けられると、請求額と使用量がすべて同じアカウントからの請求であるようにまとめて報告されます。
組織は、複数のアカウントを一括請求書にリンクさせて、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 の属性(インスタンス タイプ、範囲、期間、提供クラスなど)を決定することに加えて、チーム、アプリケーション、および機能領域全体の使用率を予測する必要があります。
VMware Aria Cost powered by CloudHealth は、実装される前に承認プロセスを通じて実行されるアクションを通じて、RI の購入を自動化するのに役立ちます。このアプローチにより、認証とセキュリティを損なうことなく、手間がかかり、ミスが発生しやすい RI 管理のプロセスを自動化できます。
VMware Aria Cost で承認プロセスによって実行されるアクションを構成して、RI 管理のさまざまな側面を自動化することができます。アクションは、以下のユーザーの少なくとも 1 人の承認を通る必要があります。
正確で効率的な RI 購入を決定することは大変な作業で、時間と手間がかかる、間違いが発生しやすい分析が必要になることがよくあります。
EC2 RI オプティマイザは、AWS インスタンスを評価して、RI の使用によるメリットを得られるかどうかを判断します。評価の際に、オプティマイザは以前の使用量を分析し、指定された予算での最適な購入を特定します。
VMware Aria Cost は制約ベースのアルゴリズムを使用します。これにより、従来の「ナップサック問題」に対して欲張り法を採用して推奨を行うことができます。この分析は、一定期間にわたる時間単位のオンデマンドの使用量を確認することで実行されます。このアルゴリズムでは、予算の制約内で最適な予約購入を行うために、1 つまたは複数のそれほど効率的ではないオプションを効率的なオプションとトレードオフします。ここでの目標は、予算、購入日、フィルタなど、指定した制約に対して最適な推奨事項を提供することです。
AWS のコストと使用量レポート (CUR) は、製品、価格設定、使用量などのコストに関する包括的なデータを提供します。詳細については、AWS のコストと使用状況レポートを参照してください。
EC2 RI オプティマイザを使用してオンデマンドの使用量を評価する前に、CUR を有効にします。
RI オプティマイザによって提示される推奨事項は、使用率の低い、サイズに柔軟性のある予約を持つ EC2 インスタンス ファミリに対しては不正確になる場合があります。
30 日以上のデータが必要です。CUR を最近構成したばかりで、30 日未満のデータしかない場合、VMware Aria Cost は、その部分的な履歴に基づいて適切な分析と推奨事項を提示します。このプラットフォームでは、サイズに柔軟性のある RI に関係しないデータで入力された古いレポートを表示するオプションを提供する警告も表示されます。
EC2 RI オプティマイザは、ユーザーが作成した見積もりに基づいてインスタンスの使用量と要件を分析します。既存の見積もりを変更または削除し、見積もり内で購入を実行することもできます。
アクション > 新規見積もり を選択します。
CUR を有効にしていない場合、オプティマイザで指定したアカウントと期間について、VMware Aria Cost は完全な予約履歴を受信しません。結果として、オプティマイザの推奨事項が不完全な情報に基づくもので、不正確となる可能性があります。デフォルトでは、VMware Aria Cost は予算に制限を設けることなく、インスタンスの 100% に近いカバレッジを提供する RI 購入を提案します。提案は、インスタンスの現在および過去のオンデマンド使用量に対する 1 時間単位の分析に基づいています。
VMware Aria Cost は、見積もりに対する変更を自動保存しません。変更を行うたびに、見積もりの右上隅で アクション > 保存 の順にクリックして、変更内容を保持します。
見積もりを作成するときに VMware Aria Cost が設定するデフォルトのオプションを確認します。オプションを変更するときは、クラウド環境に最適な設定を検討します。
Coverage = Reserved hours / (Reserved hours + On-demand hours)
ほとんどの使用量パターンでは、100% のカバレッジは経済的に最適化されていません。
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 の購入が推奨未満となる可能性があります。
オプション および フィルタ を設定した後で、オプティマイザの実行 をクリックします。
評価を実行した後、オプティマイザは RI 購入の推奨事項を返します。推奨事項には、概要および詳細なサマリの両方が含まれます。
このセクションでは、次の情報について説明します。
このセクションでは、各固有の推奨事項に関する情報を提供します。各アカウントの情報に加えて、このセクションには各提案の概要が示されます。
サイズに柔軟性のある推奨事項のみがインスタンス ファミリごとにグループ化され、サイズに柔軟性のあるファミリの各インスタンス タイプは別の行に記載されます。推奨事項のサマリの各行には、次の情報が含まれています。
提案された予約がレガシー インスタンス タイプ用の場合、レガシー インスタンス タイプから移行することを推奨する警告メッセージが表示されます。
%VPC 列は、最適化されている使用量のうち、Virtual Private Cloud (VPC) 内で実行されていると判断された使用量の割合を示します。予約を購入する場合は、予約を VPC または従来(非 VPC)のインスタンス用とするべきかどうかを指定します。従来のインスタンスと VPC インスタンスの両方で、価格削減のメリットが得られます。VPC 予約を購入したときに、特定の時間内に同等のインスタンスが実行されていない場合、その予約は、従来の(非 VPC)インスタンスを実行している同等のものに適用できます。ただし、キャパシティ予約の保証は、起動するインスタンスのタイプ(従来または VPC)によって異なります。このため、従来の予約を作成した場合、同様の VPC インスタンスを起動すると、キャパシティの保証はありません。その逆の操作についても同様です。詳細については、Amazon VPC に関するよくある質問 を参照してください。
EC2 RI オプティマイザは、設定するオプションに基づいて推奨事項を提示します。ただし、これらの推奨事項を変更することもできます。
たとえば、us-east-1a
での Linux を実行している m3.large
の使用量に対して 10 個の一部前払い予約の購入をオプティマイザが推奨した場合は、このインスタンス タイプに影響を与える負荷が将来的に軽減されることが予想される場合、7 個のみを購入することを選択できます。
ファミリ レベル(サイズに柔軟性のある予約の場合)またはインスタンス タイプ別に変更を加えることができます。見積もりから特定の行を削除することもできます。推奨事項のサマリで任意の行をクリックして、変更します。
[推奨される使用量] ビューには、タイプ別の推奨される RI 使用量に重なる形でオンデマンド使用量が表示されます。このビューは、現在の使用量を確認し、VMware Aria Cost がこの費用を RI 購入でどのように管理することを推奨しているかを確認するのに役立ちます。
さらに、このビューには推奨事項の次の主要な属性が表示されます。
見積もりをカスタマイズしたら、注文をエクスポートできます。
リザーブド インスタンスを購入する方法は 3 つあります。
VMware Aria Cost の使用:リザーブド インスタンスを購入するための承認ワークフローを構成します。次に、[見積もりのサマリ] ページの 購入 ボタンをクリックします。
この操作により、予約購入の承認に対する要求が開始されます。承認者と権限付与者の両方が要求を確認すると、購入が実行されます。
Amazon アカウントの担当者経由:見積もりを確認し、アクション > 注文のエクスポート を選択して、Amazon アカウントの担当者と共有できるファイルをダウンロードします。
VMware Aria Cost では、次の方法(複数も可)を使用して、設定済みの予約や特定のサブセットに関連付けられたすべてのインスタンスに対するカバー範囲を変更することができます。
EC2 RI Modifier は、リザーブド インスタンスやインスタンスの使用量を分析し、コストの節約のための変更を検討すべき推奨事項を提示します。
基準を指定するときに VMware Aria Cost で設定されるデフォルトのオプションを確認します。オプションを変更するときは、クラウド環境に最適な設定を検討します。
Modifier は、分析を実行した後、RI の変更に関する推奨事項を提示します。月間予測節約合計 フィールドは、基準を満たすすべての推奨事項の合計を表します。
コンバーティブル リザーブド インスタンス (RI) には、次の属性があります。
コンバーティブル RI は柔軟性に優れているため、若干高価です。また、コンバーティブル RI を交換するときにクレジットを受け取ることはありません。既存のコンバーティブル RI のコストと同等またはそれ以上のコストを有する新しいコンバーティブル RI の場合のみ、既存のコンバーティブル RI を交換できます。
コンバーティブル RI を使用する VMware Aria Cost ユーザーにとって最大の課題は、コンバーティブル RI が正常に活用されていることを確認することです。これらの課題は以下の特定の領域に集中しています。
コンバーティブル リザーブド インスタンス エクスチェンジャは、追加投資を抑えながら、AWS インフラストラクチャ内の使用率の低いコンバーティブル RI からのコスト回収を支援するツールです。この場合の投資は次のように定義されています。
Investment = True-up cost + Additional hourly commit charges
調整コストは、旧(交換前)と新(交換後)のコンバーティブル予約の差について、日割り計算された初期コストです。
エクスチェンジャは次の操作を実行します。
エクスチェンジャは、Compute Savings Plan の対象となる使用率ではなく、オンデマンドの使用率を対象とすることに重点を置いています。Compute Savings Plan はどちらも非常に動的で、コンバーティブル RI に同等の割引を提供します。そのため、エクスチェンジャは、RI が使用されなくなる別の推奨事項を作成する場合があります。
Compute Savings Plan の対象となる使用率が多い場合は、評価期間の開始を最新の CRI 交換後に設定し、交換の推奨事項が Compute Savings Plan を補完するようにすることをお勧めします。
エクスチェンジャの目的は、最小の投資で最大のコスト削減額を提供する交換を推奨することです。つまり、エクスチェンジャは交換による ROI を最大化し、コストを削減する一連の交換に関する推奨事項を生成します。以下はエクスチェンジャの仕組みです。
推奨事項 > 予約 > 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 ファイルを生成します。
ファイルには、必要な変更と交換の詳細が含まれています。交換前に変更が必要となる各予約注文の ID は特に重要です。AWS コンソールを使用して交換を処理する場合にはこれらの ID が必要です。
交換の見積もりを作成すると、VMware Aria Cost を使用して、見積もり内の 1 つ以上の交換を自動化できます。VMware Aria Cost が交換を実行することを許可するか、認証ワークフローを利用して交換を開始することができます。
選択できる自動化には 2 つのタイプがあります。
オプション | 要件 |
---|---|
交換アクションを組織内の権限付与者に委任する | 交換アクションを有効にして、認証者を選択します。認証者はアクションの要求が承認されると、AWS Security Token Service を使用して一時的な最小権限トークンをプロビジョニングします。VMware Aria Cost は、このトークンを使用して認証者に代わってアクションを実行します。 |
VMware Aria Cost による交換の実行を許可する | コンバーティブル RI を交換するための VMware Aria Cost IAM ポリシー権限を更新します。 |
このオプションでは、VMware Aria Cost を使用して、IAM ポリシーを介して権限を交換の実行を許可する AWS ユーザーに提供します。
認証者に関連付けられた IAM ポリシーがある場合は、そのポリシーにこれらの権限を追加して、VMware Aria Cost が認証者の代わりに交換を実行できるようにします。
次のセクションをコピーして、[ポリシー ドキュメント] フィールドに貼り付けます。
{
"Effect": "Allow",
"Action": [
"ec2:ModifyReservedInstances",
"ec2:DescribeReservedInstancesOfferings",
"ec2:GetReservedInstancesExchangeQuote",
"ec2:AcceptReservedInstancesExchangeQuote"
],
"Resource": "*"
}
ステータスと履歴 タブをクリックして、交換アクションのステータスを確認します。
交換アクションにより、以下のステータスが循環します。
保留中:アクションがキューに登録されました。
失敗:バッチ内の 1 つ以上の交換に失敗しました。
完了:アクションが正常に完了した、またはバッチ内の交換の部分的な障害が発生した状態です。
該当のアクションをクリックして詳細を確認します。
このオプションでは、プラットフォームで AWS アカウントに対して構成した IAM ロールに関連付けられているポリシーを編集します。
アカウントの設定ページの一番下までスクロールし、ポリシーの生成 をクリックします。次のセクションがポリシーに追加されます。
{
"Effect": "Allow",
"Action": [
"ec2:ModifyReservedInstances",
"ec2:DescribeReservedInstancesOfferings",
"ec2:GetReservedInstancesExchangeQuote",
"ec2:AcceptReservedInstancesExchangeQuote"
],
"Resource": "*"
}
このしきい値を指定する必要がある理由 ベスト プラクティスとして、見積もりの生成時間に可能な限り近いところで、交換アクションに対する承認を取得します。このアプローチにより、調整費用における差異を大幅に削減できます。コンバーティブル RI の交換における調整費用は、トランザクションの動的な性質上、一時的なものとなります。VMware Aria Cost が見積もりを生成してから交換を実行するまでの間に、実際の調整費用は見積もりで指定されているものと差異が生じる場合があります。その差異が指定したしきい値を超えると、VMware Aria Cost は交換アクションの実行を許可しません。
インスタンスをオンデマンドで実行するアプローチは柔軟性を提供しますが、コストを押し上げる可能性もあります。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 は、EC2 インスタンス タイプごとの予約使用率の概要を提供するレポートです。レポートはインスタンスのアクティビティに基づいており、その主な目的は、インスタンスが予約で十分にカバーされているかどうかの理解を助けることにあります。このレポートは、予約使用率や予約インベントリを示すことを目的としてはいません。
このレポートを作成するために、プラットフォームはまず、Amazon の詳細な請求レコード (DBR) の情報に基づいて、1 時間ごとの使用率を分析します。結果のレポートには、インスタンスと予約使用率が月初来 (MTD) または現在の平均として表示されます。
インスタンスごとに、レポートには次の情報が表示されます。
このレポートには、予約のインベントリが表示され、実行中のインスタンスと所有している予約を比較することで、節約の可能性を特定できます。逆に、多数の予約を所有していて、実行されているインスタンスが少ない場合、Analyzer は過払い額を示します。
レポートは、ソート、CSV にエクスポートおよびフィルタリングできます。レポートの列をカスタマイズすることもできます。
使用率レポートをコンパイルするために、Analyzer は予約購入のインベントリを作成します。したがって、1 つ以上の一括請求アカウントがある場合は、関連するすべてのリンクされたアカウントをプラットフォームに追加します。1 つまたは複数のリンクされたアカウントがない場合は、レポートでの予約数が不足している可能性があり、不正確さにつながります。
分析期間 ドロップダウンで、2 つの値のいずれかを設定できます。各設定により、一部のレポート列の計算方法が若干異なります。
レポートの上部にある青いバーには、分析期間 の予約使用率が表示されます。これは、当月 または 現在 を選択できます。
レポートには、分析期間 に実行されているすべてのインスタンス タイプの行が表示されます。デフォルトの列は、各インスタンス タイプの使用方法を理解するのに役立つ追加の詳細情報を提供します。
フィルタ ドロップダウンを使用して、アカウント、オペレーティング システム、テナント、または インスタンス タイプ によってレポートを絞り込むことができます。
分析期間の現在の使用率に基づいて、このインスタンス タイプを最適化するのに最適な方法についての、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
など)。レポートを効果的に使用するための鍵となるのは、(a) インスタンス数 と (b) リザーブド インスタンス数 の共通部分です。これら 2 つの列を比較して、次の質問に答えることができます。
比較結果 | 解釈 |
---|---|
(a > b) |
さらにコストを削減できる可能性があります。 |
(b > a) |
使用率の低いインスタンスがあります。 |
(a ~= b) |
予約は十分に使用されています。 |
1 か月あたりの予約の節約額:RI の購入による節約額。次のように計算されます。
(Cost of running instances on-demand per month – Current Effective Cost Per Month)
正確で効率的な RI 購入を決定することは大変な作業で、時間と手間がかかる、間違いが発生しやすい分析が必要になることがよくあります。
VMware Aria Cost の RDS RI オプティマイザは、RDS インスタンスを評価して、RI の使用によるメリットを得られるかどうかを判断します。評価の際に、オプティマイザは以前の使用量を分析し、指定された予算での最適な購入を特定します。
VMware Aria Cost は制約ベースのアルゴリズムを使用します。これにより、従来の「ナップサック問題」に対して欲張り法を採用して推奨を行うことができます。この分析は、一定期間にわたる時間単位のオンデマンドの使用量を確認することで実行されます。このアルゴリズムでは、予算の制約内で最適な予約購入を行うために、1 つまたは複数の効率的なオプションをそれほど効率的ではないオプションとトレードオフします。ここでの目標は、予算、購入日、フィルタなど、指定した制約に対して最適な推奨事項を提供することです。
AWS のコストと使用量レポート (CUR) は、製品、価格設定、使用量などのコストに関する包括的なデータを提供します。詳細については、AWS のコストと使用状況レポートを参照してください。
EC2 RI オプティマイザを使用してオンデマンドの使用量を評価する前に、プラットフォームで CUR を有効にします。
RDS RI オプティマイザによって提示される推奨事項は、使用率の低い、サイズに柔軟性のある予約を持つ RDS インスタンス ファミリに対しては不正確になる場合があります。
30 日以上のデータが必要です。CUR を最近構成したばかりで、30 日未満のデータしかない場合、プラットフォームは、その部分的な履歴に基づいて適切な分析と推奨事項を提示します。このプラットフォームでは、サイズに柔軟性のある RI に関係しないデータで入力された古いレポートを表示するオプションを提供する警告も表示されます。
RDS RI オプティマイザは、作成した見積もりに基づいてインスタンスの使用量と要件を分析します。既存の見積もりを変更または削除し、見積もり内で購入を実行することもできます。1.推奨事項 > 予約 > RDS RI オプティマイザ を選択します。2.新規見積もり をクリックします。
CUR を有効にしていない場合、オプティマイザで指定したアカウントと期間について、VMware Aria Cost は完全な予約履歴を受信しません。結果として、オプティマイザの推奨事項が不完全な情報に基づくもので、不正確となる可能性があります。
デフォルトでは、VMware Aria Cost は予算に制限を設けることなく、インスタンスの 100% に近いカバレッジを提供する RI 購入を提案します。提案は、インスタンスの現在および過去のオンデマンド使用量に対する 1 時間単位の分析に基づいています。
VMware Aria Cost は、見積もりに対する変更を自動保存しません。変更を行うたびに、見積もりの右上隅で アクション > 名前を付けて保存 をクリックして、変更内容を保持します。
見積もりを作成するときに VMware Aria Cost が設定するデフォルトのオプションを確認します。オプションを変更するときは、クラウド環境に最適な設定を検討します。
RDS RI オプティマイザを使用すると、見積もりをインフラストラクチャのサブセットに限定できます。たとえば、特定のアカウント、リージョン(US East (Northern Virginia) Region
など)、インスタンス タイプ(db.m3 インスタンス タイプなど)、機能(Elasticsearch クラスタなど)、またはビジネス グループ(マーケティング部門など)に対して、RI の購入が必要になる可能性があります。
拡張オプション セクションの フィルタ 機能を使用して、RI 見積もりについてインフラストラクチャの特定のサブセットをターゲットにします。
インフラストラクチャのサブセットに対して複数の RI 購入を行う場合は、重複するインフラストラクチャをターゲットにすることについて注意してください(たとえば、同じアカウントの使用量を 2 回含む見積もりを作成することなど)。この操作により、予約の購入過多が発生する可能性があります。
オプション および フィルタ を設定した後で、オプティマイザの実行 をクリックします。
評価を実行した後、オプティマイザは RI 購入の推奨事項を返します。推奨事項には、概要および詳細なサマリの両方が含まれます。
このセクションでは、次の情報について説明します。
このセクションでは、各固有の推奨事項に関する情報を提供します。各アカウントの情報に加えて、このセクションには各提案の概要が示されます。
RDS RI オプティマイザは、設定するオプションに基づいて推奨事項を提示します。ただし、これらの推奨事項を変更することもできます。
たとえば、mysql
DB エンジンを使用して db.m4.large
に対して 10 個の一部前払い予約の購入をオプティマイザが推奨した場合は、このインスタンス タイプに影響を与える負荷が将来的に軽減されることが予想される場合、7 個のみを購入することを選択できます。
歯車 アイコンをクリックして、推奨事項を変更します。
[推奨される使用量] ビューには、タイプ別の推奨される RI 使用量に重なる形でオンデマンド使用量が表示されます。このビューは、現在の使用量を確認し、VMware Aria Cost がこの費用を RI 購入でどのように管理することを推奨しているかを確認するのに役立ちます。
さらに、このビューには推奨事項の次の主要な属性が表示されます。
RDS RI オプティマイザの サマリ タブは、推奨事項に基づいて購入した場合に、インフラストラクチャがどのようになるかを可視化するのに役立ちます。
このレポートでは、上下の矢印を使用して、さまざまな提供サービスの使用量の変化や、コストと予約のレートの変化を表示します。この情報を使用して、主要な関係者と確認してから、購入前に合意を形成することができます。
注文 タブには、提案された予約の注文と、購入に必要な詳細が表示されます。
購入を行う方法は 3 つあります。
VMware Aria Cost の使用:リザーブド インスタンスを購入するための承認ワークフローを構成します。次に、[見積もりのサマリ] ページの 購入 ボタンをクリックします。
この操作により、予約購入の承認に対する要求が開始されます。承認者と権限付与者の両方が要求を確認すると、購入が実行されます。
Amazon アカウントの担当者経由:注文を確認し、アクション > 注文のエクスポート を選択して、Amazon アカウントの担当者と共有できるファイルをダウンロードします。
2019 年 11 月、AWS は Savings Plan と呼ばれる新しいサービスを発表しました。Savings Plan は、最大限の柔軟性を維持しながら EC2 と Fargate のコストを削減する新しい方法です。Savings Plan の詳細については、ブログを参照してください。
Savings Plan を購入した場合、VMware Aria Cost は、Savings Plan のコスト、および Savings Plan が RI とともにどのように適用されているかなどの詳細を視覚的に把握するためのレポートを提供します。また、VMware Aria Cost パースペクティブを使用して、この分析をビジネスのコンテキストでグループ化することもできます。
EC2 Compute コストと Fargate のコストは、次のように更新されます。
費用履歴レポートと同様に、EC2 インスタンスの費用と使用量に関するレポートでは、RI と Savings Plan の割引が考慮されます。さらに、オンデマンドの使用量、Savings Plan でカバーされる使用量、予約インスタンスでカバーされる使用量の全体像が把握できる「カバレッジ タイプ」と呼ばれる新しい測定項目が導入されました。この測定項目は、コストと使用量をEC2 Savings Plan、Compute Savings Plan、スタンダード RI、コンバーティブル RI、オンデマンド、およびスポットに分類します。[予約タイプ] には、リザーブド インスタンス カバレッジに加えて、Savings Plan カバレッジが含まれるようになりました。たとえば、[全額前払い] は [全額前払い RI] と [Savings Plan] のカバレッジを表示し、インスタンス ファミリごとにカバレッジ タイプなどの新しいビューをロック解除したり、カバレッジ タイプごとに既存のレポートをフィルタリングします。
[EC2 インスタンス時間] レポートが更新されました。これにより、Savings Plan が EC2 の使用量にどのように適用されるか、さらに、Savings Plan と RI の両方の料金の償却をより詳細に分析できるようになりました。
更新された列:* RI 固有の測定項目である 平均償却コスト は 平均 RI 償却コスト に名前変更されました。
新しい列:
Savings Plan には、ユーザーが自分の Savings Plan の概要、そのステータス、関連する料金などを表示できる独自の資産レポートが追加されました。他の資産レポートと同様に、このレポートを有効にするには、AWS IAM ポリシーを更新する必要があります。
Convertible RI Exchanger は、正確な推奨事項を引き続き提示し、すべての顧客が活用しなければなりません。Savings Plan によってカバーされる使用量は、推奨事項から除外されます。AWS は最初に RI を適用し、次に Savings Plan を適用するため、VMware Aria Cost は RI 投資から最大限の価値を引き出すことを推奨します。Savings Plan の割引は、予約でカバーされないオンデマンドの使用量に適用されます。使用量が Savings Plan でもカバーされている場合、予測される節約量が実際よりも多くなる可能性があることに注意してください。
Savings Plan がない場合、これらのレポートは期待どおりに機能します。Savings Plan を購入した場合、Savings Plan でカバーされる使用量は一時的にオンデマンドの使用量として考慮され、使用量が Savings Plan でカバーされる場合、RI Saving(合計金額が増えます)、予約の機会(Savings Plan でカバーされるインスタンスが表示されます)、および RI 変更により過大評価されるコスト節約に影響します。
RI Analyzer は Savings Plan を考慮しないため、これらのケースでは不正確な推奨事項を行う可能性があります。Savings Plan でカバーされる使用量は、オンデマンドの使用量として解釈されます。
選択した評価期間内に Savings Plan を購入していない場合、RI の推奨事項は正確になります。選択した評価期間内に Savings Plan を購入した場合、RI Optimizer は不正確な推奨事項を行う可能性があります。
EC2 RI Modifier は、引き続き正確な推奨事項を提供しますが、使用量が Savings Plan でもカバーされている場合は、節約量を過大に評価することもあります。Savings Plan でカバーされる使用量は、オンデマンドの使用量として解釈されます。
ポリシーは期待どおりに動作します。Savings Plan の割引は、EC2 インスタンス、AWS 請求明細、およびマルチクラウド支出リソース タイプのポリシー評価に含まれています。
パートナーとその顧客は、それぞれ Savings Plan を購入し、VMware Aria Cost 請求エンジン内の適切なレベルで節約を適用することができます。