クラウドサービス

OCI Budgets

クラウド費用の使いすぎを早期に検知。OCI Budgets は子テナンシ・コンパートメント・タグに予算額を定義し、実績・予測がしきい値を超えるとメールで警告する。

基礎コスト最適化運用上の優秀性
最終更新: 2026-07-29公式ドキュメント
3つの要点
TL;DR
  1. 子テナンシ・コンパートメント・タグに、月次または最長1年の単発予算を設定する。
  2. 実績支出と予測支出のしきい値でアラートを発火し、登録先へメールで知らせる。
  3. あくまで早期警告であり、課金やリソース作成を止める機能ではない。

解決する課題

請求書が届いてから「今月は高かった」と気づく後追いの運用では、コスト超過に手を打つのが手遅れになります。OCI Budgets は対象ごとに上限金額としきい値を定義し、超えそうな段階で能動的に警告することで、この問題を解決します。

  • チーム・プロジェクト・環境ごとに支出の上限を明示し、合意形成の基準にしたい
  • 上限に近づいたら自動で関係者へ通知し、月末の請求を待たずに気づきたい
  • 実績だけでなく予測(このままだと月末いくらか)でも早期警告したい
  • しきい値ごとに通知先を変え、段階的なエスカレーションを組みたい
  • コスト管理を属人的な目視チェックではなく、仕組みとして恒常化したい

AWS で言えば AWS Budgets に相当する位置づけです。可視化が主役の Cost Analysis(AWS の Cost Explorer 相当)と組み合わせて使います。

主要概念と用語

  • 予算(Budget): 特定の対象に対して上限金額を定義するオブジェクト。実績や予測がしきい値に達するとアラートを送る
  • 対象(Target): 予算を集計する単位。親テナンシでは子テナンシ、親・子の双方ではコンパートメントまたはタグを選べる
  • アラートルール(Alert Rule): 予算に紐づくしきい値設定。実績支出(ACTUAL)予測支出(FORECAST) のどちらを基準に、金額または割合(例 80 パーセント)で発火するかを定義する
  • 実績支出(Actual Spend): その期間に実際に発生済みのコスト。確定値ベースの判定に使う
  • 予測支出(Forecast Spend): 過去の使用傾向から推定した期間末の着地額。月の前半で急増した場合の早期検知に使う
  • 期間: 毎月繰り返す月次予算と、開始日・終了日を指定する単発予算がある。単発期間は最長1年
  • コスト追跡タグ(Cost-Tracking Tag): 定義済みタグ(Defined Tag)に「コスト追跡」属性を付与したもの。タグ単位の予算はこれをキーに集計する
  • 通知先: アラートルールへ登録するメールアドレス。Budgets から Notifications トピックへ直接送る機能ではない

仕様・制限・クォータ

  • 対象は子テナンシ・コンパートメント・タグのいずれか。子テナンシを対象にできるのは組織の親テナンシから作成する場合に限る
  • 期間は繰り返しの月次または最長1年の単発。月次では処理開始日、単発では開始日と終了日を指定する
  • 同じコンパートメントまたは同じタグを対象にできる予算はそれぞれ1つで、段階通知は1つの予算へ複数のアラートルールを付けて表現する
  • 1 つの予算に複数のアラートルールを設定できる(例: 50 パーセント・80 パーセント・100 パーセントで段階通知)
  • コスト追跡タグは事前の作成・適用が必要で、付与前に発生したコストは遡って分類されない。導入初期にタグ設計を固めることが重要
  • コストデータには反映の遅延がある。利用が記録されてから予算評価に反映されるまで時間差があり、分単位のリアルタイム監視には向かない
  • 予算アラートは通知であって課金停止ではない。しきい値を超えてもリソースは動き続け、自動でサービスが止まることはない
  • ルートコンパートメントを対象にすればテナンシ全体を追跡でき、親テナンシからは子テナンシ単位にも追跡できる。作成・閲覧にはルート側の予算権限が要る
  • 予算やアラートルールの個数にはテナンシ単位の上限(クォータ)があり、必要に応じてサービスリクエストで引き上げる

