GuardDuty
Amazon GuardDuty is a threat detection service: it reads the logs AWS already collects, looks for signs of compromise such as credential misuse or malware, and raises findings. The platform runs it for every account from core-security.
What it does
GuardDuty needs no agents. A detector in each account analyzes CloudTrail management events, VPC Flow Logs and DNS query logs, and compares what it sees with threat intelligence and behavior models. Optional features add more data sources: S3 data events, EKS audit logs, and malware scanning of EBS volumes attached to suspicious instances. A finding describes one suspected threat with a severity from 1 to 10. In an organization, one account is the delegated administrator: it sees every member's findings and can switch members on automatically.
How BuiltForProd uses it
GuardDuty is on by default (enable_guardduty = true in environments/core/security/security.hcl), the one file that switches every security service. Setup is the three-step delegated-administrator pattern, split across two units that share the same module:
| Step | Unit | Account | What it does |
|---|---|---|---|
| 1 | guardduty | core-security | Creates the detector and enables the S3 data events, EKS audit logs and EBS malware protection features |
| 2 | guardduty-delegation | core-root | Names core-security as the GuardDuty delegated administrator |
| 3 | guardduty again | core-security | With org_auto_enable.guardduty = true, enrolls every member account and turns the same features on for all of them |
Both halves read the same switch, so the service is never delegated without being run, or run without being delegated. The org_auto_enable flag stays false until the delegation unit has been applied, which is why it is a separate switch.
Findings flow two ways. Security Hub ingests them through its GuardDuty product integration, which follows the same switch. An EventBridge rule in core-security (units/security-remediation) forwards findings with severity 7 or higher to the acme-security-alerts SNS topic, so people are paged only for findings that need a decision.
The SecurityAuditorAccess permission set may list detectors and read findings in every account, which is how an auditor confirms coverage. Cost is usage based, driven by the volume of CloudTrail events, Flow Logs and DNS logs analyzed; the switch file notes a 30-day free trial per account.
Terms you will see
| Term | Meaning |
|---|---|
| Detector | The per-account, per-region GuardDuty resource that does the analysis. |
| Finding | One suspected threat, with a type, a severity and the affected resource. |
| Severity | A score from 1 to 10; the platform alerts from 7 upward. |
| Feature | An optional data source: S3 data events, EKS audit logs, EBS malware protection. |
| Delegated administrator | The account that manages GuardDuty for the organization; core-security. |
| Auto-enable | The organization setting that enrolls new and existing members automatically. |
| Product integration | The Security Hub setting that imports GuardDuty findings. |
Where to read more
- AWS Baseline overview for the security account and its services.
- Security Hub for the single view of findings from every service.
- EventBridge and SNS for how a finding becomes an alert.