Cost

Delete empty CloudWatch log groups

An empty log group costs almost nothing directly — but hundreds of them obscure what's actually logging, and most carry no retention waiting to bill silently.

11 min·10 sections·AWS

Last reviewed 27 May 2026

Empty log groups: the basics

What does it mean for a log group to be 'empty'?

CloudWatch Logs charges on two meters that both depend on data actually existing: ingestion at roughly $0.50/GB when bytes are written, and storage at roughly $0.03/GB-month for as long as those bytes sit there. A log group holding zero bytes — storedBytes == 0, no log streams, or streams that aged out long ago — is therefore costing you essentially nothing on either meter. Be honest about that up front: the direct dollar saving from deleting one empty group is a rounding error.

So why are they flagged? Because they pile up. Every Lambda you ever deployed and deleted, every ECS task definition you iterated on, every CodeBuild project and one-off experiment leaves its /aws/lambda/... or /ecs/... group behind when the resource goes away — AWS does not garbage-collect them. A mature account routinely carries tens of thousands of log groups, the large majority empty husks of things that no longer exist. The signal is buried in the noise.

The check flags groups with no stored data and, usually, no retention policy set. The value of clearing them is hygiene, not dollars: a short, accurate inventory of what's actually logging is auditable; a list of 40,000 mostly-dead groups is not. And an empty group with retentionInDays = null is a silent trap — if anything ever writes to it, it starts hoarding data forever with no pruning.

In this lesson you'll learn why an empty CloudWatch log group costs essentially nothing yet still deserves cleanup, how to identify genuinely-dead groups by stored bytes and stream activity, and — critically — how to tell a dead group apart from one that's merely empty because retention just expired while the underlying resource is still alive. You'll see the AWS CLI commands to inventory and bulk-delete safely, and how setting an account-default retention stops new groups from repeating the pattern. This is a hygiene lesson, not a savings lesson, and it pairs directly with setting retention on the groups you keep.

Fun fact

40,000 groups, 39,000 of them empty

A platform team ran describe-log-groups across a mature production account and got 41,300 results. When they filtered to storedBytes == 0, just over 39,000 came back empty — almost all /aws/lambda/... groups left behind by functions deleted months or years earlier. The total stored-data cost of those 39,000 groups was, naturally, $0.00. But the 2,300 groups that did hold data were impossible to audit until the husks were cleared: nobody could tell which active services were missing retention, because the signal was drowned in 39,000 lines of dead inventory. The cleanup saved no money — and made the next month's retention audit take an afternoon instead of a week.

Clearing empty log groups in action

Nina runs platform infra at a SaaS company. The wastage dashboard flags 8,400 "empty" CloudWatch log groups with a headline saving of basically nothing — $0.00 in stored data. She almost skips it, then notices the real value: she can't run a clean retention audit until the dead groups are gone.

She lists every group with storedBytes == 0 and finds two kinds. The bulk are /aws/lambda/... groups whose functions no longer exist — genuinely dead, safe to delete. But a handful are empty for a different reason: the Lambda still exists and is invoked daily; the group is empty because a 1-day retention just pruned everything overnight. Deleting those would be harmless (Lambda recreates the group on next invocation) but pointless — and it'd briefly lose in-flight context.

She cross-checks each candidate against the live Lambda list before deleting, scripts the deletion of the ~7,900 confirmed-dead groups, and sets an account-level default retention so the next wave of auto-created groups isn't born immortal. The bill doesn't move. The inventory drops from 8,400 noise lines to about 500 real ones, and the retention audit she runs the following week is finally tractable.

First, list every log group holding zero stored bytes — the empty-husk candidates.

$ aws logs describe-log-groups --query "logGroups[?storedBytes==\`0\`].[logGroupName,retentionInDays]" --output table

----------------------------------------------------------------------

| DescribeLogGroups |

+----------------------------------------------------+---------------+

| /aws/lambda/deleted-image-resizer | None |

| /aws/lambda/old-stripe-webhook-v1 | None |

| /aws/lambda/poc-experiment-2024 | None |

| /ecs/retired-batch-worker | None |

