Each provider runs its own billing system, so there is no ready-made unified view. Most people reach for a tool first, which reverses the order: unify the cost categories and the tagging scheme first. Four accounting mismatches will make the numbers disagree.
If you run on two or three clouds, you hit the same wall quickly: there is no single place that answers "how much did we spend this quarter, and on what".
This page covers how to get there. But the conclusion runs against instinct: most people get step one wrong. One prerequisite read first: is multi-cloud worth it - if you are still deciding whether to be multi-cloud, that page comes first.
Why there is no ready-made unified view
The reason is mundane: each provider runs an independent billing system. Their data models, charging models and billing dates all differ, and none of them has any incentive to consolidate someone else bill.
- It is not one bill, it is several. Each provider has its own bill, its own cycle and its own granularity.
- "Cost" does not mean the same thing everywhere. One aggregates by service, another by usage type, and the same resource can land in different buckets at different providers.
- Every provider has cost analysis, but only over its own data. You can group, filter and trend inside each one - there is no layer across them.
So a "unified view" is, fundamentally, a thin middle layer you build yourself - not a product you go and find that "connects all clouds". That is not to say tools are worthless; it is that before categories and tags are unified, any tool can only lay several differently-defined bills side by side - looking tidy while not actually reconciling.
Step one: define one set of cross-provider cost categories
This is the step most often skipped and the one that determines everything after it: define your own categories first, then require every provider bill to map onto them.
A workable set usually has only five or six entries:
| Your category | What it contains |
|---|---|
| Compute | Servers, containers, serverless - anything billed on compute capacity |
| Storage | Object, block and file storage, snapshots |
| Traffic | Egress, cross-zone, gateway processing, content delivery |
| Database | Relational, non-relational, cache, warehouses |
| Other | Logging and monitoring, queues, security, support plans |
Why this must come first: each provider defines its own "usage types", and you cannot compare them directly. Once you converge onto the categories above, everything downstream - a spreadsheet or a platform - is aggregating on one consistent definition. Do it the other way round (tool first, categories later) and you get "a table assembled from each provider own taxonomy": complete-looking, but unable to answer "is our money going into compute or into traffic".
A counter-intuitive discovery that often follows: many people find their assumed "biggest line" was not - they assumed compute, and after categorising discovered traffic plus database outweighed it. That is exactly what categorisation is for. The mechanics of each category are in why AWS data transfer costs so much (traffic is the most under-estimated).
Step two: deploy the tagging scheme on every provider
Categories answer "on what"; tags answer "whose". You need both - miss one and attribution fails.
The method is simple; the discipline is the hard part: define a minimal set of tag keys and deploy them on every provider.
- Few and stable keys: "project / environment / owner" is usually enough. The more keys, the less anyone bothers filling them in.
- Consistent values: one allowed set (e.g. environment is only production / staging / test). Do not write
prodon one provider andproductionon another. - Every provider covered: this is the work - the same scheme has to land several times.
⛔ The benefit of tagging is deferred while the cost is immediate, which is why it gets postponed. But consider the reverse: without tags you cannot even answer "which project is spending" - no amount of optimisation has anything to aim at. That is already true inside a single provider (see AWS billing: six actions that actually work); several providers just magnify it.
Step three: export regularly to one place
Categories and tags define the definitions; this step handles where the data comes from. One principle only: do not chase real-time aggregation - export on a schedule instead.
- Use each provider own cost export. Every provider has a mechanism for exporting detail (some call it a cost and usage report, some a cost export) - the names and entry points differ, the capability is similar. Land it somewhere you can retrieve (object storage is the usual destination).
- Export on a fixed cadence. Monthly or weekly both work; consistency is the point. Cloud billing is inherently periodic, so following that rhythm is less work than chasing real time.
- Aggregate after landing. Export formats differ, so the aggregation step has to be yours - which is exactly where the categories from step one get applied.
The typical granularity is line items "per resource, per usage type, per period". That is the shape of a cost and usage report, and it is far more detailed than a summary view - which is precisely what allows re-grouping into your own categories.
Four accounting traps that make numbers disagree
After those three steps you can aggregate. But four things make numbers disagree, and none of them is a bug:
| Trap | How it shows up | How to handle it |
|---|---|---|
| Different billing periods | Cycle start and end dates may differ, so the same calendar month covers different ranges | Archive by each provider own cycle rather than forcing calendar months |
| Different currencies | Some bill in USD, some in local currency; even in USD the conversion date differs | Anchor on one reporting currency and record the basis |
| Different tax treatment | Some bills include tax, some exclude it; rates vary by entity location | Compare consistently pre-tax or post-tax, never mixed |
| Same label, different meaning | The same word may map to different scopes at two providers | Map by your category definitions, not by the other party label |
⛔ The fourth is the sneakiest: when you see "data transfer" or "network" lines at two providers, it is tempting to just add them up. But their scopes may differ, and adding them produces a number that is neither accurate nor explainable. Map according to your own category definitions, never according to what the other party calls it.
The minimum viable version: one table is enough
Time for honesty: for most small and mid-sized teams, what you need is not a system but a table.
The minimum viable version looks like this: a monthly table where rows are "provider x your five or six categories" and columns are months. Spending ten minutes after each billing cycle gives you:
- Total and trend: how much this quarter grew against last, visible at a glance.
- Structural change: whether compute grew or traffic grew - structure usually matters more than the total.
- Provider split: how your money is actually distributed across providers.
Why a table first: it costs almost nothing to maintain, its definitions can change at any time, and it depends on no tool. A sophisticated cost platform only becomes meaningful once categories and tags are stable - reverse the order and the tool simply cements the confusion. Once the table has run steadily for a few months and the manual entry genuinely hurts, automate then.
And if even "ten minutes a month" is unrealistic, step back further: at minimum, record one line per provider per month. For trend purposes, having something beats having nothing.
FAQ
Are there tools that automatically aggregate multi-cloud costs?
Such products exist, but they solve aggregation, not definitional consistency. If you have not defined your own categories or unified tags, a tool just displays several differently-defined bills side by side - tidy to look at, not reconciling. So the order is: categories and tags first, tools afterwards.
I am a team of one - is any of this worth doing?
Yes, and the smaller the team the more it matters, because nobody else remembers the history. The minimum version is that table: one total row, five or six categories, filled monthly. Its value is not precision - it is being able to answer "did it grow, and where", which is precisely where cost optimisation starts.
Cannot the providers cost consoles talk to each other?
No. Each provider cost analysis only covers its own data - it can group by service, usage type and tag within that provider, but there is no cross-provider layer. That layer has to be built by you (even if it is only a table). Which is why this page calls it "a thin middle layer".
Why insist on categories before tools?
Because a tool solves presentation while categories solve comparability. Different providers bucket the same kind of resource differently, and placing them side by side yields an unexplainable number. Converge the definitions onto your own categories first, and whatever you present with afterwards will be consistent. That step costs nothing and needs no tool - but nothing after it works without it.
Once the unified view exists, what comes next?
Look at structural change first, then optimise. If one category is climbing fast, investigate that one - see why your AWS bill jumped (seven persistent-charge sources, and the reasoning is universal). If the structure is stable and the total simply tracks business growth, that is when discounts become relevant: official commitments and channel discounts act on different layers - see AWS credits and discounts are not the same thing and cloud discount mechanisms compared; what a channel changes is in AWS discounts and reseller pricing.