How to Control CloudWatch Logs Costs on ECS?

Why CloudWatch is silently eating your AWS bill

ECS uses the awslogs driver by default — every container's stdout goes to CloudWatch with no retention policy set. No retention means Never Expire. Logs accumulate forever. Your bill grows every month. You didn't configure this — ECS did.

ECS uses the awslogs driver by default. Every container's stdout and stderr goes to CloudWatch Logs. And here's the part nobody tells you: ECS creates log groups with no retention policy. No retention = Never Expire = logs accumulate forever = your bill grows every month.

Download the skill file — let AI fix it

Before diving into the manual steps — here's a skill file your AI agent can run. It scans your CloudWatch log groups, finds the ones bleeding money, and optionally fixes them. Everything runs locally on your machine against your AWS account.

Step 1 — Set retention on every log group

One Terraform line — retention_in_days = 30 — cuts storage cost by 60-80%. Find every log group with no retention, set it to something sensible, and stop paying for logs from six months ago.

This single change cuts 60-80% of your CloudWatch storage cost. Find every log group with no retention, set it to something sensible.

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

Spring Boot, Express, Django — all default to INFO. A single web server at INFO generates 100-500× more log volume than at WARN. Switch production to WARN, keep INFO for staging.

“CloudWatch Logs charges $0.50 per GB ingested and $0.03 per GB stored per month. There are no free tiers for Logs.”

— 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

Streaming all logs to Datadog or Splunk costs 2-3× more than keeping them in CloudWatch. Use Insights for debugging — query on demand at $0.005/GB scanned. For compliance, subscription filter to S3.

Streaming all logs to Datadog, Splunk, or a self-hosted ELK stack costs 2-3× more than keeping them in CloudWatch. For debugging, use CloudWatch Logs Insights — query on demand, pay per GB scanned ($0.005/GB), not per GB ingested.

# 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

You know CloudWatch costs $400. You don't know which service is responsible. One Insights query groups by log stream and ranks by byte volume — 10 lines of SQL, 5 minutes, you have your answer.

You know CloudWatch costs $400. You don't know which of your 15 services is responsible for $300 of it. This Insights query tells you.

# 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