fields @timestamp, @message, @logStream
| filter @message like /ERROR/ | sort @timestamp desc | limit 20 ``` This searches matching events across all streams in the chosen log group within the selected time window. Including `@logStream` in the result is useful because it tells you which stream each event came from. That is usually the fastest answer in the AWS console. ## The time range matters for cost and speed CloudWatch Logs Insights charges based on the volume of data scanned, so you should narrow the time range whenever possible. Searching a week of logs across a busy group can be much slower and more expensive than searching the last 15 minutes. A good workflow is: - start with a narrow time range - add a `filter` - expand the search only if needed That keeps both scan volume and noise under control. ## The AWS CLI can search too If you need automation or terminal-based workflows, `filter-log-events` can also search within a log group: ```bash aws logs filter-log-events \ --log-group-name "/aws/lambda/my-function" \ --filter-pattern "ERROR" ``` This command also works across streams in the specified group. It is useful for scripts, but for ad hoc investigation, Logs Insights is usually more expressive and easier to iterate on. ## Searching multiple log groups is a separate step If the logs are split across several groups, you can select multiple groups in Logs Insights and run one query across them. That is different from searching multiple streams within one group, but the user experience is similar. The important boundary is: - streams live inside one group - cross-stream search within the group is normal - cross-group search is also possible in Logs Insights if you select multiple groups ## Make your queries stream-aware when needed Sometimes you want group-wide search but still need stream-level context. In that case, return or group by `@logStream`: ```sql fields @timestamp, @logStream, @message | filter @message like /timeout/ | stats count() by @logStream | sort count desc ``` That lets you search broadly while still identifying which specific streams are noisy. ## Choose the tool by workflow Use Logs Insights when: - you are investigating interactively - you need filtering, sorting, parsing, or aggregation Use `filter-log-events` when: - you want CLI automation - you need a lightweight scripted search Both operate at the log-group level, which is why they naturally search across streams. ## Common Pitfalls - Searching one log stream manually when the real question is about the whole log group. - Forgetting to include `@logStream` in results and then losing source context. - Using a huge time range and paying to scan far more data than necessary. - Assuming CloudWatch cannot search across streams because the UI shows streams separately elsewhere. - Mixing up "search across streams in one group" with "search across multiple log groups." ## Summary - CloudWatch Logs Insights can search across all streams in a selected log group. - The normal unit of search is the log group, not the individual stream. - Include `@logStream` in your query output when stream identity matters. - Narrow the time range to reduce scan cost and improve speed. - The AWS CLI `filter-log-events` command also supports group-wide searches across streams.