You own FinOps for an AWS Organization of around 120 accounts and leadership wants each product team charged for what it uses. How would you design the allocation model, and what would you do about spend that no tag can attribute?
answer
- accounts allocate everything for free
- few mandatory keys, actually enforced
- coverage percentage is the real KPI
- shared cost needs a written policy
- showback earns the right to charge back
basics
~20 sMake the account boundary carry most of the allocation, since all spend in an account belongs to it without tagging discipline, then use a small mandatory tag set inside accounts. Split genuinely shared cost by rule, and start with showback before charging anyone.
solid answer
~1 minThe first design decision is structural, not tactical: in an Organization, an account is the cheapest allocation boundary there is, because every charge inside it belongs to it whether or not anything was tagged. So I would push team ownership onto accounts wherever the estate allows, and use a deliberately small mandatory tag set — environment, application, cost centre — for the finer questions inside a shared account. A Cost Category then maps accounts and tags to the handful of team values finance actually reports on, with a loud default so unmatched spend is visible. Genuinely shared cost — a platform account, a shared cluster, central networking, support charges — gets a split charge rule rather than a fictional tag; proportional splitting is the usual default because it puts the incentive on the heaviest consumer. I would also decide once, explicitly, whether commitment discounts follow the account that used the resource or are pooled centrally, since that single choice changes every team's number. And I would run it as **showback** first: publish the numbers, let teams argue about them, fix the model, and only move to real chargeback when allocation coverage is high enough that the argument is about behaviour rather than about the data.
go deeper
Know the vocabulary: showback publishes what each team spent, chargeback actually moves the money, and both depend on being able to attribute spend to a team through accounts or tags.
Explain the mechanics you would use — accounts and activated tags as inputs, a Cost Category to map them to team values, a default value so unallocated spend is visible — and why some spend is inherently unattributable.
Show operational judgment: enforce a small key set at creation, measure allocation coverage as the programme's KPI, and pick a defensible method for splitting shared cost rather than inventing tags for it.
Own the whole model as a design with tradeoffs. Argue the account-boundary decision on its own merits, set the policy for shared cost and commitment attribution explicitly, sequence showback before chargeback, and say plainly when chargeback is not worth doing at all.
## Start with the boundary, not the tags Most failed chargeback programmes begin by mandating tags and end two years later with 60% coverage and a spreadsheet nobody trusts. The structural answer is stronger: in AWS Organizations, the **linked account is the one boundary that allocates everything automatically**. There is no such thing as an untagged charge in an account — every line item carries the account id, including the charges that no tag can ever reach: inter-AZ transfer, support, taxes, charges from services that do not propagate tags to every line. So the first question is how far the estate can be pushed toward account-per-team-per-environment. Where that holds, allocation is essentially free and permanently correct. Tags then answer the questions *inside* an account — which application, which environment, which customer — where the account id alone is too coarse. This is a tradeoff, not a free win: more accounts means more baseline setup, more networking, more identity plumbing, and quota management per account. A principal-level answer names that cost and says why it is still usually worth paying for the allocation and blast-radius benefits together. ## Keep the mandatory tag set brutally small Every mandatory key is a permanent tax on every team and every pipeline. Three or four keys that are actually enforced beat a dozen that are aspirational. Standardise their spelling through an Organizations tag policy, activate them once in the payer account, and enforce presence at creation only for the resource types that dominate spend — the long tail is not worth the breakage. ## Compose the reporting dimension centrally Rather than asking finance to reason about accounts and tags, define a Cost Category — `Team`, or `Product` — whose ordered rules map accounts, tag values and services to the values that appear in the report, with a default of `UNALLOCATED`. That default is the programme's single most important metric: **allocation coverage**, the percentage of spend that carries a team value. Publishing coverage weekly does more for tagging discipline than any policy, because it makes the gap somebody's visible problem. ## Decide what happens to shared cost, deliberately There will always be a residue: a shared platform account, a multi-tenant cluster, central logging, security tooling, support charges. Three defensible policies exist and the wrong move is to leave it undecided. 1. **Split it.** A Cost Category split charge rule distributes the shared bucket across teams — proportional to their spend, evenly, or by fixed negotiated percentages. Proportional is the usual default because it aligns the incentive with consumption, but be ready to explain that a team's allocated share moves when *other* teams' usage moves, which surprises people on their first invoice. 2. **Carry it centrally as a platform tax.** Simple, predictable, and it removes the incentive for teams to game the split — at the cost of making the platform look expensive and its consumers look cheap. 3. **Refuse the residue by re-architecting.** Where a shared cluster is genuinely the biggest unallocated bucket, per-pod attribution via the report's split cost allocation data can turn it into real per-team rows without inventing tags. For a shared cluster specifically, option 3 is worth the effort before falling back on a splitting formula, because a formula invites argument and measured usage does not. ## The commitment question One decision quietly changes every team's number: when a discount from a commitment applies to a team's usage, does that team see the discounted figure, or does the central FinOps function hold the discounts and charge teams a standard rate? Both are defensible — the first rewards teams that ran the covered instance types, the second stops teams being penalised by a central purchasing decision they did not make. What is not defensible is switching between them silently, because it invalidates every trend a team has been managing to. Pick one, write it down, and change it only on a fiscal boundary. ## Showback before chargeback Chargeback moves real money between budgets, and the moment it does, every flaw in the model becomes a dispute rather than a bug report. Run showback first: publish per-team numbers on the same cadence the eventual chargeback will use, let teams challenge them, fix the mapping, and watch coverage climb. Move to chargeback only when the numbers survive scrutiny — and expect the behavioural win to arrive during showback anyway, because most of the value is in a team seeing its own number monthly, not in the accounting entry. ## What to measure about the programme itself Allocation coverage, the size and trend of the shared bucket, the number of distinct values a mandatory key has actually accumulated (a proxy for drift), and how long the mapping rules go between edits. If nobody has touched the Cost Category rules in six months while the estate grew 30%, the report is quietly wrong.
- Why is an account a stronger allocation boundary than a tag?Because every line item carries an account id unconditionally, including charges no tag reaches — inter-AZ transfer, support, taxes, services that do not propagate tags. Tag coverage depends on discipline at creation time and degrades continuously; account attribution cannot degrade. The cost is more accounts to bootstrap and govern, which is usually worth paying alongside the blast-radius benefit.
- A team objects that their bill moved without them changing anything. What happened?Almost certainly a proportional split of shared cost: their share is relative to all targets' spend, so another team scaling down raises their percentage. That is a legitimate consequence of the method, and the answer is transparency — show the direct and allocated components separately — or a move to fixed percentages if predictability matters more than incentive alignment.
- How do you keep a chargeback model from rotting as the estate changes?Treat the mapping as owned code, not a console setting: version the Cost Category rules, review them on the same cadence as account creation, and track allocation coverage and the size of the unallocated bucket as standing metrics. New accounts should be mapped as part of the account vending process, otherwise every new team silently lands in the default value.
- When is chargeback the wrong goal entirely?When the organization will not act on the numbers. If team budgets are not real, or nobody is empowered to decommission anything, chargeback creates accounting overhead and disputes without changing behaviour. Showback plus a small set of efficiency metrics achieves most of the benefit at a fraction of the political cost, and can be upgraded later.
saying these in an interview costs you the question
- Mandating a dozen tag keys and calling it a plan
- Assuming 100% tag coverage is achievable
- Leaving shared platform cost unallocated and undiscussed
- Starting with real chargeback before the numbers are trusted
- Changing the discount-attribution rule without announcing it