How to Control CloudWatch Logs Costs on ECS?

Why CloudWatch is silently eating your AWS bill

ECS creates CloudWatch log groups with no retention policy by default — logs accumulate forever at $0.50/GB ingestion plus $0.03/GB/month storage, with no upper bound. Every container's stdout goes to CloudWatch. Logs accumulate forever and your bill grows every month. You did not configure this.

The part that surprises most teams: ECS creates log groups with no retention policy. No retention = Never Expire = logs accumulate forever = your bill grows every month. We audited a 15-service fleet where CloudWatch was $135/month — more than the compute cost for two of the environments combined. Retention is one lever; right-sizing and scheduling are the rest of the picture.

Download the skill file — let AI fix it

The downloadable skill file lets your AI agent scan all CloudWatch log groups, identify which ones lack retention, estimate monthly cost per group, and apply fixes — without writing a line of code. Everything runs locally on your machine against your AWS account.

Step 1 — Set retention on every log group

Adding retention_in_days = 30 to every aws_cloudwatch_log_group Terraform resource cuts CloudWatch storage cost by 60–80% immediately — it is the single highest-impact change in this guide. Find every log group without retention and set it to something sensible.

This single change has the biggest impact of any step in this guide. Every log group with Never Expire keeps accumulating data you will never query. The commands below find them and set a sensible ceiling.

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

aws logs put-retention-policy \
    --log-group-name "/aws/ecs/your-service" \
    --retention-in-days 30

resource "aws_cloudwatch_log_group" "ecs_service" {
  name              = "/ecs/${var.env_prefix}-${var.service_name}"
  retention_in_days = 30  # ← was null (Never Expire). Now 30 days.
}

Step 2 — Filter by log level

Switching ECS production services from INFO to WARN log level reduces ingested log volume by one to two orders of magnitude, cutting both the $0.50/GB ingestion and $0.03/GB storage charges. Switch production to WARN, keep INFO for staging.

“CloudWatch Logs charges $0.50 per GB ingested, $0.03 per GB stored per month, and $0.50 per GB scanned by Logs Insights queries — beyond the 5 GB/month free tier.”

— aws.amazon.com/cloudwatch/pricing, verified June 2026

Spring Boot, Express, Django — they all default to INFO-level logging. That means every HTTP request, every database query, every cache hit generates a log line. Production doesn't need INFO. Switch to WARN.

# Find which log groups ingest the most data (last 7 days)
aws logs start-query \
    --log-group-name "/aws/ecs/prod-api" \
    --start-time $(date -v-7d +%s) \
    --end-time $(date +%s) \
    --query-string "stats count() by @logStream | sort count desc | limit 10"

# Check your framework's log level:
# Spring Boot: logging.level.root=WARN in application.properties
# Express: set LOG_LEVEL=warn
# Django: LOGGING['root']['level'] = 'WARNING'

Step 3 — Use Insights instead of streaming everything

Use CloudWatch Logs Insights to query on demand at $0.50/GB scanned rather than streaming every log line to a third-party tool that charges separately for ingestion and indexing. For compliance, subscription filter to S3.

Datadog's log pricing is two-part: ingestion is billed separately from indexing (making logs searchable). Once you index everything for debugging — which is the point of streaming logs there — the combined cost per GB is several times CloudWatch's ingest ($0.50/GB) + storage ($0.03/GB) total. For debugging, use CloudWatch Logs Insights instead — query on demand, pay per GB scanned ($0.50/GB), not per GB ingested or indexed.

“Datadog charges separately for log ingestion and for indexing logs to make them searchable — to query logs during incident response, they need to be indexed.”

— datadoghq.com/pricing, verified June 2026

# Find errors in the last hour across all services
aws logs start-query \
    --log-group-name "/aws/ecs/prod-api" \
    --start-time $(date -v-1H +%s) \
    --end-time $(date +%s) \
    --query-string "fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 50"

# For compliance: subscription filter → S3 (cheap, durable)
aws logs put-subscription-filter \
    --log-group-name "/aws/ecs/prod-api" \
    --filter-name "AllToS3" \
    --filter-pattern "" \
    --destination-arn "arn:aws:firehose:..."

Step 4 — Find which service costs the most

One Insights query grouping by log stream and sorting by byte volume identifies which ECS service is responsible for the majority of your CloudWatch bill — run it in under 5 minutes. You don't know which service is responsible until you run it.

Total CloudWatch cost is $400 — but which of your 15 services is responsible for $300 of it? This Insights query tells you in 5 minutes.

# Top log producers by byte volume (last 7 days)
aws logs start-query \
    --log-group-name "/aws/ecs/prod-api" \
    --start-time $(date -v-7d +%s) \
    --end-time $(date +%s) \
    --query-string "stats sum(strlen(@message)) as totalBytes by @logStream | sort totalBytes desc | limit 10"

Once you know which service generates the most logs, go to that service and do three things: (1) check its log level, (2) check if it's logging stack traces on every request, (3) check if it's logging health check pings. Those three fix 90% of high-volume log problems. And when you're done with CloudWatch, the next invisible cost is per-environment attribution.

FAQ

If you read this, you might also want to know