| /aws/lambda/active-billing-cron | 1 |

+----------------------------------------------------+---------------+

# 7,900 of 8,400 have retentionInDays = None — born immortal, just empty for now.

# Note 'active-billing-cron': empty because 1-day retention pruned it, NOT dead.

Zero-byte log groups. The None retention column is the trap; the last row shows why empty != dead.

Confirm a candidate is genuinely dead — its Lambda no longer exists — then delete the group. Lambda would recreate the group on next invocation if it were still live, so this is safe.

$ aws lambda get-function --function-name deleted-image-resizer 2>&1 | head -1 && aws logs delete-log-group --log-group-name /aws/lambda/deleted-image-resizer

An error occurred (ResourceNotFoundException) when calling the

GetFunction operation: Function not found: deleted-image-resizer

# Function gone -> the group is a true husk. delete-log-group returns no output on success.

$ aws logs describe-log-groups --log-group-name-prefix /aws/lambda/deleted-image-resizer

{

"logGroups": []

}

# Gone. If a live Lambda ever needs it again, it auto-recreates the group on first log.

Verify the owning resource is gone before deleting. A live Lambda recreates its group automatically, so deleting a dead one is non-destructive.

Why empty groups exist and what 'empty' really meansdeep dive

A CloudWatch log group is just a metadata container; the actual bytes live in log streams underneath it. AWS bills on data: $0.50/GB ingested at write time and $0.03/GB-month to store the compressed result. A group reporting storedBytes == 0 has no billable data, so neither meter is running. Deleting it reclaims no money — it reclaims clarity. The reason the account fills up with them is that auto-creators (Lambda, ECS, API Gateway, CodeBuild, Step Functions) make a group on first log and AWS never deletes it when the underlying resource is removed.

There are two distinct ways a group ends up empty, and they demand different decisions. The first is genuinely dead: the Lambda or service that created it was deleted, so nothing will ever write to it again — safe to delete, and the group will not come back. The second is live-but-pruned: the resource still exists and runs, but a short retention window (say 1 day) cleared the streams overnight, so storedBytes momentarily reads 0. Deleting that group is harmless — a live Lambda recreates its group on the next invocation — but pointless, and you'd lose any in-flight stream metadata. The reliable discriminator is to check whether the owning resource still exists.

Note that storedBytes updates on a delay (it can lag actual ingestion by hours) and reflects compressed bytes, so a group that just received its first logs may briefly still report 0. For a high-confidence "dead" verdict, combine three signals: storedBytes == 0, no log streams (describe-log-streams returns empty), and the owning resource no longer exists. Any group matching all three is a true husk.

# Is the group genuinely empty (no streams at all), or just pruned?
aws logs describe-log-streams \
  --log-group-name /aws/lambda/deleted-image-resizer \
  --order-by LastEventTime --descending --max-items 1 \
  --query 'logStreams[*].[logStreamName,lastEventTimestamp]' \
  --output table

