What Is Amazon GuardDuty? The Guard Who Reads Your Logs

Amazon GuardDuty is the threat detector for your AWS account — a managed service that reads your logs around the clock, compares what it sees against lists of known-bad IP addresses, domains, and file hashes, learns what "normal" looks like for your account, and raises a finding when something does not fit: a key being used from a Tor exit node, a server quietly mining cryptocurrency, a bucket suddenly being read from a country nobody on your team lives in. It needs no agent, no rules to write, and no log to switch on. And here is the part the last post in this series set up without meaning to: GuardDuty can see the S3 reads that CloudTrail skips by default — without you turning data events on, and for less than CloudTrail would charge to log them. The audit log has a blind spot; the guard reads it anyway. This post explains what GuardDuty is and is not (it is not a firewall, not quite an IDS, definitely not a SIEM), what its findings mean, what the 30-day trial really covers and what the bill looks like after it, which of its many protection plans a small account should keep switched on, and it keeps the promise the CloudTrail post made: a $0 alarm that emails you the moment a serious finding appears.

This is the nineteenth stop in the Learn AWS for Free series, and it is the post the CloudTrail post promised. That one gave you a record of every door that opened in your account. This one answers the question that record immediately raises: who is going to sit and read it? Not you — not at 3 a.m., not every day, not across ten thousand lines of JSON. GuardDuty is the answer AWS built to that exact problem, and it is one of the few AWS security services that a solo builder can switch on in two clicks and genuinely leave alone.

What is Amazon GuardDuty used for? The guard who reads the key-card log

My friend Ethan, who has a metaphor for every AWS service and a coffee for every metaphor, picked up where he left off last time. An office building has a smoke detector (CloudWatch) and a key-card log at every door (CloudTrail). What it also has, if it is any good, is a security guard on the night desk. The guard does not lock doors; the locks do that. The guard does not check whether the locks are strong; that is the building inspector. What the guard does is read: the key-card log, the CCTV feed, the phone records — and call you only when something is wrong. A badge used at 3 a.m. by someone who left the company. The same badge opening doors on two floors at once. A delivery van that has been parked outside for three nights. That guard is GuardDuty, and once you hold that picture, every feature of the service sorts itself into place.

In AWS terms, GuardDuty continuously analyzes three streams of data for the account it is switched on in: the CloudTrail management events you met last post (who called which API), VPC flow logs (which IP talked to which IP on which port, for every network interface in your VPC), and DNS query logs (which domain names your servers looked up). Against those streams it runs three kinds of check: threat intelligence — lists of IP addresses, domains, and file hashes that AWS, CrowdStrike, and Proofpoint know to be malicious; anomaly detection — machine-learning models that learn how your account normally behaves and notice when it stops; and, since 2025, attack-sequence correlation — stitching several individually-boring events into a pattern that looks like an attack in progress. The output is a finding: a JSON document with a type, a severity from 1 to 10, the resource involved, and a description a human can read. Nothing is blocked. Nothing is changed. The guard calls; you decide.

How does GuardDuty work? Three logs you never turned on

This is the part that catches people who read the CloudTrail post carefully. You may be thinking: I never enabled VPC flow logs. I certainly never enabled DNS query logging. And I read last week that S3 data events are off by default in CloudTrail. So what exactly is GuardDuty going to read? The answer, and it is the single most useful fact in this post: GuardDuty does not read your copies of those logs. It gets its own. When you enable the service, AWS starts feeding GuardDuty an independent stream of flow-log data, DNS-resolver data, and CloudTrail events directly from the underlying infrastructure. You do not have to turn on VPC Flow Logs (which would cost CloudWatch Logs or S3 money). You do not have to enable Route 53 query logging. And when you enable S3 Protection, GuardDuty consumes S3 data events on its own — the CloudTrail console will still say data events are off, no trail is written, and you are not billed CloudTrail’s $0.10 per 100,000 for them.

That last point deserves its own line, because it flips the last post’s shock on its head. Logging every S3 read in CloudTrail costs $1.00 per million events. GuardDuty S3 Protection, which analyzes the same reads for threats, costs $0.80 per million (as of August 2026, US East, first 500 million). The service that watches the blind spot charges less than the service that would merely record it. You do not get the raw log — GuardDuty keeps its stream to itself and hands you only findings — so for a forensic "who downloaded which file" question you still want CloudTrail data events on the one bucket that matters. But for the question most people actually have — is anyone doing something to my bucket that they shouldn’t? — the guard reads it for you, and the bill is smaller.

