AlphausCloudのTrueUnblendedとは

1920

この記事では、AlphausCloudのRippleで扱っているTrueUnblendedについてAWSのCostUsageReportsの出力データを元に解説しています。

社内ITコストでAWSを使用している場合は請求データを各利用部署に按分したり分割する必要があります。特にリザーブドインスタンス(以下、RI)を購入している場合、本来の利用料が幾らで、RIによるコスト削減効果がどの程度なのか確認する必要があります。

その一連の手順についてExcelを利用した前提として説明しています。

⒈CostUsageReportsとは

AWSを利用している場合、通常のコスト管理はCost Explorerか請求ダッシュボードで確認することになるとおもいますが、部署別の按分などExcelで処理するには、Cost Explorerや請求ダッシュボードからダウンロードしたCSVデータでは扱いづらい内容になっています。

そこでAWSが提供しているCost & Usage Reportsの機能を利用して、より詳細なデータをCSV形式で取得できるようにします。

このCSVの中には、請求に関係する全ての課金レコードが含まれています。

⒉TrueUnbeldedとは

AWS Cost & UsageReports から出力したCSVデータは、特にAWSのアカウント設定を変更していなければ、Unblededコストの出力になります。

複数アカウントを扱っている場合、マスター(支払い)アカウントを用意し、その下にメンバーアカウントをぶら下げ、まとめ払い(一括請求)にするがベストプラクティスな使い方になっています。

この状態でRIを購入しているとコスト削減効果の恩恵を受けれるのですが、下記のような本来の利用コストがどの程度なのかわかりづらくなるという課題もでてきます。

次の3点のような場合があります。

・マスターアカウントでRIを購入している場合
・メンバーアカウント自身でRIを購入している場合
・その他のメンバーアカウントでRIが購入している場合

各アカウントで購入したRIは特別な設定をしない限り全アカウントで共有される設定になっています。

これはAWSの仕様で全体コストが最適化されるようにRIを割当てるためです。

しかし、Unblededコストには組織全体のRIが適用された状態で課金データが計算されるため、RIの適用がなかった場合である本来のコストはわかりません。

図にすると、次のような例になります。

Usageが実際に各アカウントで利用した時間(1枠1時間)RI1つは1時間$10と仮定した図になります。


この場合、各アカウントで購入したRI

例)

マスターアカウントで購入したRIの適用分は一旦解除した状態にし、各メンバーアカウントで購入した分だけが適用された状態に再計算を行うのがTrueUnblendedとなります。

これにより、各メンバーアカウントで購入した範囲でコスト管理を行うことになるため適切な管理会計を行うことが可能になります。

EC2の場合は単純に利用時間と請求コストを照らし合わせることで、コスト超過具合などの判断ができますが、正確に把握しようとするには、一度TrueUnblededに置き換えてコストの確認をすることが不可欠になります。また組織内でRIを共同購入する場合も同様で、一度TrueUnblededに置き換えることで次のような効果があります。

・一括購入したRIによるコスト削減が明確になる
・公平な費用の按分を行うことが可能になる

Alphaus CloudではTrueUnblendedをCCoEを推進するための軸となるコスト算出方法として推奨しています。

注釈

AWSにも共有解除の仕様はあります。 

ただこの仕様だと共有解除したアカウント自身が保有するRIは他のアカウントに共有しない状態になりますが、他のアカウントが保有するRIの恩恵はうけるジャイアン仕様になっています。
そのため、保有RIのみを適用するように設定する場合、全アカウントを共有解除にすることになり、コスト最適化の観点から非効率になるデメリットがあります。この点がTrueUnblededとの大きな違いになります。

以降でExcelを使って算出したい場合、どのような手順で行うか説明します。

1.Cost & Usage ReportsからCURデータを用意します

2.次に、RIを解除するため「DiscountedUsage」の課金レコードを抽出します。

3.どのメンバーアカウントのRIが適用されているのか確認します。

「2.」で抽出した課金レコードの「reservation/reservationARN」項目をチェックします。

この値に含まれるAWSアカウントIDがメンバーアカウントのIDと異なる場合、他のメンバーアカウントのRIが適用されていることになります。

画像部分の黄色部分が他のAWSアカウントIDだった場合、該当するケースになります。

4.次に購入したRIがメンバーアカウント内で、どの程度適用されているか確認します。

これはRI購入数が月あたりの大よその上限になるので、「Discounted Usage」として適用されている総時間を「reservation/reservationARN」による条件を加えて算出します。

5.最後に、on-demandの利用時間でRIの適用対象になるものがないか確認します。

適用対象に該当するがon-demandとして算出されている場合、「1時間あたりの適用上限」に該当していないか追加で確認します。

この確認は、リソースIDの出力を有効にするか、hourly単位によるCURデータから判断すると比較的わかりやすいですがデータ量が膨大なのでお奨めしません。

大まかに判断する場合は、該当のインスタンスサイズでフィルタした上で、lineItem/UsageStartDateとUsageEndDateの期間をチェックします。

このときlineItem/LineItemtypeをUsageとDiscountedUsageにフィルタすると効率よく探せます。

確認できたら何を検討するか?

これで、想定した通りにRIが適用されているのか判断できるようになります。

基本的なRI適用条件から勘案して適用時間が少ないようであれば、購入したRIが他のアカウントに共有されていると判断できます。稀にゾーンRIが先に割当たり、当初購入したRIが想定しているインスタンスサイズで消化されないケースもあります。

基本的なRIの適用条件とは?

AWSのドキュメントにあるRIの適用例から抜粋すると以下の流れで制限や優先的な割当が行われます。

・1時間単位の適用上限
・ゾーンRIからの優先割当(共有可能なものがあれば先に消化)
・所有のリージョンRIからの割当
・リージョンRIによる柔軟性判定を元に低サイズインスタンスから割当

RI(リザーブドインスタンス)の適用ルールの話

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/apply_ri.html

https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/purchase-reserved-node-instance.html#how-reserved-nodes-work

課金条件に関する話

https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/concepts-reserved-instances-application.html