Skip to content
Ownership and allocation

How to allocate shared cloud costs

Choose recipients and a driver that fits the pool, retain uncovered amounts and publish the policy version alongside the allocated charge.

For platform owners designing a shared-service policy4 min readSources reviewed
In this guide

Define the pool and its recipients

List the source charges included in one shared pool. A central network can contain fixed gateway charges and traffic-dependent costs that deserve different treatment. Exclude resources already directly assigned to a team. Specify the billing period and native currency, then identify the teams eligible to receive this pool.

Decide whether unused capacity belongs to the service owner or its consumers. Reserving central capacity for future growth is different from processing a team's requests. Finance can fund that capacity centrally while distributing a measured variable component. The FinOps Foundation describes both central funding and distributed policies; the choice should match the business purpose of the service.

Choose the driver for the cost you are splitting

An equal split works when the policy deliberately gives recipients equal responsibility. Fixed percentages provide budget predictability but need a review date. A variable split uses a recurring measurement, such as relevant transferred bytes or vCPU hours. The FinOps Foundation describes these options without requiring one method for every shared service.

For a request-processing pool, completed requests can be a usable proxy if request types have comparable cost. If one request class is much heavier, separate the pools or use a documented weight. Whole-company cloud spend is convenient for allocating general support, but may poorly explain a specific network service. Explain the driver's limitations before recipients accept the policy.

Make the denominator visible

For a variable policy, each recipient's weight is its eligible measured units divided by the sum of eligible measured units for the same interval. Define what counts as a unit, including how retries are handled. Remove duplicate telemetry and reconcile the population before calculating percentages.

This illustrative September pool costs EUR 2,400.00. The policy retains EUR 600.00 of baseline capacity centrally and distributes EUR 1,800.00 using 1,000,000 eligible completed requests. Teams A, B and C account for 60%, 30% and 10%. Those percentages describe the measured proxy, not proof that every request incurred an equal provider charge.

Scroll the table sideways on smaller screens. Keyboard: focus the table and use the arrow keys.

Illustrative shared-pool policy, not customer results or a built-in Costframe split. All amounts retain EUR.
RecipientEligible requestsVariable allocationBaseline allocationTotal
Team A600,000EUR 1,080.00EUR 0.00EUR 1,080.00
Team B300,000EUR 540.00EUR 0.00EUR 540.00
Team C100,000EUR 180.00EUR 0.00EUR 180.00
Central platformNot in request denominatorEUR 0.00EUR 600.00EUR 600.00
Total pool1,000,000EUR 1,800.00EUR 600.00EUR 2,400.00

Do not turn absent measurements into zero usage

If telemetry fails for Team C, redistributing its entire share to Teams A and B makes their reports misleading. Label the denominator incomplete and apply the agreed fallback. That could retain the affected pool centrally or use a clearly labeled fixed policy approved beforehand. Do not claim an actual usage split when its inputs are estimated.

A zero denominator also needs an explicit rule. An idle shared service can still incur fixed charges. Keep those costs visible instead of dividing by zero or dropping the pool. Check service onboarding dates and missing identities before excluding a recipient. For pooled desktops, a current list of users alone does not prove their historical consumption shares.

Version the policy and reconcile the smallest units

Use exact decimal arithmetic for allocation amounts. For an illustrative equal split of EUR 100.00 across three recipients, cent-level reporting could assign EUR 33.34, EUR 33.33 and EUR 33.33 under a documented residual rule. Use a deterministic recipient order or another approved method so repeated runs produce the same result.

Apply credits according to their relationship with the original pool, and distinguish policy changes from changes in the source charges. Microsoft's Azure allocation percentages remain fixed after prefill until manually updated; they are not automatically recalculated each month. Its rules exclude reservation and savings-plan purchases. An external variable policy therefore needs its own dated measurements and reconciliation checks.

Publish what recipients can verify

Give recipients the source pool amount and selected interval, together with the policy version and their measured units. Show centrally retained or unresolved amounts beside allocated shares. Do not add recipient allocations to the original central pool in the same total. Ask the service owner to review whether the driver still fits after an architectural change.

Costframe preserves shared and unresolved AVD charges as resource costs; a user count does not automatically divide them into per-person actual costs. Arbitrary shared-pool policies are a conceptual method here, not a promise of universal product functionality. Costframe remains read-only in the customer cloud. Confirm the available scope and evidence before incorporating its reports into your allocation workflow.

Sources

Use this in your next review

Inspect labeled sample costs and evidence limits. The demo does not calculate or approve your shared-service allocation policy.

View the demo auditCheck plans and current scope