Honeytokens vs GuardDuty: What Each Catches, and Why You Want Both

The short version

GuardDuty watches real activity: CloudTrail, VPC flow logs, DNS and more, with threat intelligence and machine-learning anomaly detection. Turn it on.
It has no finding for "this long-term access key was used from somewhere new". Its credential findings are anomaly-based or threat-intelligence-based, and anomaly findings fade as the activity continues.
A honeytoken has no legitimate use, so any use is a signal. It also tells you where it was taken from, because you planted it there.
Automate on honeytoken trips and on GuardDuty's narrow, high-severity findings. Send anomaly findings to a person.
Cost: GuardDuty bills by analysed events and log volume, after a 30-day trial. A self-hosted honeytoken costs almost nothing to run.

1. The difference in one sentence

GuardDuty detects suspicious use of things you really use. A honeytoken detects any use of a thing nobody should use. Everything else on this page follows from that. GuardDuty has to decide what "suspicious" means, against a baseline of your real activity, and it covers your whole account. A honeytoken needs no baseline, because its normal is zero, but it only covers the places you put it.

A honeytoken is a decoy piece of data: here, a real AWS access key belonging to an IAM user that is denied every action. You plant it where an attacker looks for credentials, such as a CI variable, a .env file or a container's environment. The AWS canary credentials guide shows how to build one in Terraform.

2. What GuardDuty detects about credentials

GuardDuty analyses CloudTrail management events, VPC flow logs, DNS logs and, with optional protection plans, more sources, and combines threat intelligence with machine-learning anomaly detection. For credentials specifically, the relevant IAM finding types fall into three groups:

Resource credentials used elsewhere. UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS fires when credentials created for an EC2 instance through its launch role are used from an external IP address; .InsideAWS when they're used from another AWS account. Similar ResourceCredentialExfiltration findings cover ECS task and Lambda credentials. These are narrow and high severity by default.
Anomalous behaviour. The AnomalousBehavior family (for example CredentialAccess:IAMUser/AnomalousBehavior and Discovery:IAMUser/AnomalousBehavior) fires when an API is invoked in a way GuardDuty's model hasn't seen for that identity, including where the request came from.
Threat intelligence. CredentialAccess:IAMUser/CompromisedCredentials fires when Amazon's threat intelligence identifies an IAM access key as potentially compromised.

On top of individual findings, Extended Threat Detection correlates signals across data sources, resource types and time to flag multi-stage attacks. AWS enables it by default with GuardDuty, at no extra cost.

Findings reach EventBridge in near real time once generated; repeat occurrences are aggregated into one event every 6 hours by default (15 minutes or 1 hour are the other options). Pricing is per million CloudTrail management events analysed and per gigabyte of flow and DNS logs, with a 30-day free trial for accounts that have never enabled it.

If you run workloads in AWS and GuardDuty is off, turn it on before you plant a single honeytoken. It covers far more ground than any decoy can.

3. What GuardDuty can't tell you

GuardDuty's strength, judging real activity against what's normal, is also its limit.

There's no finding for "this long-term key was used from somewhere new". A stolen IAM user access key (the AKIA… kind) is covered only indirectly: by the anomaly findings if its use looks unusual, or by threat intelligence if the key is already known. An attacker who calls the APIs that key normally calls may not stand out.
Anomalies are judged against a learned baseline. AWS describes the anomaly findings as based on behaviour GuardDuty hasn't seen for that identity "within the training period", and says it doesn't look at activity from before it was enabled. AWS doesn't publish how long the training period is.
Continued activity becomes normal. For the instance-credential findings, AWS notes that if GuardDuty sees continued activity from a remote host, its model treats it as expected behaviour and stops generating the finding. That's sensible for reducing noise, and it's also how a slow, patient attacker blends in.
It doesn't know where a credential was taken from. A finding names the identity, not the CI runner, laptop or repository the attacker read it from. You still have to work that out.

None of this is a criticism of GuardDuty. Any detector that judges real activity has to trade sensitivity for noise. It's simply the gap a decoy fills.

4. What a honeytoken tells you that nothing else does

Intent, not a symptom. Nobody legitimate holds the key, so any use means someone found it, decided it was worth trying, and tried it. Your own tests and scanners are the only false positives, and you can list them.
The location of the leak. One key per place means the key ID tells you which place was read: that runner, that task definition, that repository. Whatever could read the honeytoken could read the real credentials next to it.
The attacker's first move. sts:GetCallerIdentity needs no permissions, can't be denied, and is logged by CloudTrail, so the usual "whoami" check is enough to trip it, as long as your EventBridge rule uses the ENABLED_WITH_ALL_CLOUDTRAIL_MANAGEMENT_EVENTS state.

What it doesn't give you is coverage. A honeytoken only reports on the places you planted it, and a careful attacker can sometimes recognise a decoy (see fingerprinting). Will GuardDuty itself flag the use of a honeytoken? Only if that use looks anomalous or matches threat intelligence. Alert on the decoy directly instead.

5. Base rates: why the trigger decides what you can automate

The practical difference shows up when you try to automate a response. An automated action runs every time its trigger fires, so it inherits the trigger's error rate.

Illustrative arithmetic, not data

If 1 anomaly finding in 100 turns out to be an attack, an automatic "isolate the workload" response is wrong 99 times for each time it's right. A honeytoken's legitimate use is zero by construction, so outside your own tests, every trip is real. That's the base-rate problem Stefan Axelsson described for intrusion detection in 2000.

This is why "automate on certainty" applies to some GuardDuty findings too. An instance credential used from outside AWS is narrow enough to be a reasonable candidate for revoking the role's sessions automatically. An anomaly finding usually isn't. What to automate in incident response turns this into a trigger-by-action matrix.

6. Side by side

	GuardDuty	Honeytoken (AWS key)
Question it answers	Is a real identity or resource behaving suspiciously?	Has anyone used a key nobody should hold?
Coverage	The whole account, every enabled region, many data sources	Only where you planted it
Baseline	Learned from your activity (anomaly findings)	None: normal use is zero
False positives	Some, by design, for anomaly findings	Your own tests and scanners
Tells you where it leaked from	No, it names the identity	Yes, one key per location
Speed	New findings to EventBridge in near real time once generated	Bound by CloudTrail delivery; AWS says about 5 minutes on average to S3 and Logs, not guaranteed
Cost	Per analysed event and log volume, after a 30-day trial	Near zero self-hosted; free or paid as a service
Setup	One switch per account (or organisation-wide)	An afternoon per pattern, then one key per location
Safe to automate on	Narrow, high-severity findings	Every trip, with an undoable action

7. Using them together

Turn GuardDuty on everywhere, organisation-wide if you use AWS Organizations, and route findings to the people who handle security.
Plant honeytokens where GuardDuty is blind to the source: CI variables, build logs, config repositories, container environments, developer laptops. These are the places a credential leaks from without any unusual AWS activity yet.
Alert on each honeytoken directly, not through GuardDuty: an EventBridge rule on the decoy user in every region, with a CloudTrail metric filter as a backstop.
Split the responses by certainty. Automate a contained, undoable response on honeytoken trips and on narrow findings like instance credentials used outside AWS. Send anomaly findings to a person, with the evidence gathered automatically.
Test both regularly. GuardDuty can generate sample findings; a honeytoken can be test-fired with a call you control. A detector that silently stopped working is worse than none.

8. Ways to get honeytokens, and where we fit

canarytokens.org (free, by Thinkst): an AWS API key token in about a minute; Thinkst runs the detection.
Thinkst Canary (paid): canaries and tokens across your estate, managed from one console.
Tracebit: canaries across cloud environments, with a free Community Edition for small teams.
Self-hosted, in your own account: the canary credentials guide, or our free terraform-aws-honeytoken module.

The full comparison covers how they differ on account ownership, fingerprinting and latency.

Disclosure: we make it. Compass, our open-source tool, suggests where to place honeytokens from a map of your AWS account, plants them as pull requests to your infrastructure repository, and responds when one is used (for example by deactivating the key or restarting the ECS task it was taken from) within a risk policy you set. Today the IAM key decoy is the one that works end to end.

9. FAQ

Do I need honeytokens if I already have GuardDuty?

Usually yes, because they catch different things. GuardDuty looks for suspicious behaviour by your real identities and resources. A honeytoken is a credential nobody legitimate holds, so any use of it means someone found it and tried it, and it points at the place you planted it. Keep GuardDuty on, and add honeytokens where an attacker would look for credentials.

Does GuardDuty detect stolen AWS access keys?

Partly. It has findings for EC2 instance and other resource credentials used from outside AWS or from another account, anomaly-based findings for unusual API calls by an IAM user, and a threat-intelligence finding for access keys identified as potentially compromised. It has no dedicated finding for a long-term access key simply being used from a new place, so a stolen key used in a way that looks normal may not produce a finding.

Will GuardDuty alert when a honeytoken is used?

Not reliably. GuardDuty doesn't know the key is a decoy, so it only produces a finding if the use looks anomalous or matches threat intelligence. Alert on the honeytoken directly instead, with an EventBridge rule or a CloudTrail metric filter that matches the decoy user.

How fast are GuardDuty findings compared with a honeytoken alert?

GuardDuty sends new findings to EventBridge in near real time once it has generated them, and aggregates repeats into one event every 6 hours by default (15 minutes or 1 hour are options). A honeytoken alert depends on CloudTrail delivery, which AWS says averages about 5 minutes to S3 and CloudWatch Logs, without a guarantee. Measure both in your own account.

Is GuardDuty Extended Threat Detection an extra cost?

No. AWS says Extended Threat Detection is enabled by default when you enable GuardDuty, at no additional cost. It correlates signals across data sources, resource types and time to detect multi-stage attacks.

Which should I automate a response on?

Automate on signals that are almost never wrong: a honeytoken being used, or a narrow, high-severity GuardDuty finding such as instance credentials used from outside AWS, and only with actions you can undo. Send anomaly-based findings to a person, with the evidence gathered automatically.

Written by Ilia Dubovskii, founder of Beamreach. GuardDuty finding types, pricing and delivery behaviour were checked against AWS documentation on 8 November 2026. AWS changes GuardDuty often; check the linked pages before relying on a detail.