AWS Fargate Metrics in CloudWatch: ECS Monitoring Guide

For an Amazon ECS service on AWS Fargate, CloudWatch receives service-level CPU and memory utilization metrics automatically. Enable CloudWatch Container Insights when you need additional network, storage, or task-level detail. The namespace and dimensions tell you what each metric actually represents: a service average is useful for alerting and scaling, while task and container metrics help find an outlier.

This guide covers ECS on Fargate. ECS on EC2 and EKS on Fargate have different infrastructure and monitoring details, so their metrics should not be inferred from the examples here.

Quick takeaways:

• AWS/ECS publishes Fargate service CPUUtilization and MemoryUtilization without enabling Container Insights.
• ECS/ContainerInsights adds metrics and performance data. Enhanced observability adds CloudWatch metrics with task and container dimensions.
• Fargate ephemeral-storage metrics require Linux platform version 1.4.0 or later. EBS filesystem metrics are for tasks with an attached EBS volume.
• Container Insights and custom metrics add CloudWatch charges. Start with the service-level data you need and add detail deliberately.

Set Up CloudWatch Monitoring for ECS on Fargate

Amazon ECS sends its built-in metrics to CloudWatch; your application does not need to publish them. Container Insights is a separate cluster setting for collecting richer telemetry. Choose it when the additional detail will help with a real operational question.

Prerequisites for CloudWatch and Fargate

• Run an ECS cluster and service in the Region you plan to monitor. ECS service metrics are reported at one-minute intervals while the service has tasks in the RUNNING state. A service with no running tasks may have no utilization data.
• To change Container Insights settings, use an identity allowed to update the ECS cluster. The Fargate task execution role does not need cloudwatch:PutMetricData for ECS's built-in metrics.
• Use Fargate Linux platform version 1.4.0 or later for Container Insights ephemeral-storage metrics. EBS filesystem metrics also require an EBS volume attached to the task; the ECS service metric requires Fargate platform version 1.4.0 or later.

Give an application task role permission to publish CloudWatch data only if the application itself sends custom metrics. Those metrics are separate from the metrics ECS publishes for the service.

Enable CloudWatch Container Insights

For task- and container-level CloudWatch metrics, enable Container Insights with enhanced observability on the ECS cluster. In the ECS console, open the cluster settings and choose the enhanced observability option. For an existing cluster, the AWS CLI command is:

aws ecs update-cluster-settings \
  --cluster my-cluster \
  --settings name=containerInsights,value=enhanced \
  --region us-east-1

Replace the cluster name and Region with your values. The cluster setting applies across the cluster. An account-level default affects newly created clusters; updating an existing cluster requires setting its cluster configuration. See AWS's ECS Container Insights setup guide for both standard and enhanced options.

After configuration, view metrics in the CloudWatch ECS/ContainerInsights namespace or the Container Insights dashboards. Data appears for resources that are running tasks; do not rely on a fixed activation time.

Choose Task Detail and Custom Metrics

Standard Container Insights provides cluster- and service-level metrics. Its performance log events can also be queried in CloudWatch Logs Insights, but it does not automatically publish every task as a separate CloudWatch metric. Enhanced observability adds task- and container-level metric dimensions such as TaskId and ContainerName.

For application-specific values such as queue wait time or completed orders, publish a custom metric in your own namespace or create a metric filter for a suitable log event. A task-definition environment variable does not create a CloudWatch metric or dimension on its own. See our guide to custom CloudWatch metrics for publishing application-defined data.

Key Metrics for Monitoring Fargate with CloudWatch

Start with the metric set that answers the question you need to act on. The following namespaces have different costs and levels of detail.

Core Fargate Metrics

