OCIコスト管理・ガバナンス実践Vol1｜Budgets×Compartment Quotas二層統制

1. この記事について

OCIのコスト管理・ガバナンスは、単体のサービス名だけを見るとAWSとの対応が分かりにくい領域です。予算アラートを出すBudgets、コストを可視化するCost Analysis(および2024年に登場したFinOps Hub)、コンパートメント単位でリソース消費量の上限を制御するCompartment Quotas、そしてコストの帰属先を明示するdefined tags——これらは個々には単純な機能ですが、複数のコンパートメントにまたがる検証環境を運用する段になって初めて、組み合わせて使う意味が見えてきます。本記事は、この4つの仕組みを実際に結線し、AWSでCost Explorer・Budgets・Service Quotas・タグポリシーを運用してきたエンジニアが、OCIでも同じ統制を再現できる状態まで組み立てることを目的としています。

これまでの「OCI入門」シリーズおよび9本の実践系記事では、個別のサービス(コンピュート・ネットワーク・データベース・DevOps・セキュリティなど)を1つずつ深掘りしてきました。しかし、複数のコンパートメントに分散したリソース群を実際に運用していると、「どのコンパートメントがいくら使っているか」「想定外の高額リソースの作成をどう未然に防ぐか」「タグ付けを徹底させるにはどうするか」といった、個別サービスの解説だけでは扱いきれない横断的な統制の問題が必ず出てきます。本記事は、この横断的な統制という、これまでのシリーズでは正面から扱ってこなかった観点に焦点を当てる記事です。

1-1. 本記事のゴール

本記事は、「OCIコスト管理・ガバナンス実践」シリーズの第1弾として、Budgets・Cost Analysis(+FinOps Hub)・Compartment Quotas・defined tagsの4つを実際に結線し、既刊ハンズオンで作成したコンパートメント群を対象にコスト・ガバナンス統制を組み立てることをゴールとしています。

具体的には、AWS実務者が使い慣れたBudgets・Cost Explorer・Service Quotas・コスト配分タグとの対応関係を足がかりにしつつ、OCI固有の設計であるBudgets(ソフトリミット)とCompartment Quotas(ハードリミット)を組み合わせた二層統制、およびdefined tag namespaceを起点としたタグベースのコスト配賦を、実際に手を動かして構築できる状態を目指します。

本記事が差別化のために特に重視しているのは、次の3点です。

• AWS実務者がゼロから読んでも迷わないよう、各OCIサービスに対応するAWSサービスを明示した対応マップを起点に構成を組み立てます
• タグを作って終わりではなく、defined tag namespaceの作成からcost-tracking有効化、tag defaultsによるコンパートメントへの自動付与、Cost Analysisでのタグ別配賦確認までを一続きの実践として扱います
• Budgets単体・Compartment Quotas単体の解説にとどまらず、ソフトリミットとハードリミットという性質の異なる2つの統制を組み合わせて設計する視点を扱います

これらはいずれも、個々のOCI公式ドキュメントを読むだけでは掴みにくい、複数サービスを跨いだ「設計判断」に相当する部分です。本記事は、単一サービスのマニュアル的な解説ではなく、既刊のハンズオン資産を使って実際に手を動かしながら、この設計判断を体験できる構成を目指しています。

本記事を読み終えると、次の状態になっていることを目指しています。

• OCI BudgetsとAWS Budgetsの対応関係を踏まえて、実績・予測支出に基づく予算アラートを設定できる
• defined tag namespaceを作成し、cost-tracking属性を有効化したタグをtag defaultsで新規リソースへ自動付与できる
• Compartment Quotasのポリシー文を使って、コンパートメント単位でリソース作成のハードリミットを設定できる
• BudgetsとCompartment Quotasの役割の違い(ソフトリミット/ハードリミット)を踏まえて、二層統制の設計判断を説明できる

なぜBudgets単体でもQuotas単体でも不十分なのか

Budgetsは、実績または予測支出があらかじめ設定したしきい値を超えた場合にアラートを発する仕組みであり、リソースの作成自体を止める力を持ちません。評価間隔も24時間ごとであるため、しきい値を超えてから通知が届くまでにタイムラグが生じます。一方のCompartment Quotasは、リソース作成の可否をポリシー文で即座に制御できる一方、「いくら使っているか」という金額の可視化そのものは行いません。この2つは、片方だけでは「気づくのが遅い」か「金額が見えない」かのいずれかに陥りやすく、組み合わせて初めて実務で使える統制になります。

この表からも分かる通り、Budgetsは「事後に気づいて対処する」ためのソフトリミット、Compartment Quotasは「事前に作成自体を制限する」ためのハードリミットという、補完関係にある2つの仕組みです。§5では、この2つを実際に組み合わせて設定し、どちらか一方だけでは防げないシナリオを具体的に確認します。

本記事は、あくまで「既存リソースを対象としたコスト・ガバナンス統制の構築」に焦点を絞っており、次の範囲についてはあえて深掘りせず、既存記事・今後公開予定の記事に委譲します。

• コンパートメントの作成手順そのもの: 「OCI入門」シリーズVol1を参照してください。本記事では、既に作成済みのコンパートメント群を統制対象として扱います
• IAMポリシー構文の基礎: 「OCI入門」シリーズVol2を参照してください。本記事のquota policyもポリシー文の一種ですが、構文の基礎自体の再説は行いません
• Budgets/Compartment QuotasのTerraformによるIaC化: 「OCI Terraform実践 Vol1」の延長線上にある将来記事候補として扱い、本記事では対象外とします
• メトリクスに基づくAlarm・Notifications基盤: 「OCI可観測性・運用監視実践」シリーズを参照してください。予算アラート(Budgets)とは仕組みが異なる点を§2-2で明記し、委譲します

