AWS GuardDuty: Threat Detection Setup and Best Practices

AWS GuardDuty is Amazon's managed threat detection service. It continuously analyzes account activity, network traffic, and workload behavior across your AWS environment and flags suspicious activity such as compromised credentials, malware, reconnaissance, and data exfiltration, without requiring you to deploy or manage any detection infrastructure yourself.

For cloud security engineers, GuardDuty is one of the fastest ways to add real detection coverage to an AWS account. It is also one of the most commonly tested services on the AWS Certified Security - Specialty exam, which makes understanding it valuable both operationally and for certification. This guide covers how GuardDuty works, what it monitors, how to set it up correctly, and the practices that separate a noisy, ignored dashboard from a detection system your team actually trusts.

What AWS GuardDuty Actually Monitors

GuardDuty does not require you to install agents or forward logs manually for its foundational detections. It ingests several data sources automatically once enabled:

• VPC Flow Logs for network traffic patterns, including communication with known malicious IP addresses
• DNS query logs for domains associated with command-and-control infrastructure
• AWS CloudTrail management and S3 data events for API activity that suggests account compromise or misuse
• EKS audit logs for Kubernetes-level threats

Because these sources are read directly by GuardDuty rather than pulled from logs you configure, there is nothing to instrument on the workload side for foundational detection. That is part of what makes it a good starting point for teams that do not yet have a mature logging pipeline.

GuardDuty Protection Plans

Beyond foundational detection, GuardDuty offers additional protection plans that extend coverage to specific services. Each plan is enabled separately and analyzes data sources unique to that service.

Protection Plan	What It Monitors	Example Threats Detected
S3 Protection	S3 data plane events	Unusual data access patterns, potential exfiltration, suspicious API calls against buckets
EKS Protection	Kubernetes audit logs	Container escape attempts, privilege escalation, suspicious pod deployments
RDS Protection	Aurora login activity	Anomalous or brute-force database login attempts
Lambda Protection	Lambda network activity	Suspicious outbound connections and DNS queries from function code
Malware Protection	EBS volumes, S3 objects, AWS Backup data	Trojans, worms, cryptomining malware, rootkits on compromised resources
Runtime Monitoring	EC2 and container runtime behavior	Process-level and file-level indicators of compromise on running workloads

You do not need to enable every plan on day one. A reasonable starting point for most organizations is foundational detection plus S3 Protection and Malware Protection, since those cover the most common early-stage attack patterns: compromised credentials probing storage and malicious files landing on infrastructure.

Understanding Findings and Severity

GuardDuty findings are grouped into categories such as reconnaissance, unauthorized access, credential compromise, malware, and data exfiltration. Each finding is assigned a severity level so your team can triage quickly instead of treating every alert as equally urgent.

In general terms, low-severity findings often reflect activity worth noting but not necessarily malicious on their own, medium-severity findings suggest behavior that deviates from normal patterns and warrants review, and high or critical findings indicate a resource is likely compromised or being actively misused and needs an immediate response. Rather than memorizing exact numeric thresholds, focus on building a response process: who reviews findings, how fast, and what the escalation path looks like for each severity tier.

Setting Up GuardDuty Step by Step

1. Enable GuardDuty in every region you operate in. It is a regional service, so a threat actor operating in a region you have not enabled will not be detected.
2. Use the trial period to establish a baseline. GuardDuty includes a trial window per account that helps you understand what normal activity looks like before you start tuning alerts.
3. Centralize findings with a delegated administrator account. In a multi-account AWS Organizations setup, designate one account to view and manage GuardDuty findings across all member accounts instead of checking each account individually.
4. Enable the protection plans relevant to your workloads. Start with foundational detection, S3 Protection, and Malware Protection, then expand to EKS, RDS, or Lambda Protection based on what you actually run.
5. Route findings to a response pipeline. Send findings to Amazon EventBridge and from there to Slack, a ticketing system, or a SIEM so they do not sit unread in the console.
6. Automate remediation for well-understood findings. Use AWS Lambda to take predictable actions, such as isolating an EC2 instance's security group, for finding types your team has agreed warrant automatic response.

Best Practices for Running GuardDuty in Production

Enabling GuardDuty is the easy part. Making it useful long term depends on a few habits.

Tune before you trust. Suppress or archive findings that are confirmed false positives for your environment, such as known vulnerability scanners, so real alerts are not buried in noise. Review suppression rules periodically since environments change.

Treat GuardDuty as one signal, not the whole picture. It works best alongside AWS IAM least-privilege practices and hardened S3 bucket configurations, since prevention and detection are complementary layers, not substitutes for each other.

Feed findings into AWS Security Hub if you use multiple AWS security services. Security Hub aggregates GuardDuty findings alongside those from other tools into a single view with a normalized severity scoring format, which reduces the number of dashboards your team has to check.

Assign clear ownership. A finding that nobody is responsible for reviewing provides no security value regardless of how accurate the detection is. Define who triages findings, what the response SLA is per severity level, and how escalations happen outside business hours.

Revisit protection plan coverage as your architecture changes. A team that starts with EC2 workloads and later adopts EKS or Lambda needs to add the corresponding protection plans, since GuardDuty does not automatically extend into services you have not enabled a plan for.

GuardDuty in the Real World of Cloud Security Roles

GuardDuty setup and tuning shows up in real job responsibilities for cloud security analysts, SOC engineers, and cloud security engineers, not just in exam objectives. Being able to explain what a finding means, why it triggered, and what the appropriate response is, is the kind of practical skill that hiring managers look for in interviews. If you are working toward a cloud security role, hands-on labs that involve enabling GuardDuty, generating sample findings, and building a response workflow are far more valuable than reading documentation alone.

This is the kind of applied, lab-based learning built into the PrimeSec Academy curriculum, where you configure real detection and monitoring tools like GuardDuty across AWS, Azure, and GCP environments rather than only studying them conceptually.

Frequently asked questions

Is AWS GuardDuty free to use? GuardDuty includes a trial period per account so you can evaluate it before committing, but ongoing use is billed based on the volume of data analyzed and which protection plans you enable. Review current pricing on the official AWS GuardDuty page before rolling it out broadly, since cost scales with account activity and log volume.

Does GuardDuty require me to install any agents? Foundational detection does not require agents since it reads VPC Flow Logs, DNS logs, and CloudTrail events directly. Runtime Monitoring for EC2 and container workloads uses a lightweight agent to gain visibility into process and file-level activity.

What is the difference between GuardDuty and AWS Security Hub? GuardDuty is a threat detection service that generates findings from analyzed activity. Security Hub is an aggregation and posture management service that can collect findings from GuardDuty and other AWS security tools into a single normalized dashboard. Many teams use both together.

How does GuardDuty relate to AWS certification exams? GuardDuty is commonly covered in the AWS Certified Security - Specialty exam under detection and incident response domains. Understanding its data sources, finding types, and response workflow is useful exam preparation as well as real job skill.

Should I enable every GuardDuty protection plan immediately? Not necessarily. Start with foundational detection and the plans most relevant to the services you actually run, such as S3 Protection if you store sensitive data in S3, then expand coverage as your architecture grows.

Can GuardDuty detect threats across multiple AWS accounts? Yes. Using AWS Organizations, you can designate a delegated administrator account that centrally manages GuardDuty configuration and views findings across all member accounts instead of enabling and monitoring it separately in each one.

Ready to build the hands-on skills to configure and respond to real AWS threat detection tooling like GuardDuty? Explore the PrimeSec Academy curriculum or enroll today to start training across AWS, Azure, GCP, and AI security.