sql
Template
commitment-inventory.sql
Commitment Inventory Schema
BigQuery schema for the commitment inventory table, with one row per tranche and daily utilisation snapshots.
Download ↓IFO4
Loading...The Problem
Reservations and savings plans are purchased once a year, on a calendar reminder, by whoever has the access at the time. Coverage drifts, utilisation drops, and convertible options remain unused even when the underlying workload changes. The institution either over-commits and stranded discounts compound, or under-commits and the on-demand premium compounds. Either way, the position is not a portfolio. It is an afterthought.
The Detection
If the institution cannot, at any moment, name the current coverage percentage by service family, the current utilisation per reservation tranche, and the named owner per tranche, the practice is below Best.
Practice Spectrum
Anomalies are detected in the next billing cycle, by the CFO, in a meeting. The blast radius is one month plus the time it took to read the email.
A daily threshold alert exists. Most fire. Most are ignored. Triage discipline is informal and inconsistent.
Anomalies are detected within twenty-four hours, classified by domain, and routed to a named owner. False-positive rate is under twenty percent.
Anomalies are detected within an hour, suppressed for known-good patterns, and resolved with a documented post-incident note. Mean-time-to-detect is under sixty minutes.
Anomalies are predicted, prevented, or auto-mitigated. Mean-time-to-resolve approaches zero for the top decile of patterns. The institution learns each event into policy.
The Outcome
A documented commitment policy with target coverage bands per service family. Weekly review of coverage, utilisation, and pricing signals. Above ninety-five percent utilisation across the active portfolio. Convertible RIs converted on price signals, not on calendar dates. The portfolio behaves like an institutional position.
Cost delta
-14 to -22 percent on covered service families within two quarters
Efficiency
+22 efficiency points (Score V2)
Value lift
+6 value points (Score V2)
Risk reduction
-9 risk points (Score V2)
Ship It
Step 01
List every active reservation, savings plan, and committed-use discount across every cloud account. Capture: tranche identifier, service family, term, payment posture, monthly amortised cost, current utilisation, and named owner. Treat any tranche without an owner as a finding.
gcloud compute commitments list \
--filter "status=ACTIVE" \
--format="csv(name,plan,resources[0].amount,statusMessage,creationTimestamp,endTimestamp)"Step 02
For the trailing ninety days, decompose on-demand and reserved consumption by service family (compute, memory, GPU, storage, database, network). Output is a ranked list showing where the institution has high steady-state demand and zero coverage.
Step 03
Document target coverage bands per service family. For example: compute at sixty to seventy percent coverage, GPU at thirty to fifty percent, database at seventy to eighty. Each band has a named owner, a documented rationale, and a refresh cadence.
Step 04
Each week, review coverage versus the band, utilisation versus a ninety-percent floor, and any drift versus the prior week. Outputs are a documented action set: extend, convert, sell-back where supported, or let expire.
Step 05
For convertible reservations, build a price-signal monitor that fires when the convertible target instance family becomes materially cheaper than the current binding. Conversions follow a documented runbook with named approver.
Step 06
Attach UFMS tags to every reservation tranche: owner, cost-center, target service family, target workload. The tagging makes the portfolio queryable from the same ledger as every other capital decision.
Step 07
At the start of each quarter, model expected demand for the next four quarters. Identify tranches expiring within ninety days and stage refresh decisions in advance of expiry. The aim is that no tranche ever expires without a documented decision.
Step 08
At quarter close, publish a one-page portfolio attestation: coverage by family, utilisation by tranche, decisions taken, and the dollar impact. Sign and store in the controls evidence repository.
The Templates
sql
Template
commitment-inventory.sql
BigQuery schema for the commitment inventory table, with one row per tranche and daily utilisation snapshots.
Download ↓md
Template
commitment-policy.md
Markdown template for the institutional commitment policy: coverage bands, named owners, refresh cadences, exception path.
Download ↓csv
Template
weekly-portfolio-review.csv
CSV worksheet for the weekly review: tranche, coverage, utilisation, action taken, dollar impact.
Download ↓The Evidence
Commitment inventory snapshot
Signed export of the active commitment inventory, with named owner per tranche.
Commitment policy document
Signed institutional policy with target coverage bands and named owners.
Eight consecutive weekly reviews
Eight weekly review notes documenting coverage, utilisation, and decisions taken.
Quarterly portfolio attestation
One-page quarterly attestation, signed by the FinOps lead and CIO.
The Impact
Adopters
The cohort sample is below the publish threshold (N<5). When we have at least five completions, this panel will surface the median score lift, median cost savings, and median time to complete from the IFO4 impact API.
Pair this with
Governance · Elite
Tag policies exist on paper.
Open →AI Compute · Best
AI inference invoices arrive as a single consolidated charge per provider per month.
Open →SaaS · Best
SaaS subscriptions accumulate quietly through expense cards, individual purchase orders, and shadow IT.
Open →Begin the playbook
Start the playbook, simulate the impact first, or take it to the community. Every move is logged.