AWS Organizationの管理アカウントでSPs/RIを一括購入してカバレッジを上げる

2024.01.23Update

石川貴之

AWSコスト削減が巷で話題になってますね。
こんにちは、ニフティのAWS組織管理をしている石川です。

とんでもない削減額を叩き出したわけではないですが、長年やりたかったSPs(Savings Plans)とRI(Reserved Instance)の一括購入を行いましたので、そのときに得たノウハウを共有していこうと思います。

Before/After

	Before	After	購入したもの
SPsカバレッジ	21%	95〜99%	Compute Savings Plans 3年前払いなし
RI(RDS)カバレッジ	15%	83%	RDS Reserved Instance 1年前払いなし

表1: SPs/RIのカバレッジ

※表の値は購入直後のもので現在はリソースが増えてカバレッジはちょっと下がっています
※RIをRDSのみにしているのは他のRIは利用アカウント数が少数でしたので一括購入していません

管理アカウントで一括購入することの是非

個々のAWSアカウントで買うか、管理アカウントで一括で買って共有したほうがいいのか問題。

各プロダクトチームが個々のAWSアカウントで買う場合、リソースの調整がしやすいためリソースごとに最適なプランで購入することができ割引効率がよくなります。一方、AWSアカウント×リソース×購入タイミングごとに購入タスクが発生するため、買い忘れが発生したり、少額だから買わないという状況が起きたりします。

組織管理者が管理アカウントから一括で買う場合、共有前提なので常時起動分はカバーできるように買うことができます。一方、再利用性を考慮して買うため柔軟なプランを選ぶことになり割引率が下がります。また会計上、共有して利用したAWSアカウントの費用として計算する必要があり、一手間増えます。

それぞれメリット・デメリットがあります。AWSアカウントやリソースを統制管理しているのか各チームで管理しているのか、現状適切に購入できているのかを見て、自身の組織に合う方を選ぶと良いでしょう。

ニフティの場合、各プロダクトチームごとに管理していましたが、AWSアカウントも多いためかカバレッジも低く、適切に購入できている状態とも言えなかったため今回一括購入を採用しました。

SPs/RIの仕様確認

高額な買い物となるため、AWSのSPs/RIの共有や利用のされ方をちゃんと理解しておかないといけません。個人的にここはしっかり把握しておきたかったという点をいくつか紹介します。

※2023年11月時点で公式ドキュメントやサポートに確認した内容となります

共有されたSPs/RIが使われる順番

ざっくりいうとSPsよりRIが先に使われ、適用範囲が狭い順に使われていきます。

割引共有がない状態での適用順番
1. Own: Reserved Instances
2. Own: Savings Plans (EC2 Instance)
3. Own: Savings Plans (Compute)
割引共有がある状態での適用順番
1. Own: Reserved Instances
2. Share: Reserved Instances
3. Own: Savings Plans (EC2 Instance)
4. Share: Savings Plans (EC2 Instance)
5. Own: Savings Plans (Compute)
6. Share: Savings Plans (Compute)

SPs/RIが適用される単位

1時間単位に割引効率が一番いいリソースから順に割り当てられていきます。
消費した順に適用されるわけではないです。

即時割引額が反映されるわけではなく請求レポート上への反映は翌日以降。

正規化係数の仕様

購入期間だけ異なる同じプランのRIを買い増ししたときに合算されて適用されるかどうか。

購入期間が異なっていてもRIは正規化係数で合算されて適用される。
購入期間が異なっていて問題になるのは、RIの変更時に結合できない点。

例: 購入したRI
- 2023-09-01: t2.medium 1つ購入
- 2023-09-08: t2.medium 1つ購入（期間以外は上記と同じ設定）
稼働中のインスタンス
- t2.large
適用状況
- 2023/09/01-2023/09/08:
  - t2.largeにt2.mediumのRI1つ分の割引が適用
- 2023/09/08以降:
  - 先に購入されたRIが失効するまで: t2.largeにt2.mediumのRI2つ分の割引が適用
  - 先に購入されたRIが失効した以降: t2.largeにt2.mediumのRI1つ分の割引が適用

参考：
リザーブドインスタンスがどのように適用されるか – Amazon Elastic Compute Cloud
リザーブドインスタンスの変更 – Amazon Elastic Compute Cloud

購入額の見積もり

基本的に管理アカウントで確認できる推奨値を買えば問題ないです。

推奨値と同じ値をコストエクスプローラーで出せないか試してみたところ、期間内の最小か平均で推奨値を出してくれているように見えました。スパイクは無視してくれるし、一時的に立ち上がっているものも無視してくれています。

そのため直近での変化がないかだけ購入前に確認するだけでよいです。ただ古いインスタンスは購入推奨に含まれない場合があるので、古すぎるものがないかはチェックして可能なら最新のインスタンスタイプに上げておきましょう。

