Amazon CloudWatch Pricing: Complete Guide + Calculator (2026)

Amazon CloudWatch pricing looks simple on the surface. Then you get your first real bill and realize there are 15+ billing dimensions, tiered log ingestion, and costs that multiply in ways the pricing page doesn't make obvious. I've seen teams underestimate their CloudWatch spend by 2-4x because they only looked at one or two pricing tables instead of understanding how all the components interact.

This guide breaks down every CloudWatch pricing component with exact dollar amounts, three architecture-based cost scenarios, and the hidden gotchas that silently inflate your bill. If you want a quick personalized estimate, use the CloudWatch pricing calculator to model your specific workload. For broader cost planning, see our AWS cost estimation guide.

All pricing data in this article is sourced from the official AWS CloudWatch pricing page as of February 2026 for US East (N. Virginia). Other regions can be 10-25% higher.

What Is Amazon CloudWatch (and Why Pricing Gets Complicated)

Amazon CloudWatch is AWS's native monitoring and observability service. It collects metrics, logs, and traces from your AWS resources, applications, and on-premises servers. It includes dashboards, alarms, anomaly detection, log analytics (Logs Insights), synthetic monitoring, real-user monitoring (RUM), and application performance monitoring (X-Ray and Application Signals).

Here's why pricing trips people up: unlike S3 or Lambda where you can estimate costs from 2-3 variables, CloudWatch charges across metrics, logs, alarms, dashboards, API calls, and observability features simultaneously. There are no Savings Plans, no reserved capacity, and no committed-use discounts. It's pure consumption-based pricing, and every billing dimension has its own unit, tier, and free allowance. Metrics are uniquely identified by name + namespace + up to 30 dimensions, and they auto-expire after 15 months of inactivity.

The result is a pricing model where a simple single-service app costs $3/month, but a mid-size microservices deployment with default settings can easily hit $300/month or more, most of it from costs the team didn't anticipate.

CloudWatch Free Tier: What You Actually Get

Before getting into paid pricing, let me be clear about what's free. The free tier is generous for small workloads, but the limits are tighter than most teams realize.

Two things that catch people off guard:

• Free tiers do not pool across regions. Running in 3 regions doesn't give you 15 GB of free log ingestion. You get 5 GB per region, but each region's usage is evaluated independently.
• The 5 GB log allowance covers ingestion, storage, and Insights queries combined. If you ingest 5 GB and then query it, you've exceeded the free tier.

A simple single-service app can genuinely run within these limits. The moment you add a second service, enable detailed EC2 monitoring, or start shipping application logs, you start paying.

CloudWatch Pricing Breakdown: Every Component Explained

The diagram below shows how CloudWatch's billing components relate to each other. Each box represents a separate charge, and data flowing through the system hits multiple billing meters.

Custom Metrics Pricing

Custom metrics are the single largest cost driver for many organizations, accounting for roughly 35% of typical CloudWatch spend. Each metric is billed per month, prorated hourly.

The key thing to understand: each unique combination of metric name + namespace + dimensions creates a separate billable metric. This is where costs explode. A metric called RequestLatency with dimensions {Service, Environment, Region} creates one metric per unique combination. If you have 10 services across 3 environments and 4 regions, that's 120 metrics from a single metric name.

Add a high-cardinality dimension like userId and things get expensive fast. A single metric name with 1,000 unique dimension values = 1,000 billable metrics = $300/month at the first tier.

Standard vs high-resolution metrics cost the same per metric, but high-resolution (1-second intervals) drives significantly more PutMetricData API calls.

Logs Pricing (The Biggest Cost Driver at Scale)

Logs are where CloudWatch bills surprise people most, because you pay three separate times for the same data: ingestion, storage, and query. I think of it as the triple-charge model.

Standard Log Class

Infrequent Access Log Class

Storage and Analytics (Both Classes)

The Infrequent Access class saves 50% on ingestion, with identical storage and Logs Insights pricing. But there's a meaningful trade-off:

And here's the kicker: log class cannot be changed after a log group is created. This is an irreversible decision. If you create a log group as Infrequent Access and later realize you need metric filters, you'll need to create a new log group and redirect your applications to it.

My recommendation: if the only thing you do with a log group is run Logs Insights queries during debugging, use Infrequent Access. If you depend on metric filters or subscription filters for operational workflows, stick with Standard.

Vended Logs (Lambda, VPC Flow Logs, Route 53)

Vended logs, logs generated by AWS services, use the same tiered pricing as Standard logs. But here's the important detail: all vended logs in an account consolidate for tier calculation. Your Lambda logs, VPC Flow Logs, and Route 53 resolver logs all count toward the same volume tiers.

