OpenTelemetry Collector cost: sizing the pipeline that sits between everything

Quick answer

An OpenTelemetry Collector gateway handling 100 GB/day of logs plus 2 million metric series typically needs 3 to 4 c7g.xlarge instances, roughly $420 per month including a load balancer and cross-AZ transfer. DaemonSet agents add about 100 to 250 MB of memory and 0.1 to 0.3 vCPU per node, which on a 250-node cluster is roughly 50 GB of memory and 50 vCPU, about $600 per month of reserved capacity. That $1,000 per month pipeline routinely removes 40% to 70% of telemetry before it hits a per-GB meter, saving far more than it costs whenever ingestion pricing exceeds about $0.10 per GB.

The OpenTelemetry Collector is usually adopted for portability: one agent, many backends, no vendor instrumentation lock-in. The cost story is more interesting than the portability story. The collector is the only place in your telemetry path where you can drop, sample, aggregate, and reroute data before it crosses a billing boundary. That makes its cost a rounding error against what it enables.

What the collector itself costs

Deployment shape	Sizing	Monthly
Gateway tier (100 GB/day logs + 2M series)	3 x c7g.xlarge	$316
Load balancer in front	1 ALB + LCUs	~$45
Cross-AZ transfer	~3 TB/month each way	~$60
DaemonSet agents (250 nodes)	0.2 vCPU / 200 MB each	~$600 of reserved capacity
Tail-sampling buffer headroom	+8 GB per gateway pod	included above

The gateway tier is small: c7g.xlarge at $0.1445 per hour is $105.49 per month, so three is $316. A single collector instance with 4 vCPU comfortably handles 30,000 to 50,000 spans per second or several hundred megabytes per minute of logs with modest processing, so three instances is more about availability and headroom than throughput.

The DaemonSet line is the one people miss, because it does not appear as a separate bill. Every node reserving 0.2 vCPU and 200 MB for the agent reduces schedulable capacity, and on a 250-node cluster that is 50 vCPU and 50 GB withheld from workloads. Priced at roughly the marginal cost of the node type, call it $600 per month of capacity you are paying for and not using for applications. Agents configured with aggressive batching and no heavy processing can run at 0.1 vCPU and 100 MB, halving that.

What it saves

Now the other side. A collector pipeline with filter, transform, and sampling processors typically removes 40% to 70% of telemetry volume before it reaches a backend. On 100 GB/day of logs at CloudWatch's $0.50 per GB, a 55% reduction saves $825 per month. On Azure Monitor analytics logs at roughly $2.76 per GB the same reduction saves $4,554 per month. Against a $1,000 pipeline, the return is immediate.

Processor	What it removes	Typical reduction
filter	Health checks, known-benign lines	15% to 35%
transform (delete keys)	Unused attributes and headers	10% to 25%
probabilistic_sampler	Routine successful traces	90%+ of sampled stream
tail_sampling	Successful traces, keeps errors	95%+ with no error loss
metricstransform	Unused metric labels	Cuts series count directly
batch	Per-request overhead, enables compression	5% to 15% on wire

The metricstransform row is worth dwelling on, because it is the practical defense against cardinality explosion. Stripping a high-cardinality label at the collector means the backend never sees the series, which on per-series pricing is the difference between $720 and $44,500 per month. You do not need the application team to redeploy; you need one processor stanza.

Sizing rules that hold up

For throughput, budget roughly 1 vCPU per 10,000 spans per second with light processing, dropping to 1 vCPU per 5,000 spans per second with heavy transform or tail sampling. For logs, roughly 1 vCPU per 25 to 40 MB per second depending on parsing complexity; regex-heavy parsing is dramatically more expensive than JSON field access, sometimes by 5x.

For memory, the baseline is small, a few hundred MB, but tail sampling changes everything. Buffered memory is in-flight traces times average trace size times decision wait time. At 20,000 traces per second, 8 KB per trace, and a 10-second decision wait, that is 1.6 GB of live buffer, and you want two to three times that for safety. Set memory_limiter conservatively; a collector that OOMs drops telemetry silently during exactly the incident you needed it for.

