AWS costs: CloudWatch Logs ingestion - the log bill that outgrew the app

A CloudWatch Logs bill spirals for one boring reason: you pay to get data in, pay again every month to keep it, and pay a third time every time someone queries it — and almost nobody realizes that the first charge, ingestion at $0.50 per GB in US East (N. Virginia), already happened before you ever touched a retention setting. Here's the part that catches teams off guard: shortening retention on an existing log group does not shrink this month's bill at all. It only slows next month's storage growth. If the number that scared you is this month's number, retention was never going to fix it.

The three charges hiding inside one line item

Jake runs a small phone repair and resale shop, and last year he built a little inventory-tracking app on AWS — a Lambda function that updates stock counts, an API Gateway front door, a DynamoDB table. He didn't think about logging. It just happened, because Lambda writes every invocation's output to CloudWatch Logs whether you ask it to or not.

CloudWatch Logs is not one price. It's three separate meters, and they don't move together: ingestion is what you pay the moment a log line lands in CloudWatch, billed once, immediately, at $0.50 per GB in the Standard log class or $0.25 per GB in Infrequent Access, in US East (N. Virginia) — nothing you do afterward gets that charge back. Storage is $0.03 per GB per month for compressed archived data, billed every month the data sits in the log group, and it's the one that retention settings actually control. Analysis is $0.005 per GB scanned every time a Logs Insights query runs, regardless of how many results it returns, so a query over a wide time range on a busy log group can scan far more data than the query is actually answering.

• Ingestion — $0.50/GB Standard, $0.25/GB Infrequent Access. This is billed once, per byte received.
• Storage — $0.03/GB per month for compressed archived data, billed every month it sits in the log group.
• Analysis — $0.005/GB scanned per Logs Insights query, win or lose on results.

Two extras stack on top of those three for specific use cases. Live Tail, the real-time streaming view of incoming events, costs $0.01 per minute after 1,800 free minutes a month (about an hour a day). Data Protection, the feature that scans and masks sensitive data like card numbers or emails, adds $0.12 per GB scanned — on top of, not instead of, ingestion.

Every account gets 5 GB a month combined across ingestion, archived storage, and Logs Insights scanning — a single shared allowance, not three separate 5 GB buckets. Most production workloads blow through that in the first few hours, so treat the free tier as a rounding error, not a budget.

Also Read: AWS costs: The NAT gateway bill - the $32/month nobody planned

Find which log group is actually driving the bill

Before you change anything, find out where the money is actually going. Guessing wastes effort on the wrong log group while the real offender keeps ingesting. For this exact question, start with the IncomingBytes metric, which CloudWatch reports per log group automatically.

1. Open AWS Cost Explorer, filter by service CloudWatch, and group by Usage Type. Look for entries containing DataProcessing-Bytes (Standard ingestion), VendedLog-Bytes (logs delivered from another AWS service), and TimedStorage-ByteHrs (archived storage). This tells you whether you have an ingestion problem or a storage problem — they need different fixes.
2. Switch the grouping to API Operation. If PutLogEvents dominates, ingestion is the driver, and log-level changes at the source are your best lever.
3. In the CloudWatch console, go to Logs > Log groups and sort by the Stored bytes column to rank groups by size. This shows accumulated storage, not the rate of new ingestion, so pair it with step 4.
4. Open Metrics > Logs > Log Group Metrics and graph IncomingBytes across your busiest log groups over the past week. Whichever line is climbing fastest is the one generating today's charge, not yesterday's.

In Jake's shop app, this is almost always one of three culprits: a Lambda function logging its full event payload on every invocation for "debugging" that never got turned off, an API Gateway execution log left at INFO or higher verbosity, or a database driver logging every query. None of these are malicious. They're defaults nobody revisited after launch.

Fix 1 — turn off "Never Expire" (cheapest, and the most misunderstood)

By default, every CloudWatch log group is set to keep data indefinitely. Logs are kept forever unless you set a retention policy, and the console shows this as "Never Expire." You can choose a retention period anywhere from one day to 10 years, and change it at any time.

