Agentless Kubernetes cost visibility: pricing clusters without installing anything

Quick answer

In-cluster cost agents scrape metrics to attribute spend after it happens, which is valuable but comes with real overhead: typically 0.8 to 3 vCPU and 3 to 11 GB for the collector, its time-series storage, and a per-node exporter, roughly $150 to $275 per month per cluster, plus RBAC, upgrades, and a data pipeline. An agentless approach reads node groups, disks, and load balancers from Terraform and prices them against a live catalog, giving you the cluster's cost before it is created, in the pull request. The two are complementary: agents tell you where money went across namespaces, Terraform-based pricing tells you what a change will cost before you pay for it.

There are two moments you can learn what a Kubernetes cluster costs. One is after the invoice, by measuring what ran. The other is before the apply, by pricing what is declared. Almost all Kubernetes cost tooling does the first, and the first is fundamentally a reporting exercise on money already spent.

What an in-cluster agent actually costs

Component	Typical resources	Monthly node cost
Cost collector pod	0.3 to 1 vCPU, 1 to 3 GB	$12 to $39
Time-series store	0.5 to 2 vCPU, 2 to 8 GB	$19 to $78
Persistent volume, 100 to 500 GB	gp3	$8 to $40
Metrics exporter DaemonSet	50m per node across 60 nodes	$117
Per cluster total	-	$156 to $274

On one cluster that is noise. Across a fleet of 20 clusters it is $3,100 to $5,500 per month, which is an awkward number for a tool whose job is finding savings. Add the operational cost: RBAC review, chart upgrades on every Kubernetes version bump, alerting when the collector falls behind, and storage retention decisions.

The timing problem

The deeper issue is not overhead, it is timing. An agent reports that last month's cluster cost $14,000 and that the checkout namespace used 22 percent of it. Useful. But the decisions that produced that $14,000 were made weeks earlier in pull requests: a node group's instance type, a StatefulSet's volume size, a Service set to type LoadBalancer, a GPU pool added for an experiment.

Moment	What you can know	What it costs to change
Pull request	Priced from declared config	A comment
After apply	Resources exist, billing started	A change and a deploy
Next invoice	Actual spend, attributed	A migration and a meeting

The cost of changing a decision rises by roughly an order of magnitude at each step. A GPU pool questioned in review costs nothing to remove. The same pool discovered on an invoice has already billed $2,200 and someone now depends on it.

What Terraform already knows

A surprising share of Kubernetes cost is fully determined by declarative config that lives in Terraform, before any pod schedules.

Cost line	Declared in Terraform?	Share of cluster bill
Control plane fee	Yes	2 to 8 percent
Node group instance type and size	Yes	60 to 85 percent
Node OS disks	Yes	2 to 5 percent
NAT gateways and load balancers	Yes	3 to 10 percent
Persistent volumes from StatefulSets	Partly, via Helm values	5 to 20 percent
Cross-AZ traffic	No, depends on runtime	2 to 8 percent

Between 70 and 90 percent of a cluster's bill is predictable from declared configuration. That is not a replacement for runtime attribution, but it means most of the money can be seen before it is spent, with no agent, no RBAC, and no collector pod.

It also covers the changes that cause the biggest jumps. Cluster bills rarely creep; they step. Someone doubles a node group's desired size for a launch, switches an instance family, adds a GPU pool, or turns on a second NAT gateway for a new subnet. Each of those is a single line in a Terraform plan and each moves the monthly total by hundreds or thousands of dollars. Reading the plan gives you the step change at the moment it is proposed, which no amount of after-the-fact metric scraping can do.

Where agentless falls short

Be honest about the limits. Terraform cannot tell you which namespace consumed the nodes, because that is a runtime property of scheduling. It cannot measure the gap between requested and used resources, which is the core of overprovisioning waste. It does not see cross-AZ chatter, which depends on traffic patterns. And it does not know that your HPA averaged 11 replicas instead of its 22 maximum.

So the honest architecture is both: Terraform-based pricing on every pull request to prevent expensive configuration from landing, and runtime measurement for allocation, showback, and right-sizing signals. They answer different questions and neither substitutes for the other.

A practical split

Question	Best answered by
What will this node group cost?	Terraform pricing, pre-merge
Should this Service be a LoadBalancer?	Terraform pricing, pre-merge
Which team used the cluster most?	Runtime metrics
Which pods over-request CPU?	Runtime metrics
What does a new cluster cost to stand up?	Terraform pricing
Where did last month's increase come from?	Runtime metrics plus git history

The pattern that works well for smaller fleets is agentless pricing everywhere plus lightweight runtime metrics only on production clusters, which cuts tooling overhead across dev and staging while keeping allocation where it matters. Price the cluster from Terraform against theresource catalog and pair it withruntime allocation where you need the split.

FAQ

Can I see Kubernetes costs without installing an agent?

Yes, for most of the bill. Between 70 and 90 percent of a cluster's cost, node group instance types and sizes, control plane fees, node disks, NAT gateways, and load balancers, is fully determined by configuration declared in Terraform. Pricing that configuration against a live catalog gives you the number before the cluster exists, with no collector pod, RBAC, or data pipeline.

How much overhead does a Kubernetes cost agent add?

Typically $156 to $274 per month per cluster: a collector pod at 0.3 to 1 vCPU, a time-series store at 0.5 to 2 vCPU and 2 to 8 GB, a 100 to 500 GB persistent volume, and a metrics exporter DaemonSet at roughly 50m per node. Across a fleet of 20 clusters that is $3,100 to $5,500 per month, plus RBAC review, chart upgrades, and retention management.

What can agentless Kubernetes cost tooling not tell you?

It cannot attribute spend to namespaces, since scheduling is a runtime property, and it cannot measure the gap between requested and used resources, which is the core of overprovisioning waste. It also does not see cross-AZ traffic, which depends on real traffic patterns, or what an HPA actually averaged versus its configured maximum.

Should I use both agentless and in-cluster Kubernetes cost tools?

Usually yes, because they answer different questions. Terraform-based pricing on every pull request prevents expensive configuration from landing, while runtime measurement handles allocation, showback, and right-sizing signals. A practical split for smaller fleets is agentless pricing everywhere plus runtime metrics only on production clusters.

Why does pre-deploy Kubernetes cost visibility matter?

Because the cost of changing a decision rises roughly an order of magnitude at each stage. A GPU node pool questioned in review costs nothing to remove. The same pool discovered on an invoice has already billed around $2,200 and now has dependents. Agents report spend after it happens, when the decisions that caused it were made weeks earlier in pull requests.

How does C3X provide agentless Kubernetes cost visibility?

C3X reads Terraform directly and prices node groups, disks, load balancers, NAT gateways, and control plane fees against a live catalog, producing a monthly estimate in the pull request. Nothing is installed in the cluster, there is no RBAC to grant and no collector to maintain, and the number arrives before the resources are created rather than after they bill.

What to do next

Price the cluster before it exists, with nothing installed in it. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.