内部の仕組み

横にスクロール

OCI Budgetsについて、実績・予測支出を日次評価し、しきい値超過を通知する処理経路と利用者・サービスの責任境界を示す図
OCI Budgets の処理経路。予算はソフト上限であり、課金や資源作成を停止しない

OCI の課金エンジンが各サービスの使用量を継続的に計測・集計し、その集計結果を予算の評価エンジンが周期的に参照してしきい値判定を行います。

  • 計測 → 集計 → 評価 → 通知という流れで、Budgets は集計済みのコストデータを定期的に評価する側に位置する
  • 予算の評価は24時間ごとに実行され、対象(子テナンシ・コンパートメント・タグ)に紐づく当期の実績コストを集計し、各アラートルールのしきい値と比較する
  • 予測ベースのルールでは、過去の使用傾向から推定した着地額をしきい値と比較するため、期間の途中でも超過見込みを検知できる
  • しきい値を満たすと、予算はアラートルールへ登録したメールアドレスへ警告を送る。通知先は Budgets が直接管理する
  • タグ単位の集計は、リソースに付与されたコスト追跡タグをキーに行われる。タグが付いていないコストは「タグなし」として扱われ、按分されない
予算は止めない・遅延がある

Budgets のアラートは「超えそう・超えた」をメールで知らせるだけで、リソースを自動停止しません。コストの強制ガードが必要なら Compartment Quota で作成上限を制御します。自動停止が必要な場合も、Budgets から Functions への直接配信ではなく、別の定期評価や運用処理として設計します。 また、コストデータは反映に時間差があるため、予算アラートは「即時の支出ブロック」ではなく「早期警告」として設計します。

設計パターン / ベストプラクティス

  • コンパートメント設計を予算の単位に合わせる: チーム・プロジェクト・環境(本番/検証)でコンパートメントを切ると、その境界がそのまま予算対象になる
  • コスト追跡タグを早期に標準化: CostCenterProjectEnvironment などの定義済みタグをコスト追跡対象にし、タグ付け規約を IaC(Terraform 等)で強制する。後付けは遡れないため初期が肝心
  • 段階的なアラートルール: 同じ予算に 50・80・100 パーセントなど複数のしきい値を設定し、早期は担当者、超過時はマネージャーへとエスカレーションする
  • 予測ベースのアラートを併用: 実績だけでなく予測ベースのルールも入れておくと、月の前半での急増による着地超過を早く検知できる
  • 重要度別に通知先を分離: アラートルールごとにメール宛先を分け、早期警告と超過時の受信者を整理して通知疲れを防ぐ
  • 自動アクションは別経路で設計: 検証環境の夜間停止や上限超過時のスケールダウンは、スケジュール処理やコストAPIの定期評価として実装する
  • 強制力が要る箇所は Quota で: 「これ以上作らせない」はアラートではなく Compartment Quota で実装する

運用・監視

  • アラートが鳴らない: アラートルールの基準(実績か予測か)、しきい値(金額か割合か)、登録したメール宛先、最終評価時刻を確認する
  • タグ別予算が想定と合わない: コスト追跡属性が付いた定義済みタグを使っているか、リソースに実際にタグが付与されているか、タグ付け前の期間ではないかを確認
  • 数字がリアルタイムでない: コストデータには反映遅延があるのが正常。当日のごく直近の利用は反映途中のことがある
  • 予測が大きく振れる: 月初は実績が少なく予測が不安定になりやすい。予測ルールのしきい値は余裕を持たせる
  • 権限不足で予算が見えない: 後述の IAM ポリシー(usage-budgets の参照・管理権限)を確認する
  • 可視化と組み合わせる: 超過の内訳を深掘りするときは Cost Analysis でサービス別・コンパートメント別に分解する

コスト

Budgets の機能そのものは追加料金なしで利用できます。課金されるのは予算が監視しているクラウドリソースの利用料で、予算やアラートの作成・評価、登録先への警告メールに別料金は発生しません。Budgets の価値は、警告を起点に本体のリソース費用を最適化することにあります。

