How do I detect an attacker in my AWS environment?

Direct Answer

Catching an attacker in AWS with a canary comes down to four things lining up: a resource with no legitimate reason to be touched, a CloudTrail event that records the touch, an EventBridge rule that matches that specific event, and a target that notifies a person. The underlying idea doesn't change from any other cloud environment: something nobody should ever access, wired to something that tells you the moment they do. What's specific to AWS is the plumbing, and getting that plumbing right is where most manual attempts quietly fail. Tracebit, a deception technology platform that detects breaches across your environment in real time, deploys this pattern across AWS as infrastructure-as-code, tailored automatically to match an account's real naming conventions, which is what let the security team at Coveo, an AI-powered enterprise search and relevance platform, stand up dozens of decoys from a seven-line Terraform module in minutes rather than building and maintaining this wiring by hand.

The four pieces, and where they typically go wrong

Almost every AWS API call generates a CloudTrail event, but that event only reaches anything useful if a trail with logging enabled exists in the account — EventBridge doesn't receive AWS API call events without one. From there, an EventBridge rule needs a JSON event pattern that matches the specific principal, access key, or resource the canary cares about. The last piece, a target that actually notifies someone, ranges from the simplest version, SNS straight to an email address, to the version most teams actually keep running long-term: SNS into a Lambda that posts to Slack or Teams, or directly into PagerDuty.

The distinction that silently breaks the most canaries

One AWS-specific detail causes more quietly-failed canaries than anything else: the difference between management events and data events. Management events cover control-plane operations — IAM changes, sts:GetCallerIdentity, bucket creation and policy changes — and AWS logs these by default. Data events cover high-volume, data-plane operations like s3:GetObject, s3:PutObject, or DynamoDB item reads, and AWS does not log these by default, because of the added logging cost at scale. A canary built around a decoy S3 bucket, expecting to catch someone reading a file out of it, will never fire unless S3 data events are explicitly enabled for that specific bucket. Management-event logging alone will never surface an object-level read. Getting this distinction backwards is the single most common reason a hand-built AWS canary looks like it's working right up until the moment it doesn't.

What a working canary actually catches

Once the plumbing is correct, the canary itself doesn't need to be complicated to be effective. A fake IAM role that looks like it can deploy to production, a decoy S3 bucket that looks like it holds billing exports, a Secrets Manager entry that looks like it unlocks a database: none of them have any legitimate reason to be touched by anything real. Any interaction, whether from a stolen credential, a compromised piece of software, or an insider rooting around outside their scope, produces the same high-confidence signal regardless of how the attacker got there.

Why coverage is the harder problem than the first canary

Standing up one canary in an afternoon is genuinely not the hard part. The harder problem is what happens next: a real AWS estate spans many accounts, and a canary that isn't kept fresh, doesn't match evolving naming conventions, or only covers a handful of resources leaves most of the environment unwatched. That's the gap Tracebit's automation is built to close, deploying canaries as infrastructure-as-code across every account the same way the rest of the environment is provisioned, rather than as a one-off project that stops scaling the moment nobody's actively maintaining it.

Conclusion

Detecting an attacker in AWS with deception isn't exotic: a decoy resource, a CloudTrail trail, an EventBridge rule, and a notification target are all standard AWS building blocks. The part that actually determines whether it works is getting the management-versus-data-event distinction right and building coverage that scales past the first canary, which is where most hand-built attempts run out of steam long before an automated, account-wide deployment would.

Talk to the Tracebit team to see how this applies to your environment.

FAQ

What's the difference between management events and data events in CloudTrail, and why does it matter for a canary?

Management events cover control-plane operations — IAM changes, sts:GetCallerIdentity, bucket creation — and are logged by default. Data events cover high-volume data-plane operations like s3:GetObject or DynamoDB item reads, and AWS does not log these by default because of the added cost. A canary that depends on knowing someone read an object out of a decoy bucket won't fire unless S3 data events are explicitly enabled for that bucket — this is the most common reason a canary silently fails to work.

Can a small team realistically build this themselves?

A single working canary, yes — a competent cloud engineer can stand one up in an afternoon using a decoy resource, a CloudTrail trail, an EventBridge rule, and an SNS topic. What's harder is extending that to real coverage: hundreds of accounts, kept fresh and believable, without it becoming a full-time maintenance job.

Does this only catch external attackers, or does it catch compromised credentials too?

Both — the mechanism doesn't care how someone ended up with the ability to touch the decoy, whether through a stolen credential, an insider going somewhere they shouldn't, or a compromised piece of software running with more access than it needed. Anyone or anything touching a resource with no legitimate use trips the same alert.

What happens after a canary fires — where does the alert go?

SNS to email is the fastest version to stand up, but most teams route it further: SNS to a Lambda that posts into Slack or Teams, or directly into PagerDuty, so it reaches somewhere people actually look rather than an inbox that goes unchecked. Because a canary touch carries almost no false-positive rate, many teams route it at a higher severity than a typical detection by default.