Amazon CloudWatch pricing can become hard to estimate as usage grows because AWS bills logs, metrics, alarms, dashboards, and several advanced features separately. This calculator helps you estimate the main CloudWatch cost components using current us-east-1 pricing as of April 2026. Adjust the inputs above to match your workload, then read below to understand what drives each line item
Quick Reference: CloudWatch Pricing at a Glance (US East — N. Virginia)
*Pricing varies by region. All figures reflect us-east-1 as of April 2026.
| Component | Free Tier | Paid Rate |
| Custom Metrics | 10 metrics/month | $0.30 per metric for first 10,000; $0.10 per metric for next 240,000; $0.05 per metric above 250,000 |
| Log Ingestion (Standard class) | 5 GB/month of CloudWatch Logs usage | $0.50/GB for first 10 TB; $0.25/GB for next 20 TB; $0.10/GB for next 20 TB; $0.05/GB above 50 TB |
| Log Ingestion (Infrequent Access class) | — | Starts at $0.25/GB for eligible logs |
| Log Storage (archived) | Included within logs free tier | $0.03/GB/month |
| Logs Insights Queries | 5 GB scanned/month | $0.005/GB scanned |
| Standard Alarms | 10 alarm metrics/month | $0.10 per alarm metric/month |
| High-Resolution Alarms | — | $0.30 per alarm metric/month |
| Anomaly Detection Alarms | — | Effectively 3 standard alarm metrics per alarm, so about $0.30/month for one standard anomaly alarm |
| Composite Alarms | — | $0.50/alarm/month |
| Custom Dashboards | 3 dashboards/month | $3/dashboard/month |
| API Requests | 1 million requests/month | $0.01 per 1,000 requests |
| Canary Runs (CloudWatch Synthetics) | 100 runs/month | $0.0012/run |
| Container Insights (EKS enhanced observability) | — | $0.21 per million observations for first 1 billion, then lower tiers at higher volume |
| Metric Streams | — | $0.003 per 1,000 metric updates |
| Contributor Insights | 1 rule + first 1 million matched log events/month | $0.50 per additional rule/month + $0.02 per 1 million matched log events |
| RUM Events | — | $1.00 per 100,000 events |
How Amazon CloudWatch Pricing Works
Amazon CloudWatch uses a pay-as-you-go pricing model. There is no base subscription fee. You pay for the specific CloudWatch features you use, and charges are split across several separate components such as metrics, logs, alarms, dashboards, and advanced monitoring features.
The free tier is useful for small workloads. It includes 10 custom metrics, 5 GB of CloudWatch Logs usage, 10 alarm metrics, 3 dashboards, and 1 million API requests per month. In real production environments, teams often move past these limits quickly as they add more services, custom metrics, logs, dashboards, and alarms.
A simple way to understand CloudWatch pricing is to break it into five main cost areas: metrics, logs, alarms, dashboards, and advanced features such as Container Insights, Synthetics, Contributor Insights, RUM, and Application Signals. Each area has its own pricing model, and some of them also have their own free-tier allowances.
CloudWatch Metrics Pricing: What You’re Actually Paying For
Standard vs. Custom Metrics
Standard metrics are the built-in metrics that AWS services publish automatically, such as CPU utilization for EC2 or invocation count for Lambda. These standard service metrics are generally included at no extra CloudWatch metrics charge. You pay for custom metrics, which are metrics you publish to CloudWatch yourself, including metrics sent through the PutMetricData API or the CloudWatch agent.
In us-east-1, custom metrics are priced in tiers:
- First 10,000 metrics: $0.30 per metric per month
- Next 240,000 metrics: $0.10 per metric per month
- Above 250,000 metrics: $0.05 per metric per month
The Dimension Explosion Problem
Each unique combination of metric name and dimensions is counted as a separate custom metric. That means adding high-cardinality dimensions can increase costs very quickly, because every distinct dimension set is billed as its own metric.
Prorated Hourly Billing
Custom metrics are not charged as all-or-nothing monthly flat fees. They are prorated by the hour and billed only while metrics are being sent to CloudWatch. This means short-lived metrics cost less than metrics that run all month. AWS also applies the same hourly prorating idea to detailed monitoring.
Detailed Monitoring for EC2
EC2 Detailed Monitoring is billed as 7 custom metrics per instance, prorated hourly. So if you enable Detailed Monitoring on 50 EC2 instances for a full month, that equals 350 custom metrics. At the first-tier rate, that is about $105 per month before any higher-volume tier pricing applies.
CloudWatch Logs Pricing: Where Bills Grow the Fastest
Log Ingestion Costs
CloudWatch Logs is often one of the biggest cost drivers in a CloudWatch bill, especially as log volume grows. In us-east-1, standard log ingestion uses tiered pricing:
- $0.50/GB for the first 10 TB per month
- $0.25/GB for the next 20 TB
- $0.10/GB for the next 20 TB
- $0.05/GB above 50 TB
For log groups that do not need the full feature set of the Standard class, CloudWatch Logs Infrequent Access starts at a lower ingestion price and is designed for logs you query less often. AWS launched this class at 50% lower per-GB ingestion price than the Standard class, while still supporting Logs Insights queries.
Lambda Log Pricing Change
AWS introduced volume-tiered pricing for AWS Lambda logs sent to CloudWatch Logs on May 1, 2025. Before that change, Lambda logs were commonly priced at a flat $0.50/GB in us-east-1. Under the newer model, Lambda logs sent to CloudWatch Logs now start at $0.50/GB and tier down as volume increases, reaching rates as low as $0.05/GB in the lowest tier. AWS says this change applies automatically and does not require code or configuration changes.
Log Storage and the “Never Expire” Default
CloudWatch charges separately for archived log storage after the free tier, at $0.03/GB per month in us-east-1. If log groups are left on long retention or never-expire settings, storage costs can build up over time even if ingestion stays flat. Setting shorter retention periods for debug or development logs is one of the simplest ways to reduce cost without losing useful visibility.
Logs Insights Query Costs
CloudWatch Logs Insights charges $0.005 per GB of log data scanned. The cost depends on how much data your query reads, not on how many results it returns. Narrower time ranges and smaller log group selections help reduce query cost.
Main fixes from your draft:
- Changed the standard log ingestion tiers to include the missing $0.10/GB band between 30 TB and 50 TB.
- Changed the Lambda logs pricing date from May 2026 to May 1, 2025.
- Removed the exact “60 TB = roughly $12,500 instead of $30,000” example because your draft did not show the full calculation and it is better to keep this section precise and source-safe.
CloudWatch Alarms Pricing
CloudWatch alarms are billed based on alarm type and how many metrics are involved. Standard-resolution metric alarms cost $0.10 per alarm metric per month, while high-resolution metric alarms cost $0.30 per alarm metric per month in us-east-1.
A simple alarm that watches one metric costs $0.10 per month. If you create a metric math alarm that references multiple metrics, the cost goes up because CloudWatch bills per alarm metric. For example, an alarm that evaluates 10 metrics would cost about $1.00 per month.
An anomaly detection alarm costs more than a standard metric alarm because it uses three alarm metrics: the actual metric, the upper expected band, and the lower expected band. That makes one standard-resolution anomaly detection alarm cost about $0.30 per month.
Composite alarms are billed differently. They are charged per composite alarm, not per metric, at $0.50 per composite alarm per month. This is separate from the cost of any underlying metric alarms they reference.
One practical issue to watch for is stale alarms. If you delete an EC2 instance or Lambda function, the related CloudWatch alarms do not automatically get deleted. They can stay in place and continue billing until you remove them manually, so it is worth reviewing old alarms regularly.
Dashboards, Container Insights, and Advanced Features
- Custom Dashboards:
- The first 3 custom dashboards each month are included in the free tier.
- After that, custom dashboards cost $3 per dashboard per month in us-east-1.
- AWS also notes that automatic dashboards are free.
- Container Insights (EKS enhanced observability):
- Pricing is based on observations, not hosts.
- In us-east-1, AWS charges $0.21 per million observations for the first 1 billion observations each month.
- The rate then drops to lower tiers as volume increases.
- Synthetics canaries:
- The free tier includes 100 canary runs per month.
- After that, CloudWatch Synthetics costs $0.0012 per run.
- A canary that runs every 5 minutes would run about 8,640 times in a 30-day month.
- That works out to about $10.37 in canary charges before adding Lambda, logs, metrics, and any storage costs created by the canary.
- CloudWatch RUM:
- AWS includes a first-time free trial with 1 million web RUM events per account.
- After that, RUM is billed separately based on event volume.
- In your quick reference table, keeping this as $1.00 per 100,000 events is correct for us-east-1.
- Contributor Insights:
- The free tier includes 1 Contributor Insights rule per month.
- It also includes the first 1 million log events that match the rule each month.
- After that, Contributor Insights has separate paid charges for additional rules and matched events.
- Application Signals:
- AWS treats Application Signals as its own application observability pricing area.
- The free usage depends on which Application Signals mode you use.
- For the version that includes transaction visibility, AWS gives 3 months of free usage up to 100 GB ingested or 1 million indexed spans, whichever comes first.
- For the golden-metrics-only version, AWS gives 3 months of free usage up to 100 million signals, whichever comes first.
- Because of that, it is better to model Application Signals as its own calculator input instead of folding it into a small flat add-on line.
Real-World CloudWatch Cost Scenarios
Small Serverless App (~$3–$8/month)
A simple serverless application with 3–5 Lambda functions, low log volume, a small number of custom metrics, and a few alarms can stay close to the free tier. Expect low monthly costs once you go beyond the free allowance for dashboards, custom metrics, or log ingestion. This range is reasonable as a light-usage example, but it should be treated as an estimate based on usage patterns, not as an AWS benchmark.
Mid-Size Microservices Deployment (~$250–$500/month)
A production microservices setup with multiple services, EC2 instances using Detailed Monitoring, custom metrics from the CloudWatch agent, regular log ingestion, dozens of alarms, several dashboards, and occasional Logs Insights queries can move into the few-hundred-dollar range. In many cases, logs and custom metrics become the largest cost drivers, while alarms and dashboards add smaller but still noticeable costs. This range is directionally reasonable, but it should be presented as a modeled example rather than a standard CloudWatch bill.
Enterprise with High Log Volume (~$5,000–$15,000+/month)
At larger scale, CloudWatch costs can rise quickly when you combine high monthly log volume, large numbers of services, many custom metrics, frequent query scanning, and add-on features such as Container Insights, Synthetics, or Application Signals. In these environments, log ingestion and storage are usually the biggest cost drivers, especially when paired with advanced monitoring features and heavy query usage. This range is believable as an illustrative enterprise scenario, but it should be framed as an estimate based on AWS pricing inputs, not as an AWS-published benchmark.
4 CloudWatch Billing Traps That Quietly Inflate Your Bill
Every unique combination of metric name and dimensions counts as a separate custom metric in CloudWatch. That means if you add a high-cardinality field such as user ID, request ID, or another unbounded value, your custom metric count can grow very quickly. A safer way to phrase this is that high-cardinality dimensions are a major cause of unexpected custom metric growth.
CloudWatch Logs storage is billed separately, and storage costs can build up over time if log groups are kept for long periods or left on never-expire retention settings. If teams do not actively manage retention, storage charges can quietly grow month after month even when ingestion stays steady. Shorter retention for debug and development logs is one of the simplest ways to control this.
Deleting an EC2 instance, Lambda function, or another monitored resource does not automatically remove the CloudWatch alarms tied to it. Those alarms can remain in place and continue to bill until they are deleted manually. Reviewing old alarms regularly is a simple way to reduce unnecessary spend.
An anomaly detection alarm costs more than a standard alarm because CloudWatch bills it as three alarm metrics: the actual metric, the upper expected band, and the lower expected band. So one standard-resolution anomaly detection alarm costs about three times as much as a standard single-metric alarm. Teams that enable anomaly detection broadly can see alarm costs rise faster than expected if they do not account for this.
How to Reduce Your CloudWatch Bill
CloudWatch storage costs can grow over time if logs are kept longer than necessary, and AWS specifically recommends changing log retention settings to lower storage costs. For development and debugging logs, shorter retention periods can reduce spend without affecting day-to-day monitoring.
AWS recommends using the Infrequent Access log class where appropriate because it is designed for logs that do not need the full Standard class feature set. It offers lower ingestion cost, but fewer features, so it should be used only where that tradeoff makes sense.
AWS notes that when a resource is deleted, the related metric alarms can still remain and typically move into the INSUFFICIENT_DATA state. Those alarms can continue to exist until they are removed manually, so checking for stale alarms is a practical cost-control step. AWS even documents using aws cloudwatch describe-alarms –state-value INSUFFICIENT_DATA for this check.
Because each unique combination of metric name and dimensions is billed as a separate custom metric, avoiding high-cardinality dimensions is one of the simplest ways to prevent unnecessary metric growth and cost. This is especially important for dimensions tied to unbounded values such as request IDs or user-level identifiers.
Logs Insights charges are based on how much data is scanned, so broader queries can cost more than necessary. Keeping query windows narrow and limiting the amount of log data scanned is a simple way to reduce analysis costs. AWS also notes that reviewing saved query history can help reduce unnecessary repeat query costs.
AWS recommends deciding whether certain vended logs should go to CloudWatch or to Amazon S3 based on the use case. If logs are mainly needed for auditing, compliance, or long-term storage rather than active CloudWatch analysis features, sending them to S3 can be the better fit.
When CloudWatch Gets Costly and What to Do About It
CloudWatch is a strong default choice for teams that are early in their AWS journey. It gives you built-in visibility for many AWS services, works directly with IAM and AWS resource tagging, and includes a free tier that is useful for smaller workloads.
The pricing model becomes harder to predict as environments grow. CloudWatch charges are spread across separate components such as custom metrics, log ingestion, log storage, Logs Insights queries, alarms, dashboards, and advanced features. As usage grows across several of those areas at the same time, forecasting the total bill becomes more difficult.
Teams that want simpler cost forecasting often start looking at alternatives with more predictable pricing models, especially when CloudWatch usage grows beyond basic AWS-native monitoring. That is a positioning point rather than an AWS pricing fact, so it should be presented as your interpretation, not as something AWS states.
CubeAPM uses a flat ingestion-based model at $0.15/GB across metrics, logs, and traces no per-metric charges, no per-alarm fees, no per-query costs. For a mid-size team ingesting 10 TB of telemetry per month, that’s approximately $1,500/month with no billing surprises. CubeAPM deploys in your own VPC zero egress charges, full data control, and unlimited retention.
Conclusion
Amazon CloudWatch pricing is straightforward at small scale and genuinely complex at production scale. The free tier covers early development comfortably. Once you cross into custom metrics, high log volumes, Container Insights, and Synthetics, you’re navigating 15+ billing dimensions that compound in non-obvious ways.
Use the calculator above to model your specific workload before you commit. Apply the optimization strategies in this guide log retention policies, IA log class, alarm audits, and dimension hygiene to reduce your bill without reducing observability.
If your CloudWatch estimate is higher than you expected, it’s worth comparing to alternatives built with simpler pricing models. CubeAPM’s flat $0.15/GB pricing makes large-scale observability costs predictable and linear.
FAQs
1. Is Amazon CloudWatch free?
CloudWatch has an always-free tier that includes 10 custom metrics and 10 alarm metrics, 1 million API requests, 5 GB of log data ingestion, 5 GB of log data archive storage, and 3 dashboards with up to 50 metrics each per month. Standard metrics published automatically by many AWS services are generally available without custom metric charges. Most production workloads move beyond these free-tier limits fairly quickly.
2. How are custom metrics priced and prorated?
Custom metrics are billed per metric per month and prorated by the hour. In us-east-1, the rate is $0.30 per metric for the first 10,000 custom metrics, $0.10 per metric for the next 240,000, and $0.05 per metric above 250,000 in the AWS pricing example. Each unique combination of metric name and dimensions counts as a separate custom metric. If a metric is sent only for part of the month, you pay only for the hours it was active.
3. Why is my CloudWatch bill higher than expected?
Common causes include high-cardinality dimensions creating more custom metrics than expected, long log retention increasing storage costs, stale alarms that were never deleted, and anomaly detection alarms costing more than standard single-metric alarms. It is safer to avoid saying these are “the most common causes” unless you have a separate source for that ranking. AWS recommends using billing data and CloudWatch billing guidance to identify which features are driving spend.
4. Did Lambda log pricing change in 2026?
No. The key pricing change happened on May 1, 2025, not in 2026. AWS introduced volume-tiered pricing for AWS Lambda logs sent to CloudWatch Logs, with pricing in us-east-1 starting at $0.50/GB and tiering down as volume increases, reaching as low as $0.05/GB in the lowest tier. Any guide that still treats Lambda logs as flat-rate pricing without this tiering is outdated.
5. How do I estimate my CloudWatch bill before deploying?
Use the calculator at the top of your page to model your CloudWatch usage by component. For a broader AWS estimate that includes services such as EC2, RDS, and others outside CloudWatch itself, use the AWS Pricing Calculator. For CloudWatch specifically, it is important to estimate metrics, logs ingestion and storage, query scan volume, alarms, dashboards, and any advanced add-ons separately.
6. Can CloudWatch monitor servers outside of AWS?
Yes. Using the CloudWatch agent, you can send metrics and logs from on-premises servers and from servers running in other cloud environments. In those cases, standard CloudWatch pricing for custom metrics and log ingestion still applies.