Monitor AWS with Sazabi: What Each AWS Log Source Tells You

Last verified on Nov 8, 2026.

AWS spreads its operational record across several services. Who changed what lives in CloudTrail, network decisions in VPC Flow Logs and your own application output in CloudWatch Logs. Each one answers a different question, and the useful incidents usually need two of them side by side.

Sazabi is AI-native observability and security. It ingests all six AWS sources below, so you can search them in one place instead of switching consoles.

What each AWS source tells you

• CloudTrail records API calls: the caller, the source IP address, the service, the action and whether it failed. It is your answer to "who did that".
• CloudWatch Logs holds whatever your services write to log groups. It is the answer to "what did the application say".
• AWS WAF records each request a web ACL inspected, the rule that decided it and the client IP. It answers "who is hitting the edge".
• VPC Flow Logs records accepted and rejected network flows per network interface. It answers "what is talking to what".
• GuardDuty delivers findings with a type and a severity from 1.0 to 10.0. It answers "what has AWS already flagged".
• API Gateway access logs record route, status and latency per request. They answer "which calls fail and for whom".

How the sources fit together

Four of the sources connect through your AWS account. You create one IAM role, and Sazabi sets up a CloudWatch subscription filter on each log group you pick. CloudTrail, WAF and VPC Flow Logs all ride on the same role as the CloudWatch source, so adding the second source is a small step.

GuardDuty works differently. You deploy an EventBridge rule and API destination in each Region, and Sazabi does not assume a role in your account. API Gateway logs reach Sazabi through CloudWatch Logs, either with the native CloudWatch source or an OpenTelemetry Collector. If you already run a collector, see OpenTelemetry.

A worked example: one address across three sources

Start with the network. The flow log source stores every flow log field as a searchable attribute, including aws.vpc.flow.action. Ask for rejected traffic first:

sazabi logs ask "Show VPC flow log records with aws.vpc.flow.action REJECT in the last 30 minutes"

Say a single address dominates the results. This is an example record in the default flow log format, with a documentation-range address:

2 123456789010 eni-1235b8ca123456789 203.0.113.50 172.31.16.21 51514 22 6 12 720 1418530010 1418530070 REJECT OK

The fields are version, account ID, interface ID, source address, destination address, source port, destination port, protocol, packets, bytes, start, end, action and log status. Destination port 22 over protocol 6 is SSH over TCP, and a security group or network ACL refused it.

That tells you something is probing SSH. Now ask the same question of the other sources:

1. Search WAF logs for httpRequest.clientIp equal to the address. If it also sent web requests, see which rule terminated them.
2. Search CloudTrail for sourceIPAddress equal to the address. A hit with an errorCode means someone tried your AWS API from there, not just your instances.
3. Check whether GuardDuty produced a finding that names the same resource.

Three misses is a reasonable result: noisy scanning that your security group already handled. A hit in CloudTrail changes the priority. The point is that one identifier ties four sources together.

Cost and volume

Flow logs and WAF logs can be large. AWS bills CloudWatch Logs ingestion for every flow log record and every logged WAF request. For WAF, add a logging filter that keeps blocked and counted requests only. For flow logs, start with the VPCs that face the internet.

Sazabi pricing is separate. See the pricing page for allowances and overage rates.

Where to go next

Pick the source that matches your first question. If you suspect misuse of credentials, start with CloudTrail. If you are watching the edge, start with AWS WAF. The wider group of security sources is on the security category page, and the cloud platform sources are on the cloud platforms page.