FinOps · Client: MYRIX Azure Lab (own subscription)

Cloud Cost Intelligence on a Real Azure Environment: Finding Where the Money Goes

Built a FinOps pipeline (ingestion, normalization, allocation, optimization) and pointed it at the real billing data of a running Azure hub-spoke environment instead of sample data. It showed where the money actually goes (one always-on service was over half of lifetime spend) and exposed a tagging gap that would have made any cost report look more complete than it was.

Challenge

Most cloud cost diagrams look the same: ingest billing data, normalize it, allocate it, find savings, show a dashboard. What rarely gets shown is what that pipeline produces against a real, running environment instead of a sample file. The target here was a real Azure resource group, the MYRIX hub-spoke network (VNets, Bastion, Load Balancer, a VM and a container registry), which was genuinely running and genuinely accruing cost. Two questions drove the work: where does the money actually go, and how much of it can be attributed to an owner? A cost report that silently drops untagged spend looks complete when it is not, so the allocation gap had to be measured, not hidden.

Solution

I built each layer of the pipeline and ran it against the live resource group: 1. **Real ingestion, no extra credentials.** Called the Cost Management Query API through az rest, reusing the authenticated Azure CLI session. This keeps it a CLI tool run by an authenticated person or CI job, not a browser dashboard with its own credentials, and that tradeoff is documented. 2. **Designed around a real operational limit.** Repeated calls returned HTTP 429 Too Many Requests, an undocumented per-subscription rate limit of roughly one successful query every several minutes. That is why the dashboard reads a pre-generated snapshot instead of calling the API live. 3. **One normalized record shape.** Billing columns were mapped into a single record type, so the analysis does not depend on one provider's column names. 4. **Measured the allocation gap honestly.** Before the project, zero resources in the group carried cost-allocation tags. I applied team, product, environment and workload tags to the resource group and its biggest cost drivers. The first snapshot, taken minutes later, still showed 100% unallocated, because Azure billing data lags behind newly applied tags. The report shows that number as it is rather than faking a fully tagged result. 5. **Optimization checks for always-on cost.** The checks look for services that bill a fixed hourly rate regardless of use. 6. **Cross-checked with an independent tool.** I re-ran the analysis from a fresh clone using a second, separate cost-analysis tool that loads the billing export into DuckDB. Its bundled zero-utilization policy flagged the same pattern on its own, with 215 billing rows processed.

Impact

The analysis found where the money actually goes. Across the resource group's full lifetime the total was $50.50, and Azure Bastion alone accounted for $26.02 of it, 52% of everything spent. Daily spend climbed from $0.66 per day in the first ten days to a peak of $10.39 per day as more services came online. A single-day snapshot earlier in the project put Bastion at about $2.51 per day, roughly $75 per month for a jump host in a lab, and 75% of that day's spend. That is a common FinOps pattern: a fixed-rate service that costs more than the workload it protects. Two separate methods, a hand-built check and an independent tool, found it. The environment is a lab with small spend, and no savings were realised or claimed here. The value is the method and the findings: real billing data, an explicit unallocated-spend number, and a result that two independent checks agree on. The same approach applies unchanged to a larger bill.