Expenditure / Usage AwarenessのControl

ゴール

最終的に、

請求額が増えた
↓
担当者不明
↓
月末に気付く

ではなく、

コスト / 使用量を
責任単位へ割り当てる
↓
目標を設定する
↓
実際 / 予測を監視する
↓
担当者へ通知する
↓
必要なら制御する
↓
結果を再確認する

という制御ループを作れることがゴールです。

1. 支出認識は「請求額を見ること」ではない

支出を認識するには、

いくら使ったか

だけでなく、

誰が使ったか

何のために使ったか

どの使用量が増えたか

計画値に対してどうか

このままではどうなるか

を説明できる必要があります。

したがって、

合計 AWS コスト

だけを確認しても、

コスト認識

が十分とは限りません。

2. 制御は責任範囲を決めるところから始める

例えば、

プロジェクト A
プロジェクト B
プロジェクト C

が同じAWSアカウントを使用しているとします。

全体の予算だけを、

アカウント 予算
=
100,000 USD

としても、プロジェクト Aが大きく超過し、プロジェクト B / Cが大幅に未使用なら、

アカウント 合計

だけでは問題が見えにくくなります。

そこで、

組織 / アカウント
↓
ワークロード
↓
プロジェクト / チーム

のように、実際に支出責任を持つ単位へ制御範囲を合わせます。

3. コスト配賦を制御範囲へつなげる

コスト配賦の仕組み自体は既習です。

ここでは、その既存の配賦結果を、

予算
担当者
通知
制御

へ接続します。

例えば、

Project=Checkout

という既存のコスト配賦軸があるなら、

Checkout コスト
↓
Checkout 予算
↓
Checkout 担当者
↓
Checkout アラート / 対応

という制御範囲へつなげます。

つまり、

配賦境界
=
説明責任 境界

へ近づけます。

4. 全体予算と担当単位の予算を階層化する

支出管理では、

予算を1つだけ作る

必要はありません。

例えば、

組織
↓
アカウント
↓
アプリケーション
↓
プロジェクト

のように、異なる責任レベルへ予算を設定できます。

例：

AWS全体
500,000 USD / 月

本番 アカウント
250,000 USD / 月

Checkout ワークロード
80,000 USD / 月

こうすると、

全体として正常

でも、

特定ワークロードだけ異常

という状態を検知しやすくなります。

5. コスト予算と使用量予算を使い分ける

AWS Budgetsでは、

コスト予算

と、

使用量予算

を分けて考えられます。

コスト予算では、

何USD使ったか

を監視します。例えば、

Checkout
月50,000 USD

です。

使用量予算では、

何GB
何時間

など、実際の使用量を監視します。例えば、

データ転送
10 TB / 月

EC2 稼働時間

などです。

6. 金額だけでは使用量増加を見落とす場合がある

例えば、

先月
10,000時間
10,000 USD

今月
20,000時間
10,000 USD

だったとします。

割引などによって、

コスト
変化なし

でも、

使用量
2倍

になっています。

この状態をコスト予算だけで見ていると、

問題なし

に見える可能性があります。

しかし、

割引終了
トラフィック増加継続
キャパシティ増加

などが起きれば、将来のコスト要因になります。

そのため、

コスト
+
使用量

を組み合わせます。

7. 使用量予算は同じ測定単位で考える

使用量予算では、

Usage Type

または、

Usage Type Group

を使って使用量を監視できます。

例えば、

GB

単位のデータ転送と、

時間

単位のEC2実行時間は、同じ使用量として単純合算しません。

つまり、

使用量予算
=
意味のある使用量単位

に合わせます。

例えば、

データ転送 Out
↓
GB 予算

EC2 Running
↓
時間 予算

のように分けます。

8. 実績 / 予測は制御 段階へ割り当てる

実績 / 予測の機能自体は既習です。

101で重要なのは、

どのしきい値で
誰が
何をするか

へ変換することです。

例えば、

予測
↓
プロジェクト担当者へ早期通知
↓
原因確認
↓
今月中に修正可能か判断

実績
↓
財務担当 / 管理者へエスカレーション
↓
必要なら制御アクションを承認

のように、同じ予算でも、

シグナル
↓
責任を持つ 担当者
↓
対応

を分けます。

つまり、

予測を知る
実績を知る

こと自体ではなく、

予測 / 実績を
制御ループのどこへ配置するか

がこのページの判断です。

9. アラートを1段階だけにしない

例えば、

予算
100,000 USD

に対して、1つの通知だけを設定するのではなく、

早期警告
↓
担当者が確認

より高いしきい値
↓
財務担当 / 管理者へエスカレーション

さらに超過
↓
制御アクションを検討