Metric	Namespace and dimensions	What it tells you
CPUUtilization	AWS/ECS; ClusterName, ServiceName	Percentage of the CPU reserved by the service's tasks that is in use. Available automatically for ECS services on Fargate.
MemoryUtilization	AWS/ECS; ClusterName, ServiceName	Percentage of the memory reserved by the service's tasks that is in use. Available automatically for ECS services on Fargate.
EBSFilesystemUtilization	AWS/ECS; ClusterName, ServiceName	Service-level use of attached EBS filesystems. It is available when tasks have an EBS volume attached and use Fargate platform version 1.4.0 or later.
RunningTaskCount, DesiredTaskCount	ECS/ContainerInsights; ClusterName, ServiceName	Compare the service's running and desired task counts to spot a capacity shortfall. These are Container Insights metrics.
TaskCpuUtilization, TaskMemoryUtilization	ECS/ContainerInsights; enhanced observability: ClusterName, ServiceName, TaskId	Find resource pressure on an individual task. Enhanced observability also supplies container-level metrics.
TaskEphemeralStorageUtilization	ECS/ContainerInsights; enhanced observability: ClusterName, ServiceName, TaskId	Shows task ephemeral-storage use. This is separate from an attached EBS volume and requires Fargate Linux platform version 1.4.0 or later.

The built-in AWS/ECS CPU and memory metrics are aggregated for a service, not emitted once per task. They describe use relative to the CPU and memory reserved for that service's tasks, rather than utilization of the underlying Fargate host. A service average can hide one overloaded task; use enhanced metrics to investigate task or container outliers.

Metric Namespaces and Data Interpretation

• AWS/ECS: ECS service metrics, including Fargate service CPU and memory utilization. These built-in ECS metrics are provided at no additional CloudWatch metric charge. The standard service dimensions are ClusterName and ServiceName.
• ECS/ContainerInsights: Container Insights metrics. Standard collection adds aggregated cluster and service metrics; enhanced observability adds task and container metrics with more detailed dimensions. Container Insights metrics incur additional CloudWatch charges.
• AWS/Usage: Fargate's ResourceCount metric tracks running vCPU usage, with class values Standard/OnDemand and Standard/Spot. Use it with the current Fargate service quota when monitoring account and Region capacity; there is no universal limit of 100 running Fargate tasks.

Fargate's ephemeral task storage and an attached EBS volume are different resources. Container Insights reports ephemeral-storage metrics for supported Linux tasks on platform version 1.4.0 or later. EBS filesystem metrics describe an EBS volume attached to a task and are available only when the documented platform or agent prerequisites are met. Fargate also reserves some disk space for its own use; that space can appear in tools such as df and is not included in the Container Insights ephemeral-storage metrics.

For current vCPU usage and quota dimensions, see AWS's Fargate usage metrics reference. Check Service Quotas for the actual quota in your account and Region; quota values can vary and some can be increased.

Visualize and Analyze Fargate Metrics in CloudWatch

CloudWatch dashboards can show service health at a glance and put related trends together. Build the dashboard from the same namespace and dimensions you intend to alert on.

Create a CloudWatch Dashboard

1. In the CloudWatch console, choose Dashboards and create a dashboard.
2. Add a line or number widget, then choose the correct Region and namespace: AWS/ECS for service CPU and memory, or ECS/ContainerInsights for Container Insights data.
3. Select the metric and its dimensions. For an ECS service, use its exact ClusterName and ServiceName values.
4. Graph service CPU and memory together, then add desired and running task counts if Container Insights is enabled. Use enhanced task metrics or performance-log queries when investigating a service average that conceals a single task problem.

Dashboards display CloudWatch data; they do not enable metric collection. If a metric is missing, check the Region, namespace, dimensions, cluster setting, and whether the resource has a running task.

Set Up CloudWatch Alarms

Create alarms from the exact metric and dimensions that represent the condition you want to detect. For a service-wide CPU alert, choose AWS/ECS, CPUUtilization, and the service's ClusterName and ServiceName dimensions. Use a threshold and evaluation period based on the service's normal load and response needs; 80% or 90% is not a universal failure point.

