FinOps / Technical guide
Choose a shared cloud cost model that teams can inspect
Central networking, logging and shared platforms serve several teams, but their provider bill may arrive under one resource or account. A team tag on that resource usually identifies the operator, not every consumer.
An allocation model should explain how the cost is shared, what evidence supports the shares and who approved the rule. Retaining a central budget is also a valid choice when apportionment would add effort without improving decisions.
Discuss shared allocationDefine the shared pool before choosing a denominator
Identify the included resources, cost categories, period and currency. Separate directly attributable charges first so the shared pool does not charge teams again for costs already assigned to them. Exclude or explicitly handle tax, credits and commitments according to the agreed financial basis.
Do not combine measurements with different intervals. A daily request share and a monthly bill can be compatible only through a documented aggregation rule. Retain the original source amount alongside the allocations so finance can reproduce the result.
Match the model to the service and the decision
Fixed shares are easy to budget but can lag changing usage. Proportional allocation can use a chosen spend or capacity denominator; that proxy may reward or penalize unrelated workload behavior. Usage-based allocation can be more specific, but requires trustworthy metering and coverage.
The FinOps Foundation treats allocation and shared-cost strategy as distinct parts of the practice. Choose an appropriate method for each pool instead of forcing one formula onto central support, networking and a multi-tenant platform.
| Method | Suitable evidence | Limitation |
|---|---|---|
| Central budget | Explicit finance decision | Consumer share is not calculated |
| Fixed share | Approved responsibility percentages | Can drift from usage |
| Proportional | Named spend/capacity proxy | Proxy is not measured consumption |
| Usage-based | Complete comparable telemetry | Missing metering creates unresolved shares |
Reconcile one illustrative shared pool
Suppose a EUR 1,000.00 monthly logging pool is allocated by an approved 60/40 rule. The shares are EUR 600.00 and EUR 400.00, and their sum remains EUR 1,000.00. Those are modeled shares, not direct measurements of each team's logging consumption.
Version the model and retain its exceptions
Record the effective date, approver, denominator source and treatment of missing data. Give teams a way to review disputes. When a model changes, preserve the earlier version rather than rewriting approved historical statements silently.
Current ownership, historical responsibility and permission to approve a cost-center report remain separate. A service operator can help validate usage while finance owns the allocation policy. A mapping must never grant access just because it assigns a charge.
Costframe does not imply universal shared-allocation automation
Costframe's supported Azure workflows provide configured allocation context, unresolved amounts and internal statement review with explicit source/period/revision. Those capabilities are not a universal telemetry-weighted allocation engine, Kubernetes pod allocator or native AWS commitment-sharing implementation.
An external approved model can support your broader process, but it must not be presented as measured attribution inside Costframe unless the relevant source and workflow are verified. Directory Service remains planned; missing identity evidence should not be filled with an equal per-person split.
References and further reading
Provider documentation explains native capabilities. Costframe availability and limitations are stated separately in this guide.
Discuss the pool and its evidence
Bring your shared service, period and proposed denominator to a review of supported allocation workflows.
Discuss shared allocation