This matters a lot for cost. An account generating 5 TB of Lambda logs and 8 TB of VPC Flow Logs gets the combined 13 TB evaluated against the tiers: 10 TB at $0.50/GB + 3 TB at $0.25/GB, instead of each service starting from the first tier independently.

2025 pricing change you need to know about: In May 2025, AWS reclassified Lambda logs as vended logs and introduced tiered pricing. Before this change, all Lambda log ingestion was a flat $0.50/GB regardless of volume. Now, an organization generating 60 TB of Lambda logs monthly sees costs drop from $30,000 to $12,500 (58% reduction). If you're reading a CloudWatch pricing guide that shows a flat $0.50/GB for Lambda logs, it's outdated.

AWS also added S3 and Amazon Data Firehose as alternative Lambda log destinations, with ingestion starting at $0.25/GB. For Lambda functions that generate high log volumes but don't need real-time analysis, routing logs to S3 can cut costs significantly.

For a deeper look at Lambda cost optimization, see the Lambda pricing calculator.

Alarms Pricing

Free tier: 10 standard-resolution alarm metrics.

Two traps to watch for:

Anomaly detection alarms cost 3x because they monitor three metrics internally: the actual metric value, the upper bound of the expected band, and the lower bound. Five anomaly detection alarms = $1.50/month minimum, not $0.50.

Alarms on deleted resources keep charging. When you terminate an EC2 instance or delete a Lambda function, any associated alarms don't automatically clean themselves up. They enter INSUFFICIENT_DATA state and continue billing. If you want to test your alarm setup before relying on it, here's how to trigger a CloudWatch alarm using the AWS CLI.

Dashboards Pricing

Free tier: 3 custom dashboards referencing up to 50 metrics each.

At $3/month each, dashboards are a relatively small cost. But I've seen accounts with 30+ dashboards that nobody uses. That's $90/month of waste. Use CloudWatch's free automatic dashboards first. They're actually quite good for service-level overview. Only create custom dashboards for specific operational views your team checks regularly.

API Request Pricing

The one to watch is GetMetricData. It has no free tier and is charged from the first call. If you're using third-party monitoring tools that poll CloudWatch for metrics, or you have dashboards with many widgets refreshing frequently, GetMetricData costs add up. Consider metric streams ($0.003 per 1,000 updates) as a potentially cheaper alternative for pushing metrics to external systems. For more on this and other cost reduction strategies, see AWS cost optimization best practices.

Advanced Features: Quick Reference

These features aren't part of every CloudWatch deployment, but their costs are worth knowing before you enable them.

Hidden Costs and Billing Gotchas

This is where CloudWatch pricing gets real. These seven cost traps don't appear in most pricing guides, but they're responsible for the majority of "why is my CloudWatch bill so high?" posts on AWS re:Post and DEV Community.

1. Dimension Multiplication

The most expensive mistake I see. Publishing a custom metric with a high-cardinality dimension like userId, requestId, or instanceId turns one metric into thousands. A single metric name with 10,000 unique dimension values creates 10,000 billable metrics: $3,000/month at the first pricing tier.

The fix: use low-cardinality dimensions (service name, environment, region) and aggregate high-cardinality data before publishing. If you need per-user metrics, consider Logs Insights queries instead.

2. The Triple-Charge Log Model

You pay to ingest logs ($0.50/GB), store them ($0.03/GB/month), and query them ($0.005/GB scanned). The headline price is "$0.50/GB" for log ingestion, but the effective cost of ingesting and analyzing a log entry is closer to $0.535/GB in the first month, and storage costs keep accruing every month you retain the data.

3. Default "Never Expire" Log Retention

This is the silent bill grower. CloudWatch's default log retention is "Never Expire," meaning storage costs compound forever. A log group ingesting 10 GB/month at $0.03/GB storage accumulates $3.60/year in perpetual storage charges. Across 50 log groups, that's $180/year in storage alone, growing every month. For a step-by-step guide on automating retention policies across all your log groups, see how to set CloudWatch Logs retention policy using Python.

4. Anomaly Detection 3x Markup

Each anomaly detection alarm creates three billable alarm metrics (actual value + upper band + lower band), costing $0.30/month instead of $0.10. If you're running anomaly detection on 50 metrics, that's $15/month in alarms, not $5.

5. Orphaned Alarms

Alarms on terminated EC2 instances, deleted Lambda functions, or removed Auto Scaling groups continue to charge. They enter INSUFFICIENT_DATA state but never auto-delete. I've seen accounts with hundreds of orphaned alarms costing $20-50/month. Audit regularly:

aws cloudwatch describe-alarms --state-value INSUFFICIENT_DATA \
  --query 'MetricAlarms[].AlarmName' --output table

6. Non-Pooling Free Tiers Across Regions

If you deploy to us-east-1, eu-west-1, and ap-southeast-1, you don't get 3x the free tier. Each region has its own free allowance, but that also means each region starts billing independently. A deployment that would be free in one region might cost money when spread across three, depending on how usage distributes.

7. Logs Insights Costs During Incidents

When you're debugging a production outage, you're running ad-hoc Logs Insights queries across large time ranges and multiple log groups. At $0.005/GB scanned, querying 500 GB of logs during an incident costs $2.50. Not catastrophic, but during a prolonged incident with multiple engineers running queries, it adds up.

Real-World Cost Scenarios

Instead of calculating each component in isolation, here's what CloudWatch actually costs for common AWS architectures.

Small Startup: Simple Serverless App (~$3/month)

A single Lambda function behind API Gateway, writing to DynamoDB. Basic monitoring.

At this scale, CloudWatch is genuinely cheap. You could run for years without thinking about monitoring costs.

Mid-Size Application: Microservices (~$290/month)

10-15 microservices on ECS Fargate, each with its own log group, custom metrics, and alarms. A few dashboards for the platform team.

Notice where the money goes: custom metrics ($150) and log ingestion ($100) account for 90% of the bill. Alarms, dashboards, and API calls are almost negligible. If this team used the Infrequent Access log class, they'd save $50/month on log ingestion alone.

Enterprise Deployment: Large-Scale Production (~$9,250/month)

50+ microservices, VPC Flow Logs enabled, X-Ray tracing, metric streams to an external monitoring tool. This is where tiered pricing and optimization strategies really matter.

The optimization opportunity here is significant. Switching 5 TB of application logs to Infrequent Access saves $1,250/month. Setting 30-day retention instead of 90-day cuts storage costs by two-thirds ($900/month savings). Routing VPC Flow Logs to S3 instead of CloudWatch saves even more since S3 Standard storage is $0.023/GB versus CloudWatch's $0.03/GB, plus you skip the $0.50/GB ingestion fee entirely. If VPC Flow Logs are a significant cost driver, also check whether your NAT Gateway data processing fees are contributing to the bill.

8 Ways to Reduce Your CloudWatch Bill

These are ordered by impact, starting with the changes that save the most money for the least effort.

1. Set Retention Policies on Every Log Group

The single highest-impact change. Default "Never Expire" retention means storage costs grow forever. Set 30 days for development, 60 days for production, and export to S3 anything you need for compliance.

aws logs put-retention-policy \
  --log-group-name /aws/lambda/my-function \
  --retention-in-days 30

To do this across all log groups programmatically, see this Python script for setting CloudWatch Logs retention policy.

2. Use the Infrequent Access Log Class

If you only query logs through Logs Insights (no metric filters, no subscription filters, no Live Tail), the IA class cuts ingestion costs in half. For a team ingesting 200 GB/month, that's $50/month saved.

Remember: this is irreversible per log group. Create new log groups as IA, don't try to convert existing ones.

3. Audit Custom Metric Dimensions

Find and eliminate high-cardinality dimensions. Run this to see all your metrics and their dimension counts:

aws cloudwatch list-metrics \
  --namespace "MyApp" \
  --query 'Metrics[].Dimensions' \
  --output json | jq 'group_by(.[].Name) | map({dimension: .[0][0].Name, count: length}) | sort_by(-.count)'

If any dimension has hundreds or thousands of unique values, you've found your cost leak.

4. Route High-Volume Logs to S3

For compliance-oriented logs like CloudTrail events, VPC Flow Logs, and access logs, route directly to S3 instead of CloudWatch. The cost difference is dramatic:

• CloudWatch: $0.50/GB ingestion + $0.03/GB storage = $0.53/GB first month
• S3 + Athena: ~$0.023/GB storage + $0.005/GB query = ~$0.028/GB first month

That's an 18x cost difference. You lose real-time metric filters and Live Tail, but for logs you only query during audits, S3 + Athena is the better choice.

5. Clean Up Orphaned Alarms

Find alarms stuck in INSUFFICIENT_DATA (likely monitoring deleted resources) and remove them:

aws cloudwatch describe-alarms \
  --state-value INSUFFICIENT_DATA \
  --query 'MetricAlarms[].{Name:AlarmName,Metric:MetricName,Namespace:Namespace}' \
  --output table

Review the list before deleting. Some alarms legitimately enter INSUFFICIENT_DATA temporarily (for example, during deployments).

6. Use Composite Alarms