The topology decision

Agent-only (DaemonSet exporting directly to backends) is cheapest in infrastructure and worst for control: no tail sampling, no centralized filtering, and every node holds backend credentials. Gateway-only (apps export directly to a central tier) skips the per-node overhead but loses node-level enrichment. The two-tier pattern, thin agents forwarding to a processing gateway, costs both lines but is the only shape that supports tail sampling and centralized policy.

Two-tier also adds a transfer cost people forget: telemetry crosses the network twice, and if agents and gateways sit in different availability zones you pay $0.01 per GB in each direction. At 3 TB per month that is $60, small, but route traffic to same-zone gateways with a topology-aware service where you can. If the gateway sits in another region or account, the charge jumps to $0.02 or $0.09 per GB and stops being small.

Making the trade visible

The collector is a rare case where spending more on infrastructure reliably reduces total cost, so the argument to make internally is the net. Present the gateway tier cost and the ingestion reduction together, not separately, or the infrastructure line looks like pure addition. Since the collector fleet, its load balancer, and its node capacity are all Terraform, price them from the plan against the resource catalog and put the pipeline cost next to the ingestion saving in the same pull request.

FAQ

How much does an OpenTelemetry Collector deployment cost?

A gateway tier handling 100 GB/day of logs and 2 million metric series typically runs three c7g.xlarge instances at $316 per month, plus about $45 for a load balancer and $60 for cross-AZ transfer. DaemonSet agents reserving 0.2 vCPU and 200 MB per node withhold roughly 50 vCPU and 50 GB on a 250-node cluster, about $600 per month of capacity. Total is around $1,000 per month.

Does the collector save more than it costs?

Almost always, wherever ingestion pricing exceeds about $0.10 per GB. Filter, transform, and sampling processors typically remove 40% to 70% of telemetry volume before it reaches a backend. A 55% reduction on 100 GB/day saves $825 per month at CloudWatch's $0.50 per GB and $4,554 per month at Azure Monitor's roughly $2.76 per GB, against a pipeline costing around $1,000.

How do I size an OpenTelemetry Collector?

Budget roughly 1 vCPU per 10,000 spans per second with light processing, dropping to 1 vCPU per 5,000 with heavy transform or tail sampling. For logs, about 1 vCPU per 25 to 40 MB per second, with regex-heavy parsing up to 5x more expensive than JSON field access. Memory baseline is a few hundred MB, but tail sampling needs in-flight traces times trace size times decision wait, then two to three times that for headroom.

Should I run agents, a gateway, or both?

Agent-only is cheapest but offers no tail sampling, no centralized filtering, and puts backend credentials on every node. Gateway-only avoids per-node overhead but loses node-level enrichment. The two-tier pattern of thin agents forwarding to a processing gateway costs both lines and is the only shape supporting tail sampling and centralized policy, which is usually worth it once ingestion costs are material.

Can the collector fix metric cardinality problems?

Yes, and it is often the fastest fix available. A metricstransform processor stripping a high-cardinality label means the backend never sees those series. On per-series pricing like CloudWatch custom metrics, that is the difference between a 2,400-series metric at $720 per month and a 600,000-series one at roughly $44,500. It takes one processor stanza rather than a coordinated application redeploy.

How does C3X help with telemetry pipeline cost?

The collector gateway fleet, its autoscaling group, the load balancer in front, and the node capacity consumed by DaemonSet agents are all Terraform resources. C3X prices them from the plan, so the pipeline cost appears in the same pull request as the architecture that reduces ingestion. That lets you present the net rather than having the infrastructure line reviewed in isolation as pure addition.

What to do next

Price the pipeline against what it saves. C3X reads your Terraform and prices collector fleets and load balancers against a live catalog. Start with the quickstart.