Threat Detection

Threat Detection is the process of identifying potential security threats in real-time or near-real-time. In AWS, threat detection combines multiple data sources (API logs, network traffic, DNS queries) with machine learning and threat intelligence to surface malicious activity.

AWS Threat Detection Services

• GuardDuty: behavioral analysis and anomaly detection across accounts
• Inspector: vulnerability scanning for EC2, Lambda, ECR, plus code security (SAST, SCA, and IaC scanning) since 2025
• Macie: sensitive data discovery in S3
• Security Hub: aggregation and compliance checks
• CloudWatch Anomaly Detection: metric-based anomaly alerts
• EventBridge: real-time event routing for automated response

What GuardDuty Actually Consumes

A detail that surprises many teams: GuardDuty does not read the CloudTrail trails or VPC Flow Logs you configure yourself. It consumes three foundational data sources through independent, duplicated streams that exist whether or not you have enabled logging in your account:

• CloudTrail management events: control plane operations such as IAM policy attachments, subnet creation, or trail configuration changes
• VPC Flow Logs: network metadata from EC2 network interfaces, without you creating any flow log subscription
• Route 53 Resolver DNS query logs: DNS requests, but only if your instances use the default AWS DNS resolvers

This means you get detection value from day one with zero pipeline work, but it also means GuardDuty is blind to DNS traffic if you run your own resolvers, and it does not replace your own log retention: GuardDuty extracts fields for profiling and then discards the logs.

How It Goes Wrong in Practice

The most common failure is regional blind spots. A team enables GuardDuty in the two regions where production runs and considers the job done. An attacker who obtains leaked credentials does not care where your workloads live: they will try API calls in every region, and unused regions are attractive precisely because nobody is watching. Global services like IAM, STS, and CloudFront can be abused from anywhere, and unauthorized resources (typically cryptomining fleets) get launched in regions with no detection coverage. AWS explicitly recommends enabling GuardDuty in all regions available in your account, including regions where you have no resources, because GuardDuty replicates global service events with security value into each region where it is enabled.

The second failure mode is detection without response. Findings pile up in the console, nobody is paged, and a high-severity finding is discovered weeks later during an unrelated audit. Detection only earns its keep when findings flow through EventBridge into a ticketing system, a chat channel, or an automated containment runbook. The related trap is alert fatigue: teams route every finding of every severity to the on-call channel, people learn to ignore the noise, and the one finding that matters scrolls past unread. Triage rules belong in the pipeline, not in the reader's patience: page on high severity, ticket the medium ones, and review the rest on a schedule.

Practical Check: Is Detection Actually On?

GuardDuty is enabled per region through a detector. This command tells you instantly whether a region is covered:

aws guardduty list-detectors --region eu-west-3

If the DetectorIds array comes back empty, GuardDuty is not running in that region. Loop the command over all regions in scope and you have a one-minute coverage audit. In an AWS Organizations setup, check from the delegated administrator account, which can see member account coverage centrally.

Frequently Asked Questions

Do I need to enable CloudTrail or VPC Flow Logs before enabling GuardDuty?

No. GuardDuty consumes CloudTrail management events, VPC Flow Logs data, and Route 53 Resolver DNS query logs through its own independent streams. Your existing logging configuration neither feeds nor constrains GuardDuty. You still want your own trails and flow logs for investigation and forensics, because GuardDuty discards the raw logs after analysis.

What does threat detection cost to try?

When you enable GuardDuty for the first time in a region, you get a 30-day free trial covering threat detection for all foundational data sources, with an estimated usage breakdown visible during the trial so you can project the real monthly cost before committing.

How is threat detection different from vulnerability management?

Vulnerability management (Inspector) finds weaknesses that could be exploited: unpatched packages, risky code paths, exposed configurations. Threat detection (GuardDuty) finds evidence that something malicious is happening right now: anomalous API activity, communication with known-bad infrastructure, credential misuse. You need both, and Security Hub exists largely to bring the two streams into one place.