ECS task count metrics are free: LiveTaskCount vs RunningTaskCount

The announcement is October 13; the billing change starts October 1

AWS announced two changes on October 13, 2026: LiveTaskCount is available at no additional charge, and the RunningTaskCount metric in CloudWatch Container Insights is no longer billed. The announcement covers every AWS Region where Amazon ECS is available. The RunningTaskCount pricing change applies automatically from October 1, with no application required.

LiveTaskCount is included in ECS service utilization metrics and does not require Container Insights. If a service task count is all you need, check that existing metric before enabling a broader container observability feature set.

Teams already using Container Insights can continue using RunningTaskCount as a service health and stability signal. Removing its charge does not change its counting scope to match LiveTaskCount.

Why activation and connection draining affect the count

LiveTaskCount includes service tasks in the ACTIVATING, RUNNING and DEACTIVATING lifecycle states. ACTIVATING tasks are preparing to receive traffic, such as registering with load balancer target groups or service discovery. DEACTIVATING tasks can be draining connections and deregistering from traffic-serving resources before stopping.

RunningTaskCount is narrower: both the current state and the desired state must be RUNNING. A task still handling an existing connection while moving toward a stopped state can remain in LiveTaskCount while being excluded from RunningTaskCount.

For an illustrative scenario, suppose eight tasks are running normally and two more are draining during scale-in, with other conditions unchanged. LiveTaskCount could be 10 while RunningTaskCount is 8. This is a hypothetical example, not a test we ran, and 10 does not mean ten tasks are ready for new requests.

Use LiveTaskCount when capacity monitoring or scaling decisions need the broader view of active, metric-generating tasks. Keep RunningTaskCount when the question is how many tasks currently and intentionally remain RUNNING. Neither count alone replaces application response checks or load balancer health checks.

Match the service dimensions before comparing charts

Open CloudWatch metrics in the AWS account and Region containing the ECS service, then look for LiveTaskCount in the AWS/ECS namespace. Match both ClusterName and ServiceName so that identically named services in different clusters are not confused.

The unit is Count, and the documented statistics are Average, Minimum and Maximum. Align the time window, period and statistic before comparing charts. An Average over an aggregated period can be fractional; it is not necessarily the number of rows in a task list at one instant.

The ECS metrics reference describes delivery at one-minute intervals. Start by reading existing data and comparing it with task states during the same period. Before changing a scaling alarm or capacity calculation, check whether its formula should continue counting draining tasks, then decide whether an adjustment is appropriate.

A blank chart after scaling to zero is not a reported zero

The ECS metrics reference says that a service or other resource with no tasks in the RUNNING state may send no metrics to CloudWatch during that period. The Container Insights guide likewise describes metrics for resources with running tasks in the selected time range.

Do not read a blank chart as a reported count of zero, or infer a telemetry failure from missing points alone. First check the account, Region, ClusterName, ServiceName and time range, and whether the service actually has RUNNING tasks.

How an alarm treats missing data affects its result. If monitoring a service that can scale to zero, account for absent data points in the alarm design. A free task count metric does not guarantee that every stopped or scaled-in service continuously reports zero.

Why a Container Insights bill can remain

AWS removed the charge for the RunningTaskCount metric regardless of how many ECS services or clusters are in the account. Other Container Insights metrics remain subject to their CloudWatch pricing, and container log ingestion and storage charges have not been removed.

Example 19 on the CloudWatch pricing page shows the distinction for Fargate with enhanced observability: each service reports 31 metrics, but RunningTaskCount is free, leaving 30 paid service metrics in the calculation. In its five-service example, each service has a free RunningTaskCount metric while the remaining metrics still contribute to monthly cost.

This is an AWS hypothetical example, not our measured bill. Its prices use US East (N. Virginia) and assume reporting throughout the month. Region, running time, cluster structure, observability mode and log volume can all change the amount; the example total is not a fixed monthly price for every account.

Keep the useful existing signals and add only what you need

If a RunningTaskCount alarm already serves a health or stability purpose, retain that purpose while observing LiveTaskCount for the same service, time window and statistic, especially during deployments or scale-in. An automatic pricing change does not mean dashboards, alarm formulas or scaling policies automatically switch metrics.

If Container Insights is not enabled and you only need the broader task count, start with the existing LiveTaskCount metric. Evaluate Container Insights and its costs when you need additional task, container, resource-utilization or log detail.

Confirm the two outcomes separately: the count should match the task states you intend to observe, and charges should match the billing records for your account and Region. The product and pricing announcement does not establish the health or final bill of your own service.