One honest limit: GuardDuty is regional. It analyzes the logs of the region it is enabled in, and findings live in that region’s console. Enable it in every region you use — and, because attackers love regions you forgot exist, consider enabling it in the ones you do not use too. The base cost of an empty region is close to $0, because there are no events to analyze.

Is GuardDuty an IDS? A firewall? A SIEM? Three questions, three straight answers

Is GuardDuty an IDS? Closest to yes. An intrusion detection system watches traffic and events and alerts on suspicious patterns without blocking them — that is precisely what GuardDuty does. The difference from a classic network IDS like Snort or Suricata is that GuardDuty never sees packet contents; it sees flow metadata (who talked to whom, how much, on what port), DNS lookups, and API calls. It cannot spot a SQL-injection string inside an HTTP request. It can spot that your web server has started talking to a known command-and-control domain, which is usually what matters more. AWS commissioned a third-party comparison against network IDS products in 2023 and published it on the AWS Security Blog; the fair summary is "different vantage point, comparable catch rate on cloud-native attacks, far less to run."

Is GuardDuty a firewall? No. It blocks nothing, ever. Security groups, network ACLs, AWS Network Firewall, and AWS WAF are the things that say no to traffic. GuardDuty tells you that something got through, or is trying to. The two are complementary — and the honest ordering for a small account is: get the security groups right first (they are free), then turn on GuardDuty to find out what you missed.

Is GuardDuty a SIEM? No. A security information and event management system collects logs from everywhere, stores them for a year or more, lets analysts query them, and manages the workflow of an investigation. GuardDuty keeps findings for 90 days, stores no raw logs you can query, and has no ticketing. It is the most important source a SIEM reads in an AWS environment, alongside CloudTrail. If you need the SIEM layer, AWS Security Hub is the built-in aggregator and Amazon Detective is the built-in investigator; both consume GuardDuty findings.

What does GuardDuty detect? The finding families in plain English

Every finding has a type name that looks intimidating and is actually a sentence in disguise. UnauthorizedAccess:IAMUser/TorIPCaller reads as: threat purpose (unauthorized access), resource affected (an IAM identity), what was seen (an API call from a Tor exit node). Learn the first word and you can triage most findings from the name alone. Here are the families you will actually meet, what each means in English, and a real example from the current list of roughly 200 active types.

Notice the pattern in the examples: a suffix of !DNS means the evidence came from DNS logs; .Custom means it matched a threat list you uploaded; AnomalousBehavior means the machine-learning model, not a blocklist, raised it — those are the ones worth reading slowly, because they are the ones a blocklist would never catch.

GuardDuty severity levels: what Low, Medium, High, and Critical actually ask of you

Every finding carries a number from 1.0 to 10.0 and a label. The label is the useful part, because AWS attached a plain-English instruction to each one, and the instruction is what you should build your alarm around.

A word of reassurance before you enable it: a public-facing server on AWS gets port-scanned and SSH-brute-forced constantly. That is the internet’s background radiation, not a sign you have been singled out. GuardDuty will show you Low findings for it, and the right response to those is genuinely nothing — except to check that the SSH port is not open to the world in the first place.

Jake’s first morning: the finding that turned out to be Jake

Jake — the friend whose AWS misadventures have carried this series since the S3 post — enabled GuardDuty on a Sunday evening, mostly because I had been nagging. Monday morning there was a Medium finding waiting: PenTest:IAMUser/KaliLinux. "Someone is pentesting my account," he texted, with a screenshot, at 7:40 a.m. Reader, it was Jake. He had run the AWS CLI from his Kali laptop the night before to check the finding list was empty. GuardDuty recognizes the user-agent string of a machine running Kali Linux (and Parrot, and Pentoo), and flags any API call from one as a Medium, on the reasonable theory that most accounts are not administered from a penetration-testing distribution. If you are reading this blog, there is a fair chance you are one of the exceptions. Expect that finding. It is the friendliest false positive in the service, and a perfect first suppression rule, which we will build below.

The real one came nine days later, and it was quieter. UnauthorizedAccess:IAMUser/MaliciousIPCaller — High. An access key belonging to an IAM user called backup-script had made a ListBuckets call from an IP address on a threat list. Jake had never heard of the user. CloudTrail, the key-card log, showed the key had been created in 2024 and last used in 2024 — until that morning. The key lived in a config file in a repository that had been public for eighteen months. Nobody had stolen it; a scanner had simply found it, the way scanners find everything eventually. Jake deleted the key, deleted the user, and checked the bucket list for anything new. Total damage: one ListBuckets call and a lost morning. Without the guard, the next call would have been GetObject, and the call after that would have been from his customers.

How to enable GuardDuty, step by step (and what switches on with it)

This is the shortest enable procedure in the whole series, and I have stretched it to make the choices visible. It takes under two minutes.

1. Sign in with an IAM identity that has administrator rights (not root — GuardDuty will file a finding about that too, and it will be right). Open the GuardDuty console and confirm the region selector is on the region where your resources live.
2. Click Get Started. The page lists the protection plans that will be enabled alongside the foundational detection: S3 Protection, EKS Protection, Malware Protection for EC2, RDS Protection, Lambda Protection, and AI Protection. Runtime Monitoring is not on by default (it needs an agent). Leave the defaults for the trial; you will prune them at the end of it with real usage numbers in hand.
3. Click Enable GuardDuty. That is the whole enable. A detector is created for the region — the ID you will need for any CLI command — and the 30-day trial clock starts.
4. Go to Settings and note the detector ID. While you are there, under Findings export options, change Frequency for updated findings from 6 hours to 15 minutes. It costs nothing and it is the difference between hearing about a repeat occurrence at lunch and at dinner.
5. Go to Usage. From day one this page shows a daily cost estimate per data source and per protection plan — the number you would be paying if the trial were over. Watch it during the trial; it is how you decide what to keep.
6. Repeat steps 1–3 in every other region you have resources in. If you run more than one account, skip ahead to the multi-account section and enable it once from a delegated administrator instead.
7. Build the alarm in the promise-kept section below, so that when the first High finding arrives it arrives in your inbox and not in a console tab you closed in June.

Sample findings: see what an attack looks like before you are in one

A freshly enabled GuardDuty is an empty page, and an empty page teaches nothing. AWS built a fix in: Settings → Sample findings → Generate sample findings drops one example of every active finding type into your list, each prefixed [SAMPLE] and carrying "sample": true in its JSON, so no downstream automation mistakes them for real. Open a few. Read the description, the resource section, the "action" block that shows the API call or connection that triggered it. Twenty minutes with the samples is worth more than any diagram of the service, and it is the only safe way to test the email alarm below before a real finding tests it for you.

If you want one specific type rather than two hundred — to test a rule that fires only on High, say — the CLI does it:

aws guardduty list-detectors
aws guardduty create-sample-findings \
  --detector-id 12abc34d567e8fa901bc2d34e56789f0 \
  --finding-types UnauthorizedAccess:IAMUser/MaliciousIPCaller

Sample findings expire with the rest after 90 days and can be archived immediately once you have seen them. AWS also publishes a tester script that simulates real activity (a crypto-mining DNS lookup, a port scan) in a dedicated throwaway account; that is a good weekend project once the basics are in, and a bad idea in the account your customers live in.

Is GuardDuty free? The 30-day trial and the honest price list

GuardDuty is not free, and unlike most of this series it has no permanent free tier for its core. What it has is the most honest trial in AWS: 30 days, every protection plan included except the two malware-scanning plans that carry their own free allowances, and a Usage page that shows you the exact projected bill the whole time. Enable a new protection plan later and that plan gets its own fresh 30 days. Nothing is charged until the trial ends, and you can disable the service, or any single plan, in one click on the last day. Here is the price list you will be reading on that day (US East N. Virginia, August 2026 — other regions are a little higher):

How much does GuardDuty cost for a small account? A worked example

Take the account from the first-real-project post — a Lambda function, an API Gateway, a DynamoDB table, one S3 bucket, and, let us say, one t3.small web server added since. In a month it might generate 300,000 CloudTrail management events (mostly from the console, the CLI, and AWS services talking to each other), 3 GB of flow-log and DNS metadata from the server, and a few million S3 data events if the bucket serves a website. The arithmetic: 0.3 million × $4 = $1.20; 3 GB × $1 = $3.00; 3 million S3 events × $0.80 = $2.40. Call it $6.60 a month, with Malware Protection for EC2 adding nothing until a finding triggers a scan and Lambda Protection adding cents. Delete the server and it drops to about $3. That is the realistic range for a solo builder: the price of one coffee a month for a guard who never sleeps. The number the Usage page shows you during the trial will be your own version of this sum, and it is the one to trust.

Where the bill goes wrong, and it is the same two places every time: flow-log volume on servers that move a lot of traffic (a busy NAT gateway or a media server can push tens of GB of metadata) and Runtime Monitoring switched on across a large fleet without noticing the per-vCPU rate. Both show up on the Usage page within a day. Neither is a surprise if you look.

The protection plans: which to keep, which to switch off on day 31

GuardDuty in 2026 is really one foundational service plus a menu of add-ons AWS calls protection plans, each watching one more kind of resource. The trial turns most of them on. The end of the trial is when you decide, and the honest rule is simple: keep a plan if you have the resource it protects; switch it off if you do not. A plan watching a resource you do not own costs nothing but also does nothing, and a shorter list is a list you will actually read.

The $0 "email me when it’s serious" alarm, step by step — promise kept

A guard who writes findings into a console you never open is a guard talking to an empty room. Every GuardDuty finding is also published, within about five minutes, as an event on Amazon EventBridge — the same free event bus the CloudTrail post used for the root sign-in alarm. One rule and one SNS topic turn High and Critical findings into an email, and the whole thing lives inside the permanent free allowances: EventBridge rules for AWS service events are free, and SNS gives you 1,000 emails a month at no charge. Unlike the root alarm, this rule goes in each region where GuardDuty is enabled, because findings are regional. Here it is.

1. Open SNS in the same region as GuardDuty. Topics → Create topic → Standard, name it guardduty-serious, create. Then Create subscription: protocol Email, endpoint your address. Go to your inbox and click Confirm subscription — until you do, nothing is delivered.
2. Open EventBridge → Rules → Create rule. Name it guardduty-high-critical, event bus default, rule type Rule with an event pattern. Next.
3. Under Event pattern, choose Custom pattern (JSON editor) and paste the pattern below. It matches every GuardDuty finding scored 7.0 or higher — High and Critical — and nothing quieter, so a port scan will never wake you.
4. Next. Target types: AWS service → SNS topic, choose guardduty-serious.
5. Expand Additional settings → Configure target input → Input transformer. In Input path paste the first block below; in Template paste the second. This turns a two-kilobyte JSON email into four readable lines with a link straight to the finding.
6. Next, Next, Create rule.
7. Test it before you trust it: GuardDuty → Settings → Generate sample findings, or the CLI command from the sample section with a High type such as UnauthorizedAccess:IAMUser/MaliciousIPCaller. Within five minutes the email arrives. If it does not, the usual reason is step 1’s unconfirmed subscription, and the second-usual reason is a rule created in a different region from the detector.

Event pattern (the numeric filter is the modern form; the AWS docs also show an older version that lists every score from 4.0 to 10.0 by hand, which works but is painful to read):

{
  "source": ["aws.guardduty"],
  "detail-type": ["GuardDuty Finding"],
  "detail": {
    "severity": [{ "numeric": [">=", 7] }]
  }
}

Input path:

{
  "severity": "$.detail.severity",
  "type": "$.detail.type",
  "region": "$.region",
  "description": "$.detail.description",
  "id": "$.detail.id"
}

Template:

"GuardDuty severity <severity>: <type> in <region>"
"<description>"
"Open: https://console.aws.amazon.com/guardduty/home?region=<region>#/findings?search=id%3D<id>"

Change 7 to 4 if you would rather hear about Medium findings too. Jake runs at 4 and gets perhaps two emails a month; at 7 he would have received exactly one in the last quarter, and it was the one that mattered.

Extended Threat Detection: when several small findings are one big one

The most important change to GuardDuty in years arrived quietly and costs nothing. Older GuardDuty raised findings one at a time: a Low here (unusual ListBuckets), a Medium there (a new user created), a High an hour later (objects downloaded from an unfamiliar IP). Each was defensible; none was alarming on its own; together they were a textbook credential-theft-to-exfiltration attack, and the person reading them had to be the one to notice. Extended Threat Detection does that noticing. It correlates findings across data sources, resource types, and time, and when the sequence matches a known attack shape it emits a single AttackSequence finding at Critical severity — the only way to get a Critical in GuardDuty — with the full story attached: every signal, every resource, every indicator, mapped to the MITRE ATT&CK tactics it saw.