1. In the CloudWatch console, go to Logs > Log groups and find the group you want to change.
2. In the Retention column, click the current setting (it will read "Never Expire" on an untouched group).
3. Choose a retention value under Expire events after and save. There is no confirmation step beyond this — the change applies immediately.
4. Optionally turn on deletion protection on log groups you never want accidentally deleted, which is a separate setting from retention and blocks all deletion operations until you explicitly disable it.

Here's the trust-killer nobody tells you upfront: setting retention to 7 days on a log group that's been running for two years does nothing to next month's ingestion charge. It stops future storage from accumulating past 7 days, and it will eventually reduce your storage bill as old data ages out — but the bytes you already sent were billed at the moment CloudWatch received them. If your bill spiked this month because of a logging burst, retention is a preventative measure for next month, not a fix for this one.

Fix 2 — move logs you rarely search into Infrequent Access

Storage and Logs Insights query pricing are identical between the two classes — the entire difference is the ingestion rate. But the class comes with real feature trade-offs, and here is exactly which capabilities Infrequent Access does not carry over from Standard.

Jake's inventory Lambda writes an audit trail he almost never looks at unless a customer disputes a sale. That's a textbook Infrequent Access candidate: create a new log group, point the Lambda's log configuration at it, and let the old Standard-class group age out under a short retention policy while the new one takes over at half the ingestion price.

Fix 3 — stop sending logs you don't need (the only fix that shrinks ingestion)

Ethan is blunt about this one when Jake asks why retention and log classes only shave the edges. "You're treating the symptom. If ingestion is the biggest number on the bill, the fix is upstream of CloudWatch entirely — you have to log less, not store less." Every other fix in this guide changes the price per byte or the shelf life of a byte. Only this one changes the number of bytes.

To reduce ingestion charges, evaluate your logging levels and eliminate unnecessary log ingestion. That's not a settings toggle inside CloudWatch — it's a change to what your application, container, or Lambda function decides to write out in the first place. In practice this means:

• Drop the log level in production from DEBUG to INFO or WARN, and only flip it back temporarily when actively investigating something.
• Stop logging full request and response payloads "just in case." Log the fields you'd actually search for — a request ID, a status code, a duration — not the entire JSON body.
• Sample high-frequency, low-value log lines (health checks, keep-alives) instead of writing one for every single request.
• Check whether a framework's default access logging or a database driver's query logging is enabled and more verbose than you intended. Third-party libraries are a common source of ingestion nobody signed up for.

None of this requires new AWS features. It requires someone opening the code and asking, honestly, whether every line that gets logged is worth $0.50 (or $0.25) per gigabyte, forever, the instant it's written.

Fix 4 — route the noisiest logs somewhere cheaper

Not every log needs to live in CloudWatch at all. CloudWatch Logs supports exporting log group data to Amazon S3, and both log classes support export to S3 and S3 Tables integration. For logs you keep only for compliance and almost never query interactively, S3 storage classes are typically far cheaper per gigabyte per month than CloudWatch's $0.03/GB-month archived rate, especially once you move into S3 infrequent-access or archive tiers.

The trade-off is operational, not financial: once logs live in S3 instead of a CloudWatch log group, you lose Logs Insights' point-and-click query experience and need a separate tool (Athena querying against S3, for example) to search them. That's a reasonable trade for a compliance archive nobody opens for years. It's a bad trade for anything an engineer needs mid-incident.

You can also route logs to a subscription destination (Kinesis Data Streams, Kinesis Data Firehose, or Lambda) at the point of ingestion, so a copy goes to CloudWatch for real-time visibility while the bulk volume flows to cheaper long-term storage. This adds infrastructure to manage, so it's worth it only once your log volume is large enough that the CloudWatch ingestion charge alone justifies the added complexity.

Fix 5 — stop Logs Insights from scanning more than it needs to

