CloudWatch Logs pricing: ingestion, retention, and queries

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

CloudWatch Logs is best modeled as three buckets: ingestion, retention, and queries. Many teams budget only ingestion and forget that retention policies and query scans can be meaningful at scale.

A defensible review starts by proving whether the increase came from more bytes written, more days retained, or more data scanned, because teams often blame CloudWatch Logs as one bucket when ingestion, retention, and query behavior moved for different reasons.

Logs pricing inputs

• Ingestion GB/day: primary driver of spend.
• Retention days: storage GB-month baseline.
• Insights scans: GB scanned by queries.

1) Ingestion (GB): what you write

• Measured GB/day is best (from your logging destination).
• If estimating: requests/day × bytes/log / 1e9 ~= GB/day.
• The biggest lever is log verbosity: fields, headers, and repeated payload fragments.

2) Retention (GB-month): what you keep

First-order retention model: retained GB ~= ingestion GB/day × retention days.

• Short retention for high-volume success logs.
• Longer retention for security and audit signals where required.
• Include copies: exports, replication, and forwarding to other tools.

3) Queries and scans (often the surprise)

• Logs Insights: usually priced by scanned GB.
• Downstream analytics: exported logs queried in Athena/BigQuery/etc are usually priced by scanned data.
• Dashboards: scheduled and auto-refresh queries drive steady recurring scans.

Log group strategy (reduces both retention and scan cost)

• Split by intent: separate debug logs from audit/security logs from application error logs.
• Retention tiers: short retention for high-volume success logs; longer retention where required.
• Environment isolation: keep staging/test logs out of production queries and pipelines.

This reduces “accidental scanning”: when a query meant for prod errors scans all environments and all verbosity levels.

Unit and pipeline pitfalls

• GB vs GiB: keep your unit consistent across ingestion estimates and pricing inputs.
• Copies: exports to S3, replication, and forwarding to SIEMs can duplicate storage and scanning costs.
• Retry storms: incidents increase both ingestion (more events) and scans (more investigations).

Common pitfalls

• Logging too much data “just in case” and never using it.
• Keeping high-volume logs forever without a compliance reason.
• Running dashboards that scan long time ranges repeatedly.
• Forwarding everything into a SIEM/log platform where ingestion is more expensive.

Validation checklist

You are ready to take this model into budgeting or optimization only when another reviewer can trace the ingestion baseline, the retention policy that turns it into stored GB-month, and the recurring query patterns that create steady scan cost outside incident spikes.

• Measure ingestion GB/day for at least 7 days (weekday/weekend patterns).
• Confirm retention policies per log group and lifecycle policies for exported copies.
• Measure scanned GB/day for common dashboards and incident playbooks.
• Confirm which environments are included (prod vs staging) in pipelines and queries.

Sources

• CloudWatch Logs pricing: aws.amazon.com/cloudwatch/pricing

Related guides

Related calculators

FAQ