という段階的制御にできます。

重要なのは、

何%なら絶対正しい

という固定値ではありません。

そのしきい値で
誰が
何をするのか

まで決めます。

10. アラートは対応できる担当者へ届ける

Budget Alertを作っても、

誰も見ないメールボックス

へ送られていれば制御になりません。

例えば、

Checkout 予算
↓
Checkoutチーム
+
財務担当

のように、

支出を説明できる人
+
対応を決められる人

へ通知します。

個人1人だけではなく、

チーム 配布リスト

など継続的に受け取れる通知先を設計することも重要です。

11. アラートの先に対応を定義する

Budget AlertやBudget Actionの機能自体は既習です。

101では、

通知された後に
何が起きるのか

を制御として設計します。

例えば、

予測しきい値
↓
担当者が確認

実績しきい値
↓
管理者へエスカレーション

重大 しきい値
↓
承認後に制御適用

のように、

アラート
↓
人による対応
または
制御アクション

を対応付けます。

つまり、

通知設定が存在する

だけではなく、

通知
→ 判断
→ 対応

まで接続されていることが重要です。

12. Automatic / Manualは業務影響から決める

Automatic / Manual Approvalの機能自体は既習です。

101では、

自動化できるか

を業務影響から判断します。

例えば開発環境なら、

予算超過
↓
追加利用を自動制限

が許容できる場合があります。

一方、本番環境で、

しきい値超過
↓
即時制御

すると可用性要件を壊す可能性があります。

そのため、

業務影響が小さい
↓
Automaticを評価

業務影響が大きい
↓
Manual Approvalを評価

のように、

コスト リスク
vs
サービス影響

を比較します。

13. Budgetsの遅延を制御設計へ反映する

AWS Budgetsが厳格なリアルタイム支出上限ではないこと自体は既習です。

101では、この性質を、

制御 しきい値

の設計へ反映します。

例えば、

絶対に100,000 USDを
1 USDも超えてはいけない

という要件に対して、

予算しきい値
100,000 USD

だけを設定しても、更新遅延や継続利用によって要求を保証できません。

そのため、

Budget Alert
↓
早めのしきい値

+

予防的 ガードレール
↓
プロビジョニング制御

のように、

検出的 制御
+
予防的制御

を組み合わせます。

つまり更新遅延は、

Budgetsの制約知識

で終わらず、

しきい値をどこへ置くか
どのガードレールを併用するか

へ変換します。

14. 支出制御は検出的と予防的を分ける

コスト制御では、

検知

と、

防止

を分けます。

検出的 / 対応型の代表例：

AWS Budgets
Budget Alert
Budget Action

予防的の代表例：

IAM
SCP
Service Quotas

です。

例えば、

特定リージョンを使用禁止

という組織ルールなら、

費用が発生した後にBudget Alert

だけではなく、

SCP / IAM
↓
そもそもプロビジョニングを制限

する方が適切です。

15. Service Quotasは金額予算ではない

Service Quotasを使えば、

使用可能なリソース数

を制約できる場合があります。

しかし、

Service Quota
=
100,000 USDの支出上限

ではありません。

例えば、

リソース数
キャパシティ
リクエスト関連のQuota

を制限することで、過剰利用リスクを抑えられる場合があります。

つまり、

使用量 ガードレール

として利用し、金額の管理は、

コスト予算

と組み合わせます。

16. コスト可視性は担当者が判断できる形にする

効果的なコスト可視性では、担当者が少なくとも、

現在コスト

現在使用量

予算との差

予測

主要コスト要因

自分の責任範囲

を確認できる状態を作ります。

例えば、

全AWS
1,000,000 USD

だけではなく、

Checkout
実績
62,000 USD

予算
70,000 USD

予測
78,000 USD

のように、

自分が対応できる粒度

へ変換します。

17. 可視性と説明責任をつなげる

コストが見えていても、

担当者不明

なら、改善行動につながりにくくなります。

逆に、

担当者

が決まっていても、

自分のコスト / 使用量が見えない

なら管理できません。

そのため、

コスト配賦
+
コスト可視性
+
担当者
+
予算

を一緒に設計します。

18. 未配賦コストは制御範囲の欠落として扱う

未配賦コストの概念自体は既習です。

101では、

未配賦コストが存在する
↓
どの予算 / 担当者にも
接続できない支出がある

という制御上の問題として扱います。

例えば、

総コスト
100,000 USD

配賦済み
60,000 USD

未配賦
40,000 USD

なら、

40,000 USD
↓
担当者不明
↓
担当予算なし
↓
アラート / 対応 範囲外

になる可能性があります。

したがって、

配賦カバレッジ
↓
制御カバレッジ

