How to monitor cloud spend per microservice

The fastest route to per-microservice cost visibility is enabling AWS CUR split cost allocation on your containers, or, if you need feature and tenant-level precision, adding request-level instrumentation with OpenTelemetry. Both work. Neither is optional forever, because most teams eventually need both. But if you're starting from account-level billing and nothing else, split cost allocation is the higher-confidence, lower-effort first move.

Here's the 24 to 48 hour version: turn on AWS Cost and Usage Report split cost allocation data for your EKS or ECS clusters, apply consistent labels to every namespace and workload, and load the resulting export into whatever warehouse or BI tool your finance team already trusts. That alone converts a single opaque compute line item into per-pod, per-task cost data you can slice by service.

Once that's running, three follow-on actions matter more than anything else:

• Enforce tagging and metadata rules at deploy time, not after the fact, so new services don't fall through the attribution gap.
• Build a dashboard that shows cost per service and cost per request trending week on week, not a static report.
• Set anomaly alerts on the accounts and namespaces that carry the biggest spend, so a bad deploy gets caught in hours rather than at month end.

Key Takeaways

Accurate per-microservice cost visibility comes from combining CUR-based billing attribution with telemetry, sequenced from quick tagging wins through to full request-level instrumentation.

Point	Details
Start with split allocation	Enable AWS CUR SCAD or equivalent for pod/task granularity before attempting request-level tracing.
Expect a CUR volume trade-off	Split allocation adds two to three new usage records per pod or task per hour, so budget for storage.
Sequence, don't leap	Quick wins (tags, budgets) in just a few weeks beat stalling on full instrumentation for months.
Build a control loop, not a report	Detect, evaluate, approve, apply, verify: continuous loops sustain savings that one-off reviews don't.
Koritsu AI closes the gap	Koritsu AI ingests CUR, split allocation and telemetry data, using AI agent Kori for continuous anomaly detection and success-fee engagements.

Why per-microservice cost visibility matters and typical failure modes

You can't optimise what you can't attribute. That sounds obvious until you look at how most organisations actually track cloud spend: one bill, one account, maybe a rough split by team if someone remembered to tag things correctly. Engineering teams end up debating architecture decisions with no idea which service is actually expensive to run.

Getting cost visibility down to the microservice level gives you three concrete things a consolidated bill never will. First, accurate chargeback or showback, so product teams see the real cost of what they own instead of an averaged number that hides the outliers. Second, a prioritised optimisation backlog, because you can rank services by spend and waste rather than guessing which one "feels" expensive. Third, genuine unit economics: cost per customer, cost per feature, cost per transaction, all of which finance teams need and most engineering teams can't currently produce.

The failure modes are depressingly consistent across companies of very different sizes:

• Account-level billing only — everything lands in one number, so a runaway service hides inside a total that still looks "normal".
• Missing or inconsistent tags — half your resources are tagged, half aren't, and the untagged half is usually where the waste lives.
• Shared platform costs — load balancers, shared databases, and logging pipelines get dumped into "infrastructure" with no path back to the services using them.
• Noisy, delayed metrics — by the time a report lands, the spike that caused it happened three weeks ago.

The AWS Well-Architected Framework's cost optimisation pillar recommends daily-granularity budgets and cost anomaly monitors attached to specific accounts and tags precisely because monthly, account-wide reviews catch problems too late to matter. Without that, the actual cost of not having microservice visibility isn't just a bigger bill. It's making architecture decisions blind, then finding out three months later that the "obviously right" choice was quietly the expensive one.

Three practical architectures for cost-per-microservice, and when to pick each

There isn't one correct architecture here. There are three, and the right one depends on how far you are along your Kubernetes maturity curve and how precise you actually need to be.

Architecture A: billing-driven attribution. This is CUR data plus consistent tags, rolled into a showback dashboard. Implementation effort is low: most teams can get a first version running in a couple of weeks using existing billing exports and a BI tool. Accuracy is coarser, because shared resources and untagged spend get lumped together or estimated. This is the right starting point for early-stage companies and any team that hasn't yet nailed tagging discipline. There is little point building anything more sophisticated on top of inconsistent tags.

