Amazon GuardDuty

Most security tools tell you whether your setup is configured correctly. Amazon GuardDuty is different: it watches what is actually happening in your account and flags suspicious behaviour as it occurs. It is a managed threat-detection service that reads your logs, runs them through machine-learning models and known-threat intelligence, and raises a “finding” whenever something looks like an attack — crypto-mining, leaked credentials being used from a strange location, or someone quietly probing your network. There are no agents to install and nothing to run on your servers. This page explains what it sees, how to turn it on, and the one mistake almost everyone makes with it.

What GuardDuty actually watches

GuardDuty does not need software on your instances. Instead, it continuously reads three data sources that AWS already produces for you:

AWS CloudTrail — the audit log of every API call in your account (who did what, from where). GuardDuty uses this to spot things like an IAM (Identity and Access Management) user suddenly disabling logging, or root credentials being used from a country you have never operated in.
VPC Flow Logs — a record of network traffic going in and out of your VPC (Virtual Private Cloud, your private network in AWS). This reveals an EC2 instance talking to a known crypto-mining pool, or scanning ports across your subnet.
DNS query logs — the domain names your resources look up. Malware often “phones home” to a command-and-control server, and that shows up as a suspicious DNS lookup.

Because GuardDuty consumes these streams independently, it works even if you never enabled CloudTrail or Flow Logs yourself — it taps the underlying data directly. Optional extra coverage includes S3 protection, EKS (Elastic Kubernetes Service) audit logs, RDS login activity, Lambda network activity, and Malware Protection that scans EBS volumes attached to a flagged instance.

How findings work

When GuardDuty’s models decide something is wrong, they create a finding: a structured JSON record describing the threat, its severity (a score from 1.0 to 8.9+), the resource involved, and the evidence. Finding types follow a readable naming pattern like CryptoCurrency:EC2/BitcoinTool.B!DNS or UnauthorizedAccess:IAMUser/MaliciousIPCaller.

The single most important gotcha: GuardDuty only detects and reports. It does not block, quarantine, or remediate anything on its own. A critical finding will sit in the console doing nothing useful unless you wire it up to take action. Treat “enabling GuardDuty” and “responding to GuardDuty” as two separate jobs.

Acting on findings with EventBridge

Every finding is published as an event to Amazon EventBridge (the AWS event bus). This is how you turn detection into action. You write a rule that matches GuardDuty events and routes them to a target — an SNS (Simple Notification Service) topic for an alert, or a Lambda function for automated remediation (for example, isolating an instance by swapping its security group).

Console steps

Open the Amazon EventBridge console and choose Rules > Create rule.
Name the rule (e.g. guardduty-high-severity) and keep the default event bus.
Under Event pattern, choose AWS services > GuardDuty > GuardDuty Finding.
(Recommended) Edit the pattern to filter by severity so you are not paged for low-priority noise.
Add a Target — an SNS topic to email/Slack your team, or a Lambda function to auto-remediate.
Choose Create.

AWS CLI

Create a rule that only fires on findings of severity 7.0 and above:

aws events put-rule \
  --name guardduty-high-severity \
  --event-pattern '{
    "source": ["aws.guardduty"],
    "detail-type": ["GuardDuty Finding"],
    "detail": { "severity": [{ "numeric": [">=", 7.0] }] }
  }'

Then attach an SNS topic as the target:

aws events put-targets \
  --rule guardduty-high-severity \
  --targets "Id"="1","Arn"="arn:aws:sns:us-east-1:123456789012:security-alerts"

When to use which target: send everything to SNS for visibility, but only auto-remediate threats you fully understand. A Lambda that automatically terminates instances on any finding can take down healthy workloads on a false positive.

Enabling GuardDuty

Single account — console

Open the Amazon GuardDuty console in the region you want to protect.
Choose Get Started, then Enable GuardDuty.
(Optional) Enable the extra protection plans — S3, EKS, Malware, RDS, Lambda — under Protection plans.
GuardDuty starts analysing immediately; first findings typically appear within minutes.

Single account — CLI

aws guardduty create-detector --enable

Output:

{
    "DetectorId": "12abc34d567e8fa901bc2d34e56789f0"
}

Region note: GuardDuty is a regional service. Enabling it in us-east-1 does not protect eu-west-1. You must enable it in every region you use — including ones you don’t, so an attacker can’t spin up resources somewhere you aren’t watching.

Multi-account: the delegated admin pattern

In a real organization you have many AWS accounts, and turning GuardDuty on one-by-one is unmanageable. The correct pattern is AWS Organizations with a delegated administrator: pick one account (usually a dedicated security/audit account, not the management account), make it the GuardDuty delegated admin, and have it enable and view findings for every member account from one place.

From the delegated admin account, you can set auto-enable so any new account that joins the organization gets GuardDuty turned on automatically — closing the gap where a fresh account sits unmonitored.

# Run from the Organizations management account
aws guardduty enable-organization-admin-account \
  --admin-account-id 444455556666

# Run from the delegated admin account: auto-enable for new accounts
aws guardduty update-organization-configuration \
  --detector-id 12abc34d567e8fa901bc2d34e56789f0 \
  --auto-enable-organization-members ALL

Cost: it bills by volume

GuardDuty has no fixed fee — you pay for the volume of data analysed. The main drivers are the number of CloudTrail management events, the gigabytes of VPC Flow Logs and DNS logs, and per-protection-plan charges (S3 events, EKS audit logs, malware scans). A quiet account costs cents per month; a busy, chatty workload costs more.

Cost tip: A free 30-day trial shows you the estimated monthly bill before you commit. The biggest surprise is usually high-volume VPC Flow Logs from a busy NAT gateway. Use the Usage tab in the GuardDuty console to see per-source spend and decide which protection plans are worth it.

Best Practices

Enable GuardDuty in every region, in every account — use the Organizations delegated-admin pattern with auto-enable so nothing slips through.
Never stop at “enabled”. Wire findings to EventBridge so they trigger real alerts or remediation, or they just pile up unread.
Filter EventBridge rules by severity to avoid alert fatigue — page humans only for high-severity findings.
Auto-remediate only the threats you understand well; otherwise a false positive can cause its own outage.
Forward findings to AWS Security Hub to see GuardDuty alongside Inspector, Macie, and Config in one dashboard.
Use the GuardDuty Usage view and the 30-day trial to control costs, and review which optional protection plans you actually need.
Use suppression rules to silence known-benign findings (like a trusted scanner) instead of ignoring the whole finding type.