Cross-account, multi-cloud, one number: the transparency problem

Most cost waste doesn’t hide inside a single account. It hides in the seams between them. The prod account looks reasonable. The data-science account looks reasonable. The three acquired-company accounts each look reasonable. Nobody’s looking at the sum, allocated consistently, in one place — so the waste that would be obvious across the whole estate stays invisible in the fragments.

This is the transparency problem, and it gets worse with every account you add and every cloud you adopt. You can’t optimize an estate you can only see one slice at a time.

Fragmentation hides the pattern

The same over-provisioning that’s glaring in aggregate is easy to miss when it’s spread thin. A dozen accounts each running one oversized instance is twelve small non-events; the same twelve instances in one view is an obvious, rankable waste pile worth a sprint. Consolidation doesn’t just tidy reporting — it makes patterns visible that were literally unseeable when the data was scattered.

Multi-cloud compounds it. AWS, GCP, and Azure each describe cost in their own vocabulary — different services, different billing granularity, different discount models. A t3.large, an e2-standard-2, and a Standard_D2s_v3 are the same idea wearing three costumes. Without a common model you can’t even compare them, let alone decide where a workload is cheapest to run.

One number, but allocated — not just summed

The fix isn’t a single grand total; a summed number is as useless as the fragments. The fix is one consistently allocated view — every dollar, across every account and cloud, attributed to a team, service, and environment in the same schema. That’s what lets you ask estate-wide questions that were impossible before:

• Which team — not which account — spends the most, and on what?
• Where is the same workload running on a more expensive footprint in one cloud than another?
• Which environments (all the staging across all accounts) are collectively over-provisioned?

The seams are where the money is

Cross-account and cross-cloud costs are exactly the ones with no owner, because they fall between the teams that watch individual accounts. Inter-region transfer, a shared services account, egress between clouds, the long tail of forgotten dev accounts — this is high-yield territory precisely because nobody’s been able to see it whole.

Transparency across the estate is the prerequisite

Every optimization in this series — rightsizing, commitments, cleanup, unit economics — assumes you can see what you’re optimizing. At estate scale, that assumption breaks unless something is actively unifying the picture: reading every account and cloud, normalizing them into one model, and allocating consistently so the whole thing reads as a single system.

That unified read is foundational to how Lizrd works — it connects across your accounts and clouds, normalizes the billing and utilization into one allocated view, and surfaces the waste that only shows up when you can finally see the whole estate at once. The savings in the seams have been there all along. You just needed one number you could trust to find them.