★事前知識

●タグ
リソースを整理するためのメタデータとして機能するキーと値のペア。リソース作成時にタグを追加できる。

【ディメンションとメトリクスの違い】

ディメンション	データの分析軸・データ項目のこと
メトリクス	データの数値的な指標のこと取得、監視する項目

Billing and Cost Management

AWSの各コスト管理サービスを一元化して管理するプラットフォームみたいなもの。
各コスト管理サービスを呼び出す（？）

（請求）ダッシュボード	毎月の使用量の概要と内訳を表示。
コストカテゴリ	タグやアカウントに基づいてコストデータをグループ化するルール(コストカテゴリ)を定義できる。（例:カテゴリーTeam1） ⇒詳細なレポートや分析が可能になる。コストの分類と分析を実現

【コンソールへのIAMアクセスを有効】
特定のユーザーやチームに対してコンソールへのアクセスを許可。

◇異常検出

[情報を展開する]

項目	AWSサービスのコストモニタータイプ	Linked Accountのコストモニタータイプ
対象範囲	各AWSサービスごとのコストと使用量を詳細に監視	複数のLinked Account全体のコスト動向を監視
監視対象	個別のAWSサービスやリソース（リソース単位のコスト異常）	アカウント全体のコスト（統合的なコストトレンド）
異常検出の粒度	リソース単位の詳細なコスト異常を検出	アカウントレベルの大まかな異常を検出
通知のタイミング	サービスやリソースごとのコスト異常が検出された場合	アカウント全体でコストが一定のしきい値を超えた場合
適用シナリオ	特定のサービスやリソースの異常なコスト増加を迅速に特定したい場合	複数のアカウント間で全体的なコストの傾向を把握したい場合
運用チームへの通知の精度	詳細なリソース単位でのコスト異常を通知	総合的なコスト増加の通知（詳細なリソースは不明瞭）
推奨される使用ケース	特定のリソースやサービスのコスト最適化と、不要なリソースを早期に検出したい場合	コストの全体的なトレンドを把握し、全体の予算管理を行う場合

Cost Explorer
【コスト見える化/予測】

※[請求とコスト管理] メニューからCost Explorer → 有効化することで利用できる。

◇分析機能

[情報を展開する]

大まかにデータを分析したり 、コストと使用量のデータを詳細に分析して「傾向、コスト要因、異常」を特定できる。

コストの最適化	適切なサイズ設定に関する推奨事項により実現可能。 (例: すべてのアカウントの合計コストと使用量)
コスト異常検出 (Cost Anomaly Detection)	機械学習モデルを利用して、AWSコストに異常が発生すると検出できる。想定外のコストが発生することを減らすことができ、アラートを受信することができます。

◇グラフ（ビュー）機能

[情報を展開する]

当月データは約24時間後に反映される。以降、24時間以内に一回更新される。
（※過去分：最大13ヶ月分まで）

フィルタリング / グループ化	コストと使用量のデータを深く掘り下げることができる。
カスタムレポート	作成、保存、共有することで、さまざまなデータセットを調査できる。利用状況から今後３か月分の、時間範囲のコストと使用量の予測したレポートを作成できる。
ビジネスインサイトの取得	コストと使用状況に関する情報、および設定済みのビューから確認できる。

Cost & Usage Report（CUR）
【詳細レポート】

◇使用状況レポート

[情報を展開する]

「Cost Explorer」から設定した情報をもとにAWS上で使用している。サービス、料金、リザーブドインスタンス、SavingsPlansなど各種リソースの使用状況に関して、詳細な情報をCSV形式でS3に出力する。
（１日に最大３回レポートを出力可能）

・使用状況の種類や運用ごとに分類でき、レポートは1時間、1日、1ヵ月と単位を設定が可能。

・各AWSサービスの利用状況やコストを把握しコスト最適化になるよう見直しが可能。

・AWS アカウントで使用する AWS 製品、使用タイプ、オペレーションの固有の組み合わせごとに明細項目が表示される。

➡明細項目一覧

◇コスト配分タグ

[情報を展開する]

【タグ別の利用料金】
コスト配分レポートでリソースコストを整理し、AWSコストの分類と詳細レベルの追跡を容易にする。既存タグはコスト配分タグにできない。配分タグをアクティブ化することで利用できる。なお、管理者のみ実行可能。

[ 例 ]
EC2 Instanceを複数台構築されている場合でも、1台ごとにNameタグを付与しておけば、Nameタグ別に利用料を出力することができる。

