TL

Cloud Service

OCI Budgets

クラウド費用の使いすぎを早期に検知。OCI Budgets はコンパートメントやタグ単位に上限金額を定義し、実績・予測がしきい値を超えると通知で警告する。AWS Budgets に相当する。

基礎コスト最適化運用上の優秀性
最終更新: 2026-06-28公式ドキュメント ↗
TL;DR要点だけ先に
  • 1.コンパートメントまたはタグ単位に月次の上限金額を設定する予算オブジェクト。
  • 2.実績支出と予測支出のしきい値でアラートを発火し、通知やメールで知らせる。
  • 3.あくまで早期警告であり、課金やリソース作成を止める機能ではない。

解決する課題

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

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

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

主要概念と用語

  • 予算(Budget): 特定の対象に対して上限金額を定義するオブジェクト。実績や予測がしきい値に達するとアラートを送る
  • 対象(Target): 予算を集計する単位。コンパートメント単位またはコスト追跡タグ単位のいずれかを選ぶ。1 つの予算で両方を同時に対象にはできない
  • アラートルール(Alert Rule): 予算に紐づくしきい値設定。実績支出(ACTUAL)予測支出(FORECAST) のどちらを基準に、金額または割合(例 80 パーセント)で発火するかを定義する
  • 実績支出(Actual Spend): その期間に実際に発生済みのコスト。確定値ベースの判定に使う
  • 予測支出(Forecast Spend): 過去の使用傾向から推定した期間末の着地額。月の前半で急増した場合の早期検知に使う
  • リセット周期(Reset Period): 予算を集計し直すサイクル。月次が基本で、月初など開始日を指定する
  • コスト追跡タグ(Cost-Tracking Tag): 定義済みタグ(Defined Tag)に「コスト追跡」属性を付与したもの。タグ単位の予算はこれをキーに集計する
  • 通知(Notifications / ONS): アラートの配信経路。メール宛先のほか、Notifications トピック経由で Email・PagerDuty・Slack・Functions などへ届けられる

仕様・制限・クォータ

  • 対象はコンパートメント単位かタグ単位のいずれかで、1 つの予算で両方を同時に対象にはできない
  • リセット周期は原則として月次で、リセットのタイミング(月初など)を指定できる
  • 1 つの予算に複数のアラートルールを設定できる(例: 50 パーセント・80 パーセント・100 パーセントで段階通知)
  • コスト追跡タグは事前の作成・適用が必要で、付与前に発生したコストは遡って分類されない。導入初期にタグ設計を固めることが重要
  • コストデータには反映の遅延がある。利用が記録されてから予算評価に反映されるまで時間差があり、分単位のリアルタイム監視には向かない
  • 予算アラートは通知であって課金停止ではない。しきい値を超えてもリソースは動き続け、自動でサービスが止まることはない
  • 予算は通常テナンシ全体のコストを対象にできるため、作成・閲覧には相応の権限が要る
  • 予算やアラートルールの個数には**テナンシ単位の上限(クォータ)**があり、必要に応じてサービスリクエストで引き上げる

内部の仕組み

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

  • 計測 → 集計 → 評価 → 通知という流れで、Budgets は集計済みのコストデータを定期的に評価する側に位置する
  • 予算の評価は周期的に実行され、対象(コンパートメントまたはタグ)に紐づく当期の実績コストを集計し、各アラートルールのしきい値と比較する
  • 予測ベースのルールでは、過去の使用傾向から推定した着地額をしきい値と比較するため、期間の途中でも超過見込みを検知できる
  • しきい値を満たすと、予算はメール宛先または Notifications(ONS)トピックへアラートを送る。トピックから先は Email・PagerDuty・Slack・Functions などへ配信できる
  • タグ単位の集計は、リソースに付与されたコスト追跡タグをキーに行われる。タグが付いていないコストは「タグなし」として扱われ、按分されない
予算は止めない・遅延がある

Budgets のアラートは「超えそう・超えた」を知らせるだけで、リソースを自動停止しません。コストの強制ガードが必要なら、Compartment Quota でリソース作成を制限したり、アラートを Functions に流して自動で停止・スケールダウンする処理を自前で組みます。 また、コストデータは反映に時間差があるため、予算アラートは「即時の支出ブロック」ではなく「早期警告」として設計します。

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

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

運用・監視

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

コスト

Budgets の機能そのものは、基本的に追加料金なしで利用できるのが一般的です。課金されるのは予算が監視している対象、つまりクラウドリソースの利用料であり、予算やアラートの作成・評価に対して別途費用は発生しないのが通例です。

ただし、アラートを配信する Notifications の配信分など、周辺サービス側でわずかな費用が生じる場合があります。Budgets の価値は、これらを使って本体のリソース費用を最適化することにあります。変動する具体的な料金は公式の料金ページで確認してください。

セキュリティ

  • 参照と管理を IAM で分離: 予算の閲覧と、作成・変更(manage usage-budgets 相当)を別グループに割り当て、最小権限にする
  • テナンシ全体のコストは強い権限: 予算はテナンシ全体のコストに触れ得るため、作成・閲覧はファイナンス担当など限定したグループにのみ付与する
  • 通知経路の保護: アラートの宛先 Notifications トピックは、HTTPS なら TLS と受信側認証、メールなら確認済みアドレスのみを使う
  • タグの整合性: コスト追跡タグはタグ名前空間(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 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 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 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 list --compartment-id "$TENANCY_OCID"
oci budgets alert-rule list --budget-id "$BUDGET_OCID"

OCI Service

OCI Budgetsを実務で読む

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

解決すること

管理・ガバナンス

比較で見る軸

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

導入後に効く点

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

先に潰すリスク

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

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

判断チェックリスト

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

次に確認する観点

管理・ガバナンスcostoperational