これらの委譲は、本記事のスコープを「既刊リソース群を対象としたコスト・ガバナンス統制の結線」に絞り込むための判断です。個々の周辺技術の説明に紙幅を割くよりも、Budgets・Compartment Quotas・タグという3つの仕組みを実際に組み合わせたときに初めて見えてくる設計判断(二層統制の役割分担、タグ配賦の粒度設計)に焦点を当てることを優先しています。

1-2. 読者像

本記事は、AWSでCost Explorer・Budgets・Service Quotas・コスト配分タグを使ったコスト管理・ガバナンスの実務経験があり、OCIでの対応実装を知りたいエンジニアを主な読者として想定しています。具体的には、複数のコンパートメントにまたがる検証環境や本番環境を運用していて、想定外の高額リソース作成を未然に防ぎたいインフラ/クラウドエンジニア、あるいはマルチクラウド環境でのコスト統制を横断的に設計する立場のエンジニアなどを想定しています。

いずれのケースでも、「AWSで当たり前にできていたコスト統制が、OCIでも同じようにできるのか」という素朴な疑問が出発点になることが多く、本記事はその疑問に実装レベルで答えることを目指しています。特に、複数のコンパートメントを使い分けるようになった段階で、統制の仕組みを後追いで整備することになりがちですが、本記事はその後追い整備を実際に手を動かして体験できる構成にしています。

特に、次のような疑問を持つ方に向けて、本記事は具体的な答えを用意しています。

• OCI BudgetsはAWS Budgetsと同じ感覚で予算アラートを設定できるのか
• OCIのタグには自由記述タグとdefined tagsの2種類があるが、コスト配賦にはどちらを使うべきか
• Compartment QuotasはAWSのService Quotasやサービスコントロールポリシー(SCP)とどこまで似ているのか
• 純粋なAlways Freeテナンシだけで、この記事の内容を最後まで実践できるのか

AWSでの経験と、本記事を通じて得られる理解の対応関係を整理すると、次のようになります。

本記事が主な対象としない読者像も明確にしておきます。OCIのコンソール操作そのものをこれから学びたい場合は、本記事より先に「OCI入門」シリーズを読むことをお勧めします。また、特定サービス(コンピュート・データベース・ネットワークなど)の構築手順自体を学びたい場合は、各「実践」シリーズの該当記事を先に参照する方が目的に合っています。本記事は、あくまで既に存在するリソース群を対象にした、横断的なコスト・ガバナンス統制の設計と実装に焦点を当てています。

具体的な業務シナリオとしては、たとえば検証用のコンパートメントが複数チームに分かれて増えていき、どのチームがどれだけコストを使っているか請求書の合計金額からは把握できなくなってきた、といった状況が想定されます。あるいは、新しいメンバーが検証環境に加わったタイミングで、意図せず高額なシェイプのインスタンスを作成してしまうリスクを、事前にポリシーで防ぎたいという要望もよくあるパターンです。本記事は、こうした「複数人・複数コンパートメントでの運用が始まってから顕在化する課題」に対して、Budgets・Compartment Quotas・タグの3つを組み合わせた具体的な解決策を提示します。

1-3. なぜ今これを書くか

本記事は、「OCI入門」シリーズ全6巻と、実践系9本の記事を通じて積み上げてきた既刊15記事の実リソース群を、そのまま棚卸しの題材として活用できる位置づけの記事です。他の書き手が新規に環境を用意して本記事を再現しようとしても、同じ規模・同じ構成のコンパートメント群を一から揃える必要があり、この題材の再現性の低さそのものが本記事の差別化要素になっています。

これまでのシリーズは、Tier A(OCI固有サービスの差別化)・Tier B(実践シリーズによる深度追求)・Tier C(開発者向けenablement)という3つの軸で、ロードマップ全10項目を段階的に積み上げてきました。本記事は、その最終回として、個々のサービス軸ではなく「コスト・ガバナンス」という横断軸でこれまでの成果を束ね、シリーズ全体を締めくくる位置づけを担っています。既刊シリーズを整理すると、次のようになります。

これら既刊15記事(入門6巻+実践系9本)は、いずれも個別のサービス軸を深掘りする記事でした。本記事は、この個別軸の積み重ねを前提として初めて成立する、横断軸の記事という位置づけです。

前作「OCI DevOps実践 Vol1」の締めくくりでは、次回として本記事のテーマを予告しており、そのハンズオンを通じて作成したコンパートメント群についても、コスト・ガバナンスの棚卸しの題材として活用する見込みであることに触れていました。本記事は、その予告どおり、DevOps実践までの一連のハンズオンで作成されたコンパートメント群を実際の統制対象として扱い、シリーズ全体を通じて積み上げてきたリソース資産に、最後の統制のレイヤーを重ねる記事です。

→ 前作はこちら: OCI DevOps実践 Vol1 — OCIRとビルド/デプロイパイプラインでアプリCI/CDを構築する

2. 前提・環境・準備

2-1. 前提環境

本記事を進めるにあたって必要な前提は、次のとおりです。

• OCIアカウント(テナンシ)を作成済みであること。Always Freeのみのテナンシ、Pay As You Goへ昇格済みのテナンシのいずれでも、本記事の内容は実践可能です
• コンパートメントを1つ以上作成済みであること。コンパートメントの作成手順自体は「OCI入門」シリーズVol1で解説済みのため、本記事では改めて扱いません
• 予算アラート(Budgets)やquota policyを作成できるだけのIAM権限を持つユーザーでログインできること。ポリシー文の基本構文(Allow … to … in …)は「OCI入門」シリーズVol2で解説済みのため、本記事では固有の構文のみを都度補足します
• OCIコンソールにアクセスできるWebブラウザ。CLIやSDKによる操作は本記事の必須要件ではなく、コンソール操作を中心に進めます