セキュリティ

  • 参照と管理を IAM で分離: 予算の閲覧と、作成・変更(manage usage-budgets 相当)を別グループに割り当て、最小権限にする
  • テナンシ全体のコストは強い権限: 予算はテナンシ全体のコストに触れ得るため、作成・閲覧はファイナンス担当など限定したグループにのみ付与する
  • 通知先の保護: アラートルールへ登録するメールアドレスを必要な担当者に絞り、異動や役割変更に合わせて定期的に見直す
  • タグの整合性: コスト追跡タグはタグ名前空間(Tag Namespace)で一元管理し、自由記述タグの乱立で集計が壊れないようガバナンスを効かせる
  • 操作証跡は Audit で: 予算の作成・変更・削除は OCI Audit に記録される。誰がいつ予算を緩めたかを追跡できるようにしておく
役割分担を押さえる

「コストがいくらか」は Cost Analysis、「上限に近づいたら知らせる」は Budgets、「リソースをこれ以上作らせない」は Compartment Quota、「誰がいつ何を操作したか」は OCI Audit。 コスト管理は可視化と警告、強制は Quota、操作証跡は Audit、と役割を分けて設計します。

関連サービス・比較

最も近い関連サービスは Cost Analysis です。Cost Analysis が支出を可視化・分析する読み取り系であるのに対し、Budgets は上限を定義してしきい値で能動的に警告する評価系であり、両者は補完関係にあります。

観点OCI BudgetsOCI Cost Analysis
主な役割上限としきい値で警告コストの可視化・分析
処理の性質周期評価して通知する集計をクエリして表示する
集計の単位コンパートメントまたはタグ期間・サービス・コンパートメント・タグ
主なアウトプットアラート通知グラフと集計表
AWS の相当AWS BudgetsCost Explorer

ハンズオン / CLI例

# 1) コンパートメントを対象に月次予算を作成
#    amount は通貨単位、reset-period は月次サイクルを指定
oci budgets budget budget create \
  --compartment-id "$TENANCY_OCID" \
  --target-type "COMPARTMENT" \
  --targets "[\"$COMPARTMENT_OCID\"]" \
  --amount 1000 \
  --reset-period "MONTHLY" \
  --display-name "team-a-monthly-budget"

# 2) 実績支出が 80% に達したらメールで通知するアラートルールを追加
#    type は ACTUAL(実績)か FORECAST(予測)、threshold-type は割合か金額
oci budgets budget alert-rule create \
  --budget-id "$BUDGET_OCID" \
  --type "ACTUAL" \
  --threshold 80 \
  --threshold-type "PERCENTAGE" \
  --recipients "finance@example.com" \
  --display-name "alert-80pct-actual"

# 3) 予測支出が 100% を超える見込みになったら鳴らす予測ベースのルール
oci budgets budget alert-rule create \
  --budget-id "$BUDGET_OCID" \
  --type "FORECAST" \
  --threshold 100 \
  --threshold-type "PERCENTAGE" \
  --recipients "finance@example.com" \
  --display-name "alert-forecast-overrun"

# 4) 作成済みの予算とアラートルールを一覧で確認
oci budgets budget budget list --compartment-id "$TENANCY_OCID"
oci budgets budget alert-rule list --budget-id "$BUDGET_OCID"

OCI Service

OCI Budgetsを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

管理・ガバナンス

比較で見る軸

クラウド: OCI / カテゴリ: 管理・ガバナンス / 難易度: basic

導入後に効く点

実績支出と予測支出のしきい値でアラートを発火し、登録先へメールで知らせる。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
OCI
カテゴリ
管理・ガバナンス
難易度
basic
関連資格
設計柱
cost / operational

判断チェックリスト

  • 自社の用途が「管理・ガバナンス / cost」に近いか確認する。
  • 強みである「子テナンシ・コンパートメント・タグに、月次または最長1年の単発予算を設定する。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

管理・ガバナンスcostoperational