Architecture B: container split allocation. Enabling AWS CUR SCAD (or the equivalent on other clouds) gives you pod and task-level granularity inside EKS or ECS clusters, which is a meaningful step up from account or service-level estimates. The trade-off is volume: as noted above, SCAD multiplies your CUR line items, so you need a pipeline that can handle the increase and a warehouse budget that accounts for it. AWS's own SCAD containers dashboard shows drilldowns by pod, namespace, controller and label, which is genuinely useful once it's running, but the setup is a project, not a toggle. This suits scale-up companies running meaningful Kubernetes workloads who need showback accuracy finance will actually trust.

Architecture C: telemetry and request-level instrumentation. This pairs OpenTelemetry traces with a cost-calculation layer that attributes spend to individual requests, features, or tenants. It's the only route that gives you exact per-feature or per-customer economics rather than an inferred estimate, and tools built on this pattern (Spendtrace, among others) expose per-request cost endpoints alongside aggregate service views. The cost is application-level change: every service needs consistent tracing, and that's a genuine engineering investment. This fits enterprises with mature platform teams, or any company whose product pricing genuinely depends on knowing the cost of an individual customer action.

Dimension	Architecture A (billing)	Architecture B (split allocation)	Architecture C (telemetry)
Granularity	Service / account	Pod / task	Request / feature / tenant
Accuracy	Inferred from tags	Amortised, exact per container	Exact, instrumented
Data freshness	Daily	Daily	Near real-time
Implementation effort	Low	Moderate to high	High
Cost model impact	Minimal	Higher CUR volume and storage	Engineering time, some collector overhead
Governance / chargeback	Basic showback	Showback and chargeback by namespace	Full chargeback by feature or customer

The rule of thumb: early-stage teams start with A, scale-ups running Kubernetes at any real size should move to B within their first year of container adoption, and enterprises with pricing or multi-tenant chargeback requirements should be building towards C, even if it's only instrumented on their five most expensive services first.

What KPIs and dashboards should you actually build?

Cost data that no one looks at is worthless. The dashboards matter as much as the underlying attribution method, because they're what turns a data pipeline into a decision-making tool.

The metrics worth tracking on a recurring basis:

• Cost per service — the headline number, tracked as a trend, not a single snapshot.
• Cost per request — essential once you have telemetry, and the number that actually connects to unit economics.
• CPU, GPU and RAM cost breakdown — separates compute waste from genuinely necessary spend.
• Shared cost allocation — how much of the bill is platform-level and how it's being distributed across consuming services.
• Waste rate — the gap between provisioned and actually used capacity.
• Variance versus forecast — how far actuals are drifting from what finance expected.
• Reserved and savings plan utilisation — whether committed spend is actually being used efficiently.

A workable dashboard layout mirrors the structure AWS's own SCAD containers dashboard uses: an executive summary tile view for leadership, a workload explorer for engineers to drill into specific services, a cluster breakdown for platform teams, and a labels and tags explorer for anyone auditing attribution accuracy. Each panel should support drilldown by namespace, pod, and controller, not just present a flat number.

Alerting is where most teams under-invest. The AWS Well-Architected Framework recommends daily-granularity budgets with anomaly monitors attached directly to accounts and tags, rather than a single monthly threshold that only fires after the damage is done. A sensible starting point: an anomaly alert on any service where daily spend deviates more than a set percentage from its trailing seven-day average, plus a hard budget alert per team or namespace that escalates automatically to the service owner, not a shared inbox nobody checks.

What's the fastest path from zero visibility to full attribution?

Sequencing matters more than perfection. Trying to build request-level instrumentation across forty services before you've even sorted your tags is how these projects stall for a year.

Quick wins, weeks zero to two:

1. Enforce consistent tags across all new deployments and backfill the highest-spend existing resources.
2. Enable basic budgets and cost anomaly detection on your top five accounts or namespaces by spend.
3. Export billing data to CUR, BigQuery, or Azure Cost Management, whichever matches your provider.

Medium term, weeks two to eight:

4. Enable split cost allocation for your Kubernetes clusters where it's available.
5. Integrate OpenTelemetry collectors to start gathering workload-level telemetry alongside billing data.
6. Build your first real dashboards and a monthly showback report for engineering leads.

Longer term, weeks eight to sixteen and beyond:

7. Add request-level instrumentation to the services where feature or tenant-level costing genuinely matters commercially.
8. Automate chargeback so cost gets attributed to owning teams without a manual reconciliation step.
9. Integrate cost checks into CI/CD so a pull request that meaningfully increases projected spend gets flagged before it merges.
10. Adopt a continuous control loop rather than periodic quarterly reviews.

Straightforward cleanup and right-sizing at the quick-wins stage commonly delivers savings in the 10 to 25% range without touching product scope. Sustaining that beyond the first pass needs the governance layer, not just the initial cleanup. Our guide on reducing cloud infrastructure costs covers the right-sizing side of this in more depth.

How do you choose the right tooling for the job?

Four broad categories cover most of what's on the market: self-hosted open-source platforms, SaaS cost-observability tools, in-house telemetry paired with a custom cost joiner, and consultancy or managed FinOps services. None is universally right. Each trades off control, accuracy, and engineering time differently.

Self-hosted, source-available projects like Cletrics can join usage metrics with pricing data to surface anomalies and forecasts without sending data outside your infrastructure, which matters if data residency or vendor lock-in are genuine concerns. The trade-off is that you own the operational burden of running and maintaining the platform yourself.

Before shortlisting anything, run through this checklist:

1. Does it ingest both CUR-style billing data and telemetry, or only one?
2. What's the actual data freshness, not the marketing claim?
3. Does it scale to your cluster size without the ingest cost becoming a line item of its own?
4. Does it offer role-based access and showback natively, or will you need to build that layer yourself?
5. Can it plug into your existing CI/CD and alerting stack without a custom integration project?

On pricing shapes, expect to see three common models: a percentage of managed cloud spend, a seat-plus-usage structure, or fixed tiered subscriptions. None is inherently better, but a percentage-of-spend model only makes commercial sense if the vendor is also finding savings, not just reporting a number you already had. For procurement, the sensible move is a scoped pilot on your two or three most expensive services rather than a full rollout, so you can validate accuracy before committing to a platform across your entire estate. Our cloud cost attribution guide for microservices covers attribution patterns in more depth if you're evaluating build-versus-buy.

How do you measure impact and keep control once it's built?

Visibility without a feedback loop just becomes a report nobody reads after the second month. Success needs to be measured against a real baseline, not a vague sense that things have improved.

Track these explicitly:

• Savings realised versus baseline — the actual delta, verified against billing, not projected.
• Waste rate improvement — has the gap between provisioned and used capacity actually shrunk?
• Forecast accuracy — is your predicted spend converging with actuals over time?
• Unit economics improvement — is cost per customer or per transaction trending the right way?

Governance needs owners, not just dashboards. A workable structure assigns a named owner per service or namespace, a monthly cadence for showback review, a quarterly cadence for architectural cost review, and a clear escalation path when a budget alert fires and nobody responds within a set window.

The continuous control loop is the mechanism that makes this durable rather than a one-off project. In practice, that loop looks like: detect an anomaly or budget breach, evaluate whether it's a genuine regression or expected growth, approve a fix if one's needed, apply it, then verify the change actually reduced spend without breaking anything. Wiring a cost check into your CI/CD pipeline, so a deployment that would meaningfully raise projected spend gets flagged before merge rather than discovered on next month's bill, is the single most effective way to make this loop run without needing a human to remember to check. Our cloud spending governance framework walks through the ownership and cadence side of this in more detail.

Multi-cloud and hybrid environments complicate this, because AWS CUR, Azure Cost Management, and GCP billing exports all use different schemas and different levels of container support. The workable pattern is to normalise each provider's export into a common internal schema, tagged consistently across clouds, before joining it with telemetry. Trying to build one dashboard directly on top of three raw billing formats is a maintenance burden that grows every time one provider changes its export structure.

How Koritsu AI turns attribution data into realised savings

Building the pipeline is only half the job. Someone still has to read the anomaly, work out whether it's a genuine architectural problem, and fix it, and that's where most in-house FinOps efforts stall out after the dashboard ships.

Koritsu AI's platform ingests CUR and split allocation data alongside OpenTelemetry and in-cluster metrics, so it's built on the same data sources this article has walked through, not a proprietary black box. Our AI agent, Kori, runs continuous anomaly detection across that combined dataset, flagging cost regressions and architectural inefficiencies as they happen rather than at month end. Where request-level attribution is worth the engineering investment, our specialists help teams scope and implement it rather than leaving that as a theoretical fourth architecture nobody gets round to.

A typical engagement starts with a free assessment of your current spend and attribution gaps. From there, a pilot targets your highest-spend services, with savings measured and verified against actual billing, not projected. Koritsu AI only takes a share of the savings it actually finds, so the incentive is aligned with getting attribution right, not just producing a report. Clients who want ongoing monitoring move to a subscription for continued platform access and FinOps support.

To get started:

1. Request a free assessment covering your highest-spend accounts or clusters.
2. Scope a pilot around two or three services where attribution is weakest today.
3. Let Kori run continuous anomaly detection while our team works the root-cause fixes.

What actually separates teams that get this right from teams that stall

Most advice on this topic treats tooling as the hard part. It isn't. The hard part is sequencing, and the conventional wisdom of "instrument everything, then build dashboards" gets that sequencing backwards.

Here's the uncomfortable truth: a lot of engineering teams jump straight to request-level instrumentation because it sounds like the "proper" way to do this, then stall for six months because instrumenting forty services consistently is a genuinely large piece of work with no visible payoff until it's finished. Meanwhile, the team next door turned on split cost allocation and fixed their tagging discipline in three weeks, and now has a usable showback report while the "proper" project is still in planning.

The judgement worth taking from all this: coarse, fast attribution beats precise, slow attribution almost every time, because a cost problem you can see today and fix imperfectly beats a perfect measurement of a problem you'll only see in six months. Start with CUR and tags. Add split allocation once your Kubernetes footprint justifies it. Reserve full request-level instrumentation for the handful of services where the business genuinely needs per-feature or per-tenant pricing, not as a blanket policy.

What's overrated is the idea that a single platform purchase solves this. Tooling gives you the data. It doesn't decide which anomaly is worth fixing or whether a service's architecture needs rethinking, and that judgement call is where most of the actual savings live. That's precisely why continuous, AI-assisted control loops matter more than static dashboards. A dashboard tells you what happened. A control loop with a human and an AI agent working together catches the regression while it's still cheap to fix, and that's the difference between a cost report and an actual reduction in your bill.

Get a free assessment of your microservice-level cloud spend

Koritsu AI is built for exactly the gap this article has covered: the space between having cost data and actually acting on it. Where most teams stop at a dashboard, Koritsu AI pairs continuous AI-driven monitoring, run by our agent Kori, with hands-on FinOps specialists who do the architectural root-cause work most in-house teams don't have spare capacity for.

You don't need to have finished your CUR or OpenTelemetry rollout before starting. The free assessment works from whatever billing and telemetry data you already have, identifies where the real inefficiencies sit, and scopes a pilot around your highest-spend services. Because engagements run on a success-fee basis. Initially, you're not paying for a report. You're paying for savings that are verified against your actual bill, and can move to an ongoing subscription once the initial engagement proves the model out. If you want to see what's actually driving your cloud bill at the microservice level, start with a free assessment and let Kori and our team find out.

Sources

You have more raw material than most teams realise. The question isn't whether the data exists. It's which combination gives you the accuracy you need for the effort you're willing to spend.

The core sources, roughly in order of how commonly teams already have them running:

• Cloud cost optimization: Principles that still matter
• AWS Well-Architected Framework — cost optimisation pillar

These map to three broad attribution techniques. Tag and account mapping is the cheapest: you rely on consistent labelling to roll billing data up by service or team. It's fast to set up and fragile in practice, because it's only as good as your least disciplined engineer's tagging habits. Amortised split allocation goes a level deeper for containers, distributing a shared node's cost across the pods or tasks running on it based on actual resource consumption. Telemetry-driven per-request costing is the most precise: it associates a dollar figure with an individual request or trace, which is genuinely useful for pricing decisions but requires instrumenting your application code rather than just reading billing exports.

Pro Tip: If you need confidence fast, start with CUR plus disciplined tag hygiene. It's the quickest path to a usable number. Save request-level instrumentation for the handful of services where feature or tenant-level pricing decisions actually depend on exact cost, because that route is genuinely more work.

Split cost allocation deserves a specific callout because the trade-off is easy to underestimate. Enabling it on a Kubernetes cluster creates two new usage records per pod or task per hour, three for accelerated instances, which on a large EKS cluster running GPU workloads can add tens of thousands of new line items per day. That's not a reason to avoid it. It's a reason to budget for the extra storage and processing your CUR pipeline will need once you turn it on.

Recommended

• Cloud spend per service: a guide for CTOs and finance teams | Koritsu Blog
• Cloud cost attribution for microservices: 2026 guide | Koritsu Blog
• Build an internal cloud cost dashboard: FinOps guide | Koritsu Blog
• Benefits of cloud observability for cost: 2026 guide | Koritsu Blog