ユーザー定義型	コスト配分タグとしてアクティブ化することで独自のタグによりコストの分類、利用料金を把握することが可能となる。
AWS 生成型(createdBy)	誰がリソースを作成したか追跡できるAWSタグ。 AWS生成タグを使用するには、管理アカウントの所有者がBilling and Cost Managementコンソールでそれを有効にする必要がある。

◇連携サービス

[情報を展開する]

Redshift	S3に保存したファイルをRedShiftにアップロードすることで使用可能。
QuickSight	CURをS3に保存し、QuickSightダッシュボードからデータソースとして指定することで可視化することができる。
Athena	S3に出力されているレポートファイルにクエリを発行して条件別にデータ抽出が可能。

Budgets
【数量的アラート】

「コスト」または「（リソース）使用量」が予算額や予算量を設定したしきい値超えたとき (あるいは、超えると予測されたとき) にアラートを発信する。 （毎月の固定予算を作成することが可能）
ただし、過去のコストデータを分析し、今後のコスト予測を行う機能は提供していない。

Saving Plans	使用状況を追跡し、特定の閾値に達した時、通知することができる。 ※通知を行うサービスとして、Amazon SNS が推奨される。
RI （リザーブドインスタンス）	●RI 使用率 リザーブドインスタンス契約で設定した使用率未満だった場合にアラートを上げる。 ●RI Coverage【カバー率 , 網羅立】 RI で「カバーされている時間数」、「オンデマンドインスタンスに費やした金額」、および「追加の予約を購入した場合に節約できた可能性」がある金額が表示される。これにより、RI の購入が不足しているかどうかを確認できる。

【通知手段】
・メール
・Amazon SNS
・AWS Lambda → 他チャットやSNSと連携

その他コスト削減に向けたサービス

AWS（Amazon Web Service）の利用コストを削減する方法の一環として取り上げられるサービス。

Saving Plans
【利用分を宣言】

・EC2、Fargate for ECSの利用料を最大72%削減。
・Fargate for EKSを最大52%削減。
・Lambdaを最大17%削減。SageMakerを最大64%削減。

◇性能性

[情報を展開する]

Saving Plans 通知アラート	有効期限と予約期限に対するアラート機能。
EC2 Instance Savings Plans	同じリージョン内のインスタンスファミリーに適用される（最大72%の）割引プラン。 サイズ、AZ、OS、テナンシーには影響されず、同じリージョンであれば選ばれたインスタンスファミリーの料金を削減できる。長期間にわたり継続的かつ安定した計算能力を提供する。 ・インスタンスのOS（Windows→Linux）に変更しても、割引は自動的に反映される。 ・特定のインスタンスタイプに適用され、他のインスタンスタイプは変更できない。
Compute Savings Plans	EC2インスタンスを使った量に対して自動的に割引される。インスタンスファミリー、サイズ、AZ、リージョン、OS、テナンシーすべてに対応している（最大66％割引）のプラン。 そのほか、Fargateおよび Lambdaにも適用される。メモリやストレージよりも、計算処理能力（コンピュート）を重視。一貫したコンピューティング使用料を契約することでコストの最適化を図れる。

◇Saving Plans と RI の比較

[情報を展開する]

	Compute Savings Plans	EC2 Instance Savings Plans	コンバーチブル RI*	スタンダード RI
オンデマンドに比べ節約	最大 66%	最大 72%	最大 66%	最大 72%
金銭的コミットメントと引き換えに価格を下げる	✅	✅	—	—
すべてのインスタンスファミリーに自動的に価格を適用	✅	—	—	—
任意のインスタンスサイズに自動的に価格を適用	✅	✅	※	※
すべてのテナンシーまたはOSに自動的に価格を適用	✅	✅	—	—
Fargate に自動的に適用	—	✅	—	—
Lambda に自動的に適用	—	✅	—	—
AWS 地域全体に価格を自動的に適用	✅	✅	—	—
1年または3年の期間オプション	✅	✅	✅	✅

適切なサイジング
【プロセス】

可能な限り低いコストで、インスタンスの「タイプ」と「サイズ」、ストレージの「クラス」を、ワークロードのパフォーマンスとキャパシティ要件にマッチングさせるプロセス。
また、デプロイされたインスタンスを調べ、キャパシティや他の要件を犠牲にすることなく、それらのインスタンスを取り除いたり、ダウンサイジングしたりする機会を特定するプロセスでもあり、更なるコスト削減が狙える。

※組織が AWS クラウドに初めて移行する際に考慮されないことがよくある。

[ 例 ]
インスタンスのパフォーマンスおよび使用の必要性とパターンを継続的に分析し、アイドル状態のインスタンスをオフにする。
オーバープロビジョニングされているインスタンスやワークロードとのマッチングが不十分なインスタンスを適切なサイズにする。