OpsCurb
Sign in
guides

How to Reduce CloudWatch Logs Retention Safely

Audit log groups, compare retention against real operational need, and shorten policies without losing critical evidence.

3 min read
Updated 2026-03-10

How to reduce CloudWatch Logs retention safely

CloudWatch Logs usually bloat when retention defaults stay at their original values. This guide helps you shorten retention without dropping logs that security, support, or incident response still relies on.

On this page

Before you change anything

Start with these quick questions:

  • Which log groups are production-critical?
  • Which logs support compliance, audit, or incident-response workflows?
  • Which environments can be shortened first: dev, staging, short-lived previews, or internal tools?

If any of this is unclear, treat this pass as classification first, not deletion.

Step 1: Inventory log groups and retention settings

Use the console or CLI to list current settings and put a baseline in front of you.

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

Start by identifying:

  • log groups with no retention value
  • non-production groups with unusually long retention
  • largest groups by stored bytes

Step 2: Group logs by risk and business need

A practical grouping for startup teams:

  1. High retention required: security logs, audit logs, and production incident evidence
  2. Operational but moderate retention: core production app and service logs
  3. Low retention acceptable: staging, dev, preview, migration, and temporary services

Avoid blanket policies unless those environments truly share the same evidence need.

Step 3: Change the lowest-risk groups first

When you already know your target, CLI keeps the change repeatable:

aws logs put-retention-policy \
  --log-group-name "/aws/lambda/example-service-dev" \
  --retention-in-days 14

Pick verbose non-production groups first when the upside from shorter retention is clear and low risk.

Risk reminder: old events outside the window will age out as soon as the new policy applies. Get team sign-off before touching production or security-sensitive groups.

Step 4: Measure expected savings simply

You don’t need precision to start. Use a simple approach:

  • find the largest groups first
  • challenge any retention duration longer than actual use
  • prioritize groups where shorter retention clearly reduces stored bytes over time

The biggest gain is often from better defaults, so waste does not quietly grow back every sprint.

Step 5: Make the policy sticky

Manual retention changes drift. After the first pass:

  • define retention in IaC where possible
  • set environment defaults for dev/staging/production
  • include high-volume services in your platform review process

Where OpsCurb helps

OpsCurb keeps detection focused and shows log-retention waste alongside compute, storage, and network findings. That helps when observability cleanup is needed but your team cannot inspect every log group manually each sprint.

Next steps: