What a platform team's shared services actually cost

Quick answer

A platform team's shared services typically include cluster control planes, ingress and egress, observability, secrets management, artifact registries, CI runners, and the networking backbone, commonly totaling 3,000 to 15,000 dollars a month for a mid sized organization. Because no product team owns them, they escape review. Fix that by inventorying shared services, assigning each an owner and a driver metric, allocating cost back by that metric, and estimating the cost of platform changes in the pull request that makes them.

Ask a product team what their service costs and you will get an answer. Ask what the platform costs and you get a shrug, because the platform bill is spread across shared components that belong to everybody and therefore to nobody. That is where a surprising share of infrastructure spend sits.

Shared services are not waste. They exist precisely so that 30 teams do not each run their own logging stack. But shared cost that is never attributed is also never challenged, and that is how a mesh control plane or a log pipeline quietly becomes one of the top five line items on the invoice.

The shared services inventory

Shared service	Typical monthly cost	What drives it
Kubernetes control planes (4 clusters)	About 290 dollars	Cluster count
Ingress load balancers	About 100 to 400 dollars	Balancer count and capacity units
NAT gateways and egress	About 300 to 2,000 dollars	Per GB processed
Logging and metrics	About 1,000 to 6,000 dollars	Ingest volume and retention
CI runners	About 500 to 4,000 dollars	Build minutes and concurrency
Artifact and image registry	About 100 to 800 dollars	Stored GB and pull egress
Secrets management	About 50 to 500 dollars	Secret count and API calls
Service mesh and system pods	About 200 to 1,500 dollars	Sidecar CPU and memory

Add it up and a mid sized organization lands somewhere between 3,000 and 15,000 dollars a month before a single product workload runs. That is the number to carry into any conversation about whether the platform is worth it, and the answer is usually yes, because the alternative is 30 partial copies of the same stack.

Observability is almost always the largest line

In most inventories, logs and metrics beat compute. Log ingestion is billed per GB and grows with traffic, debug verbosity, and retention, all of which drift upward by default. A single chatty service in debug mode can add hundreds of dollars a month without anyone noticing, since the charge lands on the platform account.

The fixes are well known and rarely applied: drop health check and sidecar access logs at the collector, sample high volume traces, split retention so that 7 days is hot and the rest goes to object storage, and cardinality limit custom metrics. Attributing ingest volume by namespace is what makes any of it happen, because it turns a platform line item into a team conversation. Seeobservability cost optimization for the detail.

Every shared service needs an owner and a driver

For each item in the inventory, name a person accountable for its cost and a metric that should track it. Log spend tracks GB ingested. Registry spend tracks stored GB and pull volume. CI spend tracks build minutes. Mesh overhead tracks sidecar count.

The driver metric turns a flat number into a ratio you can defend. Ten thousand dollars a month of logging is alarming in isolation and reasonable at 40 terabytes ingested. Tracking dollars per unit rather than dollars also means growth is expected and only efficiency regressions are alarming, which is the core idea behindcloud unit economics.

Allocate back, even approximately

Shared cost that stays in a platform bucket never gets optimized by the teams generating it. Allocate it back, using the driver metric where you can measure it per team and an even or headcount based split where you cannot.

Precision is less important than direction. A team that sees 1,200 dollars a month of log ingest attributed to its namespace will turn off debug logging. A team that sees nothing will not. Start with showback rather than chargeback, since the goal is behavior, not accounting, and the approaches are compared inshowback versus chargeback.

Platform changes deserve cost review too

Platform teams review application pull requests for cost and often exempt their own. That is backwards, because platform changes multiply. Adding a sidecar to every pod, raising a collector's replica count, enabling a new managed service across all clusters, each is a decision whose cost is measured per team and then multiplied.

Since the platform is defined in Terraform, the estimate can be produced in the pull request. c3x prices the plan statically with no cloud credentials, so a change that adds a node pool or a second NAT gateway shows up as a monthly delta before merge. For a shared component, that delta is the organization's delta, which is exactly the kind of change that should never land silently.

Watch the idle floor

Shared services have a fixed cost that exists whether anyone uses them or not: control planes, always-on collectors, minimum node counts, reserved runner capacity. That floor is the price of availability, and it is worth measuring separately from the variable part.

If the floor is a large fraction of total platform spend, consolidation usually pays. Four clusters where two would do saves both control plane fees and the per cluster system pod overhead, which is often 0.5 to 1 vCPU per node. Platform teams that publish their floor, their variable cost, and their per unit ratios each quarter find the budget conversation gets much easier, because the spending stops being a mystery line and becomes a service with a price.

FAQ

What counts as a platform team's shared services?

Kubernetes control planes, ingress load balancers, NAT gateways and egress, logging and metrics pipelines, CI runners, artifact and container registries, secrets management, and service mesh or system pod overhead. For a mid sized organization these commonly total 3,000 to 15,000 dollars a month before any product workload runs, and because no product team owns them, they rarely get reviewed.

Which shared service usually costs the most?

Observability, in most inventories. Log ingestion is billed per GB and grows with traffic, debug verbosity, and retention, all of which drift upward by default. A single chatty service left in debug mode can add hundreds of dollars a month, and the charge lands on the platform account where nobody connects it to the service that caused it.

How should shared platform cost be allocated to teams?

Use a driver metric per service: log spend by GB ingested per namespace, registry by stored GB and pulls, CI by build minutes, mesh by sidecar count. Where per team measurement is not possible, use an even or headcount based split. Precision matters less than direction, because a team that sees 1,200 dollars of log ingest attributed to it will act, and a team that sees nothing will not.

Should platform teams cost review their own changes?

Yes, and more strictly than application changes, because platform changes multiply across every team. Adding a sidecar to every pod, raising a collector replica count, or enabling a managed service across all clusters is a per team cost multiplied by team count. The estimate belongs in the pull request, before the change reaches every consumer.

How does C3X help a platform team control shared cost?

C3X estimates cost from the Terraform plan statically with no cloud credentials, so platform repositories can price their own changes in CI. A pull request that adds a node pool, a second NAT gateway, or a new managed component shows a monthly delta before merge. For shared infrastructure that delta is the whole organization's delta, which makes it exactly the kind of change that should not land unmeasured.

What to do next

Put a number on your platform layer before it lands. C3X prices Terraform plans with no cloud credentials. Start with the quickstart.