Log costs split into ingestion, storage and analysis - and the critical part is that the log class is chosen when the log group is created and cannot be changed afterwards. Several official cost mechanisms go unnoticed.
Log costs are the clearest example of undesigned usage on a bill: they grow naturally as features are added, yet unlike an instance nobody ever sat down and chose a specification. By the time it gets noticed, it is often the largest line under some service.
This page follows the order "where the money goes, which decision is irreversible, what mechanisms AWS already provides". Log cost is also a common cause of a sudden increase - the tracing method is in why your AWS bill jumped.
Log costs come in three parts: ingestion, storage, analysis
Understand these three dimensions and every optimisation below sorts itself:
| Dimension | Billed on | When it occurs |
|---|---|---|
| Ingestion | Volume written | When applications and AWS services write to a log group |
| Storage | Volume retained, over time | Continuously, for as long as the data is kept |
| Analysis | Volume scanned, or session length | When you query or stream logs |
The three behave completely differently, so the fixes differ too: ingestion happens once and is done; storage is continuous - in the words of the AWS blog, ingestion is one-time but storage charges accumulate for the lifetime of the data, often years under compliance regimes; analysis only occurs when you actively look. The middle one is the one that runs away, because it grows while you do nothing.
The choice you make once, at creation: the log class
This is the single most memorable point on the page, and it is stated in the documentation but frequently unknown at the moment a log group is created:
⛔ The log class is chosen when the log group is created and cannot be changed afterwards. If the default was accepted without thinking, switching later means creating a new log group - and the old one does not disappear, so you may end up paying for both.
The trade-off between the two classes is direct:
| Log class | Features | Ingestion cost |
|---|---|---|
| Standard | Full feature set: metric filters, subscription filters, field indexes, live tail, embedded metrics | Baseline |
| Infrequent Access | A reduced feature set | Typically about half of Standard |
The decision rule from the AWS blog is worth copying verbatim:
- Need real-time alerting or processing as data arrives → Standard. This is what Standard is for.
- Data kept mainly for audit and compliance → Infrequent Access. AWS states it suits the majority of use cases.
One action available right now: review existing log groups against the question "does anything need real-time alerting on this?". For new groups, choose correctly from the start - that costs nothing. For existing ones, remember that switching means rebuilding, so compare the ingestion saving against that cost first. Official pricing is authoritative.
Storage gets cheaper by itself: intelligent tiering
Storage includes a mechanism that needs no configuration: intelligent tiering. It classifies stored data by how long it has been since you last accessed it:
| Storage tier | Trigger |
|---|---|
| Standard tier | Accessed within the last 30 days |
| Infrequent Access tier | Not accessed for 31-90 days |
| Archive Instant Access tier | Not accessed for 91+ days |
Two details decide whether this actually helps:
- Accessing the data reclassifies it and resets the clock. Occasionally querying an old log group pushes its data back to Standard and restarts the countdown. So "just having a look at the history" has a cost - which is why AWS advises against accessing logs frequently.
- It is a separate thing from the log class, and the two get confused. The documentation states that storage tiers are applied automatically to all log groups by access pattern, independently of the log class. "I picked the wrong class" and "which storage tier am I in" are two different problems.
An easy misconception: storage is not billed on the raw log volume you can see - stored data is compressed at a typical ratio of 0.15, so the billed GB is materially smaller than the raw volume. Estimating storage cost from "we write 10 GB a day" will overstate it.
Three things people overlook: compression, retention, watching the volume
None of these costs anything or requires architecture change, and all three drive the storage line directly:
- The retention setting decides where storage stops. It defines how long logs are kept, and at expiry they are permanently deleted - the only setting that genuinely truncates long-term storage cost. Set nothing and the default is indefinite retention.
- Watch the ingest volume, not just the bill. AWS recommends monitoring the log volume your workloads generate on charts or dashboards, and points specifically at finding which log group caused a sudden increase.
- Reduce the volume at the source. The first recommendation AWS gives is to log only the events that carry business value, with efficient log syntax - set log levels correctly and drop redundant output.
⛔ Retention is the most common default to be caught out by: without an explicit setting, logs stay and keep billing. It is also the lowest-risk, fastest-acting optimisation available - because you normally do not need debug logs from three years ago. The only thing to confirm before setting it is whether a compliance obligation requires longer.
VPC Flow Logs: the official advice is to send them to S3
One concrete piece of official advice deserves its own section:
If you run VPC Flow Logs for audit and compliance, AWS advises sending them to S3 rather than CloudWatch. Conversely, if you need metric filters, subscription filters, log queries or Contributor Insights - the real-time analysis features - that is when they belong in CloudWatch.
Why it matters: VPC Flow Logs are the type most prone to runaway volume (they record network traffic), so assuming "logs go to CloudWatch" can quietly generate a large ingestion and storage bill. Ask one question first: do I want after-the-fact audit, or real-time analysis? The former goes to S3, the latter stays. The traffic charges themselves are covered in why AWS data transfer costs so much.
A few more charges that are easy to miss
The documentation lists several features that are free until used. Individually small, collectively common:
| Charge | Trigger |
|---|---|
| Log queries | Billed on volume scanned - the longer the time range, the more gets scanned |
| Live tail | Billed per session duration, so keep sessions short |
| Contributor Insights rules | More than the included number of rules per month, or a high volume of matching events |
| Synthetics canaries | Beyond an included number of runs per month, and each run drives charges in other services too |
| Dashboards | The free tier allows only a limited number; beyond that they are billed |
| Container Insights | Billed on the metrics collected and log data ingested |
One general fix: set a shorter time range on queries. AWS states plainly that narrowing the range reduces the volume scanned and therefore the analysis cost. It costs nothing - only a change of habit.
FAQ
The logs are already written - can I pay less for storage?
Yes, mainly three ways: set a retention period (expiry deletes automatically, the most direct lever), rely on intelligent tiering (unaccessed data drops to cheaper tiers by itself), and avoid querying old logs "just to look" (access pulls the data back to Standard and resets the clock).
What if I picked the wrong log class?
It cannot be changed on the existing log group - by design, the class is set at creation. Switching means creating a new group and pointing writes at it. So do the arithmetic: does the ingestion saving justify the rebuild? Choosing correctly on new groups, however, is free.
How do I find which log group is costing the most?
Two routes: filter by CloudWatch in cost analysis and switch the dimension to resource (note this only shows recent usage), or use cost and usage reports with a query tool to aggregate by resource ID and see which log group and which charge dominates. The latter is more thorough and suits a one-off cleanup. The wider tracing method is in why your AWS bill jumped.
Is storing logs elsewhere cheaper?
It depends on the use case. AWS explicitly advises sending audit and compliance VPC Flow Logs to S3; anything needing real-time filtering, alerting and search belongs in CloudWatch where those features exist. So it is not "which is absolutely cheaper" but "what am I actually going to do with this".
Can a discount cover log costs?
It is usage, so the levers are "write less, keep less, query less" rather than discounts. Commitment discounts cover compute-shaped usage and do not change how logging is billed - so do not expect a discount to fix log cost. What discounts can do is in AWS discounts, the complete picture; the wider cost optimisation playbook is in AWS billing: six actions that actually work; the channel-side route is in AWS discounts and reseller pricing, with the cross-provider comparison in cloud discount mechanisms compared.