GuardDuty in depth

Lesson 2 of 4 in Monitoring and Alerting.

Amazon GuardDuty is the service candidates think they know and then lose points on, because the exam tests one specific property over and over: you do not feed GuardDuty.

Turn it on and it immediately begins analysing three foundational data sources — CloudTrail management events, VPC Flow Logs, and DNS query logs — from its own independent, duplicate stream. You do not create a trail for it. You do not enable flow logs for it. You do not configure Route 53 Resolver query logging for it. If you delete your own flow logs tomorrow, GuardDuty keeps seeing network activity; its copy is not your copy, is not retained in your account, and is not accessible to you. The practical consequence runs both ways: GuardDuty needs nothing from you, and GuardDuty’s coverage is no evidence that you have the logs you would need to investigate its findings. You enable your own logging for investigation, not for detection.

The exception proves the rule. CloudTrail data events are not foundational. S3 object-level activity reaches GuardDuty only when you enable S3 Protection, and Bedrock and SageMaker data events only with AI Protection. Everything resource-level arrives through a protection plan.

A finding type is readable, which means you never need to memorise the catalogue. The format is ThreatPurpose:ResourceTypeAffected/ThreatFamilyName, and it is parsed left to right: what stage of an attack, against what kind of resource, from what family. Learn the threat purposes and the rest follows.

  • Recon:EC2/Portscan — reconnaissance against EC2. Early, low severity, common, and the thing your own vulnerability scanner triggers nightly.
  • UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS — the one worth knowing by heart. Credentials issued to an EC2 instance role are being used from outside AWS, which means the instance metadata service was reached and its temporary credentials were taken. Blocking an IP does nothing useful; you revoke the session, rotate what it touched, and work out how metadata got read.
  • CryptoCurrency:EC2/BitcoinTool.B!DNS — an instance resolving a mining pool domain. The !DNS suffix tells you the detection came from DNS telemetry.
  • Backdoor:EC2/C&CActivity.B — command-and-control traffic. The host is already compromised; this is not a prevention finding.
  • Discovery:S3/MaliciousIPCaller or Exfiltration:S3/ObjectRead.Unusual — S3 findings, which exist only if S3 Protection is on.
  • Policy:IAMUser/RootCredentialUsage — the policy family: not an attack, a practice you said you would not follow.
  • Impact:EC2/* — the resource is now being used against someone: spam, DoS participation.

Severity arrives as a number on a 1.0–10.0 scale, bucketed into four levels: low (1.0–3.9, attempted activity that did not succeed — a port scan), medium (4.0–6.9, behaviour deviating from normal that may indicate compromise), high (7.0–8.9, the resource is compromised and is being used), and critical (9.0–10.0, an attack sequence in progress or just completed). Severity reflects GuardDuty’s confidence and the threat’s potential impact, not your business context — a high-severity finding on a disposable sandbox instance may matter less to you than a medium one on the payments account, which is why routing rules usually match on account and tag as well as severity.

Interactive sorting exercise: Does GuardDuty see this telemetry the moment you enable the service, or does it need a protection plan switched on first?

At organization scale, GuardDuty follows the standard shape: the Organizations management account designates a delegated administrator — a dedicated security account, not the management account — and from there enables GuardDuty and chosen protection plans across every member. The setting that decides whether this design actually holds is auto-enable for new accounts: without it, every account created after rollout is dark, and the exam loves a scenario where findings stop appearing for exactly the newest team.

Then there are three different ways to make a finding go away, and confusing them is a standard distractor set:

  • A trusted IP list stops network findings being generated for those addresses. Use it for your corporate egress range or a contracted penetration tester. A threat IP list is the inverse: your own intelligence feed, raising findings for traffic to or from those addresses regardless of GuardDuty’s own view.
  • A suppression rule lets the finding be generated and then auto-archives it, so it never reaches EventBridge or Security Hub. Use it for a known-benign recurring pattern you still want recorded.
  • Disabling a protection plan stops the detection entirely — the right move only when you have decided you do not need that visibility, usually for cost.

Both lists are uploaded once by the delegated administrator and apply organization-wide.

Key terms: Amazon GuardDuty, GuardDuty foundational data sources, GuardDuty protection plan, GuardDuty Runtime Monitoring, GuardDuty finding type, GuardDuty suppression rule, Trusted IP list / threat IP list

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.