CloudWatch Log Groups Without Retention | Reduce AWS Logging Cost

The problem

CloudWatch Logs keeps billing for stored data until retention expires or logs are deleted. When a log group has no explicit retention policy, AWS retains logs indefinitely and storage spend grows quietly over time.

Why it happens

Log groups are created automatically by Lambda, ECS, or applications with no retention defaults.
Teams centralize logs but never come back to set an explicit expiry window.
Retention decisions vary by workload, so "set it later" often becomes "never set it."

What this means for cost

The exact impact depends on resource size, retention age, and region, but this pattern is usually worth reviewing because it compounds quietly over time.

How to detect CloudWatch log retention cost

The strongest signal is a log group with no retentionInDays value set, especially when it belongs to a high-volume Lambda, ECS, API, or batch workload.

Cloud Waste Hunter flags CloudWatch log groups that do not have retentionInDays configured. That is an intentionally narrow signal: it is looking for missing retention policy, not trying to guess the perfect retention period for every workload.

This is one of the clearest logging hygiene checks because the control is explicit. Either the log group has a retention window or it does not.

List log groups and inspect the retention field:

aws logs describe-log-groups \
  --query 'logGroups[].{name:logGroupName,retention:retentionInDays,storedBytes:storedBytes}'

Any log group where retention is empty is retaining logs indefinitely. Prioritize high-volume groups such as Lambda, ECS, API, or batch-processing logs first.

Caveats and false positives

This detector does not say that long retention is wrong. It says that unspecified retention is risky because it usually means cost and compliance decisions were never made deliberately.

If the bigger issue is self-amplifying log generation rather than simple retention drift, review S3 access logging loop. That detector focuses on a different class of logging waste: recursive log growth caused by configuration.

How to fix CloudWatch log retention cost

Set retention in code or through the AWS CLI:

aws logs put-retention-policy \
  --log-group-name /aws/lambda/app \
  --retention-in-days 30

For repeatability, move the retention setting into infrastructure definitions so new log groups do not recreate the same drift.

How this differs from S3 lifecycle cleanup detectors

The AWS Storage Cost Optimization guide and S3 Incomplete Multipart Uploads both focus on object-storage cleanup patterns. This page is specifically about CloudWatch Logs retention policy on log groups.

How Cloud Waste Hunter helps

Cloud Waste Hunter can turn “no retention configured” into a clear logging hygiene queue, with log-group names and stored-byte context, so teams can fix indefinite retention before it becomes long-tail log storage spend. For adjacent logging fixes, review the AWS Logging Cost Optimization guide.

FAQ

Is every log group without retention a waste problem?

Not automatically. Some regulated or security-sensitive workloads may need very long retention. The detector highlights missing policy, not business intent.

Why is there no savings estimate on this page?

The current detector reports the retention gap directly but does not yet convert stored bytes into a cost estimate. It is still a strong review signal because indefinite retention compounds over time.

What retention period should most teams start with?

Many application and operational logs can start with 7, 14, or 30 days, then be adjusted for specific compliance or troubleshooting needs.

CloudWatch log retention cost