Making a tenancy-wide cost ceiling stick across five subsidiaries
A holding company runs one OCI tenancy with five subsidiaries. Monthly spend is USD 180,000 and growing 20% per quarter. Compartments exist per subsidiary, but developers routinely create resources in the wrong one, and only about 60% of resources carry the cost-center tag. Finance wants a hard ceiling at USD 250,000 with 30 days notice, and wants per-subsidiary showback that auditors will accept. Last month a team left 30 GPU bare-metal instances running over a weekend, discovered only when the invoice arrived.
1. Finance asks for a budget that stops spending at USD 250,000. Explain what OCI actually provides and what you would build to deliver the intent.
Read the worked answer
Budgets do not stop anything. An OCI budget is a monitoring construct: you set the amount and alert rules (percentage of actual spend and percentage of forecast spend) that publish to a Notifications topic. It cannot terminate or block resources, and telling Finance otherwise sets up a failure.
Build three layers.
- Early warning - budgets with forecast alerts. A tenancy-level budget at 250,000 with alerts at 50/75/90/100% of both actual and forecast, delivered to a topic routed to the finance and platform teams. Forecast alerts are the ones that fire early enough to act on; actual-spend alerts fire after the money is gone.
- The actual ceiling - compartment quotas. Quotas are enforced by the tenancy and are the only hard limit available. Set per-subsidiary quotas on the expensive dimensions (compute cores, GPU count, block volume storage, load balancers) so a single subsidiary cannot consume the group's headroom. Apply them at the subsidiary compartment so the whole subtree inherits the limit.
- Detection - Cloud Guard and Events. A Cloud Guard detector for anomalous spend or resources created outside policy, plus Events rules on resource creation in wrong compartments, gives you the weekend-GPU signal.
Design judgement: quotas sized to each subsidiary's real need are the ceiling; the group budget is the early warning that something is structurally wrong. Setting quotas at the group level only means one subsidiary can still starve the others.
2. How do you get cost-center tagging from 60% to near-complete, and make the showback audit-defensible? Address both the technical and the human failure.
Read the worked answer
The 60% is a process problem, but it needs a technical backstop.
Technical.
- Use defined tags, not freeform. Defined tags have a namespace, a controlled value list and a validator, so
CostCenteris always spelled the same way. Freeform tags will never be audit-defensible. - Create tag defaults at each subsidiary compartment so resources created there inherit the cost-center value automatically. Most of the 60% comes from resources created without the tag, not from people refusing to tag.
- Mark the tag as a cost-tracking tag so Cost Analysis can group by it - a tag that is not enabled for cost tracking will not appear in reports.
- Add a Cloud Guard detector for resources missing the defined tag so drift is visible weekly rather than at audit time.
Identity. Use tag-based access control in policies: allow each subsidiary's group to manage resources in its own compartment only, with conditions on the compartment and tag values. When the tag is also part of the permission model, untagged or mis-tagged resources become an operational problem someone owns, not a reporting nuisance.
Human. Publish a monthly per-subsidiary showback built from cost-tracking tags, and reconcile the untagged residual as an explicit line item charged to the subsidiary that owns the compartment. Once untagged spend has a visible owner, the 40% closes quickly.
Also fix the weekend case: apply a quota cap on GPU instances per subsidiary and use start/stop schedules for non-production compute so idle fleets are not left running. Quotas stop the runaway; schedules stop the steady leak.