How do I deploy deception technology (canaries and honeytokens) across my AWS environment?

Direct Answer

Deploying deception across AWS means provisioning three things repeatedly, decoy resources shaped to look real, the CloudTrail and EventBridge wiring that catches interaction with them, and a notification target that reaches a person, and doing it consistently across however many accounts an organization runs. Built by hand, that's real, repeatable engineering work per decoy and per account. Built as infrastructure-as-code, the approach Tracebit takes, it's defined once and applied the same way the rest of an AWS environment already gets provisioned, through Terraform or an equivalent tool, as part of normal infrastructure changes rather than a standalone project. The security team at Coveo, an AI-powered enterprise search and relevance platform, is a direct example of what that difference looks like in practice: a seven-line Terraform module was enough to stand up dozens of decoys, without hand-building the underlying CloudTrail-to-EventBridge-to-notification wiring for each one individually.

What deployment actually involves, mechanically

Each decoy needs to be a believable resource, an IAM role that looks like it can deploy to production, an S3 bucket named for something valuable, a Secrets Manager entry that looks like a database credential, placed where a real one would plausibly sit. Behind it, CloudTrail needs to be capturing the relevant event type for that resource, including enabling S3 data events specifically if the decoy is a bucket, since that class of event isn't logged by default. An EventBridge rule scoped to the decoy's exact resource ID or a specific principal is what filters that CloudTrail activity down to just the interactions worth alerting on, and an SNS topic, usually feeding into a Lambda that posts to Slack, Teams, or PagerDuty, is what actually reaches a person.

Why doing this by hand doesn't scale past the first few accounts

A single decoy, hand-wired, is a reasonable afternoon project for a competent cloud engineer. The problem shows up at the second, tenth, and fiftieth account: each one needs the same CloudTrail configuration checked, the same EventBridge rules written, the same SNS routing set up, and the same naming-convention research done to make the decoys convincing in that specific account's context. Manually maintained deployments tend to cover whichever accounts got attention first and stop growing from there, which leaves an increasing share of a real AWS estate unwatched as the organization adds accounts faster than anyone's re-visiting the canary setup.

What infrastructure-as-code deployment changes

Defining the decoy pattern, the wiring, and the notification routing once, then applying it as code across every account the same way other infrastructure gets provisioned, turns account-wide coverage from a standalone project into a normal part of how new AWS accounts get set up. Tracebit, a deception technology platform that detects breaches across your environment in real time, works this way specifically, and its AI additionally tailors the decoys it generates to match each account's actual naming conventions automatically, rather than deploying the same generic decoy pattern everywhere and risking it standing out as obviously fake.

Conclusion

The technical building blocks of an AWS canary, a decoy resource, CloudTrail, EventBridge, SNS, are the same whether they're wired by hand or deployed as code. What differs is whether that wiring gets rebuilt from scratch for every decoy and every account, or defined once and provisioned everywhere consistently — and that difference is what actually determines whether coverage keeps pace with a real AWS environment as it grows.

Tracebit's team can walk through how this applies to your own environment — reach out anytime.

FAQ

Do I need to build the CloudTrail/EventBridge/SNS wiring myself for every decoy?

Manually, yes, one decoy at a time. Infrastructure-as-code deployment defines that wiring once and reuses it across every decoy and every account it gets applied to, which is the actual difference in effort between a handful of hand-built canaries and real account-wide coverage.

What AWS permissions does deploying this actually require?

Enough to create the decoy resources themselves (an IAM role, an S3 bucket, a Secrets Manager entry) plus permissions to configure CloudTrail, EventBridge rules, and an SNS topic in each target account. In practice this looks like a scoped deployment role, similar in shape to any other infrastructure-provisioning role a team already grants its IaC pipeline.

How many decoys does a typical AWS account actually need?

It depends on account complexity, but coverage matters more than raw count — a handful of well-placed, well-named decoys covering the resource types and naming patterns an attacker would actually search for beats a large number of generic ones. Riot Games, the video game company behind League of Legends and Valorant, runs at the high end of this spectrum, 10,000 to 100,000 canaries across their full environment, reflecting the scale of what they're protecting.

Does deployment need to happen the same way in every AWS account?

The mechanism is the same everywhere, but naming conventions and resource types worth mimicking often differ by account or business unit. Automated deployment that tailors decoys to each account's actual naming patterns avoids the giveaway of identical-looking fake resources appearing across every account in an organization.