5 Reasons Your Cloud & AI Costs Are Higher Than They Should Be

Every major FinOps platform — CloudHealth, Apptio, Azure Cost Management, AWS Cost Explorer — works from billing data. This is the fundamental constraint that almost nobody in the FinOps industry discusses openly, because it applies to all of them equally.

Cloud billing data arrives with a lag — typically hours to several days. By the time it reaches your FinOps dashboard, it has already been paid for. The engineers who made the decisions that created those costs have moved on to other things.

Your FinOps review meetings are retrospective by definition. You identify orphaned resources that have been running for three weeks. You flag regional decisions that could have been more cost-efficient if anyone had known the cost at the point of decision. Then you document the finding and try to catch the same pattern next month.

This isn't a failure of FinOps practice. It's a timing problem built into the architecture of billing-based cost management.

Every time an engineer selects a region, chooses an instance type, or spins up a resource, they are making a financial decision. In most organisations, they have no financial context when they make it.

Engineers are given technical feedback — performance metrics, reliability data, latency measurements. They are rarely given cost feedback at the point of the decision, because the tools that produce cost data work from billing data that arrives later.

FinOps teams try to close this gap with showback reports and chargeback mechanisms — communicating cost information to engineering teams after the fact. This changes awareness over time. It doesn't change the decision that was already made.

Most FinOps tools take billing data as given and work to optimise within it. Very few can identify errors in the billing itself — because they're working from the same billing data that may contain the error.

For most engineering organisations, cloud infrastructure cost management has matured significantly over the last five years. AI developer tool spend is a different problem entirely — and most organisations don't yet have the governance infrastructure to manage it.

Claude Code, Cursor, GitHub Copilot, OpenAI Codex, and the expanding ecosystem of AI-assisted development tools are typically adopted at team or individual level — often without central procurement, often on personal payment methods expensed back, almost never with usage-based visibility at engineering management or finance level.

In most enterprises, FinOps sits in or adjacent to finance — producing cost reports, managing showback/chargeback, and attending engineering planning meetings as an external stakeholder.

This creates a structural gap between the function that produces cost visibility and the function that makes cost-impactful decisions. Engineers receive cost information from a team they didn't build, in a cadence that doesn't match their sprint cycles, in a format that doesn't integrate with their tooling.

The most cost-efficient engineering organisations have solved this by embedding cost governance into engineering workflows. Cost context appears in the tools engineers already use. Recommendations are actionable from the point of delivery — a Slack message with a one-click fix, not a report with a ticket to create. Ownership is assigned at the resource level so every cost has an identifiable engineer or team responsible for it.

This is partly an organisational design problem. But the technology choice enables or prevents the design. A FinOps tool that only outputs reports cannot be embedded in engineering workflows. A tool that monitors resources in real time and delivers recommendations in Slack or Teams can be.