Amazon GuardDuty: Managed Threat Detection for AWS

An AWS environment can generate millions of API, network, and DNS events. Manually looking for a stolen credential, a compromised EC2 instance, or communication with a malware server is not realistic at scale. Amazon GuardDuty is a managed threat detection service that analyses AWS activity and threat intelligence to produce security findings.

This is Part 61 of the AWS Cloud Practitioner Study Notes. The key question is:

GuardDuty → Is there suspicious or potentially malicious activity?
Inspector  → Is this workload vulnerable?
Shield     → Is a DDoS attack targeting the perimeter?

GuardDuty detects and reports threats. It does not automatically stop every EC2 instance, block every IP address, or delete every compromised credential. Response is usually designed with EventBridge and other operational or security services.

What GuardDuty detects

GuardDuty uses threat intelligence, machine learning, and AWS-native telemetry to identify signals such as:

• Suspicious API activity
• Potentially compromised IAM credentials
• EC2 instances contacting malicious IP addresses or domains
• Cryptocurrency mining or command-and-control behaviour
• Reconnaissance and port scanning
• Suspicious container or Kubernetes activity
• Malware detected in supported EC2 or container workloads
• Unusual infrastructure changes or account behaviour

GuardDuty produces a finding when it detects unexpected and potentially malicious activity. A finding includes the type of threat, affected resource or account, severity, evidence, and remediation context.

Foundational data sources

The Cloud Practitioner exam commonly associates GuardDuty with these foundational sources:

Source	Example signal
CloudTrail management events	Unusual IAM, networking, or resource-management API calls
VPC Flow Logs	EC2 network communication with a known malicious address
Route 53 Resolver DNS query logs	Queries for known malicious domains

GuardDuty consumes an independent stream of these events. Enabling GuardDuty does not replace CloudTrail, VPC Flow Logs, or DNS logging as an operational retention strategy; those services remain responsible for your logging configuration, access, and retention.

GuardDuty also has optional protection plans and features, including EKS Protection, S3 Protection, Malware Protection, Runtime Monitoring, RDS Protection, and Lambda Protection. The exact availability and configuration depend on the AWS Region and the protection plan.

CloudTrail and GuardDuty

CloudTrail records API activity. GuardDuty analyses relevant CloudTrail activity for suspicious patterns:

IAM role makes unusual API calls
          ↓
CloudTrail management event
          ↓
GuardDuty analyses activity and context
          ↓
Potential credential-compromise finding

For example, an identity that normally operates from one pattern of locations suddenly creates infrastructure in an unusual Region and changes security settings. GuardDuty can use that behaviour, identity context, and threat intelligence to produce a finding.

CloudTrail answers “what API call happened and who made it?” GuardDuty answers “does this activity look suspicious or malicious?” They complement each other rather than replacing one another.

Network and DNS signals

GuardDuty can detect patterns in network and DNS activity. For example:

EC2 instance
      ↓ DNS query
known command-and-control domain
      ↓
GuardDuty finding

Or:

EC2 instance
      ↓ outbound traffic
known malicious IP address
      ↓
Suspicious communication finding

These detections do not mean that GuardDuty is a firewall. The service identifies the event and reports it. You can then use security groups, network controls, Systems Manager, or an automated response workflow to contain the resource.

EKS, runtime, and malware protection

GuardDuty has expanded protection features beyond its foundational sources:

• EKS Protection analyses Kubernetes audit activity when configured.
• Runtime Monitoring uses a GuardDuty security agent to collect runtime events from supported EC2, EKS, and ECS on AWS Fargate workloads.
• Malware Protection for EC2 can scan EBS volumes associated with potentially affected EC2 instances or container workloads running on EC2.
• S3 Protection, RDS Protection, and Lambda Protection add service-specific activity signals when enabled.

This creates an important nuance for exam and interview answers. Core GuardDuty detections use AWS-native telemetry without installing an agent on every EC2 instance. Optional Runtime Monitoring does use a GuardDuty security agent, and malware scanning has its own requirements.

Finding examples

GuardDuty finding categories can include:

Credential compromise

IAM principal
      ↓ unusual location or behaviour
Suspicious API activity
      ↓
Potential credential-compromise finding

Compromised EC2 instance

EC2 instance
      ↓ contacts
Known botnet or command-and-control host
      ↓
High-severity finding

Reconnaissance

An instance, identity, or external actor may exhibit scanning or probing behaviour that does not fit the expected environment. GuardDuty can report this as a potential threat for investigation.

Malware detection

When Malware Protection for EC2 is enabled or initiated by an applicable finding, GuardDuty can scan supported EBS volumes for malicious or suspicious files. This is a malware-protection feature, not the same as Inspector’s package vulnerability scan.

Findings have severity and threat context, but a finding is an alert for investigation, not proof that an attacker has definitively achieved a particular business outcome. Validate the evidence and resource context before taking destructive actions.

