All Services
Mgmt & Governance
Amazon CloudWatch
Amazon CloudWatch collects and analyzes metrics, logs, traces, events, application signals and synthetic or user telemetry, providing dashboards, alarms, anomaly detection, queries, investigations and automated actions for AWS and custom workloads.
Explore pricing models, common use cases, infrastructure support, and the AWS services that commonly work with Amazon CloudWatch.
Amazon CloudWatch pricing and cost programs
Pricing model: Observability data and feature usage
- On-Demand
- Available
- Reserved Instances or reserved capacity
- Not applicable
- Savings Plans
- Not applicable
- Spot
- Not applicable
Billing dimensions: Metrics · Logs · Traces · Alarms and dashboards
Programs and modes: Metrics and alarms · Logs · Application Signals · Internet and Synthetics monitoring
CloudWatch capabilities have separate ingestion, storage, query, and monitoring dimensions.
Free Tier: Available — verify current offers
Pricing reviewed 2026-07-25. Reviewed against the linked official AWS pricing page. Recheck regional rates and program terms before purchase.
Official AWS pricing
Official AWS sources reviewed 2026-07-21.
Why implement Amazon CloudWatch?
- Provides managed telemetry ingestion, storage, querying, visualization and alarming without operating monitoring database and dashboard fleets.
- Combines native AWS metrics and logs with custom metrics, OpenTelemetry application signals, traces, synthetics, RUM, Contributor Insights and cross-account observability.
- Routes alarms and events into notification, scaling, remediation and incident workflows and supports composite and anomaly-aware alerting.
How to implement Amazon CloudWatch
- Define user-facing objectives, symptoms, owners, severity, runbooks, retention, cardinality, privacy and cost budgets; select metrics, logs, traces and synthetic checks that answer concrete operational questions.
- Instrument workloads consistently, centralize cross-account views, protect log groups with encryption and access controls, set explicit retention, create dashboards and metric math, and build alarms from AWS recommendations plus workload baselines.
- Test each alarm and notification route, link it to a runbook or safe automation, monitor telemetry delivery and spend, tune noise and missing-data handling, and regularly delete unused metrics, logs, dashboards and alarms.
Amazon CloudWatch best practices
- Alert on customer-visible symptoms and exhaustion signals, use composite alarms to suppress cascades, define missing-data behavior deliberately, and give every page an owner and tested response.
- Control custom metric dimensions and log volume because unbounded cardinality, verbose logs and indefinite retention create avoidable cost and can expose sensitive data.
- Use recommended alarms as a starting point rather than a substitute for workload objectives, correlate metrics with logs and traces, and continuously measure alert precision, coverage and time to recovery.
Amazon CloudWatch use cases and server impact
- Infrastructure and application monitoring
- Central log and trace investigation
- SLO dashboards, alarms, and automated remediation
Replaces much monitoring, log-search and alerting infrastructure, while instrumentation, signal quality, sensitive-data controls, retention, dashboard design, on-call ownership, and remediation safety remain yours.
Official implementation resources
How Amazon CloudWatch works with other AWS services
Arrows show the documented technical direction. Reciprocal navigation does not imply a reverse technical dependency.
Official AWS sources reviewed 2026-07-25.
Elastic Load Balancing → Amazon CloudWatch
Elastic Load Balancing publishes operational metrics such as request and target health signals to CloudWatch.
- Why teams use it
- Metrics and alarms help teams detect unhealthy targets, error growth, and capacity symptoms without polling the load balancer.
- Permissions and networking
- Alarm on user-impacting signals with enough evaluation time to avoid flapping, and enable access logs separately when request-level evidence is required.
- Pricing and security caveats
- Basic service metrics and custom alarms have different pricing; metrics do not contain full request or application traces.
AWS Lambda → Amazon CloudWatch
Lambda publishes invocation metrics to CloudWatch and can write function logs to CloudWatch Logs when its execution role permits.
- Why teams use it
- The pairing provides a default operational view for errors, duration, throttles, and application output.
- Permissions and networking
- Use structured logs, retention policies, metric filters or embedded metrics, and alarms; never log credentials, tokens, or sensitive payloads.
- Pricing and security caveats
- High-volume logs, custom metrics, queries, and retention can become material costs, and telemetry delivery is not a substitute for idempotent error handling.
Amazon Elastic Container Service → Amazon CloudWatch
ECS can send container logs to CloudWatch Logs and Container Insights can collect aggregated cluster, service, task, and container metrics.
- Why teams use it
- Centralized telemetry helps teams correlate deployment state with resource pressure and application failures.
- Permissions and networking
- Configure log drivers, retention, encryption, and execution-role permissions; enable enhanced observability only where its detail is useful.
- Pricing and security caveats
- Container Insights and log ingestion add charges beyond ECS or Fargate compute, and high-cardinality telemetry can increase cost quickly.
Amazon Elastic Kubernetes Service → Amazon CloudWatch
CloudWatch Container Insights can collect metrics and logs from EKS clusters, nodes, pods, and containers.
- Why teams use it
- The integration gives platform teams AWS-native dashboards and alarms for Kubernetes workload health.
- Permissions and networking
- Deploy and authorize the observability components, set log retention, scrub sensitive fields, and account for Fargate versus node collection differences.
- Pricing and security caveats
- Logs and enhanced metrics are separately billed; observability agents consume workload resources and do not replace Kubernetes-native health checks.
Amazon Relational Database Service → Amazon CloudWatch
RDS publishes service metrics to CloudWatch and can export selected database logs for centralized retention and analysis.
- Why teams use it
- Teams can alarm on capacity and availability symptoms while correlating database behavior with application telemetry.
- Permissions and networking
- Enable only needed log exports, restrict log access, and combine metrics with database-native diagnostics for engine-level analysis.
- Pricing and security caveats
- Enhanced monitoring, Performance Insights features, log ingestion, storage, and alarms can add cost; metrics alone do not prove query root cause.
AWS WAF → Amazon CloudWatch
AWS WAF publishes rule and web ACL metrics to CloudWatch so teams can monitor allowed, blocked, counted, and challenged requests.
- Why teams use it
- Count-mode metrics support safe rule tuning before enforcement and make attack or false-positive trends visible.
- Permissions and networking
- Use stable metric names, alarm on meaningful rates, and keep sampled-request or logging access tightly controlled because requests may contain sensitive data.
- Pricing and security caveats
- WAF logs, CloudWatch metrics, alarms, and queries can add separate charges; aggregate metrics are not a complete forensic record.
AWS CloudTrail → Amazon CloudWatch
CloudTrail can send trail events to a CloudWatch Logs log group, where metric filters and alarms detect selected API activity.
- Why teams use it
- The pairing turns audit events into near-real-time operational alerts without replacing the durable trail archive.
- Permissions and networking
- Create the delivery role and log group deliberately, limit access to audit data, set retention, and design filters to avoid noisy or bypassable alerts.
- Pricing and security caveats
- CloudWatch Logs ingestion, storage, queries, metrics, and alarms add charges, and delivery latency means this is not an inline authorization control.
Architecture patterns using this service
- Run a containerized web application on Amazon ECS and Fargate — Store immutable images in Amazon ECR, deploy tasks with Amazon ECS on AWS Fargate, route HTTP traffic through an Application Load Balancer, and observe the service in CloudWatch.
- Scan uploaded objects for malware and quarantine them on AWS — Land untrusted uploads in a private Amazon S3 bucket, scan them with GuardDuty Malware Protection for S3, route scan results through EventBridge and SQS, and promote only clean objects to a bucket consumers can read.
- Run queue-backed asynchronous workers on AWS — Buffer background work in Amazon SQS, process it with Lambda or ECS workers under a concurrency ceiling, keep state in DynamoDB, and use dead-letter queues, redrive, and CloudWatch alarms to keep the system honest.
- Fan out AWS events to isolated consumers — Publish one event to EventBridge or SNS, give every consumer its own SQS queue, retry policy, and dead-letter queue, and let each consumer scale, fail, and deploy without touching the others.
Planning guides that use Amazon CloudWatch
- Amazon API Gateway planning guide — Use CloudWatch access logs, metrics, dashboards, and alarms to observe API and integration failures.
- Amazon Managed Workflows for Apache Airflow planning guide — Use CloudWatch logs, metrics, dashboards, and alarms for scheduler, worker, and task health.
- AWS AppConfig planning guide — Use CloudWatch alarms as deployment monitors that can trigger automatic rollback.
- AWS Elastic Beanstalk planning guide — Use CloudWatch metrics, logs, and health reporting to see why an environment degrades before it rolls back.
- Amazon Keyspaces (for Apache Cassandra) planning guide — Watch CloudWatch capacity, throttling, and latency metrics before changing a table's capacity mode.
- AWS CloudTrail planning guide — Send trail events to CloudWatch Logs for metric filters and alarms on specific API activity.