observabilitycost-optimizationloggingstorage

Log retention cost strategy: keeping logs without the surprise bill

Logs are cheap to write and expensive to keep forever. A retention strategy that tiers, expires, and archives logs by value cuts storage and ingestion cost without losing what you actually need. Here is how to build one.

The C3X Team··5 min read

Quick answer

Log cost has two parts: ingestion (charged per GB as logs arrive) and retention (charged per GB per month to keep them). A retention strategy controls both by setting expiration on every log group, tiering older logs to cheaper archival storage, sampling or dropping low-value high-volume logs before ingestion, and keeping only what you need for debugging and compliance. The default of keeping everything forever at full price is the expensive mistake; match retention to each log's actual value and cost drops sharply.

Logs feel free when you turn them on, and then the observability bill arrives. The cost of logging is driven by two things: how much data you ingest, and how long you keep it. Left on defaults, logs accumulate forever at full price, and the surprise compounds every month. A deliberate retention strategy keeps the value while cutting the cost.

Where log cost comes from

Cost driverHow it is charged
IngestionPer GB as logs are collected
RetentionPer GB per month to store them
Query / analysisPer GB scanned or by query

Ingestion is a one-time charge per GB when logs arrive, and it is often the larger cost for high-volume, chatty applications. Retention is an ongoing per-GB-per-month charge that grows without bound if nothing expires. Querying and analysis can add cost too. A good strategy attacks all three, but retention and ingestion are where most of the waste lives.

Set expiration on everything

The single biggest win is setting a retention period on every log group instead of keeping logs indefinitely. Most operational logs are useful for days or weeks, not years, so expire them accordingly. Keep longer retention only where compliance or forensic needs require it. This one change stops the unbounded growth that drives most log-storage surprises, the same discipline covered in the broader observability cost optimization guide.

Tier and archive by value

Not all logs deserve the same storage. Keep recent, frequently-queried logs in the fast (and pricier) log store, and move older logs you rarely touch to cheap archival object storage, using the same lifecycle policies that manage other data. For compliance logs you must retain but almost never read, cold archival storage costs a fraction of hot log retention. Tiering matches spend to how often each log is actually accessed.

Cut ingestion at the source

Because ingestion is charged per GB, reducing volume before it arrives saves the most. Drop or sample high-volume, low-value logs (debug noise, health-check spam), log at the right level in production, and avoid duplicating logs across multiple systems. Structured logging helps you filter precisely, the same volume-first discipline that trace sampling applies. Combined with expiration and tiering, source-side reduction turns logging from an unbounded cost into a managed one. Price your logging and storage footprint against the resource catalog so retention is a budgeted choice, not a default.

FAQ

What drives log storage cost?

Two things: ingestion, charged per GB as logs are collected, and retention, charged per GB per month to store them. Ingestion is often the larger cost for high-volume applications, while retention grows without bound if nothing expires. Querying and analysis can add cost too. A retention strategy targets all three, focusing on the ingestion and retention waste where most overspend lives.

How do I reduce log retention cost?

Set an expiration period on every log group instead of keeping logs forever, since most operational logs are only useful for days or weeks. Tier older, rarely-queried logs to cheap archival storage, keep long retention only where compliance requires it, and cut ingestion volume by sampling or dropping low-value logs at the source. Matching retention to each log's actual value drops cost sharply.

How long should I keep logs?

Match retention to each log's value. Most operational and debug logs are useful for days to a few weeks and can expire after that. Audit and compliance logs may need months or years, but those can live in cheap archival storage since they are rarely read. The expensive mistake is keeping all logs indefinitely at full-price hot storage; tier retention by how often each log is actually accessed.

Should I archive old logs to cheaper storage?

Yes. Keep recent, frequently-queried logs in the fast log store, and move older logs you rarely touch to cheap archival object storage using lifecycle policies. For compliance logs you must retain but almost never read, cold archival storage costs a fraction of hot log retention. Tiering matches spend to access frequency and is a major cost saver for long-retention requirements.

How do I cut log ingestion cost?

Because ingestion is charged per GB, reduce volume before logs arrive: drop or sample high-volume, low-value logs like debug noise and health-check spam, log at the appropriate level in production, avoid duplicating logs across multiple systems, and use structured logging so you can filter precisely. Source-side reduction saves the most since it avoids both the ingestion and downstream retention charges.

How does C3X help with logging cost?

C3X prices the log storage and related infrastructure in your Terraform before you deploy, so the retention and storage cost of a logging change shows up in the pull request. That lets you catch an unbounded or over-retentive logging configuration at design time, rather than discovering the accumulated storage charge months later on the observability bill.

What to do next

Price your logging and retention footprint before it ships. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.

Try C3X on your own Terraform

Free and open source. No API key required. One command to install, one command to estimate.