これらの前提を、チェックリストの形で整理すると次の通りです。

これらの前提を満たしていれば、本記事はいずれかの実践系記事を先に読んでいなくても着手できます。ただし、統制対象として複数のコンパートメントが存在している方が、Compartment Quotasやタグベースコスト配賦の効果を実感しやすいため、可能であれば「OCI入門」シリーズや他の実践系記事を一部でも進めた後に本記事へ進むことをお勧めします。

コンパートメント設計の考え方

本記事では、既刊の「OCI入門」シリーズおよび各実践系記事で使用してきたコンパートメント群を、そのまま統制対象として扱います。新たに専用のコンパートメントを作り直すことはせず、既存のコンパートメント階層に対してBudgets・Compartment Quotas・タグを後付けで適用していく構成です。これは、実務でよくある「最初は統制なしで環境を作り始め、規模が大きくなってから統制を後付けする」という状況を、そのままハンズオンとして再現する狙いによるものです。

複数のコンパートメントが既に存在する場合は、そのうち1つを本記事の主対象コンパートメントとして選び、そのコンパートメントおよび配下のコンパートメントに対してポリシーやタグを適用していく進め方を推奨します。コンパートメントが1つしかない場合でも、ルートコンパートメント配下の唯一のコンパートメントを対象にすることで、本記事の内容は同様に実践できます。

quota policy作成に必要なIAM権限

Compartment Quotasのquota policyを作成・編集するには、次のようなポリシーが必要です。

Allow group <管理者グループ名> to manage quota in tenancy

quota policyはテナンシ全体に影響し得るリソースであるため、多くの場合、コンパートメント単位ではなくtenancy単位でmanage権限を付与する運用になります。AWSでService Control Policy(SCP)を組織単位(OU)に対して管理してきた読者にとっては、「強い制御力を持つ設定ほど、限られた管理者グループにのみ権限を絞る」という発想自体は馴染みのあるものです。本記事では、この権限を持つ管理者ユーザーでログインしている前提で、§5のポリシー文作成を進めます。

Budgets・タグ作成に必要なIAM権限

Budgetsとタグ(タグネームスペース・タグキー)についても、それぞれ次のようなポリシーで管理権限を付与できます。

Allow group <管理者グループ名> to manage usage-budgets in tenancy
Allow group <管理者グループ名> to manage tag-namespaces in tenancy

いずれもquota policyと同様、テナンシ全体に関わる操作であるため、tenancy単位での権限付与が一般的です。一方、tag defaultsルールについては、適用先のコンパートメント単位でmanage権限があれば設定できます。

Allow group <管理者グループ名> to manage tag-defaults in compartment <対象コンパートメント名>

この3種類のポリシーの権限範囲(tenancy全体 vs コンパートメント単位)の違いは、AWSでIAMポリシーのリソーススコープをARN単位・アカウント単位で使い分けてきた読者にとって、考え方自体は近いものです。本記事では、これらのポリシーが既に管理者ユーザーに付与されている前提で進めますが、実際にポリシーを新規作成する場合の構文は§5で改めて確認します。

本記事で使用するリソース命名規則

本記事の§3以降で作成するリソースは、次の命名規則に統一します。

2-2. 使用技術スタック

本記事で扱うサービス・機能を整理すると、次のとおりです。

FinOps HubとCost Analysisの関係

Oracleは2024年に、Subscriptions・Cost Analysis・Budgets・Cloud Advisorという4つのコスト管理系機能を1つの画面に集約する「FinOps Hub」を公式にリリースしています。FinOps Hubは、サブスクリプションや費用の可視化、Budgetsの作成・確認、Cloud Advisorによるコスト削減提案の確認までを横断的に行える、コスト管理の中央ダッシュボードという位置づけです。

一方で、従来から存在するCost Analysis単体の画面も引き続き利用可能であり、両者は併存しています。本記事では、コンソールの主要な導線としてFinOps Hub経由での操作を基本としつつ、タグ別のコスト内訳確認など個別のCost Analysis画面のほうが分かりやすい操作については、その旨を明記した上で個別画面のスクリーンショットも交えて解説します。AWSでCost Explorerの画面が数年単位で改修されてきた経験がある読者であれば、この「新旧の画面が一時的に併存する」という状況自体には馴染みがあるはずです。

defined tagsと自由形式タグの違い

OCIのタグには、キーと値を自由に入力できる「自由形式タグ(free-form tags)」と、あらかじめ定義したタグネームスペース配下のキーのみを使える「defined tags」の2種類があります。コスト配賦の観点では、この2つには実務上大きな違いがあります。自由形式タグは、入力者ごとに表記揺れ(たとえばenvとEnvとenvironment)が発生しやすく、集計の切り口として使うには不向きです。一方のdefined tagsは、タグネームスペース単位で許可されたキー・値のみが使えるため、表記揺れが構造的に発生しません。

さらに、Cost Analysisでタグ別のコスト集計に使えるのは、defined tagsのうち「cost-tracking」属性を明示的に有効化したタグキーのみです。cost-tracking属性を有効化できるタグキー定義の数には、テナンシ全体で最大10個までという上限が公式ドキュメントに明記されています。たとえば1つのタグキー(例: cost-center)に対して部門名を値として何十種類割り当てても、それは1個分の上限消費で済みますが、コスト集計の軸として使いたいタグキー自体(部門・環境・プロジェクトなど)を10種類より多く用意できません。この上限を踏まえ、本記事では§4で作成するタグキーを、コスト集計の軸として本当に必要なものに絞り込んで設計します。

AWSのコスト配分タグにも「アクティブ化」という似た概念は存在します。ただし、OCIのcost-tracking属性は「テナンシ全体で10個まで」という明確な数値上限を持つ点が、AWS実務者にとって特に押さえておくべき違いです。

tag defaultsは既存リソースへ遡及適用されない

【落とし穴】tag defaultsルールをコンパートメントに設定すると、そのコンパートメントで「今後新たに作成する」リソースにはタグが自動付与されますが、ルール設定時点で既に存在しているリソースには遡及的に付与されません。この挙動は、公式ドキュメントに次のように明記されています。

The default tag is applied to any new resources created in that compartment. Previously existing resources in the compartment aren’t tagged retroactively.

本記事は、既刊シリーズのハンズオンで作成済みの実リソース群を棚卸しする位置づけの記事であるため、この挙動は重要な意味を持ちます。tag defaultsルールを設定するだけでは、既刊ハンズオンで作成済みの既存リソース(コンピュートインスタンスやVCNなど)にタグは付きません。既存リソースへタグを付けるには、コンソールまたはCLIから対象リソースを個別に選択してタグを手動付与するか、複数リソースをまとめて選択して一括付与する操作が別途必要です。この2段構え(§4で扱うtag defaultsによる今後の自動付与 + §6-2で実演する既存リソースへの一括付与)で、既刊ハンズオンのリソース群にタグを行き渡らせます。

AWSでコスト配分タグを既存リソースへ後から付与した経験がある読者であれば、「タグルールを作っただけでは、過去に作ったリソースには反映されない」という感覚自体はすぐに理解できるはずです。OCIのtag defaultsも、この点においてAWSのタグ運用と同じ制約を持っています。

quota policyとタグネームスペースのリージョン制約の非対称性

Compartment Quotasのquota policyは、ホームリージョン以外で作成・編集しようとすると、Oracleの公式ドキュメント上でホームリージョンへの切り替えを促すエラーが返る、ホームリージョン限定の操作です。これは、quota policyがテナンシ全体に影響するIAM関連リソースと同様の扱いを受けているためです。

一方、タグ(タグネームスペース・タグキーの定義)については、公式ドキュメントに「Tagging is currently available in all regions(タグ付けは現在すべてのリージョンで利用可能です)」と明記されており、ホームリージョン限定という制約はありません。同じ「テナンシ全体に関わるガバナンス系リソース」であっても、quota policyとタグでリージョン制約の扱いが異なるという非対称性は、実機で操作する際に混乱しやすいポイントです。本記事では、§5でquota policyを作成する際に、必ずホームリージョン(東京)へ切り替えた状態で操作することを明記します。

いずれのサービスも、公式ドキュメント上に個別の価格・SKUの記載が見当たらず、機能自体への直接課金は発生しないという判定が可能です。ただし、これは「無料である」という積極的な記載を確認した結果ではなく、価格表・Always Free/Free Tierドキュメントのいずれにも該当する課金項目が存在しないことを確認した、消去法に基づく現時点の判定です。実際の請求額は、統制対象となる既存リソース(コンピュート・ストレージなど)側の実費のみで決まり、本記事で新たに追加する統制機能そのものが請求に別枠で計上されることはありません。この判定の根拠は§2-4で改めて詳しく整理します。

なお、TerraformによるBudgets/Compartment QuotasのIaC化は本記事の範囲外です。「OCI Terraform実践 Vol1」でコンパートメント・VCN・A1インスタンスのコード化を扱っていますが、コスト・ガバナンス系リソースのコード化は将来記事の候補として切り分けています。また、メトリクスに基づくAlarm・Notifications基盤は「OCI可観測性・運用監視実践」シリーズが扱う領域であり、Budgetsの予算アラートとは評価対象(コスト実績・予測 vs. メトリクス値)が異なる別系統の仕組みである点を、本記事ではその違いの明記にとどめて委譲します。

2-3. ゴール状態の定義

本記事における「動いている状態」の定義は、次のとおりです。

• 既刊ハンズオンで使用してきたコンパートメントの少なくとも1つに、cost-tracking属性を有効化したdefined tagのtag defaultsルールが設定され、そのコンパートメント配下で新たに作成するリソースへタグが自動付与される状態になっている(tag defaultsは既存リソースへ遡及適用されないため、既刊ハンズオンで作成済みの既存リソースについては、別途タグの手動付与または一括付与で個別に対応する対象として扱います)
• Cost Analysisで、付与したタグを切り口にコストが集計・表示できる状態になっている(実費が発生していない場合も、集計軸として機能することを確認します)
• 対象コンパートメントに対してBudgetsのしきい値アラートが設定され、実績または予測支出に基づく評価が行われる状態になっている
• 対象コンパートメントに対してCompartment Quotasのポリシー文が適用され、意図したリソース作成の制御(許可・ゼロ化・上限設定のいずれか)が機能している

この状態を、それぞれ次の観点から確認できることをもって「動作している」と判定します。

この4点が揃った状態を、本記事のゴールとします。§3ではAWS↔OCIの対応マップを詳細に確認し、§4でタグベースコスト配賦、§5でBudgets×Compartment Quotasの二層統制を順に構築していきます。

2-4. 課金の見える化 — 無料性の判定方法

判定方法論

本記事が扱う4つの機能(Budgets・Cost Analysis・Compartment Quotas・タグ)について、「機能自体には直接課金が発生しない」と判定するにあたり、本記事では次の2種類の一次情報を確認しています。

1. Oracleの公式価格表・価格リストに、該当する機能名・SKUが掲載されているかどうか
2. 各機能の公式ドキュメント(Overview/Concepts系ページ)本文に、価格・課金に関する記載があるかどうか

