Cloud cost attribution has improved substantially. Cloud providers can tell you which account, service, or resource generated a charge. FinOps platforms organize that spend by team, application, environment, or business unit. Kubernetes cost tools go further still, allocating shared cluster costs to namespaces, workloads, pods, and services.

But there’s still a gap between knowing where a cost was billed and knowing what in your application actually caused it. If your AWS bill says you spent $60,000 on RDS last month, an engineer can’t do much with that. Even knowing that $20,000 belongs to the checkout-service only gets you part of the way there. The question an engineer actually needs answered is what inside the checkout service is spending the money. That’s the problem Frugal is designed to solve.

How the major approaches compare

There are several strong products in this market, but they operate at different layers of the stack.

The distinction matters. Many platforms can answer which service an infrastructure cost should be assigned to. Frugal is designed to go one step further: which application behavior caused the cost, and what code should an engineer change?

From cloud cost allocation to application cost attribution

Most cloud cost management starts with the bill and works downward through infrastructure metadata, something like:

AWS Account → EC2 Cluster → Kubernetes Namespace → Workload → Microservice

Frugal combines that infrastructure view with application and source-code context, so the result looks closer to:

Cloud Bill → Cloud Service → Microservice → Application Behavior → Code

Today, Frugal can automatically attribute cloud costs to microservices across AI, databases, storage, logs, metrics, Lambdas, and Kubernetes. That creates a consolidated view of what an application actually costs, even when its spend is distributed across many underlying cloud services. A recommendations-service, for example, might consume Kubernetes compute, PostgreSQL, S3, Datadog logs, CloudWatch metrics, Lambda, and Anthropic, with those charges appearing in different places on the cloud bill. Frugal connects them back to the application responsible for generating the usage, this is the level the Cost-to-Code Explorer works at: from the bill, through the service, down into the specific code that spent the money.

Microservice attribution is only the beginning

Knowing the application is useful, but for optimization, engineers often need to go one level deeper: what inside the application is driving the cost? This is where Frugal differs most sharply from conventional cloud cost allocation. Depending on the type of service, Frugal can continue past the microservice into more granular application constructs:

AI → call site
Storage → call site
Database → query and call site
Logs → log pattern and originating application
Kubernetes → workload and microservice

A service costing $50,000 a month is a starting point, not an answer. Frugal’s job is explaining what inside that service accounts for the spend.

Call sites: connecting production cost directly to code

A call site is the location in application code where the application invokes a usage-billed service. This matters because a service-level number still leaves an engineer with an investigation ahead of them. Consider the difference between these two pieces of information:

We spend $42,000 per month on Anthropic.

versus:

This function is responsible for $21,000 per month of Anthropic spend.

The first tells you that you have a problem. The second tells an engineer where to start working.

Frugal’s Call Sites capability connects actual production usage and cost to the part of the source code responsible for generating it. Frugal identifies the relevant function and source file and combines that location with runtime cost and usage data. For AI calls, that can include model selection, token usage, request volume, caching behavior, batching, prompt characteristics, and other variables that affect cost.

This lets engineers answer questions like which AI functions account for most of the token spend, which storage operations are generating millions of paid requests, which database queries account for most database load, which log statements or patterns are generating disproportionate ingestion cost, and which parts of the application are worth optimizing first.

Frugal’s Call Sites implementation is described in more detail in Frugal Adds Call Sites.

Database attribution: from RDS bill to query

Databases illustrate the difference especially well. Traditional cloud cost tooling might show RDS at $80,000/month. Better allocation gets you to recommendations-service at $21,000/month of that. Frugal continues further by examining the database workload itself: a particular query may account for a large share of the load on one or more database instances, and Frugal can connect that query back to the code issuing it and estimate the cost associated with that workload.

In Frugal’s own Call Sites example, Frugal identifies a PostgreSQL query from the source, then matches its measured query load against the underlying database instances to attribute cost back to that query and call site. That turns a vague complaint, the database is expensive, into something an engineer can act on: this query is responsible for a large share of database load, here is the code executing it, and here is the fix.

Log attribution: from ingestion bill to log pattern

Logs create a similar problem. A cloud bill might say Logging: $100,000/month. A service-level cost allocation system may get you to payments-service: $17,000/month, but that still doesn’t tell an engineer what to change. Frugal can analyze the actual logging behavior and identify expensive log patterns, letting the cost investigation progress from logging provider, to application, to log pattern:

logging provider → application → log pattern

At that level, a high-volume debug message, an oversized payload, or a repeated application event is a specific engineering fix: a classic Cost Trap you can see and act on.

Why Kubernetes tools stop at a different layer

OpenCost, Kubecost, and Cloudability Advanced Containers are particularly strong at Kubernetes cost allocation. Cloudability Advanced Containers, for example, supports allocation across dimensions including namespace, label, annotation, controller, and service, exactly what platform and FinOps teams need to answer questions like how much a namespace costs, which workload is responsible for cluster spend, or how much infrastructure should be charged back to a given team.