Instead of 5 separate alarms triggering 5 separate SNS notifications for related conditions, create one composite alarm that fires only when the right combination of conditions is met. This reduces alarm count, lowers cost, and cuts alert fatigue.

7. Leverage Vended Log Tier Consolidation

All vended logs in an account (Lambda, VPC Flow Logs, Route 53) count toward the same volume tiers. If you have multiple accounts generating moderate vended log volumes, consider whether consolidating logging into fewer accounts could push you into lower pricing tiers. The tiering applies per individual AWS account, not across an organization.

8. Disable Unnecessary Detailed Monitoring

EC2 detailed monitoring generates 7 metrics per instance at 1-minute intervals, each costing $0.30/month. For a fleet of 100 instances, that's $210/month. Standard monitoring (5-minute intervals) is free. Only enable detailed monitoring on instances where you genuinely need 1-minute metric resolution.

Bonus: Find Your Top CloudWatch Cost Drivers with Athena

If you have AWS Cost and Usage Reports enabled, this Athena query shows exactly where your CloudWatch spend is going:

SELECT
  CASE
    WHEN line_item_usage_type LIKE '%MetricMonitorUsage%' THEN 'Metrics (Custom/Detailed)'
    WHEN line_item_usage_type LIKE '%Requests%' THEN 'Metrics (API Requests)'
    WHEN line_item_usage_type LIKE '%GMD-Metrics%' THEN 'Metrics (Bulk API)'
    WHEN line_item_usage_type LIKE '%AlarmMonitorUsage%' THEN 'Alarms (Standard)'
    WHEN line_item_usage_type LIKE '%HighResAlarmMonitorUsage%' THEN 'Alarms (High Resolution)'
    WHEN line_item_usage_type LIKE '%DataProcessing-Bytes%' THEN 'Logs (Ingestion)'
    WHEN line_item_usage_type LIKE '%TimedStorage-ByteHrs%' THEN 'Logs (Storage)'
    WHEN line_item_usage_type LIKE '%DataScanned-Bytes%' THEN 'Logs (Insights Queries)'
    WHEN line_item_usage_type LIKE '%MetricStreamUsage%' THEN 'Metric Streams'
    ELSE 'Others'
  END AS usage_category,
  SUM(CAST(line_item_unblended_cost AS decimal(16,8))) AS total_spend
FROM costandusagereport
WHERE product_product_name = 'AmazonCloudWatch'
  AND year = '2026' AND month = '2'
GROUP BY 1
ORDER BY total_spend DESC;

This breaks your CloudWatch bill into actionable categories so you know exactly which component to optimize first.

For a complete framework on reducing AWS costs beyond CloudWatch, see the AWS cost optimization checklist.

CloudWatch Pricing Changes in 2025-2026

CloudWatch pricing has seen meaningful changes recently. If you're reading older guides, they're likely missing these updates.

May 2025: Tiered Vended Log Pricing. The biggest change. Lambda logs were reclassified as vended logs and gained tiered pricing. Before this, all Lambda log ingestion was a flat $0.50/GB. The new tiers can reduce costs by up to 90% at high volumes. Lambda also gained S3 and Data Firehose as alternative log destinations. For most teams generating 10+ TB/month of Lambda logs, this is a significant bill reduction without any configuration changes.

September 2025: Tag-Based Telemetry. CloudWatch now supports monitoring metrics and setting up alarms using AWS resource tags. Alarms automatically adapt as tagged resources change. This can reduce the number of individual alarms you need to maintain.

December 2025 (re:Invent): Unified Data Management. CloudWatch data can now be made available in managed Amazon S3 Tables (Apache Iceberg format) at no additional storage charge. This means you can query CloudWatch data from Athena, Redshift, or SageMaker Studio without paying CloudWatch Logs Insights pricing.

December 2025: CloudWatch Investigations GA. AI-powered incident resolution with automated root cause analysis. Pricing is limited to 2 concurrent and 150 monthly investigations per region.

Upcoming: Performance Insights Deprecation. AWS is replacing Performance Insights with CloudWatch Database Insights. Migration deadline is June 2026.

FAQ

What This All Means

CloudWatch's pay-as-you-go model rewards understanding. The difference between a $300 and $3,000 monthly bill often comes down to three things: log retention settings, metric dimension hygiene, and choosing the right log class. Most teams can cut 20-40% of their CloudWatch spend in an afternoon just by setting retention policies and switching non-critical log groups to Infrequent Access.

If you want to estimate your specific CloudWatch costs before making changes, try the CloudWatch pricing calculator. And if you're managing infrastructure with AWS CDK or Terraform, consider catching cost-impacting changes during code review instead of discovering them on next month's bill.