Why Your AWS Logging Bill Is Out of Control

Every few months someone on your team opens the AWS bill, scrolls to CloudWatch, and says something unprintable. The number is higher than last month. Nobody can explain why. The reason your CloudWatch bill is out of control isn't the rate per GB — it's that CloudWatch meters logging à la carte (ingest, storage, every query, every dashboard, every alarm), so the bill grows fastest exactly when you lean on your logs. The sticker rate tells you almost nothing about what you'll actually pay.

CloudWatch doesn't have a price. It has a pricing spreadsheet. Ingestion is one rate. Storage is another. Every query you run costs money. Every dashboard widget scans data and costs money. Alarms cost money. Cross-region anything costs money. The numbers change by region. Each line looks small in isolation; together they creep every month — and you still had to build every dashboard and write every alarm rule yourself.

Where the CloudWatch money actually goes

Say you're running a typical setup: five services, each producing about 4 GB of logs per day. That's 20 GB/day, roughly 600 GB/month. Manageable on paper. Here's the shape of what CloudWatch charges:

• —Ingestion — per GB, on every GB you send.
• —Storage — per GB-month, and the pile only grows with retention.
• —Queries — Logs Insights bills per GB scanned, every time anyone runs one.
• —Dashboards — metered once you go past the free few.
• —Alarms — metered per alarm.

*(CloudWatch pricing reflects public pricing pages as of Q1 2026 — vendor pricing changes; verify current rates.)*

No single line is the villain. The problem is that five separate meters compound, and the loudest one runs during an incident. Picture a roomful of engineers hammering Logs Insights at 2am, scanning gigabytes per query, trying to find the thing that broke. Every query is a charge.

The billing model punishes you for using your logs

This is the part that doesn't show up until you read the breakdown. The CloudWatch model charges you more the harder you use it. Every debug query is a billable event. Every dashboard someone opens is scanning data. The tool you bought to understand production gets more expensive precisely when you most need to understand production.

So teams adapt the wrong way. They stop querying logs because querying is expensive — which defeats the point of keeping logs. Or they trim verbosity: drop debug, then info, then anything that isn't an error. By the time they're done, the logs are too thin to debug with. You're paying for a log store and then starving it so the bill stays flat.

That's the first of three cost drivers, and it's the one people fixate on. The other two are bigger.

Driver two: cardinality is the line item nobody budgeted for

Tools that index every field charge more for high-cardinality data. Log a user_id, a trace_id, a request_id — anything with millions of unique values — and the bill climbs, because every distinct value gets indexed. Event-based indexing has the same shape: a 500-byte log line at real scale is billions of events a month, and per-event indexing is where metered bills quietly balloon.

The cruel part is that high-cardinality fields are the useful ones. trace_id is how you follow one request across services. user_id is how you find the customer who's affected. The fields that make logs worth keeping are the fields the billing model penalizes, so you end up taxed for doing observability correctly. This isn't unique to CloudWatch. Most usage-metered log tools share the shape: a per-GB ingest rate, a separate index-or-query charge, and a cardinality penalty on the data you most want to keep. The bill scales with how hard you actually use the product.

Driver three: the intelligence you build by hand

The platform fee is only half the cost. Strip away the meters and CloudWatch sells you storage and a query box. You rent the database; you build the intelligence layer on top. That layer is staff time that never appears on the AWS invoice:

• —Dashboards — an hour or two each, several per team, plus upkeep every time a service changes.
• —Alarm rules — minutes each to write, dozens for a real setup, plus the tuning loop when they're too noisy or too quiet.
• —Runbooks — who responds, what they check, the escalation path. More time per rule.
• —The on-call balance — too many alarms and people burn out; too few and incidents slip through. That tuning is never finished.

A senior engineer spending roughly a day a month on monitoring plumbing is a real loaded cost, and it recurs. Add it to the metered bill and the "cheap" storage tool stops looking cheap. The cheapest line item is not the cheapest solution.

What you actually want to pay for

You don't want to rent disk and API calls. You want to know when something breaks: a new error the moment it appears, a service that's gone quiet, an error rate that spikes after a deploy, a latency cascade no single threshold would catch. That's the thing worth paying for, not the storage underneath it.

That's the bet we made with Epok. It's detection-first: instead of handing you a search bar and a meter, it watches your logs, metrics, traces, infrastructure, and RUM together, catches what broke, and drafts the root cause — which service, what changed, who's affected — with every claim cited to the exact log line, span, or metric. No dashboards to build, no alarm rules to write, no per-query meter making you flinch during an incident.

And it's a flat price. That same 600 GB/month example sits comfortably inside the Team tier at $199/month flat, with 1 TB/month included, covering automatic detection, root-cause analysis, and Slack and PagerDuty notifications. Growth is $599/month for 4 TB/month; Custom starts at $5,000/month; overage is $0.20/GB. There's a 14-day trial with full features (~1 TB) and no credit card, and no free-forever tier. No per-query fees, no per-dashboard fees, no cardinality tax. Log any field you want; the price is the tier, not the shape of your data. (Verify current pricing at getepok.dev/pricing.)

What switching looks like

If you're already running FluentBit, Vector, Promtail, or the OpenTelemetry Collector, switching is a config change: point your shipper at Epok instead of CloudWatch. Your existing log format works as-is. If you're on the CloudWatch agent directly, forward logs to Epok with a Lambda subscription filter, about 15 minutes to wire up, and run both in parallel while you evaluate.

You don't rip anything out to try it. Run it alongside CloudWatch, and if it catches something your current setup missed, that answers the question for you. If a flat price with the intelligence already running is the wedge, the broader comparison is in Datadog alternatives for small teams.

The fix for a runaway CloudWatch bill isn't cheaper storage. It's getting off a model that charges you for using your own logs.

FAQ

Why does my CloudWatch bill keep going up when my log volume is flat?

Because volume is only one meter. CloudWatch bills ingestion, storage, queries (per GB scanned in Logs Insights), dashboards, and alarms separately. Retention grows the storage pile, and incident-time querying spikes the query meter, so the total can climb even when daily ingest holds steady. *(CloudWatch pricing reflects public pricing pages as of Q1 2026 — verify current rates.)*

What actually drives log management cost — is it the per-GB rate?

Rarely. Three things drive it: the billing model (à-la-carte meters that charge you more the harder you use the tool), cardinality and indexing penalties on high-value fields like user_id and trace_id, and the engineering time to build dashboards, alarms, and runbooks yourself. The sticker rate per GB is the smallest of the three.

How is Epok's pricing different from CloudWatch?

Epok is one flat monthly price with detection and root-cause analysis included, instead of separate meters. Team is $199/month for 1 TB/month, Growth is $599/month for 4 TB/month, Custom starts at $5,000/month, and overage is $0.20/GB. There are no per-query, per-dashboard, or cardinality charges, and no free-forever tier — a 14-day full-feature trial instead. Verify current pricing at getepok.dev/pricing.

Can I move off CloudWatch without re-instrumenting?

Usually yes. If you run FluentBit, Vector, Promtail, or the OpenTelemetry Collector, it's a config change to repoint at Epok and your log format works unchanged. On the CloudWatch agent, a Lambda subscription filter forwards logs in about 15 minutes, and you can run both in parallel while you evaluate.