The Hidden Cost of CloudWatch Logs: How We Cut Ingestion by 67% (and $500+/Month) Without Losing…
The Hidden Cost of CloudWatch Logs: How We Cut Ingestion by 67% (and $500+/Month) Without Losing Visibility
CloudWatch Logs quietly becomes one of the biggest line items on any AWS bill. Nobody decides to spend more on logging — it just accretes, service by service, until one day log ingestion costs more than half your compute.
That’s where we ended up. Here’s how we cut log volume by two-thirds, saved over $500/month in a single region, and — the part that actually matters — kept the visibility we needed to debug production.
Measure before you touch anything
Before changing a single log statement, we pulled real per-service ingestion numbers from CloudWatch’s IncomingBytes metric. "Logs feel noisy" isn't data. Actual daily GB per log group is.
Two services stood out:
- Main Event Bus: 25.43 GB/day → 3.81 GB/day — an 85% reduction
- Email Event Consumer: 16.7 GB/day → 10.25 GB/day — a 38.6% reduction
Combined, daily ingestion dropped from 42.13 GB to 14.06 GB: a 66.6% overall reduction, just from these two services.
Find out what’s actually noisy
Not all volume is equal — a service logging 25 GB/day isn’t automatically wrong. The question is whether each log line earns its cost. Four patterns showed up again and again:
- Debug logs left on in production. Verbose request/response logging that was useful in development and never turned down. The easiest fix — a config change, not a code change.
- Redundant multi-layer logging. The same event logged by the application, the middleware, and the SDK underneath it. Three log lines, one event.
- High-frequency, low-value events. Health checks and polling logged on every run instead of only on failures or state changes.
- Full payload dumps instead of summaries. Entire request/response bodies logged “just in case,” when only a correlation ID and a status code were ever actually queried.
Cut noise, not signal
The risk with cost-driven logging cuts is going blind during the next incident. What worked:
- Selective log-level changes — per module, not a blanket
INFO→WARNflip. Business logic that fails silently stays verbose; stable infrastructure code doesn't need to be. - Sampling over silence — high-frequency routine events logged at a fraction of invocations (e.g., 1 in 50) instead of cut entirely, enough to catch trends without paying for every instance.
- Correlation IDs over payload dumps — log a correlation ID and a short summary; pull full detail on demand via CloudWatch Logs Insights when actually investigating something.
- Retention tiering — real-time debugging logs don’t need a year of retention. Match the window to how the logs are actually used.
The math
Using CloudWatch’s per-GB ingestion pricing for eu-west-2:
- Daily volume dropped by 28.07 GB (42.13 GB → 14.06 GB), or ~842 GB/month
- Ingestion cost fell from ~$720/month to ~$240/month — ~$480/month saved
- Reduced storage added another ~$25/month in savings
- Total: ~$505/month, or roughly $6,000/year
Most teams running dozens of Lambdas and containers have far more headroom than this. The pattern repeats wherever logging was left on autopilot.
What we didn’t lose
The real test wasn’t the cost graph — it was the next production incident. Could we still trace a request end-to-end? We could, because the cuts targeted noise, not depth. Structured, correlation-ID-based logging meant we could always drill in on demand; we just stopped paying to store detail nobody was looking at by default.
Takeaways
- Measure per-service ingestion before touching anything — you need a baseline to prove impact.
- Look for the usual suspects: leftover debug logs, redundant layers, high-frequency low-value events, full payload dumps.
- Cut noise, not signal — sampling and correlation IDs preserve your ability to go deep when needed.
- Tier retention to actual usage, not a default.
- Re-verify after a real incident. Cheaper only counts as a win if visibility survives.
If nobody on your team has audited log ingestion in the last six months, there’s likely a similar percentage sitting there, waiting to be reclaimed.
메타데이터
- post_id
- 13e741e3cd40
- slug
- the-hidden-cost-of-cloudwatch-logs-how-we-cut-ingestion-by-67-and-500-month-without-losing-13e741e3cd40
- url
- https://medium.com/@pasankottearachchi94/the-hidden-cost-of-cloudwatch-logs-how-we-cut-ingestion-by-67-and-500-month-without-losing-13e741e3cd40
- canonical_url
- https://medium.com/@pasankottearachchi94/the-hidden-cost-of-cloudwatch-logs-how-we-cut-ingestion-by-67-and-500-month-without-losing-13e741e3cd40
- author_url
- https://medium.com/@pasankottearachchi94
- status
- ok
- fetched_at
- 2026-07-11 16:08:17