Metric publication depends on running tasks, so missing CPU or memory data is not the same as a zero reading. CloudWatch alarms let you treat missing data as missing, notBreaching, breaching, or ignore. Choose based on what an absent sample means for this service. For example, treating silence as breaching may catch an unexpected telemetry gap for an always-on service, but can cause false alarms for a service expected to scale to zero. The default is missing. See AWS's alarm missing-data guidance and our CloudWatch alarm best practices.

CloudWatch alarms have OK, ALARM, and INSUFFICIENT_DATA states. Add an action such as an SNS notification if an operator needs to respond. If your alert must distinguish “the service has no running tasks” from “metric collection stopped,” monitor task counts and service health explicitly as well as utilization.

Use CloudWatch Metrics to Scale Fargate Tasks

For an ECS service, configure service auto scaling through Application Auto Scaling. Target tracking can use the predefined ECSServiceAverageCPUUtilization or ECSServiceAverageMemoryUtilization metric to adjust the desired task count around a target. This is different from creating a notification alarm: the scaling policy manages its scaling behavior, while CloudWatch alarms can notify you about conditions that need attention.

How ECS Service Auto Scaling Works

Register the ECS service as a scalable target, set minimum and maximum task counts, and add a target-tracking or step-scaling policy that matches the workload. Target tracking is a practical starting point when service CPU or memory utilization tracks demand. It is not a substitute for checking application latency, request load, or queue depth when those better represent user impact.

Choose a Scaling Metric

ECSServiceAverageCPUUtilization is the name of a predefined ECS scaling metric; it is not the name of a metric in the AWS/ECS namespace. Set a target based on load testing and normal operation, then check that the service has enough minimum and maximum capacity for expected demand. See AWS's ECS target-tracking setup for the supported CPU, memory, and load-balancer request metrics.

Best Practices for Collecting and Using Fargate Metrics

Collect Metrics That Lead to an Action

• Start with free ECS service CPU and memory metrics for service-level alerting and scaling.
• Enable enhanced Container Insights where task or container detail will shorten diagnosis. Use service-level charts for steady monitoring and task-level data to investigate outliers.
• Use AWS/Usage vCPU data with the live Service Quotas value to watch Fargate capacity. Avoid hard-coded task limits because quota units and values vary.
• Publish custom metrics only for application behavior that the built-in ECS metrics cannot show. Keep dimensions bounded; each distinct metric and dimension set can add cost.

Understand the Cost and Data Limits

Container Insights pricing depends on the ECS mode. Standard Container Insights charges for embedded metrics, performance-log ingestion, and log storage. Enhanced observability for ECS is priced per metric per month, prorated by the hour; that metric charge includes performance-log ingestion, while retained log storage is charged separately. Metric counts grow with the clusters, services, task definitions, tasks, and containers you monitor, so task-level detail can increase the total. Application container logs have their own CloudWatch Logs ingestion and storage charges. Check the current CloudWatch pricing for your Region and use Cost Explorer to review actual usage.

Custom application metrics also add charges. Keep dimensions bounded and enable only the granularity you will use.

ECS metric data can stop when a service has no running tasks. A missing datapoint may reflect a stopped workload, a configuration problem, or an ingestion issue; dashboards and alarms should account for the expected schedule and availability of the service.

Conclusion

Use AWS/ECS for automatic service-level CPU and memory monitoring on ECS Fargate. Add ECS/ContainerInsights when the extra service, task, container, network, or storage detail answers a concrete operational need. Confirm the platform prerequisites for ephemeral storage and attached EBS volumes, and review the added CloudWatch costs before broadening collection.

FAQs

Do Fargate tasks need the CloudWatch agent for ECS metrics?

No. ECS publishes built-in service metrics and manages Container Insights collection through the cluster setting. The CloudWatch agent is used for additional instance-level metrics on ECS clusters running on EC2; Fargate does not expose a host for you to instrument. Your task role needs CloudWatch publishing permissions only if your application sends custom metrics.