CloudWatch costs climb because you pay separately for log ingestion, log storage, custom metrics, dashboards, and alarms, and every one of those grows quietly as you add services, raise verbosity, and keep data forever by default. The single largest driver in most environments is log ingestion: you are charged per gigabyte for everything written to CloudWatch Logs, so a chatty application at debug level or a high-traffic service logging every request can cost more in observability than in compute. Bringing the bill down is about deciding what to log, how long to keep it, and which metrics actually earn their cost.
This explainer sits under our complete guide to AWS cost optimization, the pillar for this cluster. CloudWatch is one of the classic hidden line items, alongside data transfer and egress charges, and the first step to controlling it is seeing it clearly in your Cost and Usage Report.
Teams over-log because storage feels cheap and nobody wants to be the one who deleted the log that would have explained the outage. At scale that instinct is expensive. The goal is not less visibility, it is paying only for the visibility you use.
Where the CloudWatch bill actually comes from
There are several distinct charges and they behave differently. Log ingestion is billed per gigabyte ingested and is usually the biggest number. Log storage is billed per gigabyte per month for everything you retain, which is why never setting a retention period quietly compounds the bill year over year. Custom metrics are billed per metric per month, and they multiply fast when an application emits a metric per dimension, per instance, per endpoint. Dashboards and alarms each carry a small recurring charge, and high-resolution metrics and detailed monitoring cost more than the standard intervals. The first move is always to break the CloudWatch line into these components, because the fix differs for each.
Cut ingestion at the source
The cheapest gigabyte is the one you never ingest. Audit your noisiest log groups and ask what is actually being read. Drop debug and trace logging in production unless you are actively troubleshooting, sample high-volume access logs rather than capturing every line, and stop shipping logs that nothing ever queries. Where you need the data for compliance or occasional deep analysis but not for live querying, route it to S3 instead of CloudWatch Logs, which is far cheaper per gigabyte for cold storage. Cutting ingestion is the highest-leverage change because it reduces both the ingestion charge and the downstream storage charge at once.
Set retention so storage stops compounding
By default, CloudWatch log groups keep data indefinitely, which means you pay storage on every log line forever. Set an explicit retention period on every log group that matches how long the data is genuinely useful, often days or weeks for application logs and longer only where regulation requires it. Applying retention across hundreds of existing log groups is a one-time cleanup with a recurring payoff, and adding it to your provisioning templates stops new groups from defaulting back to forever. This is the Lock step of our method applied to observability: a guardrail that keeps the saving from leaking back.
Want your observability bill cut without losing visibility?
Our AWS cost audit breaks CloudWatch into ingestion, storage, and metrics, finds the noisy log groups and unused custom metrics, and sets retention and routing so the bill stops climbing. On the performance model you pay only from realized savings. No savings, no fee.
Book an AWS cost audit →Prune custom metrics and dashboards
Custom metrics are easy to create and easy to forget. A library that publishes a metric for every code path, or a deployment that tags metrics with a unique build identifier, can generate thousands of distinct metrics that are each billed monthly and never looked at again. Inventory your custom metrics, identify the ones no dashboard or alarm consumes, and stop publishing them. Do the same for dashboards and alarms left behind by decommissioned services. None of these are large individually, but together they are the slow drip that makes the bill creep even when traffic is flat.
| Charge | Why it climbs | The fix |
|---|---|---|
| Log ingestion | Verbose logging, high traffic | Drop debug logs, sample, route cold data to S3 |
| Log storage | No retention set, kept forever | Set retention on every log group |
| Custom metrics | Per-dimension explosion | Stop publishing unused metrics |
| Dashboards and alarms | Left behind by dead services | Delete the orphaned ones |
CloudWatch pricing dimensions, retention behavior, and metric charges reflect AWS as of May 2026. Confirm current per-gigabyte and per-metric pricing for your region in the AWS documentation, as rates and free tiers change.
The AWS Cost Optimization Field Guide includes our log-group audit query, the retention policy template, and the unused-metric finder. It is the downloadable companion to this explainer.
The short version
CloudWatch costs climb because ingestion, storage, and custom metrics all scale quietly with growth and default to keeping everything forever. Break the bill into its components, cut ingestion at the source by dropping debug logs and routing cold data to S3, set retention on every log group, and prune custom metrics and dashboards nobody reads. Observability waste is a recurring leak best closed with a standing guardrail, the kind of work that runs throughout an AWS cost optimization engagement, as in our SaaS on AWS case study. To catch the next anomaly fast, pair this with AWS budgets and cost anomaly detection.