Logs Insights charges $0.005 per GB of data scanned, and it charges for the volume scanned, not the volume returned. A query that searches a 500 GB log group for a needle it finds in twelve lines still pays for scanning the full 500 GB if the time range and log group selection cover that much data. This becomes expensive fast during an active incident, when it's tempting to run broad, exploratory queries against large log groups repeatedly.

The fix is narrower queries, not fewer queries:

• Scope the time range as tightly as you can before running a query. "Last 15 minutes" scans a fraction of what "last 24 hours" does.
• Query specific log groups instead of every group in an account. CloudWatch Logs Insights supports querying up to 50 log groups in a single query, but selecting fewer, more targeted groups reduces the volume scanned.
• Review your query history in the Logs Insights console before re-running a broad query you've already run once; reuse the narrower version instead of the original.

If your team runs the same query on a schedule — a dashboard widget backed by a Logs Insights query that refreshes every few minutes, for instance — that recurring scan adds up over a month in a way a one-off manual query never will. Worth checking whether the refresh interval is tighter than the data actually needs.

Fix 6 — check the extras riding along on top of ingestion

Two features are easy to enable, easy to forget about, and billed entirely separately from the ingestion charge they ride alongside.

Data Protection scans log data for sensitive patterns (like Social Security numbers or credit card numbers) and can mask matches automatically. It costs $0.12 per GB scanned, in addition to normal ingestion. Turning it on for a log group that ingests 30 GB a month, scanned continuously, adds $3.60 a month on top of whatever ingestion already cost — not a huge number on its own, but it compounds across every log group you've enabled it on, and it's easy to turn on broadly during a security review and forget to scope it back down afterward.

Live Tail, the streaming view of events as they arrive, gets 1,800 free minutes a month — about an hour a day — and then costs $0.01 per minute. That's cheap for a focused ten-minute debugging session. It's not cheap if multiple engineers leave Live Tail sessions open across a long incident; minutes across users and sessions all count toward the same meter.

The vended-logs trap: VPC Flow Logs, WAF, and CloudFront

Some AWS services generate what AWS calls "vended logs" — VPC Flow Logs, AWS WAF logs, Amazon CloudFront access logs, Route 53 logs, among others — and these can produce volumes far larger than anything an application team writes by hand. Vended logs delivered to CloudWatch Logs bill at volume-tiered rates: $0.50/GB for the first 10 TB in a month, dropping to $0.25/GB for the next 20 TB, $0.10/GB for the next 20 TB, and $0.05/GB beyond 50 TB, in US East (N. Virginia). These tiers reset at the start of every month and apply per account.

Turning on VPC Flow Logs across a busy network with no filtering is one of the fastest ways to accidentally generate a five-figure monthly line item, because every accepted and rejected connection generates a log entry by default. If you only need flow logs for troubleshooting connectivity issues occasionally, scope them to specific network interfaces or subnets rather than an entire VPC, and consider sending them to S3 instead of CloudWatch Logs if you don't need real-time querying.

Lambda logs get their own pricing model now

This matters for the inventory app Jake and Ethan have been discussing: if the Lambda function is the noisiest log source in the account, that noise is now automatically eligible for the same tiered discount vended logs get, and Lambda now also supports delivering logs directly to S3 or Firehose as destinations without CloudWatch acting as a middleman. For a low-volume shop like Jake's, this tiering won't kick in — the discount tiers only start mattering in the tens-of-terabytes range — but it's worth knowing it exists before you assume Lambda logging is stuck at the headline $0.50/GB rate forever.

Which fix to reach for, in order

Cheapest and fastest first, most disruptive last. Most accounts never need to go past the first three.

When you've done all of this and the bill still isn't moving

Jake set retention, moved one log group to Infrequent Access, and trimmed a chatty debug line — and next month's bill barely moved. Ethan's answer: "You fixed the group you found. Did you check whether there's a second one?" This is the most common failure mode: teams fix the one obviously noisy log group and stop looking, while a quieter but larger group — often one created automatically by a service, not by a human decision — keeps growing untouched.

Other reasons a fix appears not to work:

• You changed retention, expected today's storage number to drop, and it didn't. Expected — deletion of expired events can take up to 72 hours after the retention setting change, and even then it only reduces storage, never the ingestion already billed.
• You created an Infrequent Access log group but the old Standard one is still active. The class can't be changed on an existing group. If your logging configuration is still pointed at the old group, the new one is sitting empty while the old one keeps ingesting at full price.
• You reduced log verbosity in one service but a dependency or third-party library is logging independently. Framework access logs, database drivers, and monitoring agents each have their own logging configuration and often ship verbose by default.
• Your bill spike came from a burst, not a steady-state increase. A single bad deploy that logged a stack trace on every request for six hours can dominate a monthly bill even after being fixed the same day. Check the date range of the spike in Cost Explorer before assuming an ongoing problem.

And here's the limit worth being honest about: if the ingestion already happened, there is no setting, no support ticket, and no retroactive log class change that refunds it. The only lever against a bill you've already been charged is making sure the same mistake doesn't repeat next month.

Catching the next spike before it becomes a bill

The first step in reducing CloudWatch charges is turning on billing alerts, and it's the single cheapest insurance policy in this entire guide. A billing alarm on estimated monthly charges catches a logging burst on day three instead of day thirty, when it's a one-line fix instead of a four-figure surprise.

Beyond a blanket billing alarm, graph IncomingBytes for your handful of highest-volume log groups on a dashboard you actually look at, not one you set up once and forget. A sudden slope change in that graph is your earliest warning — it shows up there days before it shows up in Cost Explorer, because Cost Explorer data typically lags by a day or more.

If you only remember one habit from this whole guide, make it this one: check these three line items monthly, the same way you'd check a water bill for a leak. Ingestion almost always dominates. Storage compounds quietly in the background. Analysis spikes during incidents. Knowing which of the three moved tells you which fix in this guide to reach for — without it, you're guessing.

Frequently asked questions

Why did my CloudWatch Logs bill suddenly jump?

Almost always a change in ingestion volume — a new deploy that logs more verbosely, a debug flag left on, a newly enabled service like VPC Flow Logs, or a traffic spike that naturally produced more log lines. Check the IncomingBytes metric per log group and the date the increase started; it will usually line up with a specific deploy or configuration change.

Does shortening retention lower this month's bill?

No. Retention controls how long you pay the $0.03/GB-month storage charge, not the ingestion charge you already paid the moment the data arrived. It reduces future storage bills, not the current one.

What's the difference between CloudWatch Logs Standard and Infrequent Access?

Both cost the same for storage ($0.03/GB-month) and Logs Insights queries ($0.005/GB scanned). Standard ingests at $0.50/GB and supports the full feature set, including Live Tail, anomaly detection, and field indexing. Infrequent Access ingests at $0.25/GB but drops those features; it kept most Logs Insights query support and, as of March 2026, gained data protection masking.

Can I switch an existing log group to Infrequent Access?

No. The log class is set when the log group is created and cannot be changed afterward. To get the lower rate, create a new log group in the Infrequent Access class and repoint your logging configuration to send new logs there.

How much does CloudWatch Logs actually cost per GB?

In US East (N. Virginia): $0.50/GB to ingest into Standard, $0.25/GB into Infrequent Access, $0.03/GB per month to store archived data, and $0.005/GB scanned per Logs Insights query. Rates vary by region, so check the pricing page for your specific region before budgeting.

What counts toward the CloudWatch free tier for logs?

A single shared 5 GB allowance per month, covering ingestion, archived storage, and Logs Insights query scanning combined — not 5 GB for each separately. Most production workloads exceed this within hours.

Why didn't my log group's storage go down right after I changed retention?

CloudWatch Logs doesn't delete expired events immediately — it typically takes up to 72 hours, occasionally longer. If you shorten retention while old events are already past the previous expiration date, expect up to another 72 hours before they clear.