いずれの確認においても、該当する価格・SKU・課金の記載は見当たりませんでした。これは、AWSでService Quotasやコスト配分タグ、AWS Budgetsが無料で提供されているのと同様の位置づけとして理解できます。ただし、Oracleは価格表に「明記していないサービスは常に無料」であることを保証する文言を掲げているわけではないため、本記事の判定はあくまで「確認できた範囲での消去法による判定」であることを明記しておきます。実際に本記事の内容を実践する際は、コンソールの「請求書とコスト管理」で直近の課金明細に想定外の項目が発生していないか、都度確認することをお勧めします。

確認結果を機能ごとに整理すると、次のとおりです(いずれも2026年8月時点の公式ドキュメント確認)。

いずれの機能も、統制の「対象」となるリソース(コンピュートインスタンス・ストレージ・データベースなど)自体の課金とは独立しており、統制機能を追加したことを理由に請求額が増えることはありません。この点は、既刊ハンズオンがAlways Free枠を中心に構築してきた読者にとっても、安心して本記事の内容を実践できる材料になります。

確認した公式ドキュメントの記載

Budgetsのアラート評価タイミングについては、公式ドキュメントに次の記載があります。

All budget alerts are evaluated periodically every 24 hours.

この記載の通り、Budgetsのアラートは24時間ごとの定期評価です。実機ハンズオンでアラートの発火を確認したい場合、しきい値超過の設定直後にすぐ通知が届くわけではなく、評価タイミングを待つ必要がある点に注意してください。

Compartment Quotasのquota policyについては、ホームリージョン以外で操作しようとした際に、次のような趣旨のエラーメッセージが返ってくると公式に案内されています。

Please go to your home region to execute Quota operations.

タグについては、公式のTagging Overviewドキュメントに次の記載があります。

Tagging is currently available in all regions.

この2つの記載を突き合わせると、同じ「テナンシ全体に関わるガバナンス系リソース」でありながら、quota policyはホームリージョン限定、タグはすべてのリージョンで作成可能という非対称な制約になっていることが、公式ドキュメントの記載から確認できます。

前提環境の整理はここまでです。コンパートメント設計・IAM権限・命名規則・技術スタック・無料性の判定方法という観点を押さえたことで、§3以降で実際に統制を組み立てていく準備が整いました。

改めて本章の要点を振り返ると、本記事はAlways Free環境・PAYG環境のいずれでも着手できる点、既存のコンパートメント階層をそのまま統制対象にできる点、そしてBudgets・Cost Analysis・Compartment Quotas・タグのいずれも機能自体への直接課金は発生しない点が、前提環境としての大きな特徴です。一方で、tag defaultsは既存リソースへ遡及適用されない点、そしてquota policyの作成がホームリージョン限定である点は、実機で手を動かす際につまずきやすいポイントとして、あらかじめ押さえておく価値があります。

次の§3では、AWS↔OCIのコスト管理・ガバナンスサービス対応マップを、コンソール操作レベルの具体例とあわせて詳しく確認します。

3. AWS↔OCI コスト管理・ガバナンス対応マップ — 5項目の実装レベル対応(差別化軸①)

§1では、AWS実務者向けの対応関係を概要レベルで整理しました。本章では、その対応関係をコンソール操作・IAMポリシーの構文レベルまで踏み込んで確認します。対応表としてまとめると、次のとおりです。

AWS Budgets ↔ OCI Budgets

両者とも、実績支出(ACTUAL)または予測支出(FORECAST)がしきい値を超えた場合にアラートを発するという役割はほぼ同一です。実装面での違いは主に2つあります。1つは通知の仕組みで、AWS Budgetsのアラートは多くの場合Amazon SNSトピック経由で配信されるのに対し、OCI Budgetsのアラートルールはメールアドレスへ直接配信され、OCI Notificationsのトピックを経由しません(詳細は§5-2)。もう1つはポリシーのスコープで、OCI Budgetsはどのコンパートメントを対象にする場合でも、予算自体は必ずルート・コンパートメント(テナンシ)に作成され、IAMポリシーもテナンシスコープで付与する必要があります(Allow group <グループ名> to manage usage-budgets in tenancy)。対象コンパートメントを絞り込んでいるつもりでも、ポリシーの付与先を誤ってコンパートメント単位にしてしまうと権限エラーになる点は、AWS BudgetsのIAMポリシー設計との違いとして押さえておくべきポイントです。

AWS Cost Explorer ↔ OCI Cost Analysis(+FinOps Hub)

Cost Explorerが担う「コストの可視化・グラフ化・グルーピング」という役割は、OCIではCost Analysisが担います。2024年6月に、Cost Analysis・Budgets・Subscriptions・Cloud Advisorの4つの機能を1画面に集約するFinOps Hubが追加され、Billing and Cost Managementの起点画面として使われるようになりました。Cost Analysis自体は、FinOps Hubの登場以前から存在する個別画面としても、FinOps Hub経由でも、いずれのルートからも引き続きアクセスできます。なお、Cost Analysisにはこれとは別に、SKU(Part Number)単位の内訳を確認できた旧版の「Classic Version」と呼ばれる画面が存在していましたが、これは現行のCost Analysisに統合済みで、現在は現行画面上で「SKU (Part Number)」というグルーピング軸を選択することで、旧Classic Versionと同等の内訳を再現できます。古い技術記事やフォーラムの投稿でClassic Version時代のスクリーンショットを見かけても、現行のCost Analysis画面で同等の分析が可能な点を押さえておいてください。タグ別・コンパートメント別のグルーピング実演は、§4-4で実際に行います。

AWS Service Quotas + SCP ↔ OCI Compartment Quotas

