Commitment Spend, Showback and Whether to Buy Premier Support
Corvus Media signed a one-year Universal Credits commitment of USD 240,000 for OCI. Actual consumption has ranged from USD 12,000 to USD 31,000 a month, driven partly by an untagged GPU proof of concept in a sandbox compartment that a data-science team keeps recreating after the platform team shuts it down. Finance wants month-end showback by department, an early warning before the commitment is exhausted, and a hard ceiling on the sandbox. The platform team is on Basic Support and has had two Severity 1 incidents this quarter, each taking more than six hours to reach an engineer; the CTO is asking whether Premier Support is worth the uplift.
1. Finance wants an early warning and a hard ceiling on the sandbox. What controls achieve each, and what are their limits?
Read the worked answer
- Budgets alert; they do not enforce. Scope a budget to the sandbox compartment (and a second budget to the tenancy for the commitment) and add alert rules on both actual and forecast spend, delivered by email or to an ONS topic. Set a forecast rule at 80% of run-rate plus an actual rule at 100%, and for the commitment alert on the projected exhaustion date, not just on this month's spend.
- A hard ceiling requires quota policy. For example
set compute-core quota ... to N in compartment sandbox, plus a quota for the GPU shape family and an instance-count limit. Quota is evaluated at resource creation, so the data-science team's recreation attempt fails once the limit is reached. - Quota alone does not stop waste if the group can still consume everything the quota allows. Reduce the data-science group's policy so it can only use approved shapes in sandbox, or require the platform team to provision on request.
- Know the commitment mechanics you are alerting against: consumption draws down Universal Credits, usage beyond the commitment is billed at on-demand rates, and unused credits do not roll past the end of the term. The metric that matters is the projected exhaustion date against the term end.
2. How would you implement departmental showback so the numbers are defensible?
Read the worked answer
- Choose defined tags over freeform for anything finance depends on. Defined tags live in a tag namespace with a controlled value set and can be enforced with tag defaults at compartment level, so new resources inherit the department tag even when the creator forgets. Freeform tags are unenforceable and drift within weeks.
- Enable cost-tracking for the tag key used in reporting. Only cost-tracking tags are available as a group-by dimension in Cost Analysis and the Cost and Usage Report, and there is a lag before data backfills - plan for it.
- Build showback from Cost Analysis grouped by the department tag, and reconcile monthly against a Cost and Usage Report extract feeding the finance system, so the report is auditable rather than a screenshot.
- Expect an "untagged" residual. Drive it down with tag defaults and by making the tag mandatory in provisioning, not by chasing individuals after month end.
- State the backfill limitation explicitly: spend incurred before cost-tracking was enabled cannot be re-attributed by tag, so the first report will be partly allocated by estimate.
- Attribute the GPU sandbox spend to the data-science department, not to platform. Otherwise the team with the ability to control it has no financial incentive to.
3. The CTO asks whether Premier Support is worth the uplift over Basic. How do you frame the decision?
Read the worked answer
- First establish what Basic actually provides: documentation, community forums and console access - no 24/7 access to support engineers and no contractual response-time commitments for service requests. Two Severity 1 incidents that took over six hours to reach an engineer is the expected outcome of running production without a support contract.
- Premier adds 24/7 access and contractual target response times for the highest severity, measured in minutes rather than hours, plus named contacts and escalation paths. Verify the current published targets and, critically, the severity definitions in the Oracle support policy before quoting anything to the CTO - if the incident does not meet the Severity 1 definition, the fast response does not apply.
- Decide on numbers: estimate the cost of one hour of claims/delivery downtime, multiply by the ~48 hours a year of engineer latency observed, and compare that with the support uplift (support fees scale with annual spend, so get the quote first). If the annualised downtime cost exceeds the uplift, the decision is made.
- Close the loop on the real problem: six hours of latency is also a detection and escalation gap. Buy the tier and fix monitoring, alerting and runbooks in parallel - a faster answer to an incident you noticed late is still a slow recovery.