How to Monitor Amazon EKS with CloudWatch: Metrics, Logs, and Alerts

EKS does not send metrics or logs to CloudWatch by default. Once you deploy workloads, you are blind until you install the right agents. This guide shows you the AWS-native path: what to install, what each component collects, how to verify the setup is actually working, and which five alerts to create first.

What EKS monitoring actually means#

Monitoring a Kubernetes cluster is not one thing. It is four distinct concerns that are easy to blur together:

• Infrastructure metrics: CPU, memory, disk, and network at the node (EC2 instance) level
• Kubernetes state metrics: pod phases, deployment replica counts, job status. These signals come from the Kubernetes API, not from the nodes themselves
• Container logs: stdout and stderr from every container, forwarded and searchable
• Alerts: rules that fire when a signal crosses a threshold you care about

A useful monitoring setup covers all four. The CloudWatch Observability EKS add-on with Fluent Bit gives you the first three in one step. Alerts are a separate, intentional step on top.

When to use this approach#

The AWS-native CloudWatch setup is the right starting point when:

• Your team works primarily in the AWS Console and wants to avoid managing extra infrastructure
• You are new to EKS monitoring and want a supported, well-documented path
• You want full visibility without the operational overhead of running your own Prometheus
• You need a working setup quickly, with room to layer in more tooling later

If you eventually need application-level metrics (request rate, error rate, latency percentiles from your own services) or PromQL-style querying, Prometheus or Amazon Managed Service for Prometheus (AMP) can layer on top. CloudWatch is still the right place to start. For the broader tool-choice decision, see the EKS Monitoring Guide: CloudWatch, Prometheus and Grafana.

How EKS monitoring in AWS works#

Five components work together to give you full visibility:

• Amazon CloudWatch Observability EKS add-on: installs and manages the CloudWatch agent and Fluent Bit as DaemonSets on every node in a single managed step
• CloudWatch agent (Container Insights): collects infrastructure and Kubernetes metrics from each node and sends them to the ContainerInsights CloudWatch namespace
• Fluent Bit: reads container log files from the node filesystem and forwards them to CloudWatch Logs, organized by cluster, namespace, and pod
• kube-state-metrics: connects to the Kubernetes API server and exports state information such as pod phases, deployment replica counts, and job completion status. This is separate from utilization metrics and the CloudWatch agent does not collect it automatically
• EKS control plane logs: API server, audit, scheduler, controller manager, and authenticator logs. These are not collected by the agent. They are enabled per cluster and go directly to CloudWatch Logs

The add-on handles the agent and Fluent Bit. kube-state-metrics and control plane logs are separate steps. For more background on EKS itself, see the Amazon EKS Overview.

Recommended AWS-native setup#

The add-on gets you metrics and logs in one command. The remaining three each require one extra step.

Fastest install path: CloudWatch Observability EKS add-on#

The Amazon CloudWatch Observability EKS add-on is the current recommended way to install Container Insights on EKS. It replaces the older manual DaemonSet manifest path and handles upgrades automatically through the EKS add-on lifecycle.

Step 1: Set up IAM permissions with EKS Pod Identity#

The add-on’s service account needs permission to publish metrics and logs to CloudWatch. EKS Pod Identity is the current AWS-recommended approach. IAM Roles for Service Accounts (IRSA) also works and is widely used on existing clusters:

# Create the IAM role
aws iam create-role \
  --role-name EKSCloudWatchObservabilityRole \
  --assume-role-policy-document file://eks-pod-identity-trust-policy.json

# Attach the managed policy
aws iam attach-role-policy \
  --role-name EKSCloudWatchObservabilityRole \
  --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy

# Associate the role with the add-on service account via Pod Identity
aws eks create-pod-identity-association \
  --cluster-name my-cluster \
  --namespace amazon-cloudwatch \
  --service-account cloudwatch-agent \
  --role-arn arn:aws:iam::123456789012:role/EKSCloudWatchObservabilityRole

Step 2: Install the add-on#

aws eks create-addon \
  --cluster-name my-cluster \
  --addon-name amazon-cloudwatch-observability \
  --region us-east-1

That single command deploys the CloudWatch agent DaemonSet and Fluent Bit DaemonSet in the amazon-cloudwatch namespace. Metrics start appearing in Container Insights within a few minutes.

Step 3: Enable EKS control plane logs#

Control plane logs are separate from Container Insights and must be enabled per cluster. Enable all five types unless you have a specific reason not to:

aws eks update-cluster-config \
  --name my-cluster \
  --region us-east-1 \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

Step 4: Install kube-state-metrics (recommended)#

kube-state-metrics adds Kubernetes state signals that the CloudWatch agent alone does not collect. Install it via Helm (see the Helm Package Manager guide if you are new to Helm):

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

helm install kube-state-metrics prometheus-community/kube-state-metrics \
  --namespace kube-system

What each component collects#

CloudWatch agent: Container Insights metrics#

