re:Invent 2024: AWSのCloud Financial Management最新ツールと実践
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Best practices and new tools for cost reporting and estimation (COP218)
この動画では、AWSのCloud Financial Managementに関する包括的な解説が行われています。FOCUSフォーマットによるクラウドプロバイダー間のコスト標準化や、AWS Cost Explorerを使用した分析手法、Cost Categoriesによるコストの論理的グループ化など、具体的なツールの活用方法が紹介されています。また、AWS Billing Conductorを使用した独自の価格ルールによるChargebackの実装方法や、新しく認証済みとなったAWS Pricing Calculatorによるリアルタイムのコスト分析機能についても解説されています。特に注目すべき点として、Split Cost Allocation Dataによる共有リソースのコスト分配や、Savings Plans Analyzerを使用した純節約額分析など、実践的なコスト最適化の手法が詳しく説明されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Cloud Financial Managementの重要性と本セッションの概要
クラウドの請求書は単純に使用量に応じた支払いだと考えるのは、かわいらしいほど素朴な考えです。この業界で長年経験を積んだ人々は、むしろ停止し忘れたリソースに対して課金されているのだと考えています。しかし、ここにいる皆さんの多くは真実を知っています - クラウドの請求額は、その会社が雇用しているエンジニアの数に比例するということです。私はCorey Quinn、The Duckbill GroupのChief Cloud Economistとして、かなり規模の大きな企業の興味深いAWS請求書の問題解決を行っています。請求書を深く分析する時間が非常に多いため、皆さんの中にも見られる、私の目の死んだような表情の理由かもしれません。これから私は機知に富んだ観察や、AWSの同僚のプレゼンテーションに対して、コメントやジョーク、そして少々不適切なコメントを交えながら話を進めていきます。
私はBowen Wangです。AWSのCloud Financial ManagementポートフォリオのPrincipal Product Marketing Managerを務めています。お客様やパートナーの皆様が、より効果的に支出を管理・最適化できるよう、私たちのツールやリソースについてより深く理解し、活用していただけるような方法を常に探っています。そして私はMatt Berkです。Principal Technical Account Managerとして、Cloud Financial Managementの技術フィールドコミュニティをリードしています。本日はご参加いただき、ありがとうございます。このセッションでは、Bowen、Corey、そして私から、AWSのコストと使用状況をより良く把握するための実践的なヒントと新しいツールについてお話しします。クラウドの請求額が、皆様が達成したいビジネス成果に合致するようにしたいと考えています。
クラウドコスト管理の課題と洞察を得るためのアプローチ
Cloud Financial Management（CFM）は、クラウドへの投資を理解し、組織が設定したコスト効率化目標を達成し、クラウド投資から他のビジネス価値を生み出す方法を理解するのに役立つ領域です。これはクラウド導入の過程において基本となるものです。具体的には、AWSのCloud Financial Managementツールとサービスを通じて、AWS支出のより良い計画、分析、ガバナンス、最適化をサポートしています。成熟したCloud Financial Management実践を行っている組織は、最小限のコストでビジネス成果を達成し、ビジネスリスクを軽減しながら収益性を向上させることができます。また、純粋なコスト削減の取り組みから、より包括的なクラウド効率化プログラムへと発展させることも可能です。
「この高さ以上の方がご利用できます」という遊園地の注意書きのように、このトークが誰を対象としているのかを理解することは重要です。比較的小規模な企業や、それほど複雑でない組織の場合、このトークにはあまり参考になる内容がないかもしれません。私たちが対象としているのは、複雑な課題を抱える企業で、皆さんがため息をつきながら「ああ、自分の会社にぴったりだ」と思うような組織です。クラウドの成熟度とCloud Financial Managementの成熟度は、非常に広範な要素を含んでいます。今日は、これらの課題へのアプローチにおける2つの重要な要素についてお話しします。AWSのコストと使用状況データからより良い洞察を得るために最近リリースされたCFMの機能強化とサービス、そしてより簡単で正確な計画プロセスを実現する方法について、興味深い領域をご紹介します。
クラウドで運用する利点の1つは、データへのアクセス - 理想的にはあなた自身のデータへのアクセスです。支出を理解し分析するためには、クリーンで意味のあるコストと使用状況データが必要です。そうでなければ、推測に頼ることになります。推測する場合は、自信を持って話すように心がけましょう。AWSのコストレポートと見積もりを考える際には、いくつかの要素を考慮する必要があります。例えば、目的 - 何を達成しようとしているのか？ROIの追跡やFinOps文化の推進かもしれません。また、様々な関係者に説明する必要があるかもしれません - 財務部門？ビジネス部門？私の出身である、あの困りものエンジニアたち？レポートや計画のレベルはどの程度か - クラウドプロバイダーレベル、事業部門レベル、組織レベル、プロジェクトレベル、あるいは（神のご加護を）SKUレベルでしょうか。SKUレベルは狂気への道です。そして、それをどのくらいの頻度で行うのか - 週次、月次、年次、オンデマンド、あるいは「継続的に」という、実際には「時間がかかる」ことを意味する一般的なバズワードです。何を達成しようとしているのかを明確にしましょう。多くの組織との経験から、クラウドのコスト管理は通常トップダウンアプローチで行われ、一方でコスト見積もりはボトムアップアプローチで行うのが最適であることがわかっています。
コストレポーティングの改善：FOCUSとAWSの新機能
コスト報告の分野では、ビジネスリーダーはクラウドサービスプロバイダーレベルでのクラウド支出を理解することに関心があるかもしれません。財務マネージャーやFinOps実践者は、プロジェクトやコストセンターレベルを含む、各支払組織レベルでのコストを理解したいと考えています。ITやアプリケーションのオーナーは、各チームが細かいリソースレベルでクラウドテクノロジーをどの程度効果的に活用しているかを理解したいと考えています。
コスト見積もりに関しては、ボトムアップアプローチを取る必要があります。個々のサービスレベルをより深く見て、プロジェクト、アプリケーション、または事業部門レベルで見積もりを行う必要があります。アプリケーションオーナーや上級リーダーとコミュニケーションを取り、今後の成長要因、パイプライン、来年中に予想される事業変更について理解を深める必要があります。これを定期的に行うことで、コストの予期せぬ変動を最小限に抑え、コスト見積もりの精度を向上させ、クラウド予測の正確性に関する組織全体の信頼を高めることができます。
クラウドサービスプロバイダーレベルでは、ディレクターからパブリッククラウドとSaaSプロバイダー間の料金の内訳を求められた場合、適切な比較ができるようにする必要があります。 プロバイダーから生の請求データをダウンロードすると、それぞれが異なるフォーマットであることに気付きます。請求データ自体を理解し、分析し、クエリを適切に機能させる必要があります。データを統合し始めると、プロバイダー間でのReserved Instancesの正規化方法、コンピューティング、ネットワーキング、ストレージの異なるSKUのサービスマッピング方法、AWSのunblended costを他のプロバイダーの実際のコストと比較する方法などについて、判断を下す必要があります。
共通の課題は、これらすべてのデータを統合し、クラウドプロバイダー間で合意を得る方法です。その解決策がFOCUS（FinOps Open Cost and Usage Specification）です。これはFinOps Foundationがサポートするオープンソースプロジェクトで、すべてのクラウド請求データに対する単一の標準を提供します。目標は、利用するすべてのプロバイダーがFOCUSフォーマットでファイルを提供し、すべての情報を簡単かつ一貫して集計、クエリ、可視化できるようにすることです。FOCUS 1.0は今年6月に一般提供が開始されました。
私たちは現在、AWSのカラムを含むFOCUS 1.0の一般提供を発表しました。これにより、FOCUSファイルを開発し、任意のS3バケットに取り込むことができるようになりました。FOCUSの仕様で定義された43の標準カラムと、AWSに特有の5つのカラムが含まれており、その中にはline item usageも含まれています。これはAWSの請求における重要な次元であるusage typeのインデックスとなるため、非常に重要です。この一般提供リリースでは、本番環境のパイプラインで使用できるよう、データの精度も向上させています。
タグのプレフィックスとサービスレベルのマッピングの精度を向上させるための更新を行いました。また、このファイルがFOCUS 1.0の要件をより多く満たしていることも確認しました。 FOCUSファイルを入手したら、最も簡単な始め方は、QuickSight用に事前に用意されたFOCUSダッシュボードを使用することです。これにより、そのファイル形式でのコストの概要をすぐに把握でき、ニーズに合わせてダッシュボードをカスタマイズするための良い出発点となります。さらに詳しく調べたい場合は、Amazon Athenaを使用してファイルをクエリすることができ、Well-Architected Labsのウェブサイトには、FOCUS形式用の事前に用意されたクエリがあります。また、CUR 2.0用のクエリも用意されており、常に新しいものを追加しています。すでにサードパーティのBIツールを使用している場合は、そのファイルをエクスポートして簡単に移行できます。
組織全体のコスト可視化とAWS Cost Explorerの活用
コストレポーティングに関する次のヒントは、組織の全体像を把握し、重要な領域に注意を払う方法についてです。クラウドの利用しやすさにより、専門的な知識や専用ハードウェアへの投資を必要とせずに、組織が高度なテクノロジーを利用できるようになりました。しかし、ビジネス目標を達成するには、この全体像を把握する方法を理解する必要があります。もはや昔のように、私たちが専門的に「イヤな存在」と呼ぶ「ノーと言う部門」になろうとすることはできません。環境内でこれらの変化は必ず起こり、それを制御したり止めたりすることはできません。目指すべきは、質問される前に、何が起きているかを把握し、その変化に遅れずについていくことです。
その組織の概要については、Billsページから始めることができます。ここでは、今月と先月の支出の比較や、サービスやアカウントごとの請求額などの情報をすぐに確認できます。注目すべき点は、現在でも、AWSアカウントやAWS Organizationsで実行されているすべてのものを包括的に把握できる最適な場所は、依然としてBillingページだということです。なぜなら、これはFinOpsであり、支払いがなければ、本当に存在するのでしょうか？組織がクラウドの財務管理をうまく行っているかを理解するには、AWS Billing and Cost Management consoleにアクセスする必要があります。ここでは、コストと使用状況データのハイライトを確認し、コスト配分タグやCost Categoriesでコスト使用状況データがどの程度ラベル付けされているかなどの情報を得たり、コスト削減の機会にアクセスしたりできます。
このページのレイアウトをカスタマイズしていない限り、通常は右上に配置されているCost Monitorウィジェットについて説明したいと思います。Cost Monitorウィジェット内では、コストと使用状況が予算制限を超えた場合のBudgetアラートとCost Anomaly Detectionアラートを確認できます。Cost Anomaly DetectionサービスはAmazon Machine Learning技術を活用しています。このサービスは、過去のデータを分析し、予想される日次支出を計算して、実際の支出と比較します。実際の支出が予想支出を特定のしきい値を超えて上回った場合、これを異常な支出として特定し、根本原因分析を提供します。
つい最近、AWS Cost Anomaly Detectionの根本原因分析が改善されました。現在では、1ドルを超える各異常について、最大10個の根本原因を特定し、リージョン、アカウント、サービス、使用タイプにわたる各組み合わせを分析します。これにより、異常な支出の最も重要な要因を素早く特定できます。ここでCloudWatchに関する例を見てみましょう。CloudWatchの請求に突然のスパイクが見られた場合、私の素朴な最初の推測は、ログのどこかで過度に詳細な記録が行われているのだろうというものでしょう。しかし、さらに詳しく調べてみると、ダッシュボードとカスタムメトリクスが同時に作成されていることから、誰かが異なる観測アプローチを取っていることがわかります。これは、私が話すべき内容と調査すべき場所の両方に影響を与えます。
クラウドリソースの民主的な性質により、大小の企業や組織内のすべての人々にとって、競争の場が平準化されました。異なる場所にいるチームがリアルタイムでリソースにアクセスし、共有することができます。コスト報告に関する3つ目のヒントは、ユーザーに適切なレベルのコスト可視性を与えることです。これにより、ユーザーは自身のクラウド採用によって発生するコストをより意識し、コスト削減の機会を見出すことができるようになります。
情報保護とセキュリティの観点から、組織内のすべてのユーザーに請求情報、コストと使用状況データ、またはテスト情報へのアクセスを許可したくないことは理解できます。AWS Identity and Access Managementの詳細な権限制御により、特定のコスト財務管理ツールやサービスへのきめ細かなアクセス制御が可能です。例えば、保存されたコストレポートの閲覧のみが必要な人もいれば、予算の作成や変更を行いたい人もいます。また、リサイジングや購入オプションの推奨事項へのアクセスだけを必要とするチームもあるでしょう。
以前は「すべて許可」か「すべて拒否」かの二択しかなく、時間あたり2万ドルもするクラスターを起動する権限は与えられているのに、その結果を確認する権限がないという残念な状況が生まれていました。現在は、組織のニーズのバランスを取りながら、より細かな制御が可能になっています。理想的には、ユーザーが行った操作の結果について、可能な限り多くの可視性を提供することを目指すべきです。なぜなら、「とりあえず起動して、推測して、うまくいくことを祈る」というアプローチは、これまでの経験から誰にとっても良い結果をもたらさないことが分かっているからです。
あなたがクラウド使用コストの担当者で、AWS Cost Explorerにアクセスできるとしましょう。視覚的なグラフと柔軟なフィルタリング・グループ化オプションにより、興味のある特定の領域を詳しく見ることができます。この例では、過去の四半期のコストを振り返り、サービスごとの支出を理解しようとしています。Amazon RDSのコストが高額で、毎月約2,500ドルかかっていることに気づきます。 Amazon RDSのコストの要因を理解するには、もう少し詳細な視点が必要です。表示を月次から日次に切り替え、サービスフィルターでAmazon RDSを選択し、使用タイプでグループ化します。これにより、より詳細なコスト内訳が得られます。特定のAmazon RDSインスタンスにいくら支払っているか、どのリージョンで実行されているか、拡張サポート料金を支払っているか、そしてAmazon RDSインスタンスがMySQLとPostgreSQLのどちらのエンジンで動作しているかが分かります。
同じビューで、毎月1日にAWS Singaporeリージョンで約400ドルのコストスパイクが発生していることに気づきます。これは私が毎月1日に誓うことと同じかもしれません - 「今月こそデータベースとは何か、どう動作するのかを学ぶぞ」と。そして難しいことに気づいて、また来月まで止めてしまう。でも、それは本当ではないことが分かっています。なぜなら、使い終わったものを電気のスイッチに至るまでちゃんと切ることができるエンジニアを最後に見たのはいつだったでしょうか。
コスト配分とShowback/Chargebackの実装戦略
コストの内訳を理解するには、使用タイプによるグループ化から課金タイプによるグループ化に切り替えるだけです。そうすると、定期的なコストがAmazon RDSのリザーベーションに対する定期料金であることがわかります。Amazon RDSが最もコストがかかっていることがわかったところで、コスト削減の機会がないか気になってきますよね。そこで活用したいのがAWS Cost Optimization Hubです。ここでは、組織全体のコスト削減機会を統合し、定量化し、重複を排除して提示しています。Cost Optimization Hubのページにアクセスすると、約1,000ドル相当のコスト削減機会があることがわかり、その大部分がまさにRDS Reserved Instanceの推奨事項となっています。
この推奨事項をクリックすると、特定のAmazon RDSインスタンスについて、どのリージョンにあるか、推定される削減額などの詳細が表示されます。ここで注目したいのは、大きな出費に見えても心配する必要はないということです。すべてを一度に購入する必要はなく、一部を購入して翌月に再検討するというアプローチでも構いません。時間をかけて少しずつ購入していくことで、より柔軟な選択肢が得られ、支出をきめ細かく調整できます。3年後にどんなアーキテクチャの変更が必要になるかを考えながら3年分の購入を検討するよりもずっと良いでしょう。そのような方法は誰にとっても快適ではありませんし、クラウドを利用する利点の大部分を失うことにもなります。
コミットメント型の購入は、予測可能で一定の使用量に対するコスト削減の優れた方法ですが、一度スピンアップしたものの、実際には使用していないリソースについてはどうでしょうか？私の経験では、ほとんどの人がそれを「本番環境」と呼んでいます。エンジニアが部屋の電気をつけっぱなしにするように、AWSリソースの使用についても同じようなことが起こり得ます。これは、照明や音響を担当している方々も含めて、皆さんにとって驚きではないでしょう - AWSは、つけっぱなしにすると永遠にお金がかかり続けるものなのです。
アイドル状態のリソースを特定することは管理者にとって最優先事項ですが、これは往々にして難しい課題となります。未使用リソースをオフにしないとコストがかかり続ける一方で、重要なリソースをオフにしてしまうと会社の存続にも関わる可能性があるからです。これらの判断は多くの場合不明確で、間違った対応をすると潜在的に壊滅的な結果を招く可能性があります。例えば、テスト環境でEC2インスタンスを頻繁に起動して終了させる場合、接続されていたEBSボリュームやそのスナップショットの削除を忘れがちです。問題は、これらが存在し続け、明らかにコストが発生し続けることです。リソースの過少利用は、間違いなく不要なコストにつながります。
そのため、私たちは常にアイドル状態のリソースを定期的にクリーンアップする習慣を身につけることをお勧めしています。組織内のすべてのアイドルリソースを特定するため、AWS Compute OptimizerとAWS Cost Optimization Hubで、アイドルリソースの検出とクリーンアップの推奨事項の一般提供を開始したことをお知らせできることを嬉しく思います。各リソースタイプについて、AWSサービスチームと協力して「アイドル」の定義を決めています。例えば、EBSボリュームの場合、32日以上どのEC2インスタンスにも接続されていない場合、アイドル状態で未接続とみなされます。アイドルリソースが検出されるたびに、ボリュームのスナップショットを取得して削除するなどのクリーンアップ推奨事項も送信されます。AWS Cost Optimization Hubでは、アイドルリソースの検出とクリーンアップの推奨事項、サイジングの最適化、購入オプションの推奨事項を見つけることができます。AWS Cost Optimization Hubのもう一つの利点は、委任管理者機能です。これにより、支払いアカウントへのアクセス権を付与することなく、組織内のすべてのコスト削減機会にアクセスできます。実装の労力、推定コスト削減額に基づいて、または特定の使用タイプに焦点を当てて、コスト削減の推奨事項に優先順位をつけることができます。
2024年になった今、法律で定められているかのように、カンファレンスのトークには必ずGenerative AIの話題を含めなければならなくなりました。Cost Explorerの事前知識や設定がなくても、Amazon Qを使えば自然言語で費用分析に関する質問をして回答を得ることができます。AWSコンソールのどこからでもアクセスでき、RDSデータベースを作成する際にRDSの支出状況を素早く確認することもできます。月次のコスト変動、コストドライバー、問題のあるインスタンスタイプの特定など、多くの基本的な分析が可能です。個人的に気に入っている機能は、Cost Explorerでその表示を確認できるディープリンクを提供してくれることです。これにより、すべてのドロップダウンをクリックする30～45秒の手間が省けます。この一般提供リリースでは、将来のコスト、Cost Categories、コスト配分タグに関する質問もできるようになりました。
次のヒントは、見えないターゲットは狙えないということです。多くの場合、組織はトップダウンで目標を設定しますが、進捗を追跡するアクセス権がないと、最適化の取り組みの即時的な効果を把握するのが困難です。月次や週次のレポートは役立ちますが、ワークロードを最適化する際の個々のアクションの結果を理解するには、リアルタイムの洞察が不可欠です。KPIを構築するには、まずデータセットから始める必要があります。
Cost and Usage Reportを長時間前に設定した方は、昨年リリースされた新しいData Exportsの機能をご覧になっていないかもしれません。Data Exportsでは、様々な粒度のデータセットから選択し、ニーズに合わせてカスタマイズすることができます。Cost and Usage Reportを組織内の特定のアカウントのサブセットにフィルタリングしたり、タグでフィルタリングしたり、レポート内の列を選択・選択解除したりできます。いずれにしても、時間単位のリソースレベルの粒度で、AWSのコストと請求に関する最も詳細な情報を得ることができます。
時間単位のリソースレベルの粒度で、AWSの支出データには3種類のデータソースがあります。 口頭伝承を含めれば4つになりますが、それではSQLクエリを実行するのが難しいですね。Cost and Usage Reportでは、新しいAWSのカラムサポートとCost Optimization Hubを備えたFOCUSがありますが、請求に関しては全体が衝突ドメインなので、これはスイッチではありません - これはネットワーク関係者向けのジョークです。
人々が追跡できるKPIを構築する最も簡単な方法は、カスタムダッシュボードを持つことです。そして、その最も簡単な方法は、Data Exportsページ内のCost and Usageダッシュボード用のワンクリックデプロイメントを使用することです。これにより、新しいK 2.0標準に基づくコストと使用量のダッシュボードをワンクリックでデプロイできます。コンピューティング、ストレージ、データ転送などのサービス別のコストや、償却コストや請求コストの月次トレンドなど、よくある費用に関する質問への洞察を提供します。そして、それを編集し、分析として保存し、独自のカスタムダッシュボードとして再公開することができます。
Data Exportsを通じて展開するCost and Usage dashboardは、Cloud Intelligence Dashboardsにインスパイアされています。これは、エンタープライズレベルでお客様に実用的なインサイトと最適化の推奨事項を提供するオープンソースフレームワークです。すでに多くの方々が環境に導入されていることは承知していますが、まだの方々のために、CloudFormationテンプレートで簡単に導入できるようになっています。現在は新しいKUDOS 2.0標準に対応しており、すでに導入済みの方々も、定期的なアップデートに気付かれていないかもしれません。新しいKUDOS 5.5バージョンでは、DynamoDBのReserved Capacity推奨機能や、AWS Configの最適化機能が追加されています。
AWS Billing Conductorを用いた複雑な組織構造でのコスト管理
Cloud Intelligence Dashboardスイートは、多岐にわたる機能を提供しています。使用状況分析で人気の高いKUDOSダッシュボード、推奨目標を設定するための事前構築されたKPIダッシュボード、そしてCost Optimization Recommended Actions（略してCORE）ダッシュボードがあります。私が特に気に入っている新しいダッシュボードの1つが、Graviton Savingsダッシュボードです。AWSは控えめですが、私はAWSの上司ではないので、はっきり言わせていただきますが、コスト削減効果は非常に大きいのです。このダッシュボードは、Cost and Usage Reportデータ、価格データ、およびインベントリを組み合わせて、Gravitonをサポートするサービス全体での削減機会を具体的に数値化します。EC2では少し手間がかかりますが、Amazon RDS、OpenSearch、ElastiCacheでは、ボタンをクリックするだけでほぼ実現できます。
では、複数のAWS Organizationsにまたがるデータにアクセスして分析したい場合はどうすればよいでしょうか？既存の使用状況を全て集計する必要がある場合や、契約更新や交渉を控えていて同じ基準で話し合いたい場合など、様々な理由が考えられます。Data Exportsを使用すれば、Amazon S3バケットへのデータ作成を自動化し、そのデータを一元的なデータ収集アカウントに複製することができます。これにより、Amazon Athena、Amazon QuickSight、あるいはお好みの方法（オフィスの壁にクレヨンで書くのでも）で、すべてのデータを一箇所で確認することができます。
KPIは組織で望ましい行動を促すための優れた方法です。しかし、さらに効果的なのは、チームに自身のコストを負担させることです。この分野での5番目のヒントは、ShowbackとChargebackのプロセスを通じて、チームに支出の責任を持たせることです。透明性のあるShowbackとChargebackのプロセスは、クラウドリソースの消費を経費に紐付けます。これにより、チームはリソースの利用効率だけでなく、好むと好まざるとにかかわらず、支出に対する財務的責任を負うことになります。
これは誰のためのものでしょうか？このような特殊な構造を持つのは誰でしょうか？実に様々な組織が該当します。大企業、リセラー、取締役会がまた新たなM&Aの冒険に出かけた企業などです。幅広い事業を展開している場合もあれば、アカウント構造の面で少し先走りすぎてしまったスタートアップの場合もあります。これはそんなあなたのためのものです。
このような組織には支援が必要です。財務報告構造に応じてアカウントをグループ化し、エンドチームの実際のコストを反映した価格設定を行う方法があったらどうでしょうか？AWS Billing Conductorを使用すると、コールセンターなどの同じビジネスエンティティに属するアカウントをグループ化できます。すでにAWS Organizationsのユニットで意図的にそのような構成を行っている場合は、AWS Billing Conductorに権限を付与してOrganization Unitをビリンググループとしてインポートすることができます。
価格ルールを設定する際には、コストや利益を共有するためのマークアップまたは割引を追加できます。これらの価格ルールは、全体レベルのサービス固有の課金エンティティまたはスキルレベルで設定できます。価格設定後の新しいレートはPro Formaレートと呼ばれます。Pro Formaレートは、中央ITコストセンターのエクセレンスチームとビジネスチーム間の効果的なコミュニケーションを促進する上で優れており、クラウドリソースの消費にコストが伴うことを全員が理解できます。これらのPro Formaレートを一定に保つことも、組織の優先順位や変更パターンに応じて定期的に変更することもできます。
Pro Formaというのはラテン語で「私たちが作り上げたもの、あなたも作るべきもの」という意味だということを指摘しておく価値があります。自社を見渡すと、インセンティブを追加することでクラウドの行動経済学を通じて行動の決定を修正できます。例えば、「私たちが好まない古いインスタンスタイプを実行したい場合は、面倒をかけるため20%のマークアップを課金する」といった具合です。価格プランに加えて、AWS Billing Conductorで使用できるもう1つの機能としてカスタムラインアイテムがあり、これによってコストや利益をより意図的に共有できます。多くの方々が、Enterprise Supportの料金、Reserved InstanceやSavings Plansの利益、時にはAWS以外のコストなどを共有するためにカスタムラインアイテムを使用してきました。これらのラインアイテムには好きな名前を付けることができ、それが内部顧客に表示されることを覚えておいてください。
ビリンググループの設定、価格プランの構築、そしてカスタムラインアイテムの設定が完了したら、ビリンググループレベルでコスト管理の委任を開始できます。ビリンググループ内のプライマリアカウントは、そのビリンググループに属するすべてのメンバーアカウントのクロスアカウントビューを持ち、それらのビューはPro Formaレートで表示されるため、支出の管理と最適化を支援できます。AWS Billing Conductorと他のコスト管理ツールとの最近の連携により、メンバーアカウントもPro Formaレートで独自に支出を管理できるようになり、Cost Explorerでのコストの可視化、レポートのダウンロード、Reserved InstanceやSavings Plansのパフォーマンスレポートの確認などが可能です。
ShowbackとChargebackのプロセスにより、チームはコストの透明性を確保し、各部門の説明責任を確立できます。さらに一歩進んで、コストセンターにAWS請求の自分たちの分を支払わせてはどうでしょうか？複数のビジネスエンティティを持つ組織の中には、これまで各ビジネスエンティティ用に完全に別個のAWS Organizationsを作成して個別に請求書を受け取るか、請求書から手動で料金を分割して指定されたビジネスエンティティに割り当てるかのどちらかを選択していました - どちらの方法も余分な作業が必要でした。
請求書を手作業で分割する手間を省き、標準化されたプロセスにするため、私たちはAWS Invoice Configurationをリリースしました。Invoice Configurationを使用すると、同じ請求主体、子会社、コールセンター、部門に属するメンバーアカウントごとに個別の請求書を受け取ることができます。これらのメンバーアカウントは引き続き同じOrganizationの一部であるため、ボリュームディスカウントなど、一括請求のメリットを活用できます。ただし、支払者アカウントがすべての経費を支払うのではなく、これらのビジネス主体が独自に請求書と支払いを管理できるようになりました。
タグ付けとCost Categoriesによる効果的なコスト配分
これを実装するには、同じビジネス主体に属するメンバーアカウントでInvoice Unitを作成し、そのInvoice Unit内のアカウントの中から請求書受信者を指定します。さらに、これらのビジネス主体の資金を個別に追跡できるよう、1つまたは複数のInvoice Unitに発注書を関連付けることもできます。私個人としては、5セント硬貨を山積みにしたダンプトラック1台でAWSの請求書を支払うという長年の夢を実現するために使用する予定です。では次に、プロジェクトやビジネスユニットレベルというさらに下のレベルに移りましょう。通常、このレベルではCost Allocation Tagsを使用します。
このベストプラクティスは「完璧を求めすぎて、良いものを台無しにしない」ということです。これはどういう意味でしょうか？タグの適用範囲や戦略について誰かと話すたびに、皆さん悲しそうな表情をされます。でも、それについてのサポートグループがあります - それは、re:Inventで出会う全ての人たちです。リソースの70%にタグを付けられているなら、ほとんどの組織よりもずっと良い状態です。ここで完璧を達成することは極めて難しいので、無理に目指す必要はありません。そもそも完璧を目指すべきではありません。50セントを追跡するために1万ドルを使うIRSのようになってはいけません。もしIRSの方がいらっしゃいましたら、今の発言は無視してください。今のままで結構です。
ここにはいくつかの課題があります。まず、チームが使用しているタグがあるのに、Cost Allocation Tagsとして有効化されていないという問題です。もしそのような無責任な事態が発生しても大丈夫です。今年3月、AWSは最大12ヶ月前までさかのぼってタグを適用できる機能をリリースしました。これは素晴らしい機能です。そのタグがリソースに付いていさえすれば、アカウントマネージャーに依頼することで、AWSサイドでコストデータのバックフィルを行うことができます。アカウントマネージャーはそのためにいるのです。次に、これらのタグをどのように集計・結合するかという課題があります。1つの部門に複数のコストセンターがあったり、アプリケーションが複数のIDにまたがっていたりする可能性があります。タグの数が増えると分析がさらに複雑になります。3つ目は、タグのコンプライアンスの問題です。タグは大文字と小文字を区別するため、多くの方々（私も含めて）が大文字と小文字の違いだけで複数のCost Allocation Tagsを持っています。私の場合、大文字のPと小文字のpで12個のプロジェクトタグがあります。過去の自分が面倒な人だったせいです。履歴レポートにこのデータが必要な場合、どうやってこれらを整理すればよいのでしょうか？最後に、同じリソースを使用したり共有サービスを消費したりしている場合、蠅の王への転落を避けつつ、どのように分割すればよいのでしょうか？
これらの問題の解決策は、実はあまり注目されていないAWS Cost Categoriesというサービスです。私たちはリソースとタグベースの配分方法にとらわれすぎていますが、実際にはルールベースの配分を使用してこれらのコストをグループ化できます。簡単な例を見てみましょう。大文字と小文字の違いだけで実際には同じ値のタグをグループ化するためにCost Categoryを作成できます。これで、アプリケーションIDごとにタグを確認したい場合、それらのカテゴリが集計されます。もう1つの例として、ビジネスユニット用のCost Categoryを作成できます。関連するアカウントやタグをルールでグループ化して、各部門のカテゴリを分類できます。これを行うと、そのCost Categoryがすべてのコスト管理および請求サービスに反映されます。Cost Explorerでエンジニアリングの使用状況を確認したい場合は、Cost Categoryを使用します。Cost and Usage Reportファイルでマーケティングのアプリケーションだけを照会したい場合も、Cost Categoryを使用できます。AWS Budgetsで人事システムの予算を設定したい場合もできますし、Cost Anomaly Detectionですべての支出を監視したい場合も、Cost Categoryを使用できます。
では、Cost Categoryはどのように作成するのでしょうか？まず、この例ではプロジェクト用のカテゴリーを作成します。次に、アカウントのセット、タグのセット、あるいはサービスやUsage Typeなどの他のBillingディメンションなど、各カテゴリーを分類するルールを定義します。そして、未分類のコストに名前を付けます。通常のこういったツールとは異なり、嬉しいことに、請求データにどのように反映されるかをリアルタイムで確認できるので、試行錯誤を繰り返す必要がありません。その月の償却コストを見ながら確認できます。問題なければ、Cost ExplorerとCost and Usage Reportにバックフィルするためのルックバック期間を指定できます。これは素晴らしい機能です。
7番目のヒントは、適正な分担を確保することです。多くの場合、お客様は共有コストを各環境に均等、比例、または固定レートで分配せず、中央ITで保持しているケースをよく目にします。これは、アプリケーションのオーナーである私が、組織内で実行しているものの真のコストを把握できないため、最適化が不十分になる可能性があります。 このような共有コストに対しても、Cost Categoriesが役立ちます。異なるカテゴリーに対して分割課金を計算するのに役立ちます。
例えば、分割課金により、ビジネスユニットやプロジェクトなどの異なるカテゴリーに費用を配分することができます。AWS Supportの料金などの共有コストを、カテゴリー間で比例配分、均等配分、または固定パーセンテージで分割できます。ただし、重要な注意点として、この機能は単なる計算ツールです。Cost Categoryの詳細ページでレポートを確認し、CSVをダウンロードしてステークホルダーと共有することはできますが、他のCost Categories機能とは異なり、他のBillingおよびCost Managementサービスには影響しません。Cost Explorerなどのツールには表示されませんが、環境の分析を始めたばかりの場合は、Showbackの良い出発点となります。
特定のサービスについては、より詳細なコスト配分を提供できます。 Split Cost Allocation Dataに詳しい方なら、その複雑さをご理解いただけるでしょう。この機能は、Cost and Usage Reportでより詳細なリソースレベルのデータを提供するため、サービスごとに順次展開されています。これはAWS Data Export内の組織レベルで有効化します。適用後は、ECSサービスやEKS Namespaceなどのサービスプリミティブに基づくタグを使用してコストを集計できます。また、未使用のコンピューティングコストを確認することで、異なる視点から最適化の機会を特定することもできます。
Split Cost Allocation Data（SCAD）は、ECSとEKSという2つのコンテナサービスで利用可能です。ECSでは、サービス、クラスター、タグごとにタグレベルのコストをCost and Usage Reportで集計できます。EKSでは、Namespace、Node、Deployment、ワークロードごとにクラスターで発生したPodレベルのコストを集計できます。EKSの設定時には、PodのCPUやメモリリソースの割り当て、または実際の使用率に基づいてコストデータを分割するための追加オプションがあります。Amazon Managed Service for PrometheusまたはAmazon CloudWatch Container Insights（コンテナでCloudWatchデーモンが実行されている場合）を使用して、コストデータとマージされたリアルタイムの使用率データを取得し、共有クラスターの配分と最適化のインサイトを向上させることができます。
クラウドコスト計画の精度向上と新しいAWS Pricing Calculator
8番目にして最後のヒントは、コスト計画に関するものです。451 Researchの調査によると、クラウドテクノロジーに月10万ドル以上を費やしている組織の80%が、ほとんどの月でクラウド予算を超過しているとのことです。これは懸念すべき事態ですが、この追加コストはビジネスの成長や不適切なコスト計画に起因している可能性があります。コスト計画の精度を向上させるには、設計プロセスの早い段階でエンジニアリングチームやビジネスオーナーと連携し、ソフトウェア設計やビジネス計画のサイクル全体を通じてコストを考慮する「シフトレフト」アプローチを検討してください。
コスト見積もりについては現実的に考える必要があります。クラウドで一度も実行したことのないワークロードのコストを20%の精度で見積もれるなら、その能力を活かせる仕事が待っているでしょう。これは困難な作業であり、正確な数値を求めるのではなく、方向性が合っているかどうかを重視すべきです。細かい計算に時間をかけすぎるよりも、その労力を他の部分に向けた方が有効かもしれません。 クラウド運用の利点の1つは、使用状況データに常時アクセスできることです。適切なレポートとメタデータの設定により、使用状況のベースラインを明確に把握することができます。
みなさまからのフィードバックを受けて、AWS Pricing Calculatorの機能を拡張しました。AWS Billing and Cost Management consoleの中で、機能が強化されたAWS Pricing Calculatorがパブリックプレビュー機能として利用可能になったことをお知らせします。AWS Billing and Cost Management console内の強化版AWS Pricing Calculatorは、以前のバージョンと比べて大幅な改善が施されています。
これまでPricing Calculatorを使用する際は、ベースラインとなる詳細情報を手動で収集して入力し、割引も自分で組み込む必要がありました。この新しいコンソール内の認証済みPricing Calculator機能では、AWSアカウントでログインすることで、既存の使用状況をインポートしたり、特定の部分を選択して変更を加え、リアルタイムでコストへの影響を分析したりすることができます。また、ワークロードの変更や購入オプションの変更を考慮しながら、請求全体の計算を実行することも可能です。
この強化されたPricing Calculatorには、いくつかの有用なユースケースがあります。まず、現在のワークロードを新しいリージョンに移行するコストを、すばやくインポートして見積もることができます。また、EC2インスタンスをIntelプロセッサーからAMDプロセッサーに変更した場合のコストへの影響を分析するなど、最適化の機会を効率的に大規模にチェックすることができます。多くの人があまり行っていない重要な演習として、「もし違うやり方をしていたら？」という分析があります。私たちはコミットメント購入を決断する際に悩みますが、その決定を振り返って学ぶことは稀です。過去から学ばず、代替シナリオのモデリングを行わないのは間違いです。ただし、これを非難の材料として使用したり、未来を予測できなかったことを批判したりしないように注意してください。
既存のワークロードの変更を見積もる際、Pricing Calculatorで一からやり直す必要はなくなりました。過去の使用状況を追加した後、過去30日間などの期間を選択し、リージョン、アカウント、サービス、タスク、Cost Categoryでフィルタリングできます。使用状況をプレビューし、フィルターを調整して、必要なものだけを正確にインポートすることができます。インポート後は、リージョン、アカウント、使用タイプ、使用量を変更して、既存の使用状況を編集できます。簡単な見積もりであれば、EBSボリュームをGP3からST1に切り替えたり、将来の成長を見込んで使用量を調整したりといった変更が可能です。
将来のワークロードの変更を見積もる際、Savings PlansやReserved Instancesのカバレッジについて検討することがあるでしょう。ここで新しいBill Scenarioの機能が役立ちます。ワークロードの見積もりを作成する場合と同様に、既存の使用状況をインポートしたり、新しい使用状況を追加したり、使用状況を変更したりできます。その際、組織内のReserved InstancesとSavings Plansは自動的にインポートされます。割引前と割引後の価格を同じ見積もりで組み合わせると数字が意味をなさなくなるため、これは避けることが重要です。新しいコミットメントを追加したり、既存のものを調整したり、現在のものを削除したりした後、使用状況とコミットメントに基づいて潜在的なコストを計算するBill Estimateに提出できます。
Bill Estimateの処理には、請求の複雑さに応じて数分から数時間かかることがあります。完了すると、過去の使用状況と新しく計算された見積もりの違いを詳細に示すBill Estimate reportが提供されます。これにより、変更の影響を素早く分析することができます。Bill Estimateで計算を行うことで、「もし〜だったら」というシナリオを迅速に評価できるようになります。
例えば、大幅に割引された大型のEC2インスタンスを使用するプロジェクトを導入する場合、それがSavings Planのカバレッジにどのような影響を与えるかを確認できます。過去1年間の前払いなしのSavings Planと、全額前払いの1年プランを比較するなどのシナリオを分析して、コストへの影響を理解することができます。
ワークロードの変更を組み込む必要がないシナリオでSavings Planのコスト影響を理解したい場合、異なる時間単位のコミットメント額を評価したり、ルックバック期間を編集したりすることができます。これにより、使用状況のベースラインをより意図的に設定し、それらのSavings Planが適格な使用状況にどのように活用できるかを視覚的に理解することができます。
自分の運命を自分でコントロールするために、コスト削減を最大化するSavings Plansのレコメンデーションを活用するか、新しく登場したSavings Plans Purchase Analyzerを使って、独自の時間単位のコミット額でモデリングを行うことができます。異なる時間単位のコミット額を試してみることで、コストの利用率とカバー率への影響を理解することができます。このアナライザーでは、過去7日間、30日間、60日間、あるいは過去60日以内の特定の期間をカスタマイズして分析することが可能です。さらに、今後90日以内に期限切れとなるSavings Plansを除外して、異なるシナリオを試したり、更新に向けた準備を事前に行ったりすることもできます。
先ほど説明したPricing Calculatorの請求見積もりは、ワークロードの変更や購入オプションの変更による総合的なコストへの影響をシミュレーションするものですが、Savings Plans Purchase Analyzerは、Savings Plansのシナリオによるコストへの影響を素早く分析するためのツールです。時間単位のコミット額に満足したら、そのままショッピングカートに入れて購入することができます。購入が誤りだった場合や、ビジネスニーズに合わなくなった場合は、同じ暦月内であれば7日間の返品ポリシーで全額返金を受けることができます。詳細なポリシーはドキュメントに記載されています。
このアナライザーをあらゆる角度から徹底的に調べましたが、批判や文句を言えるところが見つからないことを、残念ながら報告せざるを得ません。この困難な時期におけるみなさまの精神的サポートに感謝いたします。これらの新機能をコスト計画サイクルにどのように組み込んでいくのか、みなさまのご意見をお待ちしています。
本日は、集計レベルからリソースの詳細レベルまで、どのようにレポートを作成できるかについて説明してきました。また、クラウドの予算に影響を与えるほとんどの要因を把握するために、ボトムアップアプローチを使用してコスト見積もりを行う方法についても推奨しました。 コストのトップダウンアプローチでは、FOCUSフォーマットでのデータエクスポートを利用して、クラウドサービスプロバイダー間でコストと使用量データを標準化することができます。
組織の財務管理プラクティスの健全性を理解したい場合は、Cost Management ConsoleでBillingにアクセスし、AWS Cost Explorerを使用して分析を行うことができます。QuickSightを活用した様々なCloud Intelligence Dashboardがエクスプロレーション用に用意されています。データのダウンロードにはData Exportsを使用でき、アイドルリソースの検出、Right-sizing、購入オプションのレコメンデーションなどのコスト削減の機会を見つけるにはCost Optimization Hubにアクセスすることができます。
コストを適切にステークホルダーに配分するために、Cost Categoriesを使用してデータを論理的にグループ化し、Split Cost Allocationデータを使用して共有リソースのコストを分配し、AWS Billing Conductorを使用して独自の価格ルールでChargebackを実装することができます。これにより、コストセンターやビジネスユニットの責任者に、請求額の各自の負担分に対する責任を持たせることができます。
新しい認証済みAWS Pricing Calculatorを使用することで、AWSとの間で締結している特別な価格条件を考慮した、ワークロードの更新に関するリアルタイムのコスト分析が可能になりました。請求額全体の見積もりについては、コミットメントや使用量の変更を含めることができ、Bill Estimateで費用への影響を理解することができます。既存の使用状況を素早く分析し、Savings Plansの最適なカバレッジモデルを決定したい場合は、Savings Plans Analyzerがお勧めです。これを使用することで、純節約額、利用率、カバレッジに関する洞察を得ることができます。
まだこれらのツールに慣れていない方は、ぜひ使いこなしていただきたいと思います。また、AWS Cloud Financial Managementデジタルトレーニングの開始についてもお知らせします。この無料版は、実践しながら学ぶという高コストなアプローチよりもはるかに優れています。FinOpsのプラクティスの基礎と、主要なAWSサービスカテゴリのための詳細な技術的コスト最適化のヒントをカバーする4つのコースで構成されています。自己流で自信を持って進んでしまうことほど高くつくものはないので、これが間違いなくお勧めの方法です。
ご質問がございましたら、講演後にロビーでお会いできます。お急ぎの方は、本日終了時までにAWS Village Expoで Cloud Financial Managementのエキスパートとお会いいただけます。また、そちらではCloud Financial Managementワイヤーオーガナイザーなどの記念品も配布しています。本日は十分な数をご用意しております。本日は貴重なお時間をいただき、ありがとうございました。どうぞ良い一日をお過ごしください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion