Amazon GuardDuty was announced at re:Invent in November 2017 and became generally available in early 2018. Before it existed, detecting a compromised EC2 instance or a misused IAM credential typically meant either standing up and operating a third-party security information and event management (SIEM) platform, or building custom log analysis pipelines against raw VPC Flow Logs and CloudTrail data — both of which required significant security engineering investment before a single alert ever fired. GuardDuty’s pitch was to make that detection capability available as a service that could be enabled with a single click, with no agents to deploy and no log pipeline to build from scratch.

What made this possible technically was that AWS already had privileged, first-party access to the raw telemetry a detection engine needs — VPC Flow Logs, DNS query logs, and CloudTrail events all already exist inside AWS’s own infrastructure for every account. Rather than requiring a customer to export all of that data to an external system, GuardDuty analyzes it in place, combining it with continuously updated threat intelligence feeds (including feeds from AWS Security, CrowdStrike, and Proofpoint) and machine learning models trained on patterns of known malicious behavior.

It’s worth noting how GuardDuty’s scope has steadily widened from “network and API anomaly detection” toward something closer to a unified detection surface across nearly every layer of an AWS account — compute, network, identity, storage, containers, and databases — while keeping the same core principle from day one: analyze telemetry AWS already has, rather than requiring customers to instrument their own workloads first.

This progression also mirrors a broader shift in how cloud security is generally practiced. In the early days of cloud adoption, a lot of security tooling was ported directly from on-premises data center thinking — deploy an agent, ship logs to a centralized SIEM, build detection rules by hand. GuardDuty represented a different philosophy: since the cloud provider already has privileged visibility into infrastructure-level telemetry that would otherwise require an agent to obtain, why not offer detection built directly on that visibility as a managed capability, continuously updated by the provider’s own threat research team rather than requiring every customer to maintain their own detection content library. That philosophy has since been extended to nearly every AWS service surface that generates security-relevant telemetry, which is why features like S3 Protection and RDS Protection arrived as natural extensions rather than entirely separate products.

The core problem GuardDuty addresses is the gap between “the data needed to detect a threat exists” and “someone is actually looking at it in a way that catches the threat before real damage occurs.” VPC Flow Logs, CloudTrail events, and DNS logs are each individually voluminous and, on their own, mostly unremarkable — a single flow log entry showing an EC2 instance connecting outbound on an unusual port doesn’t automatically mean compromise, and manually reviewing millions of daily log lines for a needle like that isn’t a realistic ask for most teams.

Threats also frequently reveal themselves only through correlation across multiple signal types, not from any single log line in isolation. A compromised instance calling out to a known command-and-control domain (visible in DNS logs), combined with unusual API calls attempting to disable logging (visible in CloudTrail), combined with an unexpected spike in outbound data transfer (visible in Flow Logs), paints a much clearer picture together than any one of those signals does alone. Building and maintaining the correlation logic, threat intelligence feeds, and machine learning models needed to make that connection reliably is exactly the kind of specialized, continuously updated capability that’s expensive and difficult for most individual organizations to build and keep current on their own.

There’s also a resourcing dimension to the motivation that’s easy to underestimate: the specialized skill set needed to build and continuously tune a detection engine of this kind — someone who understands both offensive security tradecraft and the specific telemetry patterns AWS services produce — is scarce and expensive, and even organizations that can afford to hire for it often find themselves reinventing threat intelligence feeds and correlation logic that AWS, given its scale and visibility across millions of accounts, is uniquely positioned to build once and share broadly. In effect, GuardDuty lets an individual organization benefit from detection patterns learned across AWS’s entire customer base, not just from its own historical incidents — a form of collective defense that would be very difficult for any single company to replicate independently.

Findings and Finding Types

A “finding” is GuardDuty’s core output — a structured record describing a specific suspicious activity, including what resource was involved, what behavior triggered it, when it happened, and a severity score. Finding types follow a structured naming convention that encodes the threat category, the resource type affected, and the specific behavior observed — for example, a finding type describing an EC2 instance communicating with a known malicious IP is named distinctly from one describing an IAM user exhibiting anomalous API call patterns, which lets automated tooling parse and route findings without needing to read free-text descriptions.

Severity Scoring

Every finding carries a severity score from 0.1 to 8.9, grouped into Low, Medium, and High bands. This scoring reflects GuardDuty’s own assessment of how likely the finding is to represent genuine malicious activity and how significant the potential impact is — a High severity finding, like an instance actively communicating with known malware infrastructure, warrants immediate investigation, while a Low severity finding, like a single failed login attempt from an unusual location, may simply be logged for pattern-tracking rather than triggering an urgent page.

Threat Intelligence Feeds vs. Anomaly Detection

GuardDuty’s detections come from two fundamentally different mechanisms working together. Threat intelligence-based detection matches observed activity (like a destination IP or domain) against continuously updated lists of known-malicious infrastructure — this catches known threats quickly and with high confidence. Anomaly-based detection, by contrast, uses machine learning models trained on the normal behavior baseline of a specific account or resource, flagging deviations from that baseline even when the specific indicator (like a particular IP address) has never been seen as malicious before. This combination is what lets GuardDuty catch both known threats (fast, high-confidence) and genuinely novel ones (slower to confirm, but not dependent on someone else having already discovered and cataloged the threat first).

Suppression Rules and Trusted/Threat Lists

Because no automated detection system produces zero false positives, GuardDuty supports suppression rules that automatically archive findings matching specific criteria a security team has determined are expected and benign — for instance, a security scanning tool’s own traffic pattern that would otherwise look like reconnaissance. Trusted IP lists let a team pre-declare IP ranges (like their own VPN egress) that should never generate findings, while custom threat lists let a team inject their own known-bad indicators, supplementing AWS’s built-in threat intelligence with organization-specific knowledge.

Protection Plans as Modular Add-Ons

Beyond the core network and API-based detection that’s been part of GuardDuty since launch, the service is organized around optional “protection plans” that extend detection into specific AWS service areas — S3 Protection analyzes S3 data plane events for unusual access patterns, EKS Protection analyzes Kubernetes audit logs for suspicious cluster activity, RDS Protection analyzes database login activity for credential-based attacks, and Malware Protection adds agentless scanning triggered by relevant findings. Each protection plan can be enabled or disabled independently, which matters for cost management in large environments — a team might enable EKS Protection only in accounts actually running Kubernetes workloads, for example, rather than paying for analysis of a service surface that isn’t in use.

The Free Trial and Estimation Period

When first enabling GuardDuty (or a new protection plan) in an account, AWS provides a 30-day free trial period specifically so a team can estimate expected ongoing cost based on their actual telemetry volume before committing financially, and can also observe the initial baselining behavior described elsewhere in this guide without that period counting against a budget. This trial period is a genuinely useful evaluation tool for teams uncertain whether the cost of a specific protection plan is justified for their environment.

graph TB
    subgraph Sources["Data Sources (read, never modified)"]
      Flow["VPC Flow Logs"]
      DNS["DNS Resolver Logs"]
      CT["CloudTrail Events"]
      S3E["S3 Data Events"]
      EKS["EKS Audit Logs"]
      RDS["RDS Login Activity"]
    end
    subgraph Engine["GuardDuty Detection Engine"]
      TI["Threat Intelligence Matching"]
      ML["Machine Learning Anomaly Models"]
      Corr["Finding Correlation & Attack Sequences"]
    end
    Findings["Findings"]
    EB["Amazon EventBridge"]
    SH["AWS Security Hub"]
    Lambda["Automated Remediation - Lambda"]
    SNS["Notification - SNS"]

    Flow --> Engine
    DNS --> Engine
    CT --> Engine
    S3E --> Engine
    EKS --> Engine
    RDS --> Engine
    TI --> Corr
    ML --> Corr
    Corr --> Findings
    Findings --> EB
    EB --> SH
    EB --> Lambda
    EB --> SNS
        

Key Components

An important architectural characteristic is that GuardDuty is entirely agentless for its core detection surface — it doesn’t require software to be installed on EC2 instances, containers, or Lambda functions to analyze network and API-level telemetry, because that telemetry already exists at the AWS infrastructure layer. The exception is Malware Protection, which does perform an agentless scan of EBS volume snapshots when triggered by a suspicious finding, but even this doesn’t require a persistent agent running inside the instance.

Multi-Account Architecture via AWS Organizations

For organizations with many AWS accounts, GuardDuty supports a delegated administrator model: one account (typically a dedicated security account) is designated as the GuardDuty administrator for the entire AWS Organization, automatically enabling GuardDuty in member accounts and aggregating findings from all of them into a single view. This avoids the impractical alternative of a security team having to separately log into dozens or hundreds of individual accounts to check for findings.

Regional Scoping of the Architecture

GuardDuty’s detection engine and its findings are scoped per Region — an account running workloads in three Regions effectively has three independent GuardDuty deployments, each analyzing that Region’s own telemetry and building its own behavioral baseline. The delegated administrator model aggregates across accounts within a Region, but a security team still needs to explicitly review or configure aggregation across Regions if they want a single unified view spanning both dimensions simultaneously — a detail that’s sometimes assumed to be automatic but actually requires deliberate multi-Region configuration.

Internally, GuardDuty operates as a continuously running analysis pipeline rather than a periodic batch job. As VPC Flow Logs, DNS query logs, and CloudTrail events are generated within an account, GuardDuty ingests them (without requiring the account owner to have separately enabled or configured those underlying log sources — GuardDuty accesses the raw telemetry directly at the infrastructure layer, distinct from whether a customer has separately turned on VPC Flow Logs for their own visibility). Each event is evaluated in near-real-time against threat intelligence feeds and against machine learning models that have built up a behavioral baseline for that specific account’s resources.

The machine learning models underlying anomaly detection are trained on both AWS-wide threat patterns observed across the full customer base (in an anonymized, aggregate way) and account-specific behavioral baselines — meaning a pattern of API calls that would be perfectly normal for one account’s typical usage might be flagged as anomalous in another account where that pattern has never occurred before. This per-account baselining is why a newly enabled GuardDuty deployment sometimes produces more findings in its first days or weeks, as the models are still establishing what “normal” looks like for that specific environment.

Finding Correlation and Attack Sequences

Rather than treating every individual suspicious signal as its own isolated alert, GuardDuty’s Extended Threat Detection capability specifically looks for sequences of findings across multiple stages of an attack — reconnaissance, followed by initial access, followed by lateral movement or data exfiltration — and groups them into a single “attack sequence” finding when the pattern strongly suggests a coordinated, multi-stage compromise rather than several unrelated one-off anomalies. This correlation reduces alert fatigue by presenting a security analyst with one high-confidence, high-severity attack sequence instead of five separate medium-severity findings that, viewed individually, might not each seem urgent enough to prioritize.

Malware Protection’s Agentless Scanning Mechanism

When a finding suggests an EC2 instance or container workload may be compromised, GuardDuty Malware Protection can automatically trigger an agentless scan: it takes a snapshot of the affected EBS volume, scans that snapshot copy for known malware signatures, and then deletes the temporary snapshot once the scan completes — all without touching or slowing down the running instance itself. This design specifically avoids the operational risk of installing scanning agents on production workloads, at the cost of the scan only running on-demand in response to a triggering finding rather than continuously.

How Behavioral Baselines Handle Legitimate Change

A practical question that comes up quickly once GuardDuty’s anomaly detection is understood at this level of detail is what happens when an account’s legitimate usage genuinely changes — a new application deployment that introduces a new, previously unseen traffic pattern, for instance. The underlying machine learning models are designed to continuously incorporate new observed behavior into their baseline over time, rather than treating the original baseline as permanently fixed, which means a sustained new pattern of legitimate activity is gradually absorbed into what the model considers normal rather than continuing to generate findings indefinitely. This adaptive behavior is part of why sudden, large infrastructure changes can produce a temporary bump in findings similar to the initial baselining period, even in an account that’s been running GuardDuty for a long time.

sequenceDiagram
    participant Infra as AWS Infrastructure
    participant GD as GuardDuty Engine
    participant TI as Threat Intel Feeds
    participant EB as EventBridge
    participant SH as Security Hub
    participant Lam as Lambda Remediation

    Infra->>GD: VPC Flow / DNS / CloudTrail events
    GD->>TI: Check indicators against threat lists
    TI-->>GD: Match found - known malicious IP
    GD->>GD: Correlate with recent account activity
    GD->>EB: Publish new Finding event
    EB->>SH: Forward finding for centralized triage
    EB->>Lam: Trigger automated remediation (e.g. isolate instance)
    Lam-->>Infra: Apply restrictive security group
        

The lifecycle of a finding begins the moment GuardDuty’s engine identifies a pattern worth surfacing, and from that point the finding exists as a persistent record within the service, retained for 90 days by default (configurable), during which its status can be updated (archived, marked as resolved) and its occurrence count can increase if the same underlying activity is observed repeatedly rather than generating a brand-new finding each time. This “roll-up” behavior — incrementing an existing finding’s count rather than creating duplicates for genuinely repeated activity — keeps a security team’s finding queue from being flooded by the same ongoing issue appearing as dozens of separate alerts.

Once published, findings become available through three parallel channels: the GuardDuty console itself, the GuardDuty API for programmatic retrieval, and EventBridge events for real-time automated processing. Most mature security operations rely primarily on the EventBridge channel, since it enables findings to trigger downstream actions — ticket creation, Slack notification, automated remediation — within seconds of the finding being generated, rather than depending on someone manually checking a console.

What Happens to Archived Findings

When a finding is archived — either manually by an analyst or automatically via a suppression rule — it doesn’t disappear from the system entirely; it moves to an archived state that remains queryable for historical analysis but no longer appears in the default active findings view. This matters for after-the-fact investigations: if a security team later suspects an incident occurred earlier than initially realized, archived findings from that period remain available to review, which can retroactively surface an early warning signal that was dismissed too quickly at the time.

The central trade-off is between coverage and action. GuardDuty is extremely good at surfacing signal from noise across a wide range of AWS-native telemetry with minimal setup effort, but the value of that signal is entirely dependent on what a team does with it afterward — a finding that generates an email nobody reads is barely more useful than no detection at all. The teams that get the most value treat findings as the input to an automated or well-staffed response process, not as a passive dashboard to glance at occasionally.

Another trade-off worth naming explicitly concerns the modular protection plans. Enabling every available protection plan (S3, EKS, RDS, Malware Protection) by default across every account maximizes coverage but also maximizes cost, and not every account necessarily runs every protected service — enabling RDS Protection in an account with no RDS instances provides no value while still needing to be tracked as part of an organization’s overall GuardDuty configuration. Deliberately matching enabled protection plans to the actual service footprint of each account, rather than blanket-enabling everything everywhere, is a trade-off many organizations navigate as their account count grows.

GuardDuty is a fully managed service, meaning there’s no infrastructure for a customer to size or scale as data volume grows — AWS operates the detection engine’s capacity behind the scenes. From an operational perspective, “scalability” for GuardDuty is less about the detection engine’s own throughput and more about two other dimensions: how many AWS accounts and Regions are being monitored, and how a security team’s own response processes scale as finding volume grows alongside account growth.

Cost, which functions as a practical proxy for scale, is based on the volume of data analyzed — CloudTrail events, VPC Flow Log volume, DNS query volume — plus additional charges for optional features like Malware Protection scanning and S3 Protection’s analysis of S3 data events. A large, high-traffic account naturally generates more telemetry and therefore costs more to monitor than a small, low-traffic one, which means cost estimation before enabling GuardDuty organization-wide typically involves reviewing existing CloudTrail and Flow Log volume as a leading indicator.

Scaling Response, Not Just Detection

As an organization grows from a handful of accounts to hundreds, the volume of findings grows roughly in proportion, and manual triage that worked fine for a small footprint becomes untenable without automation. Teams that scale successfully typically invest early in automated triage rules (auto-archiving known-benign patterns, auto-escalating high severity findings to a paging system) rather than waiting until finding volume has already overwhelmed a manual review process.

Estimating Cost Before Organization-Wide Rollout

Because cost scales with telemetry volume rather than with a flat per-account or per-instance fee, teams planning an organization-wide rollout typically start with the free trial period in a representative sample of accounts — a mix of high-traffic production accounts and lower-traffic development accounts — to build a realistic cost model before committing to full deployment across potentially hundreds of accounts at once. Extrapolating cost from a single small account to an entire large organization can significantly underestimate real cost if that account isn’t representative of the higher-traffic production accounts that generate the bulk of an organization’s telemetry volume.

Because GuardDuty is a Regional service operated entirely by AWS, its own availability follows the same operational model as other AWS-managed services — customers don’t manage or patch any GuardDuty infrastructure directly. Reliability considerations for a GuardDuty deployment center less on “will the service stay up” and more on “is coverage complete across every Region and account a customer actually operates in.”

Because GuardDuty must be explicitly enabled per Region, a common reliability gap in practice isn’t a service outage — it’s an account with workloads running in a Region where GuardDuty was never turned on, leaving that Region’s activity entirely unmonitored. This is one of the most consequential intermediate-level operational details: enabling GuardDuty in only the Regions a team is actively aware of using can leave blind spots in Regions used incidentally (for instance, a global service creating resources in an unexpected Region, or an attacker deliberately operating in a Region a security team doesn’t normally watch).

You may likeAmazon Redshift→

graph LR
    subgraph Covered["Monitored Regions"]
      R1["us-east-1 - GuardDuty ON"]
      R2["eu-west-1 - GuardDuty ON"]
    end
    subgraph Gap["Coverage Gap"]
      R3["ap-southeast-2 - GuardDuty OFF"]
    end
    Attacker["Attacker Activity"] --> R3
    R3 -.->|"No detection - blind spot"| Analyst["Security Team"]
        

Reliability of Downstream Automation, Not Just the Detection Engine

Because a finding’s real-world value depends on the automation or human process that acts on it, the reliability of a GuardDuty deployment in practice extends to the EventBridge rules, Lambda functions, and notification pipelines built on top of it. A misconfigured EventBridge rule that silently stops matching findings after an unrelated infrastructure change can leave an organization believing it has active automated response coverage when, in reality, findings have been generated correctly but never reached the intended downstream action — a failure mode that’s easy to miss without periodically testing the full pipeline end-to-end, not just confirming that GuardDuty itself is enabled.

GuardDuty itself operates with read-only access to the telemetry it analyzes — it doesn’t modify VPC Flow Logs, CloudTrail events, or DNS records, and it has no ability to alter the resources it monitors. Its own service role is scoped narrowly to reading the specific data sources needed for detection, which limits the blast radius if the service’s own permissions were ever somehow misused (an important distinction from any custom-built detection pipeline that might inadvertently be granted broader permissions than strictly necessary).

Threat Intelligence Confidentiality

The specific threat intelligence indicators GuardDuty uses to match against known-malicious infrastructure aren’t fully exposed to customers in raw form — this is a deliberate design choice, since publishing the complete list of known-bad indicators would give attackers a roadmap for which specific infrastructure to avoid using next. Security teams generally accept this as a reasonable trade-off, since the value of the detection (knowing an indicator matched) doesn’t require full visibility into the entire underlying threat feed to be actionable.

Ironically, a service designed to monitor everything else also needs to be monitored itself — teams typically track GuardDuty’s own operational health through CloudWatch metrics covering finding counts by severity, data source coverage (confirming Flow Logs, DNS logs, and CloudTrail are all actively being ingested), and the health of downstream EventBridge rules and remediation pipelines that depend on findings actually arriving as expected.

Avoiding Alert Fatigue Through Metrics

Tracking the ratio of findings marked as true positives versus those archived as benign over time gives a security team a concrete signal about whether their suppression rules and triage process are well-tuned. A consistently high archive rate for a specific finding type is often a sign that a suppression rule should be added, rather than continuing to have analysts manually dismiss the same pattern repeatedly.

Establishing a Baseline Metrics Review Cadence

Beyond reactive, per-finding investigation, mature security teams typically review aggregate GuardDuty metrics on a regular cadence — weekly or monthly — looking specifically for trend shifts: a gradual increase in reconnaissance findings against a particular resource, a new finding type appearing for the first time in a previously quiet account, or a change in the geographic distribution of flagged API activity. This periodic trend review catches slower-developing threats that wouldn’t necessarily trigger urgent individual alerts but represent a meaningful shift in an organization’s overall risk exposure over time.

GuardDuty is typically enabled through the AWS Management Console for a quick evaluation, but production deployments across an AWS Organization almost always use infrastructure-as-code (CloudFormation, Terraform, or AWS Organizations’ own delegated administrator APIs) to ensure every existing and newly created account automatically has GuardDuty enabled without relying on someone remembering to turn it on manually for each new account.

Downstream integration typically routes findings through EventBridge to one or more of: AWS Security Hub for centralized triage, an SNS topic feeding a ticketing system or Slack channel for human notification, and a Lambda function for automated remediation of well-understood, low-risk finding types (like automatically isolating an EC2 instance flagged for malware communication by attaching a restrictive security group). More mature environments often integrate GuardDuty findings into a broader Security Orchestration, Automation, and Response (SOAR) platform, using GuardDuty as one input signal alongside others rather than the sole source of truth.

Onboarding New Accounts Automatically

A common deployment pattern in growing organizations is wiring GuardDuty enablement directly into the account-vending process — whenever a new AWS account is provisioned through AWS Control Tower or a custom account factory pipeline, GuardDuty (along with other baseline security services) is enabled automatically as part of that provisioning workflow, rather than left as a manual follow-up step that can be forgotten under the pressure of getting a new account operational quickly for a project deadline.

Cross-Region Aggregation Strategies

For organizations operating across many Regions, some teams build a lightweight aggregation layer on top of GuardDuty’s own delegated administrator model — using EventBridge cross-Region event routing to funnel findings from every Region into a single centralized Region for unified dashboarding and alerting, rather than requiring analysts to check each Region’s findings separately even after account-level aggregation is already in place.

Pattern: Tiered Automated Response by Severity

Rather than treating every finding identically, mature deployments route findings differently based on severity — High severity findings trigger immediate automated containment actions and page an on-call responder simultaneously, Medium severity findings create a ticket for review within a defined SLA, and Low severity findings are logged for pattern analysis without individual human review. This tiered approach concentrates human attention where it matters most while still capturing lower-priority signal for later trend analysis.

Pattern: Centralized Multi-Account Aggregation

Designating a dedicated security account as GuardDuty’s delegated administrator across an entire AWS Organization, with findings aggregated centrally and downstream automation configured once at the organization level rather than duplicated per account, is the standard pattern for any organization operating more than a handful of AWS accounts.

Pattern: Suppression as a Continuously Maintained Asset

Treating suppression rules as living configuration — reviewed and updated as an environment changes, rather than written once and forgotten — keeps the signal-to-noise ratio healthy over time. An outdated suppression rule can either hide a genuine emerging threat that happens to resemble a previously benign pattern, or fail to suppress a pattern that changed shape slightly after infrastructure was updated.

ANTI-PATTERN · DES-02 Avoid

Pattern

Suppressing entire finding types broadly (rather than narrowly scoped suppression rules) in response to a handful of false positives, out of frustration with alert volume.

Why It’s a Problem

Broad suppression of an entire finding type can silently blind the organization to future genuine occurrences of that same threat category, trading short-term alert fatigue relief for a long-term detection gap that may not be discovered until an actual incident goes unnoticed.

Correct Approach

Scope suppression rules as narrowly as possible — to the specific resource, IP range, or pattern known to be benign — rather than disabling an entire category of detection.

You may likeAWS Lambda→

Treating Findings as a Feedback Loop for Broader Security Posture

Beyond individual incident response, recurring finding patterns are valuable input for improving an organization’s underlying security posture — repeated reconnaissance findings against a specific public-facing resource might justify tightening its security group rules proactively, and repeated anomalous API call findings tied to a specific IAM role might justify reviewing whether that role’s permissions are broader than actually needed. Treating GuardDuty purely as an incident-by-incident alerting tool, without periodically stepping back to look at patterns across findings, leaves this broader improvement opportunity on the table.

Testing the Full Response Pipeline Periodically

Because the value of GuardDuty is realized entirely through the response process built on top of it, periodically validating that the full pipeline works end-to-end — from a simulated or sample finding through EventBridge, into Security Hub, and through to whatever notification or remediation action is expected — catches silent breakages before they matter during an actual incident. Teams sometimes discover during a real event that a downstream integration had been quietly broken for weeks, a gap that a routine quarterly test of the pipeline would have caught with no real risk involved.