New: Brownfield onboarding
Learn more
Uncover the "hidden iceberg" of costs by bringing legacy infrastructure into your governance model.
The biggest cloud cost opportunity in most enterprises isn’t in what you just recently deployed or are about to deploy next quarter. It’s in the infrastructure you’ve long been paying for… and quietly ignoring.
Cloud cost management doesn’t have a tooling problem. It has a visibility problem.
FinOps as a discipline has grown up. Teams exist. Dashboards exist. Tagging policies exist (at least in theory). Rightsizing recommendations are being reviewed in meetings that could have been emails.
And to be fair, real savings are being achieved.
On the portion of the estate that’s actually visible.
That qualifier is where the problem lives. It tends to get glossed over, usually right before someone proudly presents a 12% optimization on what turns out to be 30% of total spend.
In most enterprises, the infrastructure governed through a central platform is only a fraction of what’s running. The rest lives elsewhere, in:
All of it sits outside any unified cost model. It shows up in native provider billing dashboards — separately, inconsistently, and with just enough formatting differences to make reconciliation a minor lifestyle choice.
So what you end up with is a FinOps function that is extremely good at optimizing the part of the problem it can see, and structurally blind to the part that actually moves the needle.
This isn’t edge-case inefficiency. In most organizations, established cloud estates, the infrastructure that predates any unified governance model is the majority of what's running, and therefore, where most of the money goes.
The newest workloads, the ones deployed within FinOps framework and through governance-aware platforms, are usually the cleanest and smallest slice of the estate.
The oldest workloads?
They’re bigger. Messier. Business-critical. And about as transparent as a brick wall.
Which means all the good FinOps work — rightsizing, commitment planning, allocation models — is being applied to the easiest part of the estate, not the most expensive one.
It’s a bit like aggressively budgeting your current coffee spend, while silently paying for the five subscriptions you haven’t used in years.
Applications get shut down. Infrastructure often doesn’t.
Compute keeps running. Storage keeps growing. Databases sit there patiently billing you for their continued existence.
There’s usually no clean handshake between “we’ve retired this app” and “we should probably stop paying for the things that powered it.”
So the costs linger quietly, indefinitely, and entirely outside any governed model.
At some point, everything was sized for peak demand.
That peak either never came or came once, in 2019, and has been fondly remembered ever since.
But the infrastructure didn’t get the memo.
Without centralized visibility (and ownership), oversized instances and bloated storage just keep running at full price, because nothing is more durable than a “temporary” overprovisioning decision.
Modern infrastructure is increasingly created by automation — CI/CD pipelines, infrastructure-as-code processes, scaling policies, and tooling that provisions resources in response to conditions rather than explicit human decisions.
Which is great for speed, less great for governance and control.
It creates resources that are perfectly valid, fully functional, and completely invisible to your unified cost model.
They exist. They cost money. They show up in provider billing but often not in any unified cost analysis.
The default FinOps response to rising costs is predictable: optimize what’s visible.
Tighten rightsizing. Revisit commitments. Improve tagging compliance. Add another dashboard.
All useful. None sufficient.
Because you’re still optimizing a partial view.
Closing the gap means expanding the boundary and bringing the entirety of the existing estate into the same model as governed resources, so the same rules, analysis, and accountability apply everywhere.
Not just where it’s convenient.
This is what brownfield onboarding actually solves.
Not in a theoretical “single pane of glass” sense, but in a very practical one:
Suddenly, the analysis you were already doing applies to everything.
Same FinOps discipline. Just applied to the full estate instead of the curated demo version.
Of course, cloud estates don’t sit still.
So a one-time cleanup just means you get to rediscover the problem later, usually under more stressful circumstances.
This is where continuous audit matters.
You need periodic audits — anything sitting in a connected account but outside the scope of governance gets flagged automatically.
Translation:
New cost exposure doesn’t wait politely for your next quarterly review. It shows up immediately, which is exactly when you still have a chance to do something about it.
Before brownfield onboarding:
After brownfield onboarding:
Most FinOps conversations start with:
“How do we optimize this further?”
A better question is:
“How much of our actual spend are we even looking at?”
Because in most organizations, the biggest savings aren’t hiding in plain sight. They’re hiding just outside the boundary of what you’ve decided to measure.
Brownfield onboarding is how you fix that—without rewriting workloads, breaking things, or launching a six-month “transformation initiative” that everyone secretly dreads.
So, you need to verify in any PoC, if the tool actually handles brownfield onboarding across your entire multi-cloud estate.
But that’s just the starting line. The real nuance is in the workflow: does it force a “dump everything in at once” approach, or does it let you take a more deliberate, audit-first path?
A smart process — connect, discover, review, then selectively import — lets your platform engineering team adopt governance at their own pace, without accidentally importing a decade of unused, cost-draining resources that end up consuming your optimization efforts instead of being decommissioned upfront.
emma's brownfield onboarding connects existing AWS, Azure, and GCP accounts to emma's unified cost and governance model — no migrations, no disruption, no existential crises for your infrastructure. See how it works at: https://www.emma.ms/tutorials/how-to-import-your-existing-cloud-infrastructure