今回は推奨値から以下のものを抜き足しした額を購入しました。

除外
- 直近でSPs/RIを購入していたもの
- 近いうちにリソースを削除する予定のもの
- ライセンスありのリソース
- 個別購入して管理したいAWSアカウント or リソース
追加
- 近いうちに個別で購入していたSPs/RIが切れるもの
- 直近で立ち上げられた永続利用するリソース

購入作業

買うだけではあるんですが、何度も確認や再計算して購入したのですごく疲れる作業でした。

SPsの購入は、見積もり額通りに時間あたりの費用を入力して買うだけなので比較的楽です。
ただ額が大きくて購入ボタンを押すのがすごく怖かったです。。ここの心理的負荷を下げるなにかが欲しい。

購入した翌日の昼過ぎくらいにコストエクスプローラーへ反映されていました。CURにも反映されていました。

RDSのRIの購入は、推奨値のままだと購入台数多くて上限に引っかかりそうなので、合計正規化係数の変わらないインスタンスタイプと台数に変更後それぞれ購入するのですが、インスタンスファミリーやらエンジンやら組み合わせ数が多くてオペミスがすごく怖かったです。。
CLIで予約購入を入れて、画面で確認して問題なかったらそのまま購入、問題があったらキャンセルというフローにしたかったのですが、RDSのRIは予約購入機能なかった（EC2にはある）ため実現できず。予約購入というかRDSのSPsが欲しい。

想像より調整・確認工数や精神的疲労が大きかったので、買い足しは半年に1回の運用にするつもりです。

効果確認

コストエクスプローラーでは購入したSPs/RI単位の効果を調べにくいので、AthenaからCURにクエリーを投げて調べます。

購入したSPsごとにarnが振られるので、それを使ってSPsが適用されたリソースのオンデマンド価格(pricing_public_on_demand_cost)からSPsが適用された価格(savings_plan_savings_plan_effective_cost)と未使用分(savings_plan_total_commitment_to_date – savings_plan_used_commitment)を引いてコスト削減額を出せます。

SELECT savings_plan_savings_plan_a_r_n,

sum(pricing_public_on_demand_cost) as pricing_public_on_demand_cost,

sum(savings_plan_savings_plan_effective_cost) as savings_plan_savings_plan_effective_cost,

sum(

savings_plan_total_commitment_to_date - savings_plan_used_commitment

) as savings_plan_unused_cost,

sum(

pricing_public_on_demand_cost - savings_plan_savings_plan_effective_cost

) as savings_plan_reduction_cost

FROM "aws_billing"."aws_billing_cur_month_parquet"

WHERE year = '2023'

and month = '11'

and line_item_line_item_type != 'Tax'

and savings_plan_savings_plan_a_r_n like 'arn:aws:savingsplans::{AWSAccountID}%'

group by savings_plan_savings_plan_a_r_n

RIも同じように管理アカウントのRDSのarnを使って、RIが適用されたリソースのオンデマンド価格(pricing_public_on_demand_cost) からRIが適用された価格(reservation_effective_cost)と未使用分(line_item_unblended_cost – reservation_effective_cost)を引いてコスト削減額を出せます。

SELECT reservation_reservation_a_r_n,

sum(pricing_public_on_demand_cost) as pricing_public_on_demand_cost,

sum(reservation_effective_cost) as reservation_effective_cost,

sum(

line_item_unblended_cost - reservation_effective_cost

) as reserved_unserd_cost,

sum(

pricing_public_on_demand_cost - reservation_effective_cost - (

line_item_unblended_cost - reservation_effective_cost

)

) as reserved_reduction_cost

FROM "aws_billing"."aws_billing_cur_month_parquet"

WHERE year = '2023'

and month = '11'

and line_item_line_item_type in ('RIFee', 'DiscountedUsage')

and reservation_reservation_a_r_n like 'arn:aws:rds:ap-northeast-1:{AWSAccountId}%'

group by reservation_reservation_a_r_n

費用の付け直し

管理アカウントでSPs/RI一括購入すると、unblended cost(非ブレンドコスト) では管理アカウントの費用として請求されます。組織内のAWSアカウントに共有されて使われた分は、それぞれのAWSアカウントの費用として計算したいので、内部的に請求費用の再計算を必要があります。

サクッと出すには amortized cost(償却コスト) を使うのが良いです。前払いでも月ごとに期間按分してくれます。amortized cost は便利な項目ではあるものの、なぜかCURには amortized cost という列がありません。なにか調査したいときにCURで同じような値(完全に同じ値は出せなかった)を出すには、そこそこ複雑なSQL書く必要があります。

最終的にどの数字を元に費用の付け直しをするかは社内で相談して決めましょう。