GuardDuty does not automatically remediate

GuardDuty’s core output is a finding. A response workflow can be automated separately:

GuardDuty finding
        ↓
EventBridge rule matches severity or finding type
        ↓
Lambda, SNS, or Systems Manager Automation
        ├── Notify security team
        ├── Quarantine an EC2 instance
        ├── Remove a compromised instance from a target group
        ├── Disable or rotate a credential
        └── Start an investigation workflow

Automated containment must be designed carefully. Automatically stopping a production instance or disabling a role can interrupt legitimate work if the finding is misunderstood. A safer pattern may be to notify first, add a quarantine security group, capture evidence, and require approval for irreversible actions.

GuardDuty with EventBridge

GuardDuty automatically publishes findings to Amazon EventBridge. You can filter events by finding type, severity, account, Region, resource, or other event fields and send them to targets such as SNS, Lambda, Kinesis, Step Functions, or Systems Manager workflows.

New high-severity GuardDuty finding
        ↓
EventBridge rule
        ├── SNS alert
        ├── Lambda response
        ├── Security Hub aggregation
        └── Incident-management integration

GuardDuty retains findings for a limited period, so EventBridge can also help route finding data to longer-term storage or security systems when a longer retention period is required.

GuardDuty with Security Hub and Detective

Security Hub aggregates findings from multiple security services into a central view. GuardDuty creates threat findings; Security Hub helps correlate and manage them alongside Inspector, Macie, IAM Access Analyzer, and other sources.

Amazon Detective serves a different purpose. It helps investigate relationships and historical activity around a security issue. A useful division is:

GuardDuty  → Detects a potential threat
Security Hub → Aggregates and prioritises findings
Detective   → Investigates context and relationships

These services are often deployed together in a security or delegated-administrator account across an AWS Organization.

GuardDuty versus related services

Service	Main question	Example
Amazon GuardDuty	Is there suspicious or malicious activity?	EC2 contacts a known malware server
Amazon Inspector	Is the workload vulnerable?	EC2 has a package with a critical CVE
AWS Shield	Is a DDoS attack overwhelming the perimeter?	TCP SYN flood targets an application
AWS WAF	Should this HTTP or HTTPS request be blocked?	SQL injection or rate-based web rule
AWS Config	Does the resource meet a configuration rule?	S3 bucket is publicly accessible
CloudTrail	What API activity occurred?	Role called CreateSecurityGroup
Security Hub	How do we aggregate security findings?	Central dashboard for multiple services
Amazon Detective	Why did this suspicious activity occur?	Investigate related entities and activity

The distinction between Inspector and GuardDuty is especially important:

Inspector:  old package → CVE → vulnerability finding
GuardDuty:  compromised workload → malicious behaviour → threat finding

An EC2 instance can have an Inspector vulnerability and a GuardDuty threat finding at the same time. The first describes a weakness; the second describes suspicious activity.

Multi-account GuardDuty

GuardDuty can be managed across an AWS Organization with a delegated administrator account. A central security account can manage member-account configuration and findings, helping security teams monitor many accounts consistently.

Still, GuardDuty is Regional. Enable it in the Regions that matter to the organisation, including Regions where global-service activity or unauthorised resource creation could occur. Define who owns response, how findings are routed, and which automated actions are permitted in each account.

Common exam questions

Which service detects suspicious activity in an AWS environment?

Amazon GuardDuty.

Which service detects an EC2 instance communicating with a known malicious IP?

Amazon GuardDuty.

Which service detects vulnerable packages and CVEs?

Amazon Inspector.

Which service protects against DDoS attacks?

AWS Shield.

Which service records API calls?

AWS CloudTrail. GuardDuty analyses relevant CloudTrail activity for threats.

Does GuardDuty automatically block or stop the attacker?

Not by itself. GuardDuty generates findings; EventBridge and response services can automate containment.

Does core GuardDuty require installing an agent on every EC2 instance?

No. Foundational detections use AWS-native telemetry. Optional Runtime Monitoring uses a security agent, and optional malware-protection features have additional requirements.

Which service provides a central dashboard for findings from several security services?

AWS Security Hub.

Final memory map

GuardDuty
├── CloudTrail management events
├── VPC Flow Logs
├── Route 53 Resolver DNS query logs
├── Optional EKS, S3, RDS, Lambda, and runtime protections
├── Threat intelligence and machine learning
├── Security findings
└── EventBridge automation and Security Hub aggregation

The one-sentence takeaway is: Amazon GuardDuty continuously analyses AWS activity and threat intelligence to detect suspicious behaviour and potential compromises, then publishes findings for investigation and response.

Sources

• GuardDuty foundational data sources
• Getting started with GuardDuty
• Understanding GuardDuty findings
• Processing GuardDuty findings with EventBridge
• GuardDuty Malware Protection for EC2
• GuardDuty EKS Protection