Set retention on CloudWatch log groups

CloudWatch Logs charges two ways: ingestion (paid once at write time) and storage (paid every month the data sits there). By default every log group AWS auto-creates — from Lambda, ECS, API Gateway, and dozens of other services — is born with no expiry. "Never Expire" means the storage meter never stops. In accounts running for more than two or three years, accumulated log storage routinely becomes a material, growing line on the CloudWatch invoice.

The fix costs nothing operationally and requires no architectural change: set a retention window per log group, and AWS deletes the old data automatically. The money question is how long each category of log genuinely needs to be retained. Debug logs from a Lambda function have almost no value after 7 days; a compliance audit trail may need 400 days in hot storage before archiving cheaply to S3 and Glacier. Getting that split right — short windows on ephemeral logs, right-sized windows on everything else — is where most of the savings come from.

This is a FinOps hygiene issue rather than a one-time fix: new services auto-create log groups constantly, and each new group starts with no retention unless you have a guardrail. The durable win is pairing a bulk remediation of existing groups with an account-level default and an AWS Config rule that flags any future group born without a retention policy.

Preet is the FinOps analyst for a growth-stage company. At the quarterly cloud cost review the CloudWatch line has grown from $800 to $3,400 over eighteen months — and the engineering lead says ingestion has barely changed. Preet asks for a breakdown: how much is ingestion and how much is storage?

The answer is revealing. Ingestion is flat at about $800/month; storage is $2,600/month and still rising. Preet pulls a report grouping stored bytes by log group age and finds that over 60% of the storage cost comes from log groups more than two years old — dozens of Lambda functions, two decommissioned ECS services, and an API Gateway group that hasn't had a live request in over a year. None of them have ever had a retention policy set.

Preet brings the number to the next engineering sync as a dollar figure with a list: these specific groups account for $1,900/month of storage, and setting a 30-day retention on them costs nothing and requires no architecture change. The team runs the bulk fix that afternoon. Two weeks later the CloudWatch storage line has dropped by $1,700/month — an annualized saving of just over $20,000 for roughly an hour of work.

The unit economics of CloudWatch storage are simple: $0.03 per GB per month, applied to every byte that hasn't been deleted. There's no volume discount, no automatic tiering, and no expiry unless you set one. A log group storing 200 GB costs $6/month. After a year it has cost $72 — more than most teams spent ingesting it in the first place. After five years it costs $360, and the data inside is almost certainly worthless. This is the compounding structure that makes log hygiene a material FinOps issue, not a minor housekeeping task.

The cost has two components worth separating in a finance review. Storage waste — data sitting in groups long past any operational or compliance need — is pure deadweight. It can be eliminated by setting short retention windows on ephemeral and debug logs. Storage obligation — logs that genuinely need to be retained for compliance — is not waste, but the rate can often be dramatically reduced. Keeping a 400-day compliance log in CloudWatch Standard class at $0.03/GB-month costs roughly 30 times more than archiving it to S3 Glacier Deep Archive at $0.00099/GB-month after the hot period ends.

There is also a hidden query cost. Log Insights charges $0.005 per GB scanned. A forensics query running over five years of accumulated data in a group costs five times more than the same query over one year of data. Retention policy directly reduces query bills as well as storage bills.

For the audit trail: any production log group holding customer PII, API tokens, or transaction data with no retention policy is also a data-residency exposure that shows up in privacy and security reviews. Retention policy is a cross-functional control — cost, compliance, and privacy — and should appear on the risk register alongside the dollar figure.

AWS stores every log your cloud workloads generate until someone explicitly sets a limit. Without a retention policy, log storage compounds month over month — most organizations don't notice until the CloudWatch line on the bill is thousands of dollars a month, the majority of which is data from services that were shut down years ago. This is infrastructure debt that accumulates silently.

The remedy is a retention policy: a decision, per log category, about how long data genuinely needs to exist. That's a governance question, not a technical one. Debug logs have no value after a week; regulatory access logs may need seven years, though they should be archived cheaply to object storage rather than kept in expensive hot storage indefinitely. A mature organization has this decided by policy and enforced by tooling, so every new service that comes online inherits the right behavior automatically rather than defaulting to "keep forever."

At one company the engineering director, Sasha, used to field a quarterly "why is CloudWatch so expensive" question with no good answer. After a FinOps review flagged log storage as the culprit, the team did two things: ran a one-time bulk remediation on the 4,000-plus groups with no retention, and set a policy that every new service must declare a retention window in its infrastructure template before it ships.

Twelve months later Sasha's answer to the same question was a one-liner: CloudWatch costs $900/month, it's stable, and the breakdown by service is on the internal dashboard. The storage line had dropped from a third of the bill to under 10%. No architectural changes, no vendor negotiations — just a governance default that the tooling enforces automatically.

That's the right outcome for this control: not a heroic cleanup every year, but a standing policy that makes "never expire" impossible to reach production. The annual saving pays for the hour of setup many times over, and the CFO stops seeing CloudWatch as a mystery line.

Every cloud workload writes logs. By default AWS keeps them forever. In an organization running for more than a year or two, that default quietly compounds into a significant storage cost — and the data generating it is, in the vast majority of cases, debug output and operational noise that nobody will ever look at again. This is structural waste: it grows automatically and stops only when someone sets a policy.

The risk dimension extends beyond cost. Log groups with no retention are also a data-residency liability: customer records, session tokens, and internal stack traces accumulate indefinitely, widening the exposure window for any unauthorized access event. A retention policy is simultaneously a cost control and a privacy control.

The organizational signal is straightforward. An account where the majority of log groups have no retention policy is an account where infrastructure is being provisioned without governing defaults — services are created, they generate data, and nobody has decided how long that data matters. The corrective is a policy, not a one-time cleanup: a decision on retention by log category, enforced by tooling, so every service that comes online inherits the right behavior automatically.