But Kubernetes represents only part of an application’s cost. A microservice running in a relatively inexpensive pod can still generate enormous database, AI, storage, logging, or other consumption outside the Kubernetes cluster entirely. Kubernetes cost allocation and application cost attribution solve different problems: one tells you what the cluster costs, the other tells you what the application costs, and a team usually needs both.

Datadog gets particularly close at the microservice level

Datadog is worth distinguishing from purely billing-oriented tools because it already has rich infrastructure and application telemetry. Datadog Cloud Cost Management automatically allocates cloud cluster costs to services and workloads, joining cloud provider cost data with Kubernetes or ECS resource usage and enriching the result with tags from pods, nodes, containers, and tasks. That’s genuine automatic cost attribution at the workload and service layer.

The difference is what happens next. Datadog is built around observability and infrastructure operations. Frugal is built around the economics of application code, specifically: what is this software costing us, why is it costing that much, and what should an engineer change to make it cheaper?

CloudZero and the distinction between dimensions and causality

CloudZero takes a different approach. Its strength is organizing spend into useful business and engineering dimensions such as application, product, feature, team, customer, or unit metric, producing views like cost per customer, cost per transaction, or cost per feature. That answers an important economic question: who or what should we associate this spend with?

Frugal is focused on a different question: what software behavior actually caused the spend? The difference is subtle but important. Cost dimensions are extremely useful for reporting, planning, showback, and unit economics. But if a developer is trying to reduce a cloud bill, causality is what matters.

Allocation versus attribution

We think there’s a useful distinction between two concepts:

Cost allocation: who should this cost belong to?
Application cost attribution: what caused this cost?

Those answers may be the same, but often they aren’t. An organization might allocate an entire RDS instance to the Payments team because that team owns it, but 70% of its database load might actually come from one inefficient query generated by a completely different microservice. The accounting answer is still Payments. The engineering answer is the query, and from an optimization perspective, the engineering answer is usually the one you need: it tells you what to change.

The hierarchy of cloud cost visibility

One way to understand the market is as a progression of increasingly granular attribution:

Organization
↓
Account
↓
Cloud resource
↓
Kubernetes workload
↓
Microservice
↓
Feature or operation
↓
Query / log pattern
↓
Call site

Each level answers a progressively more actionable question: at the top, where are we spending money; further down, which application is spending it; and eventually, which code should an engineer change. Traditional FinOps products have historically been strongest in the upper layers. Kubernetes cost tools pushed attribution significantly further toward workloads and services. Frugal is extending that model into the application itself, which is what the Cost-to-Code Explorer is built to do end to end.

Why code-level attribution matters more now

This capability becomes increasingly important as more cloud costs are directly controlled by application behavior. Consider AI: changing infrastructure configuration isn’t necessarily going to reduce the bill. Changing this might:

response = client.messages.create(

model="claude-opus-4-8",

max_tokens=8000,

messages=history

)

Perhaps the application is using the wrong model. Perhaps 80% of the context is unnecessary. Perhaps identical prompts aren’t being cached. Perhaps an operation runs ten times when it should run once. Perhaps the feature itself costs more to operate than the value it provides.

The same dynamic exists elsewhere. A database bill can be driven by one pathological query. A logging bill can be driven by one noisy log pattern. A storage bill can be driven by millions of unnecessary operations. A metrics bill can be driven by one high-cardinality dimension. Each one is a software engineering problem, a Cost Trap, expressed in dollars.

From cost report to engineering action

This is the larger change we believe needs to happen in cloud cost management. A cost system shouldn’t stop at RDS: $87,000/month, and it shouldn’t even stop at Recommendations Service: $22,000/month. When possible, it should continue:

getRecommendations() is responsible for this query.
The query represents 38% of database load.
It is executed millions of times per month.
Here is the code.
Here is the fix.

That’s the level at which cloud cost becomes an engineering signal instead of a finance report.

Cloud cost allocation tells you where the money went. Frugal connects the money back to the software that spent it.

If your team is stuck comparing dashboards that all stop at the same layer, book a demo and we’ll show you what a Frugal Fix looks like against your own bill.

FAQ

How is Frugal different from tools like Datadog, CloudZero, or Kubecost?

Those platforms are strong at allocating cost by service, team, or Kubernetes dimension. Frugal goes one layer deeper, attributing spend to the specific function, query, or call site in your source code that generated it, then proposing a fix.

What is a call site?

A call site is the location in application code where a usage-billed service gets invoked: the function or query responsible for the spend, not just the service it runs under.

Does Frugal replace tools like Kubecost or Datadog Cloud Cost Management?

Not usually. Kubernetes cost tools and Frugal solve different problems. Kubernetes tools tell you what a cluster or workload costs. Frugal tells you what the application itself costs and which code to change. Many teams run both.

What kinds of services can Frugal attribute cost to?

AI APIs, databases, storage, logs, metrics, Lambdas, and Kubernetes workloads, connecting each back to the specific call site responsible through the Cost-to-Code Explorer.