CloudWatch Logs is a quiet budget eater because it charges per GB ingested, and that ingestion charge usually dwarfs storage and query costs combined. The biggest drivers are debug level application logging left on in production, VPC flow logs, and chatty services that log every request. You cut the cost by reducing ingestion at the source, setting retention so logs expire instead of living forever, and routing logs you only need occasionally to the Infrequent Access log class or to S3, both of which cost far less than standard ingestion and storage. None of this requires giving up observability, only giving up the logs you never actually read.
The reason it stays hidden is that no single team owns it and no single change causes it. It grows a debug flag here and a new flow log there until it is real money. Here is how to find it and bring it back down.
Where does the CloudWatch Logs bill actually come from?
There are three charges, and they are wildly uneven. Ingestion is billed per GB of log data sent in and is by far the dominant cost on most estates. Storage is billed per GB month and is modest per gigabyte but compounds because log groups default to never expire, so old logs sit there for years. Logs Insights queries are billed per GB scanned, which is usually small unless someone runs broad queries across huge groups repeatedly. Vended logs such as VPC flow logs and other AWS service logs ride the same ingestion charge.
Because ingestion dominates, the lever is volume. Indicative public pricing puts standard ingestion in the region of $0.50 per GB and standard storage far lower per GB month; treat those as indicative and verify against the current CloudWatch pricing page, but the shape is what matters: cutting a gigabyte of ingestion saves far more than cutting a gigabyte of storage.
How do you cut ingestion without going blind?
Attack the source first, because every gigabyte you do not send is a gigabyte you never pay to ingest, store, or query.
| Lever | What to do | Effect |
|---|---|---|
| Log level | Run production at info or warn, not debug | Often the single largest ingestion cut |
| Sampling | Sample high volume, low value logs such as health checks | Keeps signal, drops repetitive noise |
| Field trimming | Stop emitting fields you never query | Smaller events, less ingestion per line |
| VPC flow logs | Scope to the interfaces you investigate, not everything | Flow logs are a common silent driver |
| Metric filters | Extract metrics rather than querying raw logs repeatedly | Cuts Logs Insights scan cost |
Then deal with what remains. Set a retention policy on every log group so data expires on a schedule that matches how long you would ever investigate it, rather than the default of forever. For logs you must keep but rarely read, the Infrequent Access log class lowers the ingestion rate in exchange for reduced query features, and exporting to S3 with lifecycle policies into Glacier is cheaper still for long term archival you touch almost never.
Find the driver before you cut
Do not cut blind. Break CloudWatch Logs cost down by log group to see which ones dominate ingestion, because the distribution is almost always lopsided: a handful of groups account for most of the spend. That tells you exactly where a log level change or a sampling rule pays off, and it stops you trimming logs that cost almost nothing while ignoring the one noisy service driving the bill.
A European SaaS company found CloudWatch Logs had grown into one of its top operational line items without anyone deciding it should. Breaking ingestion down by log group showed two services logging at debug in production and unscoped VPC flow logs accounting for most of the volume. Raising the production log level, sampling health check traffic, scoping flow logs to the interfaces actually investigated, and setting retention on every group cut ingestion sharply. Logs the team kept only for occasional audits moved to S3 with a lifecycle policy. Observability was unchanged. Figures are verified against billing data and anonymized.
Where this fits in the AWS estate
Logging cost is one of the quiet drivers behind both storage and network spend, and it grows fastest where new services ship quickly, including AI workloads. It connects directly to Bedrock and GenAI spend on AWS, which often logs verbosely, to the broader AWS storage review playbook, and to network architecture choices that cut the bill. The whole estate picture lives in the AWS cost optimization guide.
Frequently asked questions
What drives CloudWatch Logs cost most?
How do you reduce the cost without losing observability?
Why is my bill growing when usage looks flat?
Find your quiet budget eaters with us
We help enterprises find the unowned logging, network, and storage costs that grow without anyone deciding they should, then cut them without touching observability. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.