What Container Insights costs on EKS (2026)

Container Insights has three pricing models on EKS, and they are not ordered the way the feature names suggest. The mode with fewer metrics can cost twice as much as the mode with more, and the newest mode is cheaper than both. All three numbers come from worked examples on one AWS page, which is the only place the comparison exists.

How much does Container Insights cost on EKS?

With enhanced observability, it is priced per observation. The CloudWatch pricing page works a whole cluster: "assume a set-up where you monitor 1 cluster with 10 nodes, 1 namespace, 5 unique service names, 16 workloads, 20 pods, and 20 containers and the data points are reported for the entire month." The result:

"Your monthly Container Insights bill = 246,412,800 * $0.21 / 1M Observations = $51.75"

About fifty dollars a month for a ten-node cluster, before any of your own application logs. Two hundred and forty-six million data points to describe twenty pods is the number worth sitting with, because it explains why the cost scales the way it does.

What is an observation in Container Insights pricing?

A single data point at a single timestamp. AWS defines it as unifying two meters into one: "an observation corresponds to a data point ingested at a single timestamp and unifies the two price dimensions of metric storage and logs ingestion – which is used to ingest performance metrics – into one. Logs storage is charged separately."

The page then publishes the rates per component per minute, which is the part that lets you forecast rather than guess:

"Every cluster reports 1,720 observations; every node reports 68 observations; every namespace reports 2 observations; every service reports 2 observations; every workload reports 7 observations; every pod reports 138 observations and every container reports 21 observations per minute on average."

Pods are the driver, at 138 observations a minute each. Nodes are almost irrelevant by comparison, at 68. That inverts the usual mental model for cluster cost, where nodes are what you pay for: on this meter, packing more pods onto fewer nodes makes monitoring more expensive, not less.

The rate is tiered above a billion: "once you exceed 1B observations per month then volume pricing tiers will apply respectively." The example cluster is at a quarter of that, so a forty-node cluster of similar density is where the tiers start to matter.

Why can Container Insights without enhanced observability cost more?

Because the older mode bills as custom metrics, and custom metrics are $0.30 each. The Container Insights documentation states the difference plainly: "with the original version of Container Insights, metrics collected and logs ingested are charged as custom metrics. With Container Insights with enhanced observability for Amazon EKS, Container Insights metrics and logs are charged per observation instead of being charged per metric stored or log ingested."

AWS works the same cluster through the old model: "if you are monitoring 1 container cluster with 10 nodes or Amazon EC2 instances, 20 pods, 5 unique service names, and 1 namespace", the metric count is "24 + (10 * 8) + (20 * 9 * 1) + (5 * 6 * 1) + (1 * 6) = 320 CloudWatch metrics", which prices as "monthly CloudWatch metrics costs = $0.30 per metric for first 10,000 metrics * 320 metrics = $96". Logs add "$0.50 per GB of ingested logs * 11.45 GB of performance events as CloudWatch Logs = $5.73 per month", for a "monthly CloudWatch costs = $96 + $5.73 = $101.73 per month".

The mode that collects less costs twice as much. Nothing on the page says so, because the two numbers sit in different sub-examples of the same section and are never put side by side. It happens because the old model's cost is driven by distinct metric names rather than by data volume, and 320 metrics at $0.30 is $96 before a single byte of log.

There is a corollary worth knowing before you go looking for savings by turning enhanced observability off: doing that on a small cluster will probably raise the bill.

What does OTel Container Insights cost instead?

A flat per-GB ingestion charge with nothing else attached. OTel Container Insights is billed so that "ingestion is charged at $0.08 per GB with no separate charges for API calls, storage, or metric series count." AWS's example: "monthly OTel ingestion = 15 GB/day × 30 days = 450 GB/month Monthly Container Insights OTel charges = 450 GB × $0.08/GB = $36.00 per month", for "1 EKS cluster with 50 nodes, 200 pods, and 200 containers".

AWS then compares the two directly: "by comparison, the same cluster under observation-based Container Insights pricing (Example 18) would cost approximately $51.75/month at 246M observations."