AWSでは、アカウント/リージョン単位のサービス上限緩和をService Quotasが、AWS Organizations配下でのアクション制限をSCP(Service Control Policies)がそれぞれ別サービスとして担います。OCIでは、この2つの役割が「特定のコンパートメントで、特定のリソースを、いくつまで(あるいはゼロ、あるいは無制限に)作成できるか」を1本のポリシー文で表現するCompartment Quotasに統合されています。IAMポリシーの構文に近い宣言的な文法(set・zero・unsetの3種類のキーワード)を使う点も、SCPのJSON構文とは異なるOCI独自の実装です。詳細な文法と実践は§5で扱います。

AWSのコスト配分タグ ↔ OCIのdefined tags(cost-tracking属性)

AWSでは、タグをコスト配分の対象とするため、Billingコンソールでコスト配分タグとして個別に有効化(アクティベート)する操作が必要です。OCIでは、これと同じ役割を、defined tagのタグキー定義側でis-cost-tracking属性をtrueに設定することで実現します。あるタグキーをcost-trackingとして有効化すると、そのタグはCost Analysisのグルーピング軸として選択できるようになります。ただし、この属性を有効化できるタグキー定義は、テナンシ全体で最大10個までという上限がある点は、AWSのコスト配分タグにはない実装上の制約です(詳細は§4-2)。

AWSのTag Policies ↔ OCIのtag namespaces + tag defaults

AWS OrganizationsのTag Policiesは、タグキー・タグ値の命名規則をアカウント横断で強制する仕組みです。OCIには同名の機能はありませんが、近い役割を、タグの入れ物であるtag namespace(命名規則の一元管理)と、コンパートメント単位でタグを自動付与するtag defaults(付与の強制)の組み合わせが担います。AWSのTag Policiesが「間違ったタグ値を拒否する」という強制力を持つのに対し、OCIのtag defaultsは「新規作成されるリソースに既定値を自動的に付与する」という、強制というよりは省力化に近い性質を持つ点が構造的な違いです。この違いは§4-3で、tag defaultsが既存リソースには遡って適用されないという実装上の制約とあわせて確認します。

これらの対応関係を踏まえたうえで、次の§4では、defined tag namespaceの作成からCost Analysisでのタグ別配賦確認までを、実際に一続きの操作として実践します。

4. タグベースコスト配賦の実践 — namespace作成からCost Analysis確認までの一気通貫(差別化軸②)

本章では、§3で整理した「defined tags(cost-tracking属性)」「tag namespaces + tag defaults」の2つの対応関係を、実際に手を動かして結線します。単にタグを1つ作って終わりにするのではなく、タグネームスペースの作成→cost-tracking属性の有効化→tag defaultsによるコンパートメントへの自動付与→Cost Analysisでのタグ別配賦確認という一連の流れを、閉環させることを目的としています。

4-1. タグネームスペースの作成

タグネームスペースは、タグキーの入れ物です。コンソールでは、Governance & Administration > Tenancy Management > Tag Namespacesを開き、「Create Tag Namespace」から作成します。タグネームスペースはテナンシ全体で一意な名前を持つ必要があり、§2-1で述べたコンパートメント作成手順とは異なり、ホームリージョン以外でも作成できます(この点はCompartment Quotasのquota policyがホームリージョン限定である§5-1の制約と対照的です)。

CLIで同等の操作をする場合は、次のコマンドを使います。

oci iam tag-namespace create \
  --compartment-id <テナンシOCID> \
  --name oci-cost-governance-vol1-ns \
  --description "OCIコスト管理・ガバナンス実践Vol1で使用するタグネームスペース"

タグネームスペースの--compartment-idには、テナンシ(ルート・コンパートメント)のOCIDを指定します。タグネームスペース自体はテナンシ全体に対して定義されるガバナンス上の器であり、特定の子コンパートメントに閉じたものではないためです。

4-2. cost-tracking属性を持つタグキーの定義

作成したタグネームスペースの配下に、コスト配賦の切り口となるタグキーを定義します。ここでは、コンパートメント横断でコストの帰属先を表すCostCenterというタグキーを、cost-tracking属性を有効にして作成します。

oci iam tag create \
  --tag-namespace-id <タグネームスペースOCID> \
  --name CostCenter \
  --description "コスト配賦の帰属先を表すタグ。Cost Analysisのグルーピング軸として使用" \
  --is-cost-tracking true

コンソールでは、対象のタグネームスペースの詳細画面から「Create Tag Key Definition」を選び、Cost tracking欄のチェックボックスを有効にすることで、同じ設定を行えます。§3-4で述べた通り、このis-cost-tracking属性を有効にできるタグキー定義は、テナンシ全体で同時に最大10個までという上限があります。複数のタグキーで横断的なコスト配賦を設計する場合は、この上限を意識して、本当にコスト分析の軸として必要なタグキーだけを厳選する必要があります。

4-3. tag defaultsによるコンパートメントへの自動付与

タグキーを定義しただけでは、既存・新規いずれのリソースにもタグは付与されません。tag defaultsは、指定したコンパートメント配下で新規作成されるリソースに対して、既定のタグ値を自動的に付与するルールです。

oci iam tag-default create \
  --compartment-id <対象コンパートメントOCID> \
  --tag-definition-id <CostCenterタグ定義OCID> \
  --value "oci-roadmap-handson"

コンソールでは、対象コンパートメントの詳細画面から「Tag Defaults」タブを開き、「Add Tag Default」から同様の設定ができます。ここで重要な制約は、tag defaultsが適用されるのは、このルールを設定した後に新規作成されるリソースだけだという点です。ルール設定より前から存在していたリソースには、タグは遡って付与されません。値を後から変更したり、ルール自体を削除したりしても、既に付与済みのタグの値は変化しません。

