Community collaboration is at the heart of the Foundation, why not create the initial content for this page so others can benefit and build onto it?
Cost Allocation is the set of practices to divide up a consolidated invoice or bill among those who are responsible for its various component parts. In the context of FinOps this typically involves dividing up consolidated Cloud Service Provider invoices among various IT groups who use cloud within the organization.
FinOps, itself, is necessary due to the large quantity of billing and usage data provided by cloud providers, and the speed at which it is delivered. Cloud billing and usage data is aggregated into a few data sources, often with millions of lines of data, delivered multiple times per day. Cost Allocation can be a challenge to appropriately divide the total cloud bill among the many parts of an organization who are using it.
Cost Allocation is done through a combination of functional activities primarily focused around the use of a consistent hierarchy of accounts, projects, subscriptions, resource groups and other logical groupings of resources (and the naming of these hierarchical groupings); along with resource-level metadata – tags or labels – applied within the cloud service provider, or by a third party FinOps platform.
All of the clouds provide tools to allow users to arrange hierarchy groupings, and to apply metadata to those groupings. The naming standards used for the accounts, resource groups, projects, and folders, can also be useful in determining the owner of any group of resources.
All of the cloud providers also allow for the use of tags or labels which can be applied as metadata to most individual resources, and which then appear in the billing and usage data when turned on by the user.
Increasingly, FinOps platforms and cloud providers are adding the capability to more flexibly manage resource metadata and hierarchy groupings either within the cloud provider or in the cost and usage data after delivery by the cloud provider.
Cloud provider invoices can be analyzed, using a combination of hierarchy and metadata to allocate costs to various organizational, functional, or financial targets within the user company. Any resources or hierarchy groupings which have no metadata attached can be addressed by the FinOps team as a compliance issue. Resources and hierarchy groupings which can be directly attributed to an internal target can be mapped to that target. Resources and hierarchy groups which are shared, can be identified as shared cost, and then various models of distributing those costs can be applied.
An important prerequisite to effective cost allocation is the metadata strategy, which should include all of the details governing the cost allocation process. The strategy should create a list of metadata which should be applied, possible values, compliance requirements, and mechanisms for doing so. Likewise, it should indicate a mapping of those metadata or hierarchy groupings to internal identifiers within the user organization, such as the business unit, P&L group, cost center, application ID, etc. to which costs will be allocated. There can be multiple layers of cost allocation and multiple ways to slice the cost and usage data as well. For example, finance may need to see costs divided into the Cost Center, but some engineering teams may need more granular breakdown by application, and there may also be a need to see all costs related to Production environments for all applications, or costs which are identified as R&D costs.
Measures of success are represented in the context of cloud costs and may include one or more key performance indicators ( KPI ), describe objectives with key results ( OKR ), and declare thresholds defining outliers or acceptable variance from forecasted trends.
An excerpt from a FinOps Foundation Slack discussion |
---|
The FinOps framework refers to this as “resource hierarchy metadata” and it’s a big part of cost allocation. The naming standard is as important or more important than the tag/label metadata that can be applied using things like Cost Categories or Project Labels. |
Note all the hierarchy groupings you use from the billing account/management account/enrollment all the way down (departments, subscriptions, account groups, management groups in Azure; management account, OU, member account in AWS; billing account, organization, folder, project in GCP) (probably not comprehensive, from memory) |
Take note of where your organization has “break points”, i.e. we never have multiple ENVIRONMENTS (prod, test. dev, etc.) in the same ACCOUNT GROUP/ACCOUNT/PROJECT (e.g. this might tell you that you can name these with the -DEV, -TST, -PRD suffix), or every application will receive an entire SUBSCRIPTION/OU/FOLDER and all the subordinate groupings will be paid for by that Application budget (this might tell you where to apply cost center or App ID tags, or whether to include them in the name). |
We have done things like EnvironmentDepartment names. So if the dept was called “JJ123” it would be ProdJJ123, TestJJ123, DevJJ123, SandboxJJ123 etc. The problem you run into is org changes. When JJ123 merges into FF456. That can be a bit messy. If there is a way you can keep Environments hardcoded in the account name but business groups/departments tagged in a metadata repo to pull from - that would give you more flexibility to manager your accounts over time. |
Every org is different, but I like a scheme that moves from most granular to least - something like this: <org>-<provider>-<department>-<application>-<environment> |
This gives you stuff like: * myorg-aws-finance-payroll-prod * myorg-gcp-flightops-flightbag-staging |
Reference of cloud cost management platforms, tooling and service providers related to this Capability coming soon.
Reference of courses and training partners related to this Capability coming soon.
Get involved and contribute to the community by sharing your real world experiences related to this Capability in the form of a story or providing a playbook for how you have implemented best practices in your organization. Your real world experiences can be provided in the context of:
Join the conversation about this Capability in Slack . You can submit stories, how-tos and suggest improvements using one of the options for contributing here.