Metrics land in the ContainerInsights CloudWatch namespace with dimensions for cluster, node, namespace, pod, and container:

• Node CPU utilization, memory utilization, disk I/O, and network throughput
• Pod CPU, memory, network, and disk usage per namespace and pod name
• Container memory utilization per container
• Number of running pods per namespace
• Container restart counts

You can view these in the CloudWatch console under Insights > Container Insights, or query them via the AWS CLI and CloudWatch Dashboards.

Fluent Bit: container log forwarding#

Fluent Bit reads /var/log/containers/ on each node and routes logs to three CloudWatch Logs groups:

• /aws/containerinsights/CLUSTER_NAME/application: container stdout and stderr
• /aws/containerinsights/CLUSTER_NAME/host: node-level system logs
• /aws/containerinsights/CLUSTER_NAME/dataplane: kubelet and containerd logs

For searching and querying these log groups, see CloudWatch Logs. For more on how Kubernetes log forwarding works, see Logging in Kubernetes.

kube-state-metrics: Kubernetes state signals#

State signals that the CloudWatch agent does not see directly:

• kube_pod_status_phase: whether each pod is Running, Pending, Failed, or Succeeded
• kube_deployment_status_replicas_available: ready replicas vs desired replicas
• kube_node_status_condition: node health flags (Ready, MemoryPressure, DiskPressure)
• kube_job_status_failed: whether any Kubernetes Jobs have failed

These metrics are in Prometheus format. They pair well with the CloudWatch agent for alerting on Kubernetes state and become the foundation if you later add Prometheus or AMP.

EKS control plane logs#

Logs from the components that AWS manages for you:

• api: requests to the Kubernetes API server
• audit: full audit trail of who accessed what, which resource, and whether it was allowed
• scheduler: pod scheduling decisions and failures
• controllerManager: deployment, replica set, and job lifecycle events
• authenticator: IAM-to-Kubernetes authentication events

These land in CloudWatch Logs and are queryable with CloudWatch Logs Insights. Audit logs are especially useful for security investigations. See Securing EKS Clusters for the full security picture.

How to verify it is working#

After installing the add-on, work through this checklist before moving on.

1. Check the add-on pods are running:

kubectl get pods -n amazon-cloudwatch
# You should see cloudwatch-agent-* and fluent-bit-* pods, one per node

2. Check the CloudWatch agent logs for errors:

kubectl logs -n amazon-cloudwatch -l name=cloudwatch-agent --tail=20
# Look for: "Starting input plugins" with no ERROR lines

3. Check Fluent Bit logs for errors:

kubectl logs -n amazon-cloudwatch -l k8s-app=fluent-bit --tail=20
# Look for successful flush output lines with no ERROR lines

4. Verify metrics appear in Container Insights:

Open the AWS Console, navigate to CloudWatch, then Insights, then Container Insights. Select your cluster. If metrics are present, the agent is working. Allow 2 to 5 minutes after installation.

5. Verify log groups exist in CloudWatch Logs:

aws logs describe-log-groups \
  --log-group-name-prefix "/aws/containerinsights/my-cluster" \
  --region us-east-1

You should see the /application, /host, and /dataplane log groups.

6. Quick metric check via AWS CLI:

aws cloudwatch list-metrics \
  --namespace ContainerInsights \
  --region us-east-1 \
  --query "Metrics[?Dimensions[?Name=='ClusterName' && Value=='my-cluster']] | [0:5]"

What to alert on first#

Start with five high-signal alerts. Get these working well before adding more. Alerts you trust are more useful than twenty alerts that engineers have learned to dismiss.

For step-by-step instructions on creating these in CloudWatch, see Creating Alerts in CloudWatch.

If your pods have started crash-looping and you are not sure why, see EKS CrashLoopBackOff Explained for a diagnostic flow.

Cost and retention basics#

The main cost drivers are:

• Custom metrics: CloudWatch charges per custom metric published per month. A 10-node cluster at pod granularity generates hundreds of metrics quickly.
• Log ingestion: CloudWatch Logs charges per GB ingested. Container logs on a busy cluster add up fast.
• Log storage: log groups retain data indefinitely unless you set a retention policy.

Set retention on all Container Insights log groups on day one:

# Application logs: 30 days is typical
aws logs put-retention-policy \
  --log-group-name "/aws/containerinsights/my-cluster/application" \
  --retention-in-days 30 \
  --region us-east-1

# Audit logs: 90 days is a common compliance baseline
aws logs put-retention-policy \
  --log-group-name "/aws/eks/my-cluster/cluster" \
  --retention-in-days 90 \
  --region us-east-1

Enable control plane log types selectively. Audit logs are the most valuable for security but also the most expensive on a busy cluster. Enable only what you have a plan for.

CloudWatch vs Prometheus vs AMP#

This page covers the CloudWatch path in depth. For a full comparison of all three options, including setup examples for Prometheus and AMP, see the EKS Monitoring Guide: CloudWatch, Prometheus and Grafana.

Last verified: 3 May 2026 · Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.