この制約は、本記事の§6で扱う「既刊15記事のハンズオンリソース群の棚卸し」にそのまま影響します。既刊記事で作成したリソースは、いずれも本記事でtag defaultsを設定するより前に作られているため、tag defaultsだけでは棚卸しの対象にタグが付きません。この場合の実務的な解決策は、oci iam tag bulk-editコマンド(またはコンソールのTenancy Explorerから対象リソースを選択して「Manage Tags」を実行する操作)を使い、既存リソースへタグを事後的に一括付与することです。この一括付与の実演は§6-2で行います。

4-4. Cost Analysisでのタグ別配賦確認

タグが付与されたリソースについて、実際にCost Analysisでタグ別の内訳を確認します。コンソールでBilling & Cost Management > Cost Managementを開き、FinOps Hub経由、または個別のCost Analysis画面のいずれからでもアクセスできます。「Group by」の選択肢で「Tags」を選び、§4-1・§4-2で作成したタグネームスペース(oci-cost-governance-vol1-ns)とタグキー(CostCenter)を指定すると、そのタグの値ごとに集計されたコストがグラフとして表示されます。

実費の発生していないAlways Freeリソースのみを対象にしている場合でも、集計軸としてタグが機能していることは、$0の内訳グラフとして確認できます。有償リソースを含む環境で試す場合は、タグ付与からCost Analysisへの反映まで、最大24時間程度のタイムラグが生じ得る点に留意してください。

タグによるコスト配賦の切り口が整ったところで、次の§5では、Budgets(ソフトリミット)とCompartment Quotas(ハードリミット)という、性質の異なる2つの統制を組み合わせる実践に進みます。

5. Budgets × Compartment Quotas による二層統制の実践(差別化軸③)

§1-1の表で整理した通り、Budgetsは「事後に気づいて対処する」ためのソフトリミット、Compartment Quotasは「事前に作成自体を制限する」ためのハードリミットです。本章では、この2つを実際に設定し、それぞれの評価タイミングと制御範囲の違いを手を動かして確認します。

5-1. Compartment Quotasのポリシー文作成

Compartment Quotasのポリシー文は、set(上限を設定)・zero(アクセスをゼロにする)・unset(既定のサービス上限に戻す)の3つのキーワードで構成される、宣言的な文法です。

set compute-core quota standard-a1-core-count to 4 in compartment <対象コンパートメント名>
zero database quotas in compartment <対象コンパートメント名>

1行目は、対象コンパートメントで作成できるA1シェイプのコア数を4コアまでに制限する例、2行目は、同コンパートメントでのDatabase関連リソースの作成を一切禁止する例です。ポリシー文を手書きする代わりに、コンソールのGovernance & Administration > Tenancy Management > Limits, Quotas and Usageページから、対象サービス・スコープ・リソースを選択し、Actionsメニューの「Create Quota Policy Stub」を実行すると、選択した内容に対応するポリシー文のひな形が自動生成されます。手書きでの文法ミスを避けたい場合は、このスタブ生成機能を使うことをお勧めします。

Compartment Quotasの作成・編集は、テナンシのホームリージョンでのみ実行できます。ホームリージョン以外で操作しようとすると、エラーメッセージが表示されて作成・編集ができません。§4-1で確認したタグネームスペースの作成がリージョンを問わずに行えるのとは対照的な制約であり、複数リージョンで作業する際に混同しやすいポイントです。

IAMポリシー側では、Quotasサービスのリソースタイプはquota(単数形)で、次のようなポリシー文で操作権限を付与します。

Allow group <グループ名> to manage quota in tenancy

5-2. Budgetsのしきい値アラート作成

続いて、Budgetsを作成します。CLIでは、対象タイプ(コンパートメント単位かタグ単位か)を--target-typeで指定します。

oci budgets budget create \
  --compartment-id <テナンシOCID> \
  --target-type COMPARTMENT \
  --targets '["<対象コンパートメントOCID>"]' \
  --amount 50 \
  --reset-period MONTHLY \
  --display-name oci-cost-governance-vol1-budget \
  --description "対象コンパートメントの月次支出しきい値アラート"

§3-1で述べた通り、--compartment-idには対象コンパートメントではなく、テナンシ(ルート・コンパートメント)のOCIDを指定する点に注意してください。Budgetsは、どのコンパートメントを対象にする場合でも、リソース自体はテナンシ直下に作成される仕様です。

--target-typeにはTAGも指定でき、その場合--targetsには"タグネームスペース.タグキー.タグ値"という形式の文字列を渡します。§4で作成したタグを使うなら、oci-cost-governance-vol1-ns.CostCenter.oci-roadmap-handsonのような値になります。コンパートメント単位ではなく、複数コンパートメントにまたがる特定のプロジェクト単位で予算を管理したい場合は、こちらのTAGターゲットが有効です。

Budgetを作成したら、アラートルールを追加します。

oci budgets alert-rule create \
  --budget-id <BudgetのOCID> \
  --type FORECAST \
  --threshold 100 \
  --threshold-type PERCENTAGE \
  --recipients "<通知先メールアドレス>"

--typeには、実績支出を対象にするACTUALと、予測支出を対象にするFORECASTのいずれかを指定します。§3-1で述べた通り、Budgetsのアラートはメールアドレスへ直接配信され、OCI Notificationsのトピック作成やサブスクリプション登録は不要です。この点は、「OCI可観測性・運用監視実践」シリーズで扱ったMonitoringのAlarmが、Notificationsトピックを経由して通知する仕組みだったのとは異なります。同じ「アラート」という言葉でも、Budgetsの予算アラートとMonitoringのメトリクスAlarmとでは、評価対象(支出額 vs. メトリクス値)も通知経路(メール直接配信 vs. Notificationsトピック経由)も別系統の仕組みである点を、ここで改めて整理しておきます。