That comparison does not hold up, and the gap runs in AWS's favour rather than against it. Example 18 is a 10-node, 20-pod cluster. The OTel example is a 50-node, 200-pod cluster. Using AWS's own per-component observation rates on the larger shape gives [1,720 + (50 × 68) + 2 + 10 + 112 + (200 × 138) + (200 × 21)] = 37,044 observations a minute, or about 1.6 billion a month. At the first-tier rate that is roughly $336, not $51.75. The volume tiers above a billion would pull it down somewhat, and AWS does not publish those tiers in prose, so treat $336 as an upper bound. Either way the honest comparison for that cluster is $36 against something in the hundreds, not against fifty.

We have not migrated our own tooling to the OTel collector, so this is arithmetic on AWS's published rates rather than a measured bill. Check it against your own cluster before switching, because the OTel meter is data volume and yours depends on label cardinality in a way the observation model does not.

Does Container Insights charge for container logs too?

Yes, separately, and with a surcharge per line. In every one of AWS's Container Insights examples the same sentence appears: "all container logs are collected by default. Container Insights adds 700 bytes per log line for the metadata required to enable filtering. Container logs will continue to be charged based on standard CloudWatch logs ingestion and logs storage pricing."

700 bytes per line is not a rounding error for application logs. A service writing structured JSON lines of 300 bytes each is billed on 1,000 bytes, which is more than triple. A chatty pod emitting a million lines a day adds 700 MB a day of pure metadata across the cluster.

That charge lands under CloudWatch Logs, not under Container Insights, which is why it survives a review of Container Insights spend. The levers on it are the ones in what CloudWatch Logs actually cost: retention, and the Infrequent Access log class, which halves ingestion at the price of losing metric filters.

One deliberate saving is already applied for you: "to help you manage your Container Insights costs, CloudWatch does not automatically create all possible metrics from the log data. However, you can view additional metrics and additional levels of granularity by using CloudWatch Logs Insights to analyze the raw performance log events." Those ad hoc queries are billed per GB scanned.

How do you turn Container Insights off on an EKS cluster?

It is opt-in per cluster, and AWS describes enhanced observability the same way: it "enables you to opt-in at the cluster level to collect container-level EKS performance metrics, Kube-state metrics, and EKS control plane metrics out-of-the box." On EKS the data comes from an agent you deployed: "Container Insights uses a containerized version of the CloudWatch agent to discover all of the running containers in a cluster."

So switching it off means removing the agent or the EKS add-on that deploys it, not clicking a toggle in the CloudWatch console. One thing that does not go away by itself is the log group: "when you deploy Container Insights, it automatically creates a log group for the performance log events. You don't need to create this log group yourself." That log group keeps its retention setting and keeps billing for stored data after the agent is gone. Delete it or set retention on it deliberately.

Before you disable anything, check what depends on it. On ECS the pricing model is different again, "priced per metric, per month, prorated by the hour", which is a third billing shape for what looks like the same feature. ECS differs on the cost-allocation side too, as ECS split cost allocation data vs EKS sets out.

Does Container Insights replace split cost allocation data?

No, and the two answer different questions. Split cost allocation data is a CUR feature that divides the dollar cost of an EC2 instance across the pods that ran on it. Container Insights is a monitoring feature that reports utilisation. Neither one produces the other.

The confusion is understandable, because Container Insights appears inside split cost allocation data as a measurement source: AWS lists it as an option offering "more granular cost visibility for your clusters running multiple application containers using shared EC2 instances". How that choice is made, and where it is silent, is in EKS split cost allocation data, and the CUR columns it produces are compared against FOCUS in CUR 2.0 vs FOCUS.

The practical division of labour: use split cost allocation for the dollars, and use a metrics pipeline for the utilisation that tells you whether those dollars bought anything. If you are choosing between Container Insights and an in-cluster agent for the second job, the deciding number is usually the 700 bytes per log line, because it applies to your application logs rather than to the monitoring data.

Which Container Insights mode should you run?

• Do not turn enhanced observability off to save money. On AWS's own examples the older mode costs about twice as much on the same cluster, because it bills per metric name rather than per observation.
• Forecast on pods, not nodes. A pod is 138 observations a minute and a node is 68. Density raises this bill, which is the opposite of how the EKS compute meters behave.
• Price the OTel collector before assuming it is cheaper. It usually is, at $0.08 per GB, but the meter is data volume and label cardinality drives it.
• Look at the log group, not just the feature. The 700-byte per-line surcharge on container logs can exceed the Container Insights charge itself, and it appears under CloudWatch Logs.