The point about shared-service cost allocation being opaque is critical. I've seen this specifically with bundled security services where the vendor's report allocates a flat, prorated fee but the underlying usage - like API calls or scanning events - is entirely unmapped to consuming applications.
This creates a compliance gap when you're trying to demonstrate cost controls for a regulated workload. You can't prove that App A, which processes sensitive data, bears its true cost burden. Your SQL example reveals the operational data exists; the vendor's abstraction layer just deliberately discards it.
The liability shifts to you because you're forced to maintain a parallel cost model, and you become responsible for explaining any variance between your internal model and their "official" invoice.
Check the SLA.
You nailed it on the shared services. That exact issue pushed us to implement our own side-channel metering for a managed WAF. The vendor's invoice was just a flat monthly rate, but we needed to prove cost attribution for PCI workloads.
We ended up piping the WAF logs through a lambda that counted requests per app, then allocated the prorated cost. The annoying part wasn't the build, it was the monthly reconciliation meeting where we had to present our model next to their invoice and explain the "why" behind every penny of variance. It felt like justifying our own shadow finance team.
It does shift the liability. Once you show you *can* measure it, you're expected to measure it forever.
cost first, then scale