Does Infrequent Access support Logs Insights queries?

Yes, most Logs Insights query commands work in Infrequent Access log groups. What's missing is Live Tail, anomaly detection, field indexing, facets, and natural language query assist — features tied to real-time or advanced interactive analysis, not basic querying.

Which AWS service usually creates the most CloudWatch log volume by accident?

Lambda functions are a common source, because every invocation logs by default with no retention set unless you configure one. VPC Flow Logs and detailed API Gateway execution logging are the other frequent offenders, since both can generate an entry for every single request or connection.

How do I find which log group is driving my bill?

Use AWS Cost Explorer, filter by CloudWatch, and group by Usage Type to see whether ingestion, vended-log ingestion, or storage is the largest line. Then graph the IncomingBytes metric per log group in the CloudWatch console to find which specific group is generating the most volume.

Does deleting a log group refund the ingestion charge?

No. Ingestion is billed the instant a log event is received. Deleting the log group afterward stops further storage charges but doesn't undo any charge already assessed.

Is VPC Flow Logs billed the same as regular application logs?

It's billed through the same CloudWatch Logs meters, but as a "vended log" it can qualify for volume-tiered pricing: $0.50/GB for the first 10 TB delivered in a month, dropping to $0.25/GB, then $0.10/GB, then $0.05/GB above 50 TB, in US East (N. Virginia). The volume from an unfiltered VPC can be enormous compared to typical application logging.

What is Data Protection and why is it billed separately?

Data Protection scans log data to detect and mask sensitive information like card numbers or personal identifiers. It costs $0.12 per GB scanned, charged on top of ordinary ingestion, because it's a distinct analysis pass over the same data rather than part of the base ingestion pipeline.

Are Lambda logs billed differently now?

Since May 1, 2025, AWS applies volume-tiered pricing to Lambda function logs automatically, starting at $0.50/GB and tiering down to as low as $0.05/GB at high volume in US East (N. Virginia) for CloudWatch Logs delivery, with lower starting rates for S3 or Amazon Data Firehose destinations. No configuration change is needed to receive the discount at qualifying volumes.

How do I stop a Logs Insights query from scanning terabytes?

Narrow the time range as tightly as possible and query only the specific log groups you need, rather than every group in the account. Since Logs Insights bills by data scanned regardless of results returned, a broad, unfiltered query can scan far more than a well-scoped one that finds the same answer.

What's the cheapest way to keep logs for compliance without paying CloudWatch storage forever?

Export the log group's data to Amazon S3. CloudWatch Logs supports export to S3 and S3 Tables from both log classes, and S3's long-term storage classes are typically far cheaper per gigabyte per month than CloudWatch's archived-storage rate. You lose the point-and-click Logs Insights query experience and need a separate tool to search the archive, which is a reasonable trade for data you rarely, if ever, need to open.

Also Read:

AWS costs: The NAT gateway bill - the $32/month nobody planned

 AWS costs: Data transfer pricing - the map of what is free and what is not

 AWS costs: CloudWatch Logs ingestion - the log bill that outgrew the app

 AWS costs: Cross-AZ traffic - the invisible cent per gigabyte

 AWS costs: Unattached Elastic IPs and idle load balancers - the standing waste list

AWS costs: S3 request pricing - when storage is cheap but touching it is not

AWS costs: S3 storage classes decided honestly - IA, Glacier, Intelligent-Tiering

AWS costs: Glacier retrieval - the bill for wanting your data back

Revision note. Written September 2026, covering CloudWatch Logs Standard and Infrequent Access pricing and features, including the March 2026 Infrequent Access feature expansion and the May 2025 Lambda tiered-pricing change. AWS periodically adjusts per-GB rates and regional pricing, so treat the dollar figures here as a snapshot and check the current pricing page before budgeting a large migration. If this bill has been eating into a Saturday you didn't plan to spend on it, you're not the only one — the defaults really were built to surprise you, and the fix is smaller than the bill made it look. Happy learning!