AWS CloudWatch sits at the center of every AWS deployment, collecting metrics, logs, and events across services whether you know it or not. CloudWatch is how most teams monitor their AWS infrastructure, but understanding what it actually monitors, how much it costs at scale, and where it falls short requires looking past the marketing.
This guide covers AWS CloudWatch fundamentals, how metrics and logs work, alarm configuration, pricing structure including the hidden costs most teams discover after deployment, and when CloudWatch alone is not enough for full application visibility. By the end, you will understand how CloudWatch fits into modern observability and where complementary tools fill the gaps CloudWatch leaves.
What Is AWS CloudWatch?
AWS CloudWatch is Amazon’s native monitoring and observability service built specifically for AWS resources and applications running on AWS infrastructure. It collects metrics, logs, and events automatically from AWS services and provides dashboards, alarms, and automated responses to changes in resource behavior.
CloudWatch operates as a managed service, which means AWS handles all backend infrastructure, scaling, and availability. You configure what to monitor, set thresholds for alerts, and build dashboards to visualize performance. CloudWatch stores the data, runs queries, and triggers actions when conditions are met.
The service breaks into several core components: metrics for time series performance data, logs for structured and unstructured text data, alarms for threshold based alerting, dashboards for visualization, and events for tracking configuration changes and operational actions across your AWS account.
CloudWatch was designed first for infrastructure monitoring, tracking CPU, memory, disk, and network utilization across EC2 instances, RDS databases, Lambda functions, and other AWS services. Over time, AWS expanded it to include application level signals through CloudWatch Application Signals, container monitoring through Container Insights, and synthetic testing through CloudWatch Synthetics.
Every AWS service sends basic metrics to CloudWatch by default at no additional charge. EC2 instances report CPU utilization and disk read/write operations every five minutes. RDS databases send metrics on database connections, read/write IOPS, and storage space. Lambda functions report invocation count, duration, error rate, and throttles. This automatic ingestion means CloudWatch always has baseline visibility into your infrastructure, even if you never configure it explicitly.
The data CloudWatch collects is stored in namespaces, which act as containers to separate metrics from different services. For example, EC2 metrics live in the AWS/EC2 namespace, RDS metrics in AWS/RDS, and Lambda metrics in AWS/Lambda. Custom application metrics can be published to custom namespaces, giving you control over how application data is organized alongside AWS service data.
CloudWatch integrates directly with other AWS services for automated responses. You can trigger Lambda functions when an alarm fires, auto scale EC2 instances based on CPU utilization, or send notifications through Simple Notification Service (SNS) when log patterns match a specific error signature. This tight integration makes CloudWatch the simplest option for basic AWS infrastructure monitoring and automated responses within the AWS ecosystem.
How AWS CloudWatch Works
CloudWatch operates as a centralized data collection and analysis service. AWS services push metrics and logs to CloudWatch continuously. Applications and custom scripts can also push data using the CloudWatch API or the CloudWatch agent. Once ingested, CloudWatch stores the data, indexes logs for search, aggregates metrics into statistics, and evaluates alarm conditions in near real time.
Namespaces and Metrics
Metrics are the core data type in CloudWatch. A metric is a time ordered set of data points representing a measurable value over time, such as CPU utilization, request count, or error rate. Each metric belongs to a namespace, which groups related metrics together and prevents naming collisions between different services.
Metrics are defined by a unique combination of namespace, metric name, and dimensions. Dimensions are key value pairs that provide additional context for a metric. For example, an EC2 instance metric might include dimensions for InstanceId and InstanceType, allowing you to filter or aggregate metrics by specific instances or instance types.
CloudWatch supports standard resolution metrics, which are collected at one minute intervals, and high resolution metrics, which can be collected at intervals as short as one second. High resolution metrics are useful for real time monitoring and rapid detection of issues but incur higher costs due to increased storage and API call volume.
Metrics Collection and Publishing
AWS services automatically publish metrics to CloudWatch. For EC2 instances, basic monitoring sends metrics every five minutes at no cost. Enabling detailed monitoring reduces the interval to one minute but adds $2.10 per instance per month to your bill. For other services like Lambda, RDS, and ECS, metrics are published automatically with no additional charge for basic CloudWatch integration.
Custom application metrics require explicit publishing using the CloudWatch PutMetricData API or the CloudWatch agent. The agent runs on EC2 instances or on premises servers and collects system level metrics such as memory utilization, disk usage, and process stats, which are not available in basic EC2 monitoring. The agent also supports collecting custom application metrics and forwarding logs to CloudWatch Logs.
Publishing custom metrics costs $0.30 per metric per month for the first 10,000 metrics. Beyond that, pricing drops to $0.10 per metric per month. For applications that emit hundreds of thousands of metrics, this cost compounds quickly. A single microservice publishing 500 unique metrics costs $150 per month before any log ingestion or alarm configuration.
Logs Collection and Storage
CloudWatch Logs collects log data from AWS services, applications, and custom sources. Logs are organized into log groups, which contain log streams. A log group typically corresponds to an application or service, while log streams represent individual sources within that group, such as different EC2 instances or Lambda function invocations.
Log events are individual log entries with a timestamp and message. CloudWatch stores these events and indexes them for search using CloudWatch Logs Insights. Logs Insights supports three query languages: a custom CloudWatch query language, SQL, and Piped Processing Language (PPL). All three allow filtering, aggregating, and analyzing log data across large volumes in near real time.
Log ingestion is charged at $0.50 per GB for the first 10 TB per month, dropping to $0.25 per GB for volumes above 50 TB per month. Log storage costs $0.03 per GB per month. Unlike some log platforms that charge separately for indexing and querying, CloudWatch includes indexing by default but charges $0.005 per GB scanned during Logs Insights queries.
For an application generating 500 GB of logs per month, the ingestion cost is $250, storage is $15 per month, and querying costs depend on how much data is scanned during investigations. Teams often underestimate query costs until they run large scale root cause analysis across multiple months of retained logs.
Alarms and Automated Actions
CloudWatch Alarms monitor metrics and trigger actions when thresholds are crossed. An alarm watches a single metric and evaluates it against a threshold over a specified period. When the threshold is breached, the alarm changes state from OK to ALARM and can trigger actions such as sending an SNS notification, executing a Lambda function, or initiating an Auto Scaling policy.
Alarms support static thresholds, where you define a fixed value, and anomaly detection, where CloudWatch uses machine learning to detect deviations from expected behavior. Anomaly detection is useful for metrics with variable baselines, such as web traffic that spikes during business hours and drops overnight.
Alarms cost $0.10 per alarm per month for standard metrics and $0.30 per alarm per month for high resolution metrics or anomaly detection. For large environments with hundreds of alarms, this adds up. A production environment monitoring 200 metrics with alarms costs $20 per month in alarm fees alone, before any notification or action costs.
Dashboards and Visualization
CloudWatch Dashboards provide customizable views of metrics, logs, and alarms in a single interface. Dashboards can display line graphs, bar charts, numbers, and text widgets. They support cross account and cross region views, allowing centralized monitoring of distributed infrastructure.
AWS provides automatic dashboards for many services, which display key metrics without requiring manual configuration. Custom dashboards are charged at $3 per dashboard per month. For teams managing multiple environments (development, staging, production), dashboard costs can reach $50 to $100 per month across all environments.
Dashboards are useful for high level operational visibility but lack the flexibility and performance of specialized observability platforms when dealing with high cardinality data or complex distributed tracing across microservices.
Key CloudWatch Metrics and What They Measure
CloudWatch collects different metrics depending on the AWS service being monitored. Understanding what each service measures and what is missing is critical for effective monitoring.
EC2 Instance Metrics
EC2 instances report CPU utilization, disk read/write operations, network in/out bytes, and status check metrics. CPU utilization measures the percentage of allocated compute capacity being used. Disk metrics track read and write operations per second and bytes transferred. Network metrics show inbound and outbound traffic.
EC2 basic monitoring does not include memory utilization, disk space utilization, or process level metrics. To monitor these, you must install the CloudWatch agent, which collects system level data and publishes it as custom metrics. This adds $0.30 per metric per month to your costs.
RDS Database Metrics
RDS sends metrics on database connections, CPU utilization, free storage space, read/write IOPS, and replication lag for read replicas. These metrics help detect capacity issues, slow queries, and replication delays.
RDS does not expose query level performance data in CloudWatch. For detailed query analysis, you must use RDS Performance Insights, which is a separate service with its own pricing. Performance Insights costs $0.009 per vCPU per hour for the first 7 days of data retention and $0.018 per vCPU per hour beyond that.
Lambda Function Metrics
Lambda automatically publishes invocation count, duration, error count, throttle count, and concurrent executions. These metrics help track function performance, detect cold starts, and identify throttling caused by account level concurrency limits.
Lambda does not expose memory utilization as a metric. Instead, it reports memory usage in CloudWatch Logs at the end of each invocation. Parsing this data requires running Logs Insights queries, which cost $0.005 per GB scanned.
ECS and EKS Container Metrics
ECS and EKS send cluster level metrics such as CPU and memory utilization, task count, and service status. For deeper container visibility, you must enable Container Insights, which collects metrics at the task, pod, node, and container level.
Container Insights costs $0.30 per metric per month for custom metrics it publishes. For a Kubernetes cluster with 50 pods publishing 20 metrics each, that totals 1,000 metrics or $300 per month before log ingestion. Many teams enable Container Insights without understanding the metric explosion it creates in CloudWatch billing.
API Gateway Metrics
API Gateway sends metrics on request count, 4xx errors, 5xx errors, latency, and integration latency. These metrics track API health and performance but do not expose detailed request or response payloads.
For end to end tracing of API requests through backend services, you need distributed tracing through AWS X-Ray, which is a separate service with its own ingestion and storage costs. X-Ray charges $5 per million traces recorded and $0.50 per million traces retrieved.
AWS CloudWatch Logs: Collection, Retention, and Search
CloudWatch Logs is AWS’s managed log aggregation and analysis service. It collects logs from AWS services, EC2 instances, Lambda functions, and custom applications, stores them for a configurable retention period, and provides search and query capabilities through CloudWatch Logs Insights.
Log Groups and Log Streams
Logs are organized into log groups and log streams. A log group represents a logical collection of logs, typically one per application or service. Log streams represent individual sources within that group, such as different EC2 instances or Lambda function invocations.
Log groups define the retention period for logs, which can range from one day to indefinite retention. Retention affects storage costs. Storing logs indefinitely at $0.03 per GB per month means 1 TB of logs costs $30 per month in perpetual storage fees.
Log Ingestion and Parsing
AWS services send logs to CloudWatch automatically when configured. EC2 instances require the CloudWatch agent to forward logs. Lambda functions can write logs directly using the AWS SDK or standard output streams, which are automatically captured and sent to CloudWatch.
CloudWatch does not parse or index logs beyond basic timestamp and message fields. Unlike observability platforms that extract structured fields from logs during ingestion, CloudWatch stores logs as raw text and requires query time parsing using Logs Insights.
CloudWatch Logs Insights Query Language
Logs Insights supports three query languages: the CloudWatch query syntax, SQL, and PPL. The CloudWatch query syntax uses a pipe delimited structure similar to Unix commands. SQL queries use standard SELECT, FROM, WHERE, and GROUP BY syntax. PPL is a Piped Processing Language similar to Splunk’s search syntax.
All three languages scan log data at query time, which means every query incurs a cost based on the amount of data scanned. Large queries over months of retained logs can cost dollars per query. For an application generating 5 TB of logs per month, scanning three months of logs for a single root cause analysis costs $0.005 per GB scanned × 15,000 GB = $75 per query.
Most teams discover this cost after running expensive queries during incidents. Unlike platforms that pre index logs and charge for storage rather than query time scanning, CloudWatch shifts cost to the investigation phase, making troubleshooting expensive.
Metric Filters and Log Based Alarms
CloudWatch Logs supports metric filters, which scan incoming log events and extract numerical values to publish as CloudWatch metrics. For example, you can extract HTTP response codes from web server logs and create a metric tracking 5xx error rates.
Metric filters cost $0.50 per filter per month and add to the overall metric count for pricing purposes. For an application with 10 metric filters publishing 10 metrics each, that adds 100 custom metrics to your bill, costing $30 per month.
Log based alarms combine metric filters with CloudWatch Alarms. When a log pattern indicates a problem, the metric filter publishes a value, and the alarm fires. This is useful for detecting application errors that do not surface as infrastructure metrics but requires careful tuning to avoid alert fatigue from noisy log patterns.
AWS CloudWatch Alarms and Automated Responses
CloudWatch Alarms monitor metrics and trigger actions when thresholds are breached. Alarms are the primary mechanism for proactive monitoring and automated incident response in AWS environments.
Static Threshold Alarms
Static alarms compare a metric against a fixed value. For example, you can create an alarm that fires when EC2 CPU utilization exceeds 80% for five consecutive minutes. When the threshold is breached, the alarm changes state and triggers configured actions.
Static alarms work well for predictable baselines but require manual tuning as workloads change. Over time, teams accumulate alarm debt, where outdated thresholds generate false positives or miss real issues because the baseline has shifted.
Anomaly Detection Alarms
Anomaly detection alarms use machine learning to establish a baseline for metric behavior and detect deviations. CloudWatch trains a model on historical data and creates an expected range, called a band. When the metric moves outside the band, the alarm fires.
Anomaly detection is useful for metrics with variable patterns, such as web traffic that spikes during business hours. It reduces the need for manual threshold tuning but costs $0.30 per alarm per month, three times the cost of a static alarm.
Anomaly detection can generate false positives during deployment changes, traffic shifts, or infrastructure scaling events. Teams often combine anomaly detection with composite alarms that require multiple signals to fire before triggering a response.
Composite Alarms
Composite alarms combine multiple alarms using AND, OR, and NOT logic. This reduces alert noise by requiring multiple conditions to be true before firing. For example, a composite alarm might fire only when CPU utilization exceeds 80% AND disk I/O is saturated AND memory utilization is high.
Composite alarms cost $0.50 per alarm per month and can help reduce alert fatigue in complex environments. However, they add complexity to alarm management and require careful design to avoid creating alarms that never fire because the composite conditions are too strict.
Alarm Actions and Integrations
CloudWatch Alarms can trigger several types of actions: sending notifications through SNS, executing Lambda functions, starting or stopping EC2 instances, and initiating Auto Scaling policies.
SNS notifications are the most common action. SNS can deliver notifications via email, SMS, HTTP/HTTPS endpoints, or integrations with third party services like Slack, PagerDuty, and Opsgenie. SNS costs $0.50 per million notifications for email and SMS.
Lambda functions provide flexible automation. An alarm can trigger a Lambda function that performs remediation, such as restarting a failed service, scaling up capacity, or creating a support ticket. Lambda costs $0.20 per million requests and $0.0000166667 per GB-second of compute time.
Auto Scaling is the most common use of CloudWatch Alarms in production. Alarms trigger scaling policies that add or remove EC2 instances, ECS tasks, or RDS read replicas based on demand. This automation improves availability and cost efficiency but requires careful alarm tuning to avoid flapping, where scaling actions trigger repeatedly in short succession.
AWS CloudWatch Pricing Breakdown
CloudWatch pricing is complex and built on multiple dimensions: metrics, logs, alarms, dashboards, API requests, and data transfer. Understanding each component is essential to avoid surprise costs as usage scales.
Metrics Pricing
AWS services send basic metrics to CloudWatch at no additional charge. These include default EC2, RDS, Lambda, and ECS metrics. Custom metrics published via the PutMetricData API or CloudWatch agent cost $0.30 per metric per month for the first 10,000 metrics, dropping to $0.10 per metric per month beyond that.
High resolution metrics cost $0.30 per metric per month regardless of volume. For applications requiring sub minute monitoring, this adds up quickly. A single application publishing 1,000 high resolution metrics costs $300 per month in metric storage alone.
Logs Pricing
Log ingestion costs $0.50 per GB for the first 10 TB per month, $0.25 per GB for 10 TB to 50 TB, and $0.10 per GB beyond 50 TB. Storage costs $0.03 per GB per month. Logs Insights queries cost $0.005 per GB scanned.
A growing team generating 2 TB of logs per month pays $1,000 for ingestion, $60 for storage, and $10 to $50 per month in query costs depending on investigation frequency. After one year, storage costs reach $720 for 24 TB of retained logs.
Log data archival to S3 can reduce costs for long term retention. CloudWatch supports exporting logs to S3, where storage costs drop to $0.023 per GB per month in S3 Standard or $0.004 per GB per month in S3 Glacier. However, archived logs are not searchable in CloudWatch Logs Insights, requiring manual download and local analysis.
Alarms Pricing
Standard metric alarms cost $0.10 per alarm per month. High resolution or anomaly detection alarms cost $0.30 per alarm per month. Composite alarms cost $0.50 per alarm per month.
A production environment monitoring 500 metrics with standard alarms pays $50 per month. Switching to anomaly detection increases that to $150 per month. Teams often over provision alarms during initial setup and accumulate hundreds of unused alarms that continue billing.
Dashboards Pricing
Custom dashboards cost $3 per dashboard per month. Teams managing multiple environments often create separate dashboards for development, staging, and production, plus dashboards for specific services, resulting in 10 to 20 dashboards across the organization. That totals $30 to $60 per month in dashboard fees alone.
Automatic dashboards provided by AWS are free but offer limited customization. For detailed operational visibility, custom dashboards are necessary, and their cost scales linearly with the number of dashboards maintained.
API Request Pricing
CloudWatch charges for API requests used to publish metrics, retrieve metrics, and query logs. GetMetricStatistics, PutMetricData, and DescribeAlarms each cost $0.01 per 1,000 requests.
For applications making frequent API calls, this adds up. A monitoring agent collecting metrics every 10 seconds makes 8,640 requests per day or 259,200 requests per month per metric. For 100 metrics, that totals 25.92 million requests per month, costing $259.
Most teams overlook API request costs until they receive a bill showing hundreds of dollars in CloudWatch API charges. Optimizing collection intervals and batching metric submissions reduces this cost but requires careful tuning to balance cost and monitoring granularity.
Data Transfer Pricing
CloudWatch itself does not charge for data transfer within the same region. However, publishing logs or metrics from EC2 instances to CloudWatch consumes outbound data transfer, which AWS charges at $0.09 per GB after the first 1 GB per month free tier.
For log heavy applications generating 500 GB of logs per month from EC2 instances, data transfer to CloudWatch costs $45 per month in addition to the $250 log ingestion fee. This data transfer cost is often missed in initial cost estimates.
Cost Scenario: Growing Team at Scale
A mid market SaaS company running 100 EC2 instances, generating 2 TB of logs per month, publishing 1,000 custom metrics, and maintaining 200 alarms faces the following monthly CloudWatch costs:
- Custom metrics: 1,000 metrics × $0.30 = $300
- Log ingestion: 2,000 GB × $0.50 = $1,000
- Log storage: 2,000 GB × $0.03 = $60
- Alarms: 200 alarms × $0.10 = $20
- Dashboards: 10 dashboards × $3 = $30
- API requests: 10 million requests × $0.01 / 1,000 = $100
- Data transfer: 500 GB × $0.09 = $45
- Total: $1,555 per month or $18,660 per year
This scenario assumes moderate usage. Enabling detailed EC2 monitoring adds $210 per month. Switching to anomaly detection alarms adds $40 per month. Enabling Container Insights for an EKS cluster with 50 pods adds $300 per month. Costs compound quickly as teams adopt more CloudWatch features.
This estimate models a production deployment with standard retention and monitoring coverage. Actual costs vary based on data volume, alarm count, and feature usage. Verify current rates at [AWS CloudWatch Pricing](https://aws.amazon.com/cloudwatch/pricing/).
Best Practices for AWS CloudWatch Monitoring
Effective CloudWatch monitoring requires deliberate configuration, cost management, and integration with broader observability practices. These best practices help teams maximize visibility while controlling costs.
Use Metric Filters Instead of Custom Metrics Where Possible
Metric filters extract values from logs and publish them as CloudWatch metrics. This is cheaper than publishing custom metrics directly from applications. For example, instead of instrumenting your application to publish an HTTP 5xx error count metric, configure a metric filter to extract 5xx counts from access logs.
Metric filters cost $0.50 per filter per month, while custom metrics cost $0.30 per metric per month. However, metric filters also incur log ingestion costs, so this is only cost effective if you are already sending logs to CloudWatch.
Set Appropriate Log Retention Periods
CloudWatch Logs default to indefinite retention, which maximizes storage costs. Set retention periods based on compliance requirements and investigation needs. For development environments, 7 to 14 days is often sufficient. For production, 30 to 90 days balances cost and operational needs.
Exporting older logs to S3 reduces long term storage costs while maintaining access for compliance or historical analysis. Automate log export using Lambda functions triggered by CloudWatch Events.
Batch Metric Publishing to Reduce API Costs
Applications publishing metrics one at a time generate high API request volumes. The PutMetricData API supports batching up to 40 metrics per request. Batching reduces API costs by 40× and improves performance by reducing network round trips.
Most AWS SDKs support batching natively. Configure your instrumentation library to buffer metrics and publish them in batches every 10 to 60 seconds.
Use Composite Alarms to Reduce Alert Noise
Single metric alarms often fire on transient issues that resolve themselves. Composite alarms combine multiple signals and reduce false positives. For example, a composite alarm requiring both high CPU and high memory utilization fires only when the system is genuinely under load, not during brief spikes.
Composite alarms cost more ($0.50 per alarm vs. $0.10), but they reduce alert fatigue and improve signal to noise ratio in production environments.
Enable Detailed Monitoring Only Where Necessary
Detailed monitoring provides one minute metric resolution for EC2 instances at $2.10 per instance per month. For most workloads, five minute resolution is sufficient. Enable detailed monitoring only on critical instances where rapid detection of issues is necessary.
Use high resolution custom metrics sparingly. Most applications do not need sub minute granularity. Standard one minute resolution balances cost and visibility for typical monitoring needs.
Automate Alarm Management with Infrastructure as Code
Managing hundreds of alarms manually leads to configuration drift and outdated thresholds. Use infrastructure as code tools like AWS CloudFormation, Terraform, or AWS CDK to define and deploy alarms consistently across environments.
Automate alarm updates when application baselines change. For example, after deploying a performance optimization that reduces average latency by 30%, update alarm thresholds to match the new baseline.
Integrate CloudWatch with Centralized Observability Platforms
CloudWatch is essential for AWS infrastructure monitoring but lacks the application level depth and distributed tracing capabilities of modern observability platforms. Teams running microservices, Kubernetes, or multi cloud deployments often integrate CloudWatch with tools that provide unified visibility across AWS and non AWS systems.
Platforms like infrastructure monitoring tools aggregate CloudWatch metrics alongside application traces, logs, and Kubernetes metrics in a single interface. This reduces context switching and improves mean time to resolution during incidents.
AWS CloudWatch Agent: System Level Metrics Collection
The CloudWatch agent extends CloudWatch’s default monitoring to include system level metrics not available through basic AWS service monitoring. It runs on EC2 instances, on premises servers, and hybrid environments, collecting memory utilization, disk space, process stats, and custom application metrics.
What the CloudWatch Agent Collects
The agent collects metrics such as memory utilization (not available in default EC2 monitoring), disk space usage, swap usage, and per process CPU and memory consumption. It also collects and forwards logs from files, systemd journals, and Windows Event Logs to CloudWatch Logs.
This data fills critical gaps in default CloudWatch monitoring. Without the agent, you cannot monitor memory utilization or disk space usage on EC2 instances, which are common causes of application failures.
Installing and Configuring the CloudWatch Agent
The agent is installed using an installer package available from AWS. Configuration is defined in a JSON file specifying which metrics and logs to collect and how frequently to publish them to CloudWatch.
AWS Systems Manager can distribute the agent and its configuration across fleets of instances automatically. This simplifies deployment but requires configuring IAM roles that allow instances to publish metrics and logs to CloudWatch.
Agent configuration requires balancing granularity and cost. Collecting metrics every 10 seconds generates more data than collecting every 60 seconds, improving detection speed but increasing API request costs and metric storage fees.
Cost Implications of the CloudWatch Agent
The agent publishes custom metrics, which cost $0.30 per metric per month for the first 10,000 metrics. Each system level metric (memory, disk, swap) counts as a separate metric per instance. For 100 instances collecting 5 metrics each, that totals 500 metrics or $150 per month.
Teams often enable the agent across all instances without considering cost. A more cost effective approach enables the agent on critical instances only, or configures it to collect fewer metrics and publish at lower frequency for non production environments.
Monitoring Kubernetes and Containers with CloudWatch Container Insights
CloudWatch Container Insights provides visibility into Amazon ECS, Amazon EKS, and Kubernetes clusters running on EC2. It collects metrics at the cluster, node, pod, and container level, surfacing resource utilization, performance, and operational health.
What Container Insights Monitors
Container Insights collects CPU, memory, disk, and network metrics for clusters, nodes, pods, and containers. It tracks pod restarts, container image pull time, and resource throttling. For EKS clusters, it integrates with Kubernetes API server logs and control plane metrics.
Container Insights uses the CloudWatch agent deployed as a DaemonSet on each node. The agent scrapes metrics from the Kubelet and container runtime, publishes them to CloudWatch, and forwards logs from container stdout and stderr streams.
Cost of Container Insights
Container Insights publishes custom metrics, which cost $0.30 per metric per month. A Kubernetes cluster with 50 pods publishing 20 metrics each generates 1,000 metrics, costing $300 per month. For large clusters with hundreds of pods, this scales into thousands of dollars per month.
Log ingestion adds further cost. Kubernetes control plane logs and application logs from containers are sent to CloudWatch Logs at $0.50 per GB. A busy cluster generating 500 GB of logs per month pays $250 for ingestion plus $15 per month for storage.
Teams often enable Container Insights without understanding the cost implications. For Kubernetes monitoring at scale, Kubernetes monitoring platforms that use Prometheus or OpenTelemetry can provide deeper visibility at lower cost than CloudWatch Container Insights.
Performance Insights for RDS Databases
RDS Performance Insights provides detailed database performance monitoring beyond CloudWatch’s basic RDS metrics. It tracks SQL query performance, database load, wait events, and top SQL statements by execution time or resource consumption.
Performance Insights is a separate service from CloudWatch and has its own pricing: $0.009 per vCPU per hour for the first 7 days of data retention and $0.018 per vCPU per hour beyond that. For a db.r5.4xlarge instance with 16 vCPUs, retention beyond 7 days costs $207 per month.
Performance Insights is useful for identifying slow queries and database bottlenecks but adds significant cost for long term retention. Teams often enable it reactively during incidents rather than running it continuously.
AWS CloudWatch vs. CloudTrail: Understanding the Difference
CloudWatch and CloudTrail serve different purposes and are often confused. CloudWatch monitors performance metrics, logs, and operational health. CloudTrail logs API calls and tracks who did what in your AWS account for security, compliance, and auditing purposes.
What CloudTrail Monitors
CloudTrail records every API call made in your AWS account, capturing the identity of the caller, the time of the call, the source IP address, the request parameters, and the response elements. This creates a detailed audit trail for governance and compliance.
CloudTrail is not a performance monitoring tool. It does not track CPU, memory, or application performance. It tracks actions: who created an EC2 instance, who deleted an S3 bucket, who modified a security group.
CloudWatch and CloudTrail Together
CloudWatch and CloudTrail complement each other. CloudWatch detects that an EC2 instance is experiencing high CPU utilization. CloudTrail logs show who started a load test script that caused the spike. CloudWatch identifies the symptom. CloudTrail identifies the cause.
Both services can trigger alarms and automated responses. CloudWatch Alarms react to performance thresholds. CloudTrail can trigger Lambda functions in response to specific API calls, such as automatically revoking IAM credentials when a high risk action is detected.
Cost Comparison
CloudTrail delivers the first copy of management events to each region at no cost. Additional copies and data events (S3 object level logging, Lambda function invocations) cost $0.10 per 100,000 events. CloudWatch pricing is based on metrics, logs, and alarms as detailed earlier.
For most teams, CloudTrail costs are predictable and low unless extensive data event logging is enabled. CloudWatch costs scale with infrastructure size and monitoring granularity.
When AWS CloudWatch Is Not Enough
CloudWatch is powerful for AWS infrastructure monitoring but has limitations that become apparent as teams adopt microservices, Kubernetes, multi cloud architectures, or need application level observability beyond basic metrics and logs.
No Distributed Tracing
CloudWatch does not provide distributed tracing. Tracing tracks requests as they flow through multiple services, showing where time is spent and where errors occur. Without tracing, diagnosing latency or failures in microservices requires manually correlating logs and metrics across services.
AWS X-Ray provides distributed tracing but is a separate service with its own instrumentation, pricing, and limitations. X-Ray costs $5 per million traces recorded and $0.50 per million traces retrieved. For high traffic applications, this adds thousands of dollars per month.
Many teams prefer observability platforms that unify traces, metrics, and logs in a single interface using OpenTelemetry instrumentation, which is vendor neutral and portable.
Limited Application Performance Monitoring
CloudWatch collects infrastructure metrics but lacks deep application performance monitoring capabilities. It does not surface endpoint level latency breakdowns, database query performance, or code level bottlenecks without extensive custom instrumentation.
Application performance monitoring tools provide automatic instrumentation that captures application traces, error stack traces, and service dependency maps without requiring manual metric publishing.
No Support for Non AWS Infrastructure
CloudWatch is AWS native and does not monitor on premises infrastructure, other cloud providers, or hybrid environments without significant manual configuration. The CloudWatch agent can run on non AWS servers but lacks the integration depth available for AWS services.
Teams running multi cloud or hybrid infrastructure need observability platforms that monitor AWS, Azure, GCP, on premises data centers, and edge locations in a unified view. CloudWatch cannot provide this without extensive custom integration work.
Weak Real User Monitoring
CloudWatch does not provide real user monitoring (RUM) out of the box. RUM tracks frontend performance from actual user browsers, measuring page load times, rendering speed, JavaScript errors, and user interactions. This is critical for understanding end user experience in web applications.
AWS CloudWatch RUM was introduced in late 2021 but remains limited compared to specialized [real user monitoring tools](https://cubeapm.com/blog/what-is-real-user-monitoring-