← Back to list

The Hidden Cost of CloudWatch Logs: How We Cut Ingestion by 67% (and $500+/Month) Without Losing…

Pasan Kottearachchi · 2026-07-06 17:47 · 2 claps · 2.5 min read
#aws #cloudwatch #logs #cost-optimization #cloud-cost-optimization
Open on Medium ↗
Wiki topics: ☁️ · DevOps & Cloud

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 INFOWARN flip. 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

  1. Measure per-service ingestion before touching anything — you need a baseline to prove impact.
  2. Look for the usual suspects: leftover debug logs, redundant layers, high-frequency low-value events, full payload dumps.
  3. Cut noise, not signal — sampling and correlation IDs preserve your ability to go deep when needed.
  4. Tier retention to actual usage, not a default.
  5. 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