CloudWatch Logs Insights pricing: what to model (GB scanned)

Logs Insights pricing usually boils down to one number: GB scanned. A cost model should separate “routine” scanning (dashboards and daily debugging) from “incident” scanning (wide searches and repeated queries).

Logs Insights pricing inputs

GB scanned: per query scan volume.
Queries/day: dashboards and ad hoc usage.
Peak scans: incident searches can dominate.

What to include in an estimate

Scanned GB/month: routine queries + dashboards
Incident multiplier: scanning spikes during outages and security investigations
Log group scope: which environments and services are included in your common queries

Logs Insights cost calculator Estimate scanned GB

Fast modeling workflow

Estimate log volume (GB/day) for the log groups you query.
Estimate scanned GB/query from time range and log group scope.
Estimate queries/day (dashboards + ad-hoc + scheduled).
Multiply to monthly scanned GB and apply your $/GB scanned rate.

What matters (and what doesn't)

Matters: time range, log group scope, and query frequency (these drive scanned GB).
Doesn't matter much: how many rows you return. A query that returns 10 rows can still scan terabytes if it searches broadly.

Worked example (routine vs incident)

Routine: 3 GB scanned/query × 150 queries/day × 30.4 ~= 13,680 GB scanned/month
Incidents: 2 days/month at 10× scanning -> add ~ (3 × 150 × 9) × 2 ~= 8,100 GB scanned/month

The point is not perfect math. The point is that incident behavior can be a significant fraction of monthly spend.

Rules of thumb (quick checks)

Halving the time range usually halves scanned GB (first-order).
Separating noisy log groups reduces scanned GB for routine error queries.
Dashboards should default to 15m/1h windows; widen only on demand.

Common pitfalls

Querying multiple environments (prod + staging) by default.
Dashboards that scan 7–30 days on a short refresh interval.
Broad queries over noisy success logs for questions about errors.
Not modeling incident behavior (where scan volume is often highest).

Optimization direction

The safest optimization is usually to reduce scan scope, not to reduce logging itself. Start by time-bounding queries and separating noisy log groups.

Guide: Logs Insights cost optimization.

Validation checklist

Measure scanned GB for a real week (including at least one busy day if possible).
Validate dashboard time ranges and refresh intervals.
Validate which log groups are included in the most common queries.