If your multi-cloud cost review still means reconciling cloud bills by hand, you already know spreadsheet hell: provider-specific data, manual consolidation, and a dashboard mistaken for the architecture.
A2A—the Italian energy and circular-economy company in this case, not an agent-to-agent technology—escaped that loop with a multi-cloud FinOps pipeline on AWS. AWS and A2A report that the platform eliminated manual spreadsheet consolidation, cut monthly budget review time by approximately 40%, and identified about EUR 1.5 million in annual savings through roughly 100 optimization actions in 2025. A2A is described as having roughly 15,000 employees.
The practical lesson for data, platform, and FinOps teams is direct: the dashboard is the endpoint, not the architecture.
Decouple Ingestion from Normalization
Treat raw billing data as unsafe for shared reporting until it passes through the FOCUS normalization layer. Provider-specific ingestion belongs upstream of a shared FOCUS model. That boundary absorbs provider differences before analysts and reporting tools depend on the data.
The path is concrete:
- Amazon S3 receives billing data from AWS, Azure, and Google Cloud.
- AWS Glue transforms the provider schemas into FOCUS.
- Amazon Athena exposes the normalized data through SQL.
- Amazon QuickSight presents role-based dashboards.
Each stage has a distinct job, so collection, mapping, query, and presentation problems have clear places to be investigated. The dashboard remains the endpoint instead of becoming the place where incompatible billing logic is hidden.
Query the Shared FOCUS Model in Athena
Once provider differences are normalized, reporting queries can operate on shared FOCUS columns instead of rebuilding provider mappings inside each dashboard. Assuming focus_costs is the normalized Athena table, a cross-provider cost rollup can look like this:
-- Replace focus_costs with your normalized Athena table.
SELECT
ProviderName,
ServiceName,
BillingCurrency,
SUM(BilledCost) AS total_billed_cost
FROM focus_costs
GROUP BY
ProviderName,
ServiceName,
BillingCurrency
ORDER BY
total_billed_cost DESC;
The query is intentionally straightforward. Provider quirks stay upstream; the query layer uses the shared model.
Treat Chargeback as a Controlled Release
A cost report can be useful before it is safe for allocation. Showback can tolerate visible warnings because it helps teams inspect and discuss costs. Chargeback moves money or accountability between owners, so its release condition must be stricter.
Stop chargeback when freshness, reconciliation, lineage, or ownership evidence is missing. Freshness shows whether the source is current. Reconciliation shows whether totals agree. Lineage makes transformations traceable. Ownership identifies who can resolve an exception.
A warning banner is therefore valid for showback but insufficient for chargeback. This distinction prevents a polished visualization from being mistaken for finance-grade evidence.
Do Not Stream for the Sake of Architecture
Near-real-time is not a permission slip to stream. If batch processing captures source changes inside the required decision window, streaming has not earned its added operational responsibility.
Start with source behavior and the decision that must be made. Use continuous updates only when the source and decision genuinely require them. Streaming for the sake of architecture creates more states to monitor and recover while leaving correction handling, allocation rules, and reconciliation untouched.
Choose the least complex ingestion pattern that meets the decision window and preserves the evidence finance requires. A faster-looking architecture diagram is not the same as a better FinOps decision.
Compare Build and Buy Beyond the UI
Dashboard screenshots are a poor build-versus-buy test. The comparison should cover total operating responsibility.
Who maps each billing source? Who handles corrections? Who owns allocation rules? Who reviews failed gates? Who maintains the FOCUS mapping as provider inputs change? A purchased reporting layer may still leave those duties with the internal team, while a custom system makes them explicit. Neither choice is automatically better; both must account for the same responsibilities.
At Van Data Team, we start by mapping billing sources, correction paths, allocation rules, and review gates before selecting a dashboard. Copy this responsibility matrix into Jira or Notion and complete every row before making the decision:
- [ ] Billing-source mapping — Build owner: ___ | Buy-side owner or vendor obligation: ___ | Required evidence: ___
- [ ] Correction-path handling — Build owner: ___ | Buy-side owner or vendor obligation: ___ | Required evidence: ___
- [ ] Allocation-rule definition and changes — Build owner: ___ | Buy-side owner or vendor obligation: ___ | Required evidence: ___
- [ ] Freshness gate — Build owner: ___ | Buy-side owner or vendor obligation: ___ | Required evidence: ___
- [ ] Reconciliation gate — Build owner: ___ | Buy-side owner or vendor obligation: ___ | Required evidence: ___
- [ ] Lineage evidence — Build owner: ___ | Buy-side owner or vendor obligation: ___ | Required evidence: ___
- [ ] Ownership evidence — Build owner: ___ | Buy-side owner or vendor obligation: ___ | Required evidence: ___
- [ ] Failed-gate review and resolution — Build owner: ___ | Buy-side owner or vendor obligation: ___ | Required evidence: ___
- [ ] FOCUS mapping maintenance — Build owner: ___ | Buy-side owner or vendor obligation: ___ | Required evidence: ___
A blank responsibility is unowned work, regardless of how polished the dashboard looks.
Read the Outcomes Carefully
The reported results make the case tangible, but they should not be reduced to a QuickSight story. The reusable lesson is the chain underneath: upstream provider handling, shared FOCUS normalization, SQL access, role-based reporting, and release controls matched to the financial use case.
If you copied the responsibility matrix into your planning today, which row would still have no clear owner—and would that gap change your build-versus-buy decision?
📖 Read the full guide → Inside A2A's Multi-Cloud FinOps Data Pipeline on AWS
Top comments (0)