として確認します。

ここで目的なのは未配賦コストそのものを再説明することではなく、

制御ループに入っていない支出を
残さない

ことです。

19. 共有コストにも制御 担当者を設定する

共有コストの配賦方法自体は既習です。

101では、その配賦結果について、

共有コスト
=
制御不要

にしないことが重要です。

例えば共有ネットワークやログ基盤なら、

共有サービス コスト
↓
既存の配賦ルール
↓
各ワークロード 予算へ反映

または

共有プラットフォーム
↓
プラットフォーム 担当者
↓
専用予算 / アラート

のように制御範囲へ接続します。

つまり、

共有コスト
↓
担当者
予算
アラート

のどこにも属さない状態を避けます。

20. 制御はコスト超過だけを見るものではない

使用量認識では、

予算超過

だけでなく、

急な使用量増加

未使用キャパシティ

想定外のサービス使用量

新しいリージョンでの利用

予定外のプロジェクト コスト

なども確認します。

例えば、

予算内

でも、

使用量が毎月30%増加

しているなら、将来のコスト超過リスクがあります。

21. 定期的に制御自体を見直す

予算を作った時点では、

適切な予算
適切なしきい値
適切な担当者

でも、事業規模やアーキテクチャが変われば条件も変わります。

例えば、

新機能リリース
↓
トラフィック 3倍

予算
従来のまま

なら、Budget Alertが常に発生して、

アラート疲れ

につながる可能性があります。

反対に、予算が実態より大きすぎれば、

異常な支出

へ気付きにくくなります。

そのため、

実績
↓
使用量
↓
予算
↓
事業計画

を定期的に比較します。

22. Expenditure / 使用量認識の統合例

例えば、

本番 アカウント

プロジェクト
Checkout

月間コスト 目標
50,000 USD

データ転送 目標
20 TB

があるとします。

制御は、

コスト配賦
↓
Project=Checkoutを識別

↓

コスト予算
50,000 USD

+

使用量予算
データ転送 20 TB

↓

予測シグナル
↓
Checkoutチームが早期確認

↓

実績しきい値
↓
財務担当へエスカレーション

↓

必要なら
承認付き制御

↓

組織ポリシー違反なら
IAM / SCPなどの
予防的制御

↓

実績 / 使用量を再確認

という一連の流れにできます。

23. 代表的なアンチパターン

24. SAP-C02での判断フロー

誰が支出責任を持つ？
        ↓

コスト配賦 範囲を決める
        ↓
アカウント
ワークロード
プロジェクト
チーム
環境

        ↓

何を管理する？
        │
        ├─ 金額
        │    ↓
        │ コスト予算
        │
        └─ 使用量
             ↓
          使用量予算

        ↓

実績 / 予測を
何と比較する？
        ↓
予算 / 目標

        ↓

誰へ通知する？
        ↓
担当者
財務担当
管理者

        ↓

どのしきい値で
何をする？
        ↓
確認
エスカレーション
対応

        ↓

事後通知だけで十分？
        │
        ├─ はい
        │   Budget Alert
        │
        └─ いいえ
            IAM / SCP /
            Service Quotas等を評価

        ↓

自動制御してよい？
        │
        ├─ はい
        │   Automatic Action
        │
        └─ いいえ
            Manual Approval

        ↓

コスト / 使用量 / 配賦を
継続的に再評価

まとめ

Expenditure / 使用量認識では、

予算を作る

だけでは不十分です。

まず、

コスト配賦
↓
担当者

を明確にします。

次に、

コスト予算
+
使用量予算

を使って、

支出
+
消費量

を監視します。

既習の実績 / 予測 / Budget Actionを、

誰が
どのしきい値で
何をするか

という制御ループへ接続します。

また、Budgetsの更新遅延を考慮し、

検出的 制御
+
予防的制御

を必要に応じて組み合わせます。

組織ルールとして事前に防止したい場合は、

IAM
SCP
Service Quotas

などを評価します。

最終的には、

コスト可視性
+
コスト配賦
+
予算
+
使用量 監視
+
支出制御
+
担当者

を1つの制御ループとして設計します。

主要AWS公式資料

• AWS Certified Solutions Architect - Professional SAP-C02 Exam Guide — Task 2.6
• AWS Well-Architected Framework — Expenditure and Usage Awareness
• COST02-BP05 — Implement Cost Controls
• COST03-BP03 — Identify Cost Attribution Categories
• COST03-BP05 — Configure Billing and Cost Management Tools
• AWS Budgets — Managing Costs
• AWS Budgets — Creating a Usage Budget
• AWS Budgets — Configuring Budget Actions
• AWS Billing — Cost Allocation Tags