# High-confidence dead check: zero bytes AND no streams AND owning Lambda gone.
LG=/aws/lambda/deleted-image-resizer
FN=${LG#/aws/lambda/}
if ! aws lambda get-function --function-name "$FN" >/dev/null 2>&1; then
  echo "$LG: owning function gone — safe to delete"
fi

What is the impact of empty log groups?

Start with the honest part: the direct cost impact is approximately zero. A group with no stored bytes incurs no storage charge and no ingestion charge. If you delete 39,000 empty groups, your CloudWatch line will not visibly move. Anyone selling this as a savings win is misreading the meter. The impact is real but it is not a dollar figure on this month's invoice.

The first genuine impact is auditability. CloudWatch Logs management — setting retention, attaching metric filters, wiring subscription filters to ship logs to S3 or a SIEM — all operates on the list of log groups. When that list is 95% dead husks, every audit and every bulk operation has to filter the noise first, and humans simply stop doing it. Clearing the empties turns an un-auditable inventory into one a person can actually reason about, which is the precondition for the retention discipline that does affect the bill.

The second impact is the silent-cost trap. Most empty groups carry no retention policy (retentionInDays = null, i.e. "keep forever"). They cost nothing while empty, but the moment anything writes to one — a redeployed function reusing an old name, a misrouted log exporter, a debug flag left on — it begins accumulating data with no automatic pruning. So an empty group with no retention is a loaded gun pointed at a future bill. This is exactly why empty-group cleanup pairs with the retention lesson: clear the husks, and ensure the survivors all have a window.

The third impact is operational and security hygiene. A cluttered group list hides metric filters and subscription filters that are still wired up and still billing for processing, makes it harder to spot a group that's leaking sensitive data, and slows down incident response when an on-call engineer has to find the right group among tens of thousands. None of this is a cost line, but all of it is the kind of neglect that predicts real waste — idle resources, oversized stores, forgotten exports — trending the same way.

How do you clear empty log groups safely?

The fix is a four-step loop: inventory the empties, distinguish genuinely-dead groups from live-but-pruned ones, bulk-delete the confirmed-dead, then set a default retention so new groups don't repeat the pattern.

1. Inventory every zero-byte group

Use aws logs describe-log-groups (it paginates — handle the nextToken) and filter to storedBytes == 0. Capture logGroupName and retentionInDays. Expect the result to be enormous in a mature account — tens of thousands of rows is normal. Note how many also have retentionInDays = null; that subset is both the cleanup target and the retention-trap warning. Do not delete anything off this raw list yet — storedBytes lags ingestion by hours, so a brand-new group can briefly read 0.

2. Separate genuinely-dead from live-but-pruned

An empty group is only safe-and-worthwhile to delete if its owning resource is gone. For /aws/lambda/* groups, strip the prefix and call get-function; a ResourceNotFoundException confirms the function is dead. For /ecs/*, /aws/codebuild/* etc., check the corresponding service. A group that's empty only because a short retention pruned it overnight is still attached to a live resource — deleting it is harmless (the resource recreates the group on next log) but pointless, so leave it. The discriminator is always: does the owner still exist?

3. Bulk-delete the confirmed-dead groups

Loop the confirmed-dead list through aws logs delete-log-group --log-group-name $name. The call is idempotent and returns no output on success; it's rate-limited (~5 TPS per account), so budget time for large batches. Deletion is immediate and irreversible for the metadata, but since these groups hold no data there's nothing to lose, and any still-live resource auto-recreates its group on next write. Run it in dry-run first (echo the names) and eyeball the list before letting it delete for real.

4. Stop new groups being born immortal

The husks keep coming unless new groups get a sane default. Set an account-level default retention so auto-created groups (Lambda especially) aren't born with Never Expire, and enable the AWS Config managed rule cw-loggroup-retention-period-check to flag any future group missing a retention window. For greenfield infra, bake retention_in_days into the Terraform/CDK module that defines the group. This is where empty-group cleanup hands off to the retention lesson — the two disciplines are one habit.

# Find empty groups, confirm the owning Lambda is gone, then delete — with a dry-run guard.
DRY_RUN=${DRY_RUN:-true}
aws logs describe-log-groups \
  --query "logGroups[?storedBytes==\`0\`].logGroupName" \
  --output text | tr '\t' '\n' | while read -r LG; do
    case "$LG" in
      /aws/lambda/*)
        FN=${LG#/aws/lambda/}
        if aws lambda get-function --function-name "$FN" >/dev/null 2>&1; then
          continue   # function still exists — leave it
        fi ;;
    esac
    if [ "$DRY_RUN" = "true" ]; then
      echo "WOULD DELETE: $LG"
    else
      aws logs delete-log-group --log-group-name "$LG" && echo "deleted $LG"
    fi
  done

# Stop the next wave: set an account-wide default retention for new groups.
aws logs put-account-policy \
  --policy-name default-retention \
  --policy-type DATA_PROTECTION_POLICY \
  --policy-document '{"retentionInDays":30}' 2>/dev/null || \
  echo 'Set the Lambda/account default retention via your IaC or console as appropriate.'

Quick quiz

Question 1 of 5

You find a /aws/lambda/active-billing-cron log group reporting storedBytes = 0 and retentionInDays = null. The billing-cron Lambda still exists and runs hourly. What's the right read?

Keep learning

Dig deeper into CloudWatch Logs lifecycle, pricing, and the guardrails that keep the inventory clean and retention enforced.

You've completed Delete empty CloudWatch log groups. You now know the honest truth — an empty group costs essentially nothing directly — and why clearing them still matters: inventory clarity, escaping the no-retention silent-cost trap, and a cleaner surface for the retention discipline that does move the bill. You can tell a genuinely-dead group from a live-but-pruned one, bulk-delete the husks safely, and set a default retention so the next wave doesn't repeat. Next time the report flags thousands of empty groups, you'll know it's a hygiene signal to act on, not a saving to book.

Back to the library

Empty log groups: what it means for the bill

A category where the dollar number is almost zero — and that's the point

This is an unusual finding because the honest answer is that it costs almost nothing right now. CloudWatch Logs bills for data written and data stored; a genuinely empty log group has neither, so it contributes essentially $0 to this month's invoice. If you're looking for a number to celebrate, this isn't the line item. It's worth understanding precisely because it tempts people to ignore it, and ignoring it is how the conditions for real waste accumulate.

What an account full of empty log groups actually tells you is that resources are being created and destroyed without anyone tidying up after them. Each deleted Lambda, each retired service, each abandoned experiment leaves a husk behind. When there are tens of thousands of these, nobody can answer a basic question — "what is actually logging, and is it logging the right things for the right length of time?" — without wading through noise. That inability to audit is the cost, and it doesn't show up as a dollar figure.

There's a sharper reason to care. Most of these empty groups have no retention policy set, which means "keep forever." The day something starts writing to one — a re-deployed function reusing an old name, a misconfigured exporter — it begins hoarding data with no automatic pruning, and that genuinely does land on the bill later. So the right framing for the monthly review is that empty-group cleanup is hygiene that pairs with retention discipline: clean the husks, and make sure the survivors all have a retention window.

This lesson is for the finance partner who sees a wastage report flag thousands of "empty" log groups and wants to know whether it's worth a conversation. The short answer is: not for the dollars, but yes for what it signals. It walks through why the direct saving is near zero, why the count and trend matter more than the cost, how this connects to retention discipline (which does affect the bill), and what to actually ask engineering at the monthly review. By the end you'll know why a chart that says "$0 of waste, 38,000 resources" is still telling you something useful.

Fun fact

40,000 groups, 39,000 of them empty

How a finance partner reads a $0 finding

Sam is the finance partner embedded with the platform team. The wastage pack has a new line: "empty log groups — 8,400 resources, $0.00/month." Her first instinct is to strike it from the agenda; a zero-dollar finding doesn't belong in a cost review. Then she reframes it. The dollar amount isn't the point — the count is, and the count is a hygiene reading.

At the review she doesn't ask about bytes or retention syntax. She asks two things: "Why do we have 8,400 of these, and is that number going up or down?" The engineering lead explains they're husks from deleted functions and old experiments — nothing is billing — but admits nobody has been cleaning them up. Sam's follow-up is the one that matters: "How many of our active log groups have no retention set?" That number — the one that does eventually cost money — had been impossible to see clearly under the pile of empties.

The agreement isn't a cleanup heroics push. It's that the team will clear the dead groups, set an account-default retention so new groups expire by default, and report the count of empty groups and the count of active-groups-without-retention as standing lines. A month later the empty-group count is flat and small, and Sam treats it the way she treats it: as a confidence signal that lifecycle hygiene is working, not as a saving she booked.

Why a $0 finding still belongs on the report

The direct line-item impact is, honestly, nil. Empty log groups hold no data, so there is nothing to bill, and clearing them will not reduce the CloudWatch number. If the only lens is this quarter's invoice, you can skip it — and you'd be missing the signal. The value is in what the count and trend reveal, not in a saving you can book.

The first thing to track is the connection to retention, which does cost money. Empty groups overwhelmingly have no retention policy, meaning anything that starts writing to them will hoard data indefinitely. The number you actually want at the review isn't "how many empty groups" — it's "what fraction of our active log groups have no retention set." Empty-group sprawl is the symptom; missing retention is the disease that eventually shows up as a growing storage line.

The second is inventory clarity as a control. Chargeback, tagging audits, and compliance reviews all depend on being able to see what's actually running. An inventory drowning in dead husks can't be audited cheaply, so it doesn't get audited, and ungoverned spend accumulates in the gaps. The cleanup makes the books legible; legible books are what let you defend the chargeback model and catch the real waste.

The third is the leading-indicator framing. Sustained growth in the count of empty, no-retention groups means decommissioning hygiene is slipping — resources are being torn down without cleanup. That same slippage reliably predicts bigger waste categories trending up six months later. Watch the trend as an early-warning gauge, and never present this category as a dollar saving — present it as a hygiene reading paired with the retention metric that does move money.

What finance can actually do about this

Finance can't delete log groups, but it can make sure this is read correctly — as a hygiene signal paired with retention — and not chased as a phantom saving.

1. Report the count and trend, never a dollar saving

Add "empty log groups" to the pack as a count, not a cost. Presenting it as a saving is misleading — it saves nothing. The useful numbers are the count of empty groups and its month-over-month direction. A flat, small count is fine; a steadily growing one is the prompt to ask why decommissioning isn't including cleanup.

2. Ask the question that does cost money: retention coverage

The bill-relevant metric next to this one is the share of active log groups with no retention policy. That's the number that turns into a growing storage line over time. Make "what percentage of active log groups have a retention window?" a standing question; empty-group sprawl is just the symptom that this discipline is slipping.

3. Bake cleanup into the decommissioning checklist

Don't fund one-off purges. Ask that retiring a service include deleting its log group, and that a default retention be enforced account-wide so new groups aren't born immortal. That converts the problem from a recurring manual chore into a property of how the org ships and retires software.

4. Use it as an early-warning gauge, not a target

Driving empty groups to zero isn't the goal and isn't worth engineering time on its own. The goal is a legible inventory and full retention coverage. Treat a rising empty-group count the way you'd treat a smoke alarm: it tells you to look at the hygiene behind it, not to chase the alarm itself.

Quick quiz

Question 1 of 5

The wastage pack shows "empty log groups: 8,400 resources, $0.00/month," up from 3,000 six months ago. As the finance partner, what's the right next move?

Keep learning

Dig deeper into CloudWatch Logs lifecycle, pricing, and the guardrails that keep the inventory clean and retention enforced.

You've finished the finance partner's view of empty log groups. You know the direct saving is near zero, so this is reported as a count and trend, not a dollar figure — and that the metric next to it that actually moves money is retention coverage on active groups. Next time a $0 finding shows up, you'll read it as the hygiene and early-warning signal it is and ask the sharper question about retention.

Back to the library

Empty log groups: the headline

Near-zero cost today, a hygiene signal worth watching

This category saves almost no money directly, and we should be candid about that. An empty log group holds no data, so there is nothing to bill. The reason it appears on a cost report at all is what its volume says about operational discipline: tens of thousands of leftover, empty log groups means resources are being created and abandoned without cleanup, and the team can no longer easily see what is actually logging.

Treat it as a leading indicator, not a savings opportunity. A clean, small inventory means lifecycle hygiene is working and the related discipline — making sure every active log group has a sensible retention window — is more likely to be in place too. A sprawling inventory of empty husks is the early warning that the same neglect is quietly accumulating real waste elsewhere.

A short read on a category that saves almost no money but still belongs on the radar. You'll get the honest framing — near-zero direct cost — and the reason it's tracked anyway: as a leading indicator of cloud hygiene and a partner to retention discipline. One headline, one question to ask, no commands.

Fun fact

40,000 groups, 39,000 of them empty

What it looks like when the org gets this right

At one company the cloud cost pack carried a line that read "38,000 empty log groups, $0/month." The exec sponsor's first reaction was the right one: why is a zero-dollar item on a cost report? The answer reframed it usefully — it's not a cost, it's a tell. Thirty-eight thousand abandoned resources means nobody is closing the loop when things are decommissioned, and the same neglect almost certainly applies to categories that do cost money.

Rather than chase the non-existent dollars, the sponsor asked a hygiene question: "Can the team actually see what's logging, and does everything that logs have a retention window?" Within a quarter the empty groups were cleared, a default retention was enforced account-wide, and the pack stopped reporting a count of husks and started reporting "100% of active log groups have a retention policy" — which is the thing that protects the bill.

That's the right outcome state. "Zero empty groups" was never the goal; "a clean inventory and retention on everything live" is. The cost report stopped flagging a meaningless dollar figure and started carrying a real confidence signal.

Why this is on the report at all

The dollar impact here is essentially zero, and the report should say so plainly. Empty log groups hold no data and cost nothing to keep. The reason the category is tracked is that the volume and trend are a hygiene reading: tens of thousands of abandoned, immortal-by-default log groups means resources are being decommissioned without cleanup, and the inventory can no longer be audited at a glance.

There are two real consequences worth a leader's attention. First, most of these groups have no retention set, so they're primed to start accumulating real, recurring cost the moment anything writes to them — which is why the meaningful metric to ask for is the share of active log groups that have a retention window, not the count of empties. Second, the same neglect that leaves 40,000 husks lying around is the neglect that hides idle resources and stale data that show up as both cost and security findings. The dollar figure is zero; the discipline it measures is not.

The leadership move on this category

The handle here isn't a saving to capture — it's setting norms so the inventory stays clean and the retention discipline that protects the bill stays in place.

1. Don't let a $0 finding be sold as a saving

Insist this category is reported honestly — as a hygiene signal, not a cost reduction. Crediting a deletion of empty groups as savings erodes trust in the whole FinOps report. The value is a clean inventory and what the trend reveals, full stop.

2. Ask for retention coverage, not husk counts

The one question worth your time is "do all our active log groups have a retention window?" That's the metric that prevents real, recurring storage cost. Empty-group sprawl is the early symptom; retention coverage is the thing that actually moves money and risk.

3. Make decommissioning-includes-cleanup a norm

The reason husks pile up is that tearing a thing down rarely includes tidying its leftovers. Set the expectation that retirement includes cleanup, and that new resources are born with sane defaults. That single norm keeps both this category and several bigger ones from accumulating.

Quick quiz

Question 1 of 5

Your team reports they deleted 39,000 empty CloudWatch log groups and books it as a cost saving on the FinOps pack. What's the right response?

Keep learning

Dig deeper into CloudWatch Logs lifecycle, pricing, and the guardrails that keep the inventory clean and retention enforced.

That's the lesson. Two takeaways: empty log groups cost essentially nothing, so this is never a saving to claim — and the volume and trend are a hygiene signal worth watching. The leadership question is about retention coverage on active groups and decommissioning discipline, not about the dollar amount, which is zero.

Back to the library

Part of the learning path Kill idle waste

Delete empty CloudWatch log groups

Empty log groups: the basics

40,000 groups, 39,000 of them empty

Clearing empty log groups in action

Why empty groups exist and what 'empty' really meansdeep dive

What is the impact of empty log groups?

How do you clear empty log groups safely?

1. Inventory every zero-byte group

2. Separate genuinely-dead from live-but-pruned

3. Bulk-delete the confirmed-dead groups

4. Stop new groups being born immortal

Quick quiz

Keep learning

Empty log groups: what it means for the bill

40,000 groups, 39,000 of them empty

How a finance partner reads a $0 finding

Why a $0 finding still belongs on the report

What finance can actually do about this

1. Report the count and trend, never a dollar saving

2. Ask the question that does cost money: retention coverage

3. Bake cleanup into the decommissioning checklist

4. Use it as an early-warning gauge, not a target

Quick quiz

Keep learning

Empty log groups: the headline

40,000 groups, 39,000 of them empty

What it looks like when the org gets this right

Why this is on the report at all

The leadership move on this category

1. Don't let a $0 finding be sold as a saving

2. Ask for retention coverage, not husk counts

3. Make decommissioning-includes-cleanup a norm

Quick quiz

Keep learning

Related cost lessons