How Hexagon Built Its Own “AI Powered” FinOps Tool with AWS

Allocating Cloud Spend Across a Complex Organization

As Hexagon’s multi-cloud footprint grew, so did the operational complexity of allocating costs across the business. With hundreds of cloud accounts spread across many decentralised teams, matching spend to the right owners took increasing effort at scale.

Finance needed a consistent way to cross-charge costs to the right teams and business units. Executives needed a unified view across the whole organization.

The underlying billing records were complete. The challenge was turning provider-specific data into a single allocation model that reflected how Hexagon is organized.

Hexagon evaluated commercial FinOps tools. Some were excellent products. But all of them shared a common limitation: they were built around a generic organizational model, and Hexagon is not a generic organization. Getting any of them to reflect how costs actually flow through Hexagon’s division to business unit to budget owner hierarchy required so much custom configuration that Hexagon would have ended up owning complexity in someone else’s platform rather than our own. The licensing cost, for the level of flexibility Hexagon needed, was hard to justify. So Hexagon built its own FinOps tool. Here’s what they learned, and where they are headed.

What Hexagon Built: AutoCFM

AutoCFM (short for Automated Cloud Financial Management) started as a chargeback script. An AWS Lambda function, a few Amazon Athena queries, a CSV file sent to finance every month. It worked, and teams found it useful, adoption grew and so did the tool.

Three years and many iterations later, it is a full FinOps platform: multi-cloud cost ingestion, interactive dashboards for executives and account owners, waste optimization, Generative AI spend and usage tracking, and a conversational AI agent that answers questions about the data in plain language. It runs entirely on AWS, uses only managed services, and the operational cost is a small fraction of what any commercial alternative would have charged in licensing alone.

AutoCFM sign-in page with Hexagon single sign-on on a demo environment. DEMO – All data shown is synthetic.

The Foundation: Getting the Data Model Right

Before writing a single line of application code, Hexagon spent time on the data model. This turned out to be the most important decision Hexagon made.

Cloud billing data from AWS, Azure, and GCP looks completely different at the source. Different field names, different granularities, different concepts of what a “cost” means. Hexagon aligned our internal model with the FinOps Open Cost and Usage Specification (FOCUS), a vendor-neutral schema that normalizes billing data across providers. Every provider’s data gets transformed into this common format before it touches anything downstream.

On top of FOCUS, Hexagon layered its own organizational hierarchy: entity > division > business unit > AWS account. Each cloud account or subscription gets mapped to a node in this tree, enriched with metadata like cost center, owner email, team, and project. This mapping lives in a dedicated accounts table that every billing query joins against.

The result is a data lake in Amazon S3 (Parquet format, partitioned by provider and billing period), queryable through Amazon Athena. Everything in AutoCFM (dashboards, reports, the AI agent) reads from the same Athena views. There is one source of truth.

Hexagon went through the same exercise for generative AI providers. Usage and spend data from Anthropic, Kiro, Azure, OpenAI, and Amazon Bedrock each have their own shapes and concepts, so Hexagon built a normalized generative AI data model alongside the cloud billing one. Both live in the same data lake, follow the same organizational hierarchy, and are queryable through the same Athena views. The approach that worked for cloud billing translated directly to generative AI.

The Architecture: Serverless, End to End

The platform is split into two logical layers: data and presentation. Both run entirely on managed AWS services.

AutoCFM architecture diagram. How AWS, Microsoft Azure, and Google Cloud billing data reaches the AutoCFM dashboards in AWS.

Data layer. AWS Step Functions state machines orchestrate the billing pipeline. Each cloud provider has its own ingestion path: AWS Cost and Usage Reports (CUR) replicated via Amazon S3, Azure and GCP billing exports pulled by AWS Lambda functions, generative AI provider APIs polled for usage data. AWS Lambda handles the transformation, normalizing fields, joining organizational metadata, and calculating derived metrics like waste and savings. Processed data lands in Amazon S3 as Parquet, partitioned for efficient querying. Amazon Athena provides the SQL engine on top, with views that pre-aggregate the data into the shapes the dashboards need.

Presentation layer. A Node.js application (Hono – Web framework built on Web Standards) running on Amazon ECS with AWS Fargate serves as the front door. Users authenticate via Microsoft Entra ID SSO. The application embeds Amazon Quick Sight dashboards directly in the UI, scoped to each user’s role using Amazon Quick’s row-level security. Data access is enforced through Quick Sight row-level security (RLS). Rather than building a separate dashboard per audience, Hexagon maintain one set of dashboards backed by a permissions dataset that maps each authenticated user to the data they are entitled to see.

The entire stack is pay-per-use. No servers to manage, no clusters to scale. As data volume has grown, the platform has scaled with it, without any infrastructure changes.

Two Personas, One Platform

AutoCFM serves two distinct audiences, and the product experience is different for each.

C-level executives get a strategic view. Spend by division, by provider, by quarter. Year-over-year comparisons. Savings performance and forecast accuracy. Generative AI adoption across the organization: which providers, which teams, how much. The dashboards are designed for exploration, letting you filter by division, drill into a business unit, and compare quarters. The data speaks for itself.

Cloud Financials executive dashboard showing spend overview and trends across the organization. DEMO – All data shown is synthetic.

Account owners and budget owners get a practical view. Their dashboards focus on the accounts they are responsible for: spend trends, charge category breakdowns, waste recommendations, and savings rate. They also receive a monthly showback email with a personalized cost summary, discount breakdown, and a CSV attachment for further analysis.

The separation matters. Executives do not want to see individual account details. Account owners do not want an organization-wide summary. Giving each group exactly what they need, through the same underlying data model, is what makes the platform useful rather than just comprehensive.

Cloud Spend user dashboard showing charge category distribution and marketplace spend year to date. DEMO – All data shown is synthetic.

Tracking Generative AI Spend: A Newer Challenge

As generative AI adoption accelerated across Hexagon, a new problem appeared. Teams were spinning up Anthropic workspaces, Kiro subscriptions, Azure, OpenAI deployments, and Amazon Bedrock usage, and there was no consolidated view of what it all cost or who was using it. AutoCFM extended its data model to cover generative AI providers using the same architecture as cloud billing: provider-specific Lambda collectors, a normalized data model, Amazon Athena views, and Amazon Quick Sight dashboards. The dashboard show cost and usage side by side, not just what was spent but how the tools are actually being used: active users, conversations, messages, code actions.

This distinction matters for chargeback. A license fee is easy to allocate. But when usage varies significantly between teams, per-seat billing misrepresents the actual consumption. AutoCFM tracks both.

Generative AI Insights executive dashboard showing spend and usage across AI providers. DEMO – All data shown is synthetic.

The AI Agent: From Dashboards to Conversations

Dashboards answer the questions you know to ask. They do not help when you are not sure where to look, or when you need a quick number without navigating to the right filter combination. That gap is what the AutoCFM conversational agent addresses.

The agent is embedded directly in the platform as a persistent side panel, visible alongside the generative AI dashboards. It is powered by Anthropic Claude Sonnet on Amazon Bedrock, using the Converse API with streaming and tool use. When a user asks a question, the agent generates a SQL query, executes it against the Athena data lake, and formulates a precise response in plain language. The same data that powers the dashboards powers the agent. There is no separate data store, no RAG index, no approximation. Just SQL against the source of truth.

Responses stream in real time via Server-Sent Events. Users see a “Querying generative AI data…” indicator while Athena runs, then watch the answer appear token by token. Multi-turn conversations work naturally. Ask a follow-up, refine a date range, drill into a specific team, and the context carries through.

The AutoCFM conversational agent answering questions about generative AI alongside the dashboard. DEMO – All data shown is synthetic.

What Hexagon Learned

Your cost allocation model is the product. The technology (AWS Lambda, Amazon Athena, Amazon Quick Sight, Amazon Bedrock) is commoditized. The hard part is modeling how costs flow through your organization. Every design decision downstream follows from getting that right.

Showback builds awareness. Chargeback drives change. When teams can see their cloud spend, some of them optimize voluntarily. When costs are formally cross-charged to their budget, everyone optimizes. Both matter, but chargeback is where behavior actually changes.

Build what makes you unique. Delegate everything else. AutoCFM’s value is in its business logic: the allocation model, the organizational hierarchy, the metrics, the AI agent’s understanding of Hexagon’s data. Every generic problem (storage, querying, authentication, dashboarding, inference) is solved by an AWS managed service. This keeps the codebase focused and the operational overhead low.

Iterating on a live system is faster than designing the perfect system. AutoCFM started as a script. It grew because teams found it useful and asked for more. The architecture today reflects what was actually needed, not what was anticipated. Starting small and shipping early was the right call.

Where This Goes Next

AutoCFM is a working product, but the roadmap is longer than what has been built. On the data side, the model will expand to cover unit economics, connecting cloud spend to business outcomes rather than just billing periods. On the AI side, the agent is moving from answering questions to taking actions: orchestrating billing pipelines, preparing chargeback files, distributing showback reports, all through natural language, with humans in the loop for review. The goal is a platform where AI handles the routine and humans focus on decisions. Not because AI is a trend, but because the routine work (running billing pipelines, generating reports, enforcing allocation rules) is exactly the kind of repeatable, structured task that agents handle well. The insight layer already exists. The action layer is next.

Want to build something similar?

Start with the data model, not the dashboards. Normalize your billing data with the FOCUS specification, map it into your own organizational hierarchy, and compose the platform from managed services: Amazon Athena over Amazon S3 data lake for querying, AWS Step Functions and AWS Lambda for ingestion, Amazon Quick Sight with row-level security for the dashboards, and Amazon Bedrock for the conversational agent. Begin with one provider and a single monthly chargeback report, prove the allocation model, then expand from there, the same path AutoCFM followed.

To learn more, explore the AWS Cloud Financial Management resources and the FinOps Foundation, alongside the Amazon Athena, Amazon Quick Sight, AWS Step Functions, and Amazon Bedrock documentation.

AutoCFM is an internal Hexagon platform built on AWS. The architecture described in this post reflects the production system as of mid-2026.