There are five sequences at the time of writing: compromised IAM credentials, compromised S3 data, a compromised EKS cluster, a compromised ECS cluster, and a compromised EC2 instance group. The IAM one works from foundational data alone. The S3 one needs S3 Protection on, which is the practical reason to keep that plan even on a tiny account. Extended Threat Detection is enabled automatically, cannot be turned off separately, and is the reason the alarm above filters at 7 rather than 9: Critical is rare and unmistakable, but High is where the individual signals live.

Suppression rules: making GuardDuty quiet without making it blind

Every detection system has a noise problem, and the way people usually solve it — by ignoring the console — is the way they end up with a High finding nobody read for three weeks. GuardDuty’s answer is the suppression rule: a saved filter that automatically archives new findings matching it. Archived findings are still generated and still stored for 90 days (you can see them under the Archived filter), but they are not sent to EventBridge, Security Hub, S3 export, or Detective, so they never reach your inbox. Two rules of thumb from AWS, both worth keeping: build suppression rules reactively, only for findings you have seen repeat and confirmed harmless; and keep them narrow — a type plus a specific instance or IP — because a broad rule also hides the signals Extended Threat Detection needs to spot a sequence. Here is Jake’s first one, the Kali finding, built the narrow way.

1. In the GuardDuty console open Findings. In the filter bar add Finding type equals PenTest:IAMUser/KaliLinux.
2. Add a second criterion so the rule only covers you: API caller IPv4 address equals your home or office IP (or the CIDR your ISP gives you). Findings of the same type from any other address stay live — which is the point.
3. Click Save / Suppress findings, name the rule my-kali-laptop, add a one-line description your future self will thank you for, and save.

The other suppression rules AWS itself recommends follow the same shape: UnauthorizedAccess:EC2/SSHBruteForce limited to a bastion host by tag; Recon:EC2/PortProbeUnprotectedPort limited to the one web server that is meant to be reachable; Recon:EC2/Portscan limited to the AMI of your own vulnerability scanner. Type plus identity. Never type alone.

Keeping findings past 90 days: S3 export and Security Hub

GuardDuty forgets a finding 90 days after its last update. For a hobby account that is fine. For anything with a compliance obligation, or simply a year-end "what happened this year" question, you want the findings somewhere permanent, and there are two built-in roads. The first is export to S3: under Settings → Findings export options you name a bucket and a KMS key (GuardDuty insists on encrypting the export — you attach a short policy to the key and to the bucket, both given in the console), and from then on every new active finding lands in the bucket as gzipped JSON lines within about five minutes, under AWSLogs/<account>/GuardDuty/<region>/. Storage cost is S3’s, and a year of findings for a small account is a few megabytes. Suppressed findings are not exported, which is one more reason to keep suppression rules narrow.

The second road is AWS Security Hub, which pulls GuardDuty findings (and Inspector’s, and Macie’s, and dozens of third-party tools’) into one normalized list with its own retention and its own compliance scoring. Security Hub has a cost of its own and a lot of surface a solo builder will never use; the honest ordering is GuardDuty alone first, S3 export when you need history, Security Hub when you have more than one security tool to reconcile.

GuardDuty vs Inspector vs Security Hub vs Macie vs Shield vs WAF vs CloudTrail

The single most-searched question about GuardDuty is "GuardDuty vs Inspector," and the reason is that AWS names its security services after nouns rather than verbs. Ethan’s building fixes it: each of these is a different person in the same building, doing a different job. Once you know the job, you know which one you are missing.

So GuardDuty vs Inspector is not a choice; it is before-and-during. Inspector tells you the lock on the back door is a 2019 model with a known bypass. GuardDuty tells you someone just walked through it. A small account with one server gets more from GuardDuty first, because a compromised key does not need a vulnerability to be used; a fleet of servers running old packages gets more from Inspector first. Both is the grown-up answer, and Inspector is the next promise this series will keep.

What GuardDuty does not do

