まず、何に使った費用かをそろえる
- 比較する範囲と期間を決める
本番と検証、サービス、担当用途など、説明したい単位を決めます。税や集計の扱いが異なる数字をそのまま比較しないようにします。
- 用途ごとに分類する
Cost Explorerのサービス、アカウント、タグなどによる分類を使い、どの部分が変わったかを調べます。タグの意味と付け方もそろえます。
- 増減の理由を合わせて記録する
利用者数の変化、データ追加、一時的な検証などを確認します。額が増えた理由と、不要な利用が残っているかを分けて考えます。
見直す対象によって、確認する品質が変わる
| 見直す対象によって、確認する品質が変わる | 使っていない資源 | 保存するデータ | 処理と配信の設定 |
|---|---|---|---|
| 見直しの起点 | 用途と担当が分からないものを調べる | 保持期間と過去版の量を確認する | 利用状況と設定の対応を見る |
| 変更前の確認 | 依存先、再利用予定、復旧手段 | 原本、許諾情報、復元に必要な範囲 | 待ち時間、失敗、取得結果への影響 |
| 変更後の確認 | 必要な機能が動くか | 必要な版を引き続き参照できるか | 費用と利用者体験を同じ条件で比較できるか |
予算通知は、支出を即時に止める装置ではない
AWS Budgetsの通知を検討するときは、料金の集計から通知までに遅れがあることを前提にします。通知条件を超えてからも利用が続く可能性があり、通知だけを支払上限として扱わないようにします。
通知を受けたときに、何を調べ、どの利用を止めてよいかを決めます。停止が業務に与える影響や、止めても残る費用を確認する必要があるため、通知先の設定と対応手順を一緒に考えます。
削減額と一緒に残す、変更の根拠
- 比較条件
- 対象の用途、期間、利用量、設定変更を記録し、異なる条件の合計額だけで効果を判断しないようにします。
- 品質の確認
- 必要な応答、処理の完了、データ保持、復旧の条件を維持できるかを確認します。
- 戻す条件
- 期待した効果が出ない場合や業務に支障が出た場合に、何を元へ戻すかを事前に決めます。契約や長期の利用約束が伴う変更は別途条件を確認します。
見積もりと実際の費用を考える
予算アラートを設定すれば、その金額で利用が止まりますか。
通知だけでは利用停止や支払上限を保証しません。集計や通知の遅れも踏まえ、通知を受けた後の調査と必要な対応を決めておきます。
合計額が下がれば、最適化できたと判断できますか。
利用量が減っただけの可能性や、必要な機能を失った可能性もあります。用途ごとの費用と利用条件、必要な品質を合わせて確認します。