-- 擬似amortized cost算出、前払いには未対応

WITH b AS (

SELECT year,

month,

bill_invoice_id,

line_item_usage_account_id,

line_item_line_item_type,

line_item_unblended_cost,

CASE

WHEN line_item_line_item_type = 'SavingsPlanCoveredUsage' THEN savings_plan_savings_plan_effective_cost

WHEN line_item_line_item_type = 'SavingsPlanNegation' THEN 0

WHEN line_item_line_item_type = 'SavingsPlanRecurringFee' THEN (

savings_plan_total_commitment_to_date - savings_plan_used_commitment

)

WHEN line_item_line_item_type = 'DiscountedUsage' THEN reservation_effective_cost

WHEN line_item_line_item_type = 'RIFee' THEN reservation_unused_recurring_fee ELSE line_item_unblended_cost

END AS line_item_unblended_cost_haihu

FROM "aws_billing"."aws_billing_cur_month_parquet"

WHERE year = '2023'

and month = '11'

)

SELECT year,

month,

bill_invoice_id,

line_item_usage_account_id,

SUM(line_item_unblended_cost) AS line_item_unblended_cost,

SUM(line_item_unblended_cost_haihu) AS line_item_unblended_cost_haihu

FROM b

WHERE b.line_item_line_item_type != 'Tax'

GROUP BY year,

month,

bill_invoice_id,

line_item_usage_account_id

ORDER BY bill_invoice_id,

line_item_usage_account_id;

line_item_line_item_type	item type説明	差し替えて使っている値
SavingsPlanCoveredUsage	SPsが適用された分のオンデマンド費用（集計用ではなくデータとして残すために出力されていると思われる）	savings_plan_savings_plan_effective_cost （SPsが適用された費用、要は使った分）
SavingsPlanNegation	SavingsPlanCoveredUsageを相殺する行（集計用ではないので相殺しているのだと思われる）	0
SavingsPlanRecurringFee	前払いなしまたは一部前払い時に対応する定期的な時間単位の料金 SPsを購入したアカウントに表示される	savings_plan_total_commitment_to_date – savings_plan_used_commitment （定期的な時間単位の料金から使った分を引いたもの、要は余った分）
DiscountedUsage	RI適用後の費用	reservation_effective_cost （RIを使った分）
RIFee	RI前払いなしか一部前払いで買った場合、時間単位の料金	reservation_unused_recurring_fee （RIが余った分）

表2: SQL内に使われているCURスキーマの説明

参考：
予約の明細項目を理解する – AWS コストと使用状況レポート
 予約の詳細 – AWS コストと使用状況レポート
 Savings Plans について – AWS コストと使用状況レポート

見落としていた点

唯一見落としていたのがサポート費用の増大。

SPs/RIを一括購入した管理アカウントには請求書上ではかなりの額が乗るので、それに合わせてサポート費用も増大します。

仕方ないこととはいえ、どうにかならんかという気持ちではあります。最安を目指すなら専用のAWSアカウントを新設してサポートプランをベーシックのまま、そのアカウントで一括購入するのがよいかと思います。

最後に

今回ドキュメントからは判別つかない点も多く、AWSサポートにだいぶ助けられました、本当にありがとうございました。実際に購入してみないとわからない点や、CURの複雑な点はどうしても自力でどうにかするのは難しいですね。

おかげさまで見積もり通りミスなくSPs/RIが購入できて、カバレッジも高められ、それなりの額のAWSコスト削減ができました。

ただ定期的に買い足しや買い直しをしなければならない運用はありますし、精神的負荷も変わらずあります。ここは定型化やチェックフローを自動化できるところはして負荷を下げていきたいと思います。

最後にこれからSPs/RIを買おうとしている方達へアドバイス。

事業が成長し続ける限り、買った方が得なので買うなら早く買おう
- 割引額が少し低くても柔軟性があるほうが事前調整が楽
- Compute SPsが再利用されないことはほぼないので許可が取りやすい
- 不要インスタンスは削除、稼働インスタンスも最適化してから買いましょう
- 参考：適切なサイズ設定に関する推奨事項によるコストの最適化 – AWS コスト管理
SPs/RIの仕様をしっかり理解しておこう
- 大きい買い物になるのでちゃんと説明できるようになっておく必要がある
- 購入時の恐怖がちょっと和らぎます
CURと戯れておこう
- コストエクスプローラーだけでは出せない数字もあるので、欲しい数字がありそうな列を思いつけるくらいになっておくとなにかと便利です
- 参考：AWS CUR Query Library :: AWS Well-Architected Labs
初めて買うなら少額買って適用具合や費用の付き方を調べよう
- 買ってからじゃないと体験できないことも多いので、買って学ぶほうが早い