It does not block anything; remediation is yours, or a Lambda function you wire to EventBridge (isolate the instance, disable the key) once you trust the finding. It does not read packet contents — an attack that lives entirely inside legitimate-looking HTTPS to a reputable host is invisible to it, which is what WAF and Runtime Monitoring are for. It does not scan for vulnerabilities; that is Inspector. It does not see inside a server unless you install the Runtime Monitoring agent; foundational GuardDuty knows a server talked to a mining pool, not which process did it. It does not work retroactively — enabling it today tells you nothing about last month, though CloudTrail Event history still does. It keeps findings for 90 days only. And it is not a compliance certificate: it is PCI DSS validated as a service, which helps your audit, but running it does not make your account compliant with anything. What it does is read three logs you would never read yourself and tell you, usually within minutes, when something in them is wrong. That is more than most companies had ten years ago at any price.

More than one account: the delegated administrator

If you have followed the billing post’s advice and split work into a few accounts under AWS Organizations, do not enable GuardDuty in each one by hand. From the management account, designate one account — ideally a dedicated security account — as the delegated GuardDuty administrator. That account can then enable GuardDuty, and every protection plan, across all current and future member accounts in one action (there is an auto-enable for new accounts switch), sees every member’s findings in one console, owns the suppression rules for everyone, and can build the email alarm once with a rule that fires on findings from any member. The member accounts still see their own findings; they just cannot switch the guard off. That last property is the whole point: the account an attacker compromises should not be able to blind the account watching it.

If you’re here for the certification

GuardDuty is a reliable exam guest from Cloud Practitioner up through Security Specialty, and the questions are almost always the "which service" kind from the versus table. The lines to have cold: GuardDuty is threat detection from CloudTrail, VPC flow logs, and DNS logs, using threat intelligence and machine learning; it does not block; Inspector is vulnerability assessment; Macie is sensitive data discovery in S3; Security Hub aggregates; Detective investigates; findings go to EventBridge for automation and are kept 90 days; multi-account uses a delegated administrator through Organizations; and the trial is 30 days. A question that mentions cryptocurrency mining, compromised credentials, Tor, or "unusual API activity" is pointing at GuardDuty. One that mentions CVEs or "software vulnerabilities" is pointing at Inspector. One that mentions "personally identifiable information in S3" is Macie. The 2026 certification changes post has the current exam map.

FAQ — Amazon GuardDuty, answered straight

What is Amazon GuardDuty in one sentence?

A managed threat detection service that continuously reads your CloudTrail events, VPC flow logs, and DNS logs (plus optional sources), compares them against threat intelligence and learned normal behavior, and raises severity-ranked findings when something looks malicious — without blocking anything.

What is AWS GuardDuty used for?

Catching compromised credentials, crypto-mining on your servers, malware, data exfiltration, reconnaissance, and multi-step attacks across an AWS account, and telling you about them in minutes rather than on the next bill.

Is AWS GuardDuty free?

No permanent free tier for the core service, but a real 30-day free trial with every protection plan on and a Usage page that shows your projected bill throughout. Malware Protection for S3 has a permanent free tier of 1,000 requests and 1 GB a month. Extended Threat Detection is free.

How much does GuardDuty cost?

Per volume analyzed: $4 per million CloudTrail management events, $1 per GB of flow and DNS logs (falling to $0.25 at scale), $0.80 per million S3 events, $1.50 per vCPU for Runtime Monitoring, and small per-GB or per-vCPU rates for the other plans (US East, August 2026). A solo project typically lands at $2–10 a month.

Is GuardDuty an IDS?

Functionally yes: it detects intrusions and alerts without blocking. Unlike a network IDS it reads flow metadata, DNS, and API logs rather than packet contents, so it catches cloud-native attacks (stolen keys, mining, C2 beacons) that a packet inspector would miss, and misses in-request payload attacks that WAF is built for.

Is GuardDuty a firewall?

No. It never blocks traffic. Security groups, network ACLs, Network Firewall, and WAF block; GuardDuty detects and reports. Use both.

Is GuardDuty a SIEM?

No. It keeps no queryable raw logs, retains findings 90 days, and has no case management. It is a primary source for a SIEM; Security Hub and Detective are AWS’s own aggregation and investigation layers on top.

How does GuardDuty work without me enabling VPC Flow Logs or CloudTrail data events?