Budgetsのアラートは、24時間ごとの定期評価で判定されます。しきい値を超えても通知が即座に届くわけではなく、最大で丸1日近いタイムラグが生じ得るという評価間隔の性質は、動作確認のタイミングを設計する際に見落としやすい落とし穴です。即時性を求める監視には、Compartment Quotasによるハードリミット、またはMonitoringのメトリクスベースAlarmを組み合わせる必要があります。

5-3. 二層統制としての組み合わせ設計

§5-1のCompartment Quotasと§5-2のBudgetsを組み合わせると、次のような役割分担になります。

Compartment Quotasだけでは、許可した範囲内でリソースを積み上げ続けた場合の累積支出には気づけません。Budgetsだけでは、しきい値を超えるリソースが作成されてから通知が届くまでに最大24時間近い空白が生じます。この2つを組み合わせることで、「作成そのものを制限する層」と「累積支出を継続的に監視する層」の両方を、既刊ハンズオンで作成した既存のコンパートメント群に対して重ねて適用できます。

Budgets×Compartment Quotasの二層統制と、§4のタグベースコスト配賦が揃ったところで、次の§6では、これらの統制を既刊ロードマップ全10項目・15記事のハンズオンリソース群に実際に適用し、シリーズ全体を棚卸しします。

6. ロードマップ全10項目の棚卸しとまとめ(差別化軸④)

本章では、§4のタグベースコスト配賦と§5のBudgets×Compartment Quotasによる二層統制を、既刊「OCI入門」シリーズ全6巻および実践系9記事、計15記事のハンズオンリソース群に実際に適用し、OCIロードマップ全10項目を横断的に棚卸しします。

6-1. ロードマップ全10項目の振り返り

これまでのロードマップは、Tier A(OCI固有サービスの差別化)・Tier B(実践シリーズによる深度追求)・Tier C(開発者向けenablement)という3つの軸で積み上げてきました。

「OCI入門」シリーズVol1〜Vol6は、概念と操作手順そのものの解説に重点を置いた構成であるため、固有の命名規則を持つ個別リソースを作り込む記事ではありません。一方、項目1〜9の実践系記事はいずれも、既刊シリーズ共通の命名規則(<シリーズ名>-vol1-<リソース種別>)に従ったリソース群を作成しており、これらが本章の棚卸しの主対象です。

6-2. 既存リソースへのタグ一括付与とCost Analysisでの横断棚卸し

§4-3で述べた通り、tag defaultsは新規作成リソースにのみ適用され、項目1〜9で既に作成済みのリソースには遡って適用されません。既存リソースを棚卸しの対象に含めるには、oci iam tag bulk-editコマンドで、対象コンパートメント配下の既存リソースへCostCenterタグを事後的に一括付与します。

oci iam tag bulk-edit \
  --compartment-id <対象コンパートメントOCID> \
  --resources file://resources.json \
  --bulk-edit-operations file://bulk-edit-operations.json

resources.jsonには、棚卸し対象とするリソースのOCIDとリソース種別を配列で列挙し、bulk-edit-operations.jsonには、§4-2で定義したCostCenterタグへoci-roadmap-handsonという値を設定する操作を記述します。コンソールで同様に操作する場合は、Tenancy Explorerで対象コンパートメントを選択し、表示されたリソース一覧から棚卸し対象を選んで「Manage Tags」を実行します。

一括付与が完了すると、§4-4で確認したCost Analysisのタグ別グルーピング画面に、項目1〜9のハンズオンリソース群がCostCenter = oci-roadmap-handsonという単一の切り口で横断的に表示されるようになります。個々のリソースがどのサービス(Autonomous Database・Functions・DevOpsパイプラインなど)に属しているかは、Cost Analysisの「Group by」をServiceに切り替えることで別軸から確認でき、CostCenterタグとServiceという2つの軸を組み合わせることで、「ロードマップ全体でどれだけのリソースを積み上げてきたか」と「そのうちどのサービスの占める割合が大きいか」の両方を、1つの画面から把握できます。

Always Freeテナンシのみで進めてきた場合、この棚卸しの結果は主に「リソース数・種別の可視化」という意味を持ちます。Pay As You Goへ昇格済みのテナンシで実践してきた場合は、これに加えて実費ベースでの内訳確認まで踏み込んだ、実務に即した棚卸しとなります。

6-3. シリーズのまとめ — OCIロードマップ全10項目完結

本記事では、Budgets・Cost Analysis(+FinOps Hub)・Compartment Quotas・defined tagsという4つの仕組みを結線し、§4でタグベースコスト配賦、§5でBudgets×Compartment Quotasの二層統制、§6でロードマップ全体の横断棚卸しを、それぞれ実際に構築しました。個々のサービスの深掘りを積み重ねてきたTier A・B・Cの各記事に対し、本記事は「コスト・ガバナンス」という横断軸を最後に重ねることで、既刊15記事のハンズオンリソース群を、単なる学習の積み重ねではなく、実際に統制・可視化された資産として扱える状態にしました。

これをもって、「AWS記事は出し尽くした。しばらくOCI中心に進める」という方針のもとで着手したOCIロードマップ全10項目(Tier A: Autonomous Database・MySQL HeatWave・Generative AI/Tier B: ネットワーク・Functions & API Gateway・可観測性・セキュリティ/Tier C: Terraform・DevOps・コスト管理ガバナンス)が、「OCI入門」シリーズ全6巻の基盤の上に完結しました。他の書き手が同じ規模のコンパートメント群を一から再現することが難しいという、本記事冒頭で述べた再現性の低さそのものが、このシリーズ全体を通じて積み上げてきた資産の価値でもあります。