GuardDuty Findings: Finding Types, Severity and Sazabi Ingestion

Last verified on Nov 8, 2026.

GuardDuty is the one AWS source that arrives already interpreted. When it detects suspicious or unexpected behavior in your environment, it generates a finding with a type, a severity and the resources involved. Sending those findings to Sazabi puts AWS's verdicts next to the raw logs you search during an incident.

What a finding contains

A finding names a potential security issue. The type follows a fixed format from the AWS docs:

ThreatPurpose:ResourceTypeAffected/ThreatFamilyName.DetectionMechanism!Artifact

The last part is optional. Reading the type tells you most of what you need. Recon:EC2/PortProbeUnprotectedPort says an EC2 instance has an unprotected port that a potential attacker is probing. CryptoCurrency:EC2/BitcoinTool.B!DNS says an instance is talking to a Bitcoin-related domain. Backdoor:EC2/DenialOfService.Tcp is denial of service over TCP.

Threat purposes include Backdoor, Behavior, CredentialAccess, Cryptocurrency, DefenseEvasion, Discovery, Execution and Exfiltration. Some align with MITRE ATT&CK tactics.

Severity runs from 1.0 to 10.0 and is split into bands:

• Low is 1.0 to 3.9.
• Medium is 4.0 to 6.9.
• High is 7.0 to 8.9.
• Critical is 9.0 to 10.0.

AWS notes that a finding of one type can carry different severities depending on context, so read the number on the finding, not the type alone.

What to look for

• Critical and High findings first, grouped by resource. One compromised instance can produce several findings.
• The same ThreatPurpose across several accounts or Regions in a short window.
• The service.count value next to the type. AWS combines later occurrences of a finding with the original, so one finding can stand for repeated activity.
• Medium findings on resources you did not expect to be reachable.

By default AWS aggregates later occurrences of a finding type within 6-hour intervals into one EventBridge event, so a single event can stand for activity over several hours. Check the count before you decide something happened once.

Two habits keep triage short. First, write down what you expect: which accounts have internet-facing instances and which roles should call which APIs. A finding that contradicts that list is more urgent than one that matches it. Second, treat the finding as a pointer. Open the flow logs and the CloudTrail events for the same account and time window before you decide on a response.

Example: one finding as it arrives

This abbreviated example shows the fields Sazabi maps. All values are placeholders.

{
  "id": "example-finding-id",
  "accountId": "111122223333",
  "region": "us-east-1",
  "type": "Recon:EC2/PortProbeUnprotectedPort",
  "title": "Unprotected port on EC2 instance is being probed.",
  "severity": 8.0,
  "updatedAt": "2026-11-08T10:15:00.000Z",
  "resource": { "resourceType": "Instance" },
  "service": { "detectorId": "example-detector-id", "count": 14, "archived": false }
}

Per the Sazabi docs, this becomes one log record under the service guardduty. The body is the finding JSON. type becomes aws.guardduty.finding.type, severity becomes aws.guardduty.finding.severity, service.count becomes aws.guardduty.finding.count and accountId becomes cloud.account.id. The record's time is updatedAt.

The level comes from GuardDuty's severity scale. A severity of 8.0 falls in High, so the record's level is ERROR. Low is INFO, Medium is WARN and Critical is FATAL.

How Sazabi receives findings

GuardDuty publishes every finding to Amazon EventBridge. You deploy one rule per Region that matches this pattern, from the Sazabi docs:

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"]
}

The rule sends each match to your Sazabi intake URL through an EventBridge API destination. The setup also creates an EventBridge connection and an IAM role that is allowed only events:InvokeApiDestination on that destination. EventBridge requires an authorization method, so it sends a fixed x-sazabi-source: aws-guardduty header. Sazabi ignores the header and the intake URL carries the credential.

You can deploy with CloudFormation or Terraform. From the CLI, sazabi log-sources create aws_guardduty --mode manual prints the intake URL.

Context from the other sources

A finding says what AWS suspects. The evidence is in VPC Flow Logs for network activity and CloudTrail for API activity. For a plain list of what to log and what to query for threats, see the AWS integration page. Plans are on the pricing page.