It receives its own independent copies of flow-log, DNS, and CloudTrail data from AWS’s infrastructure. You do not enable, store, or pay for those logs elsewhere; GuardDuty analyzes them and hands you only findings, not the raw stream.

What is the difference between GuardDuty and Amazon Inspector?

Inspector finds vulnerabilities before an attack (CVEs in packages, exposed ports, risky Lambda code). GuardDuty detects an attack in progress from logs. Inspector is the inspector checking locks; GuardDuty is the guard watching who walks through them.

What is the difference between GuardDuty and Security Hub?

GuardDuty produces threat findings. Security Hub collects findings from GuardDuty, Inspector, Macie, and third-party tools across accounts, normalizes them, and runs compliance checks against standards like CIS. GuardDuty first; Security Hub when you have several sources to reconcile.

What is the difference between GuardDuty and CloudTrail?

CloudTrail writes the record of every API call; GuardDuty reads that record (and two others) and judges it. CloudTrail alone tells you a key listed your buckets from an IP; GuardDuty tells you that IP is on a threat list and the key has never been used from there before.

What are GuardDuty findings and how long are they kept?

JSON documents describing a detected threat: type, severity 1–10, affected resource, the action seen, and remediation guidance. Kept 90 days after last update; export to S3 or Security Hub to keep them longer.

How do I get email alerts from GuardDuty?

An EventBridge rule matching aws.guardduty findings with severity 7 or above, targeting an SNS topic with your email subscribed, and an input transformer for a readable message. Free within the standing EventBridge and SNS allowances; steps are in the post.

Why does GuardDuty flag Kali Linux?

The PenTest:IAMUser/KaliLinux finding (Medium) fires when API calls come from a machine whose user agent identifies Kali, Parrot, or Pentoo — distributions built for penetration testing. If that machine is yours, create a narrow suppression rule for the finding type plus your IP address.

How do I generate sample findings in GuardDuty?

Console: Settings → Sample findings → Generate sample findings (one of every type, prefixed [SAMPLE]). CLI: aws guardduty create-sample-findings --detector-id ID --finding-types TYPE for a single chosen type. Sample findings carry "sample": true.

What is a GuardDuty suppression rule?

A saved filter that auto-archives matching new findings so they never reach EventBridge, Security Hub, or S3 export, while staying viewable under Archived for 90 days. Build them reactively and narrowly — finding type plus a specific resource, tag, or IP.

What is GuardDuty Malware Protection for S3?

A plan that scans newly uploaded objects in a chosen bucket for malware and tags or reports them. It works without the rest of GuardDuty enabled, has a free tier of 1,000 requests and 1 GB a month, and is meant for buckets that accept uploads from the public.

What is GuardDuty Runtime Monitoring?

An optional agent-based plan that watches processes, files, and network activity inside EC2 instances, ECS tasks, and EKS pods, catching reverse shells, crypto-miners, container escapes, and fileless execution. $1.50 per vCPU per month; off by default.

Is GuardDuty regional or global?

Regional. Enable it in every region you use (and ideally in unused ones, where it costs almost nothing), or enable it once across all accounts and regions through a delegated administrator in AWS Organizations.

What is the GuardDuty equivalent in Azure and Google Cloud?

Microsoft Defender for Cloud (its threat-detection plans) in Azure and Security Command Center’s Event Threat Detection in Google Cloud play the same log-reading, finding-raising role. All three sit on top of the platform’s audit log the way GuardDuty sits on CloudTrail.

Where to go next

Revision note. Written August 29, 2026, with every price read off AWS’s GuardDuty pricing page the same day and stamped "as of August 2026" where it appears — the protection-plan menu is the part of this service AWS extends most often (AI Protection and Malware Protection for Backup are both recent), so if a plan or a rate has moved by the time you read this, tell us through the contact page and we will bring the page back to true. This post keeps the promise the CloudTrail post made: the guard who reads the log is above, and the $0 "email me when it’s serious" alarm is real, seven steps, tested with a sample finding. The next promise follows from the most-asked question on this page: Amazon Inspector in plain English — the inspector who checks the locks before anyone tries them. And if you arrived here the way Jake did, staring at a finding with a name you have never seen: read the first word, check the severity, and look at the resource. If it is Low, breathe. If it is High, rotate the key first and understand it second. The guard has done the hard part — it noticed. The rest is a checklist, and you are already on it.