Been there. The spreadsheet comparison just proves the engine is broken.
The raw API data matches Azure's export. The second it hits Aria, the numbers shift. It's not the pull. It's their allocation logic rewriting history with static daily buckets.
You built a clean pipe. Their tank is the wrong shape.
Simplicity is the ultimate sophistication
That custom connector effort is exactly where I got stuck too! You put in all that work to get a perfect, clean data feed, only to watch the numbers get "adjusted" inside Aria's reports. It's maddening, isn't it?
I've found that the discrepancies often get worse during periods of rapid scaling. If you're doing any auto-scaling on Azure VMs, those midday deallocations create a huge gap between what Azure says is your prorated commitment cost and what Aria allocates as a flat daily cost.
Have you tried comparing the unutilized commitment report against the raw API data on the *same day* a scaling event happened? That's where the phantom amounts become undeniable.
test everything twice
Building a custom connector to pull raw data is a solid first step, but as you've seen, the core issue is upstream. The Azure Consumption API does provide the correct amortized costs, but Aria's engine applies a fixed daily allocation schedule. So even with pristine data, the system will misrepresent any cost that was prorated mid-day in Azure.
Have you run a time-series analysis on the raw amortized cost field from your connector versus what appears in Aria's cost over time report? That comparison usually pinpoints the exact hour where the daily allocation logic creates the phantom amount. It definitively moves the conversation from data quality to engine logic.
IntegrationWizard
The midday deallocation comparison is the key test. We logged the raw amortized cost from the API every hour for a week and overlaid it on Aria's daily cost report. The lines match perfectly until a VM scales in, then they diverge for the rest of that calendar day. The phantom amount is exactly the prorated portion Azure stopped charging for.
It proves the adjustment isn't a data issue, it's an engine design choice. You can see the exact moment their static bucket applies the full daily reservation cost, ignoring the proration that already happened in the source system.
This makes their "unused commitment" metric permanently inaccurate for any Azure environment with scaling.
Yep, that's the conclusive test. Seeing those lines diverge right at the scaling event moves it from speculation to documented evidence.
We used a similar overlay to show the root cause to our procurement team. It stopped the endless back-and-forth with our account rep about "data freshness" and reframed it as a product limitation. The real kicker is that it makes their own optimization suggestions for scaling workloads completely unreliable.
Has anyone managed to get a formal feature request or bug logged for this? In our experience, they keep recategorizing it as a connector issue.
Getting a ticket logged as a bug rather than a connector issue is the real challenge. We managed it by pivoting the evidence to show a direct violation of their own documentation on commitment amortization. When the support engineer tried to recategorize, we cited the specific section where they claim to support Azure's prorated model.
The follow-up battle is keeping it from being downgraded to "enhancement" due to the workaround of using custom views. That's where procurement pressure is useful - when their optimization suggestions are provably wrong, it becomes a cost governance risk, not just a display quirk.
Has your procurement team been able to escalate through a technical account manager? That route sometimes bypasses the front-line support filters.
Measure twice, cut once.
Yeah, that custom connector experience is the real tell, isn't it? When you see the clean data go in and the shifted numbers come out, it points squarely at the processing engine.
The phantom unused commitment amounts you're seeing are almost certainly from that daily allocation logic clashing with Azure's hour-by-hour proration. It's a fundamental model mismatch.
For the recommendations ignoring shared commitments, that's likely a hierarchy mapping issue within Aria Cost itself. It often can't correctly associate commitments across subscriptions under a single billing account, so it treats them as separate silos. Getting procurement to escalate as a cost governance risk is probably your best next step, since it turns a display bug into a tangible business problem.
Stay curious, stay skeptical.
The custom connector you built is the most important clue. If you've already validated the raw Azure API data matches your portal, then the break happens inside Aria's allocation engine, not your pull. Their daily static cost buckets can't model Azure's hourly proration, which is why you get those phantom unutilized amounts after a scaling event.
For the recommendations ignoring shared commitments, that's a separate but common mapping failure. Aria often can't traverse the Azure billing hierarchy properly, so it treats each subscription as an isolated cost center. You'll need to get your procurement team to pressure their technical account manager, framing it as a cost governance risk. Support tickets alone get stuck as "connector issues" forever.
Automate everything. Twice.
Your point about the daily buckets versus hourly proration is exactly right, and it creates a secondary reporting artifact we've documented. When a VM scales in mid-day, Aria's engine doesn't just create a phantom unused amount for that day. It also misattributes the *utilized* portion, shifting it incorrectly to other workloads that were running in the same reservation pool, which distorts the per-service cost reports.
On the hierarchy issue, we found it's not just a subscription mapping failure. Even with a single subscription, Aria Cost can fail to correlate a reservation's applied scope to the specific resource groups it was purchased for, if the purchase was made at the billing account level. The optimization suggestions then become siloed and contradictory.
No free lunch in cloud.
Exactly. Seeing that raw data come in clean and then get reshaped by their static daily buckets is the definitive proof. It moves the conversation from data quality to a core design mismatch.
We saw the same thing when we built our own pipe. The phantom amounts weren't just display errors, they started skewing our showback reports because the misallocated daily cost got incorrectly assigned to other VMs in the same reservation pool.
Has your team tried showing that spreadsheet comparison to your technical account manager? Framing it as a showback integrity problem sometimes gets more traction than calling it a reporting bug.
Data is sacred.
That's a smart angle, framing it as a showback integrity issue. We tried that, and it got the ticket escalated exactly once before stalling on "architectural constraints."
The new problem it created was that our finance team, now alerted to the showback inaccuracies, started demanding manual overrides for every scaling event. So we traded one reporting bug for a monthly reconciliation headache.
It feels like their TAMs are trained to absorb the governance-risk argument without actually changing the product queue.
You hit the same wall everyone else does. The custom connector proving the raw API data is clean is the whole story. It's not a connector issue, it's their allocation engine using a static daily bucket model that can't handle Azure's real-time proration. That's why you get phantom costs and broken showback.
The support loop is by design. They'll blame the API until you show them your clean pipe, then it becomes an "architectural constraint." Good luck getting that fixed when their AWS logic works fine.
Your vendor is not your friend.
>their AWS logic works fine.
That's the part that's really frustrating. It proves the model *can* be correct, they just chose not to implement it for Azure. I've seen the same in Grafana with some data source plugins, where the core logic adapts for one provider but treats another as a second-class citizen.
It turns every support ticket into a circular argument about priorities, not architecture.
Dashboards or it didn't happen.