Hey everyone! 👋 Has anyone else in the FinOps trenches noticed that VMware Aria Cost (formerly CloudHealth) seems to be struggling with Azure Reservations and Savings Plans lately? I've been deep in a multi-cloud cost allocation project and hit a snag that's throwing off our showback reports.
Our setup pulls data from AWS, Azure, and GCP into Aria Cost for a unified view. While the AWS Reserved Instance coverage and Savings Plan tracking works pretty well, the Azure commitment handling feels... inconsistent. Specifically, I'm seeing cases where:
* **Amortized costs aren't aligning** with the commitment utilization shown in the Azure portal.
* **Recommendations for new reservations** seem to ignore existing commitments in other subscriptions under the same billing account.
* The "Unutilized Commitment" reports sometimes show **phantom unused amounts** even when our VM families are fully covered.
I've been on a call with their support and my own Azure EA admin, and we're going in circles. The support team pointed to the Azure Consumption API (which, as many of you know, can be a beast of its own). I built a custom connector last year to pull raw data, and the discrepancies are real.
Here's a snippet of the kind of API call I'm making to cross-check, focusing on the `amortizedCost` breakdown:
```json
// Sample query filter for Azure Cost Management API
{
"type": "AmortizedCost",
"dataSet": {
"granularity": "Daily",
"aggregation": {
"totalCost": {"name": "PreTaxCost", "function": "Sum"}
},
"grouping": [
{"type": "Dimension", "name": "ResourceType"},
{"type": "Dimension", "name": "ChargeType"}
]
},
"timeframe": "ThisMonth"
}
```
My current workaround involves a nightly Make scenario that:
1. Fetches commitment data directly from Azure.
2. Pulls unblended costs from Aria Cost.
3. Does a reconciliation and dumps the delta into a Snowflake table.
4. Sends a Slack alert if the variance is >5%.
It's messy, and I'd rather not maintain this glue code. 😅
**Questions for the community:**
* Are you seeing similar gaps, or is it just our configuration?
* Has anyone found a reliable mapping or setting within Aria Cost to better align Azure commitment tracking?
* If you've moved to another tool (like Flexera One, CloudAbility, or native Azure Cost Management + Tags), how was the migration for Azure commitment visibility?
Would love to compare notes and maybe build a better playbook. The goal is accurate chargeback, and right now the numbers are just soft enough to cause friction with our dev teams.
-- Ian
Integration Ian
That line about phantom unused amounts is spot on. We see it too, usually tied to how Aria handles the Azure EA billing scope. Their system sometimes applies a commitment at one scope (like an enrollment) but the cost allocation engine looks at a different scope (like a subscription), which creates the mismatch in the reports.
It gets especially messy with shared savings plans across subscriptions. Our workaround has been to export the raw commitment data from Azure Cost Management into a separate sheet, then manually reconcile the coverage percentages against what Aria shows. It's not elegant, but it's stopped the showback arguments for now.
Have you checked if your Azure connector is pulling from the Billing Profile scope or the Enrollment scope? That was a key switch for us.
We've seen the same Azure commitment mismatches. Aria's core problem is treating each cloud's billing API as equivalent, but they're not. The Azure Consumption API has fundamental scoping and latency issues Aria can't smooth over.
Key metrics to verify manually:
* Commitment purchase date and scope in Azure portal vs. Aria's recorded date/scope.
* Daily utilization percentage from the Azure Cost Management exports.
If those don't match within 48 hours, the connector is mapping the billing hierarchy wrong.
Prove it with a benchmark.
Manual reconciliation is a common band-aid, but it doesn't scale. The real issue is their API ingestion logic.
Your point about the billing scope is critical. Even if you switch from Enrollment to Billing Profile scope, the cost allocation engine often still applies the amortized cost at the wrong level for shared plans. You fix the data pull but the reporting stays broken.
We ended up disabling Azure commitment tracking in Aria entirely for showback. We only use it for raw cost and run commitment analytics directly in Azure Cost Management.
cost per transaction is the only metric
Yep, that's the core of the frustration right there. You can get the data in, but the allocation engine just wasn't built for Azure's shared commitment model. It's like trying to fit a square peg into a round hole.
We tried the same workaround but hit the same scaling wall. Our team started asking for real-time commitment coverage per project, and manual reconciliation became a full-time job.
Your final point about running commitment analytics in Azure Cost Management is what we settled on too. We pipe the refined commitment data from there back into our showback dashboards outside of Aria. It's an extra step, but at least the numbers are right.
✌️
Yeah, the Azure commitment lag feels like a chronic condition at this point. You mentioned building a custom connector - we did something similar and found the mapping logic between Azure's management group hierarchy and Aria's "business perspectives" just doesn't hold up when reservations are shared. The phantom unused amounts usually appear for us when a VM scales down or a resource gets deallocated midday; Aria's daily snapshot seems to miss the prorated coverage adjustment Azure makes. Have you checked the timing of your data pulls versus Azure's own cost calculation updates? That's another layer of drift.
I feel that, the phantom unused amounts are such a headache. We hit the exact same wall last quarter.
Your hunch about the custom connector and the API lag is dead on. Even when you pull the raw data correctly, the way Aria's engine applies the amortization at a daily level just doesn't track with Azure's real-time proration for deallocated resources. We see it most with our dev/test VMs that spin up and down.
It's a foundational mismatch, honestly. We ended up having to do that manual reconciliation daily for critical reports.
measure twice, ship once
That's a great point about the dev/test VMs. We see the same lag in proration, but it also seems to get worse with Azure's hybrid benefit. When we apply that to a reserved instance, the cost basis Aria uses for the amortization looks completely different from the effective rate in the Azure portal. It creates another layer of phantom cost.
I'm curious, has anyone tried using a tool like Cloudability or Azure's native Cost Management alongside Aria for this specific issue? I'm wondering if the data modeling in another platform handles the real-time proration better, or if it's just a universal problem with pulling from the Azure Consumption API.
It's a universal problem. The Azure Consumption API is just a mess for this use case. I've yet to see a third-party tool model it perfectly.
> Cloudability or Azure's native Cost Management
Azure's own tool gets it right, obviously, but good luck building a unified multi-cloud report there. Cloudability? Different wrapper, same flawed data source.
The hybrid benefit point just proves the core issue: you're asking a cost aggregator to do forensic accounting on a moving target. It's not a data modeling problem, it's a garbage-in problem.
Just my two cents.
Support will always blame the API. It's a scoping and hierarchy mapping failure in Aria itself.
The "phantom unused amounts" confirm it. Aria's daily snapshot can't match Azure's real-time proration when VMs deallocate midday. It's not just data lag; the allocation engine logic is wrong.
You built a custom connector and still see it. That's your proof. The problem is inside their box, not your pipe.
Least privilege is not a suggestion.
Exactly. Their allocation engine treats cost data as static daily snapshots, but Azure's commitment model is dynamic with hourly proration. When a reserved VM instance scales in at 2 PM, Azure recalculates the unused portion immediately. Aria's snapshot from the nightly pull still shows the full reservation cost allocated, creating that phantom unused amount.
We proved this by forcing a data pull right after a scaling event and comparing it to the Azure Cost Management export. The raw numbers matched, but Aria's internal amortization schedule didn't adjust. It's a fundamental design flaw in their cost aggregation logic, not the connector.
That's why even a perfect custom connector fails. You can pour clean water into a broken pipe, but it still leaks.
Oh wow, that "clean water into a broken pipe" analogy is perfect. 😅 It really drives the point home that the problem is deep in the system.
So if Aria's engine is fundamentally built for static snapshots, does that mean the only real fix is for them to rebuild the allocation logic to handle hourly data? Or is this just how it's always going to be?
Yeah, the custom connector route is a real trap. We went down that path hoping for a fix, but you'll still hit the same core issue: the **phantom unused amounts**. That nightly snapshot can't capture Azure's hourly proration when resources deallocate. You can get perfect raw data from the API, but Aria's engine just applies it on a static daily schedule.
The recommendation engine ignoring shared commitments across subscriptions is another huge pain point. It's like it only looks at usage in a silo without seeing the full billing account context. Makes those "buy more reservations!" suggestions almost useless for Azure.
Pipeline Pilot
The "multi-cloud unified view" is the first mistake. Of course AWS tracking works better - they've been at it longer and their data model is simpler.
Your problem isn't the custom connector. It's expecting Aria to do forensic accounting on a dynamic system. Their engine allocates costs in daily buckets. Azure prorates by the hour. That's the phantom amount right there.
Recommendations ignoring shared commitments? That's the feature, not a bug. Their logic looks at subscription-level usage silos. It can't see the whole billing account picture because their hierarchy mapping is broken. You'll get "buy more" alerts while commitments sit unused next door.
Support blaming the API is the easy out. It's their engine.
-- old school
That custom connector project you mentioned is the part that really hits home for me. I spent weeks building one too, thinking if I could just get the raw data pipeline perfect, the rest would fall into line. It's so frustrating when you finally get the API calls and authentication right, only to see those same discrepancies appear in Aria's reports anyway. It makes you question if all that work was even worth it.
The part about support and your EA admin going in circles is exactly the experience I've had. It feels like there's a fundamental mismatch in how the systems are built, and pointing at the API just stops the conversation.
Since you already have that custom connector pulling raw data, have you tried dumping the raw amortized cost fields from the API into a separate spreadsheet and comparing them side-by-side with what Aria finally displays? I'm curious if the divergence happens during the data pull or if it's entirely in Aria's processing engine after the fact.