CloudWatch Logs: What They Hold and How to Monitor Them With Sazabi

Last verified on Nov 8, 2026.

CloudWatch Logs is where most AWS services write their output. Lambda functions, API Gateway stages, WAF web ACLs and CloudTrail trails can all deliver to a log group, which makes CloudWatch the common layer under several other sources.

How CloudWatch organizes logs

AWS defines four terms that you need to read a log group correctly:

• A log event is a record of activity with two properties: a timestamp and the raw event message.
• A log stream is a sequence of events from the same source, such as one application instance.
• A log group is a set of streams that share retention, monitoring and access control settings.
• A metric filter extracts metric observations from ingested events. Filters are assigned to log groups.

Because retention and access control belong to the group, the way you split groups decides who can read what and how long it lasts. One group per service is easier to reason about than one shared group.

CloudWatch also offers subscriptions, a real-time feed of log events to another destination. AWS says events are usually delivered in under three minutes, and that subscriptions are supported only for log groups in the Standard log class. Check the class of any group you plan to forward.

What to look for

A log group holds your own application messages, so the questions depend on your code. These work with any stack:

• Which log groups stopped writing? A silent service often fails before it logs anything.
• Which error messages first appeared after the last deploy?
• Which request IDs or user IDs show up next to the same exception more than once?
• Are retries or timeouts rising in one stream while its neighbors stay flat?

Structured messages make this much easier. Log one JSON object per line with a level, a message and the identifiers you search on.

Example: a structured line in a log group

This is an example of an application log message as it might sit in a Lambda log group. The field names are your choice, not an AWS standard.

{
  "level": "error",
  "message": "payment provider timed out",
  "requestId": "6f1c2b7e-0c7e-4d93-9d27-0f1f2f5d1a11",
  "route": "POST /checkout",
  "upstream": "payments",
  "durationMs": 10004
}

The requestId lets you walk from this line to the API Gateway access log for the same call. The route and upstream fields let you ask how many timeouts hit one dependency in the last hour. Without them you are reading free text.

If the line is plain text instead, you can still search it, but you lose grouping by field.

How Sazabi reads CloudWatch

Per the Sazabi docs, you connect your AWS account and Sazabi sets up a CloudWatch subscription filter on each log group you select. Sazabi assumes a cross-account IAM role that you create, adds your account to the Sazabi-managed CloudWatch destination policy and installs the filters. You do not run anything.

The role lets Sazabi list log groups, inspect and manage subscription filters and manage account-level policies. Only log groups in the same region as your Sazabi project appear in the picker. After the filter is in place, logs typically arrive within one to two minutes.

The same role serves the other connected AWS sources: CloudTrail, AWS WAF and VPC Flow Logs. If you prefer to keep credentials on your side, the docs describe a path where you run an OpenTelemetry Collector with the awscloudwatch receiver and export OTLP to Sazabi. More on that in OpenTelemetry.

The Sazabi docs also point to this source for sending EKS control-plane audit logs.

Choosing log groups

Start with the groups that matter during an incident: your API, your workers and anything that touches money or identity. Add the rest later. Fewer groups keep volume and cost easier to predict.

If you are comparing this setup to staying in the CloudWatch console, see Sazabi compared with CloudWatch. The full AWS list is on the AWS integration page, and plans are on the pricing page.