Threat Detection and Incident Response
The detection stack
GuardDuty is the core service that detects threats by itself: it continuously analyses VPC flow logs, CloudTrail management events, DNS query logs and EKS audit logs (plus opt-in S3 data events, EBS malware scans and RDS login activity) and emits severity-ranked findings. It never blocks traffic - that is the most common trap. CloudTrail, Config and Security Hub are not detectors: CloudTrail records API calls, Config records resource state, and Security Hub only aggregates and scores findings in ASFF format against standards such as CIS and FSBP.
Amazon Detective builds a behaviour graph from up to a year of CloudTrail, flow-log and GuardDuty data for investigation - it is not real-time prevention. Inspector finds CVEs and reachability issues on EC2, ECR images and Lambda; Macie finds sensitive data in S3. Swapping Inspector, Macie and GuardDuty in a distractor is a classic trick.
Response
Automate containment with EventBridge rules that match GuardDuty finding types and invoke Lambda or an SSM Automation runbook. Typical playbook steps: replace the instance's security groups with an isolation group (or apply a deny-all NACL), snapshot EBS volumes for forensics, disable (not delete) compromised IAM access keys, and revoke active role sessions. Do forensics on a copy of the snapshot in a dedicated, isolated account with no internet path. Follow prepare → detect → contain → eradicate → recover → lessons learned, and remember shared responsibility.
Rule of thumb
If the question asks for real-time prevention, the answer is a security group, NACL, WAF, SCP or Network Firewall - never GuardDuty. If it asks what surfaced the anomaly, it is GuardDuty, Inspector or Macie depending on whether the subject is behaviour, vulnerabilities or data.