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

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

Use this page when you need to decide what belongs inside the Logs Insights bill before you debate query habits, dashboard refreshes, or log-organization fixes. Logs Insights pricing usually boils down to one number: GB scanned, but this page is about bill scope before workflow or optimization.

What belongs inside the Logs Insights bill

This guide is about bill boundaries: scanned-GB charges from Logs Insights queries, and the adjacent log ingestion, retention, export, and wider observability costs that should be tracked beside Logs Insights rather than blended into it.

• Inside the bill: scan charges driven by query scope, time range, and query frequency.
• Beside the bill: log ingestion, storage, exports, and downstream analytics platforms.
• Decision point: separate the scan bill first, then decide whether you need measurement or intervention.

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

When this is not the right page

• If you need to build a defendable scanned-GB model, go to the estimate guide.
• If you already know the dominant scan driver and need to change dashboard or query behavior, go to the optimization guide.
• If you are modeling the wider logging bill, treat that as a separate log-cost question.

Fast modeling workflow

1. Estimate log volume (GB/day) for the log groups you query.
2. Estimate scanned GB/query from time range and log group scope.
3. Estimate queries/day (dashboards + ad-hoc + scheduled).
4. 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.

Sources

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

Related guides

Related calculators

FAQ