An AWS honeypot is a decoy cloud resource that has no legitimate production use. Because normal workloads and operators should not access it, an interaction creates a high-confidence signal that deserves investigation. Honeypots do not prove that every control is working, and they do not prove who is behind an event. They add a focused detective layer for suspicious credential use, cloud reconnaissance, and access to resources made to look valuable.
ops0 packages that idea as deception as code. The Honeypot (deception) blueprint generates low-interaction AWS decoys, the CloudTrail and EventBridge detection path around them, and a notifier that turns a trip into an ops0 security incident. The result is a governed tripwire deployed through the same infrastructure-as-code workflow used for other cloud resources.
What Is the Difference Between a Honeypot, a Honeytoken, and a Decoy?
The terms overlap, but they describe different parts of a deception system.
Honeypot. A system or environment designed to attract and observe suspicious interaction. A traditional example is an isolated server that appears to run a valuable service.
Honeytoken. A fake credential, key, record, or identifier that should never be used legitimately. Any attempt to use it is a reason to investigate.
Decoy resource. A believable but non-production cloud object such as a private S3 bucket, an IAM identity with no useful permissions, or a secret containing dummy data.
AWS recommends private decoy resources as a complement to services such as GuardDuty, CloudTrail, Detective, Security Hub, and existing SIEM workflows. The decoys should contain no sensitive data, remain isolated from real assets, and generate alerts when accessed. AWS documents this pattern for private decoy resources.
Why Deception Produces a Cleaner Signal
Most cloud security controls operate across real infrastructure. A scanner finds configuration weaknesses. Anomaly detection compares current behavior with a baseline. A CSPM prioritizes posture findings. Each is useful, but each must separate legitimate activity from dangerous activity in systems people use every day.
A carefully placed decoy changes that equation. It has no business workflow, application dependency, or approved operator behind it. Access is unusual by design.
That does not make every trip definitive proof of compromise. An internal scanner, inventory process, administrator, or test can still touch a decoy. The accurate claim is that deception can provide a high-confidence, low-noise signal. AWS describes attempted access as suspicious activity that should be investigated, while OWASP describes deception as a way to produce high-fidelity alerts and detect reconnaissance. OWASP also notes that decoys require maintenance and careful placement.
What the ops0 Blueprint Deploys
The verified ops0 implementation currently focuses on three low-interaction AWS decoys.
A honeytoken IAM key. The blueprint creates a decoy IAM user with no attached policies and generates an access key for controlled placement. Because the identity has no useful permissions, using the key does not grant access to genuine resources. CloudTrail can still record the attempted API activity and expose the access key ID used in the event.
A private decoy S3 bucket. Public access is blocked. The bucket contains a dummy object named to resemble database credentials, but the content is explicitly fake. S3 object data events are enabled for the decoy so operations such as GetObject, ListBucket, and HeadObject can trigger detection.
A decoy secret. The blueprint creates an AWS Secrets Manager entry with dummy database details. GetSecretValue or DescribeSecret activity against the decoy is treated as suspicious inspection.
These resources are generated as Terraform or OpenTofu files and deployed through the normal ops0 project flow. They are not production data stores and should never contain genuine credentials, customer information, or secrets.
How a Honeypot Trip Becomes an Incident
The detection path has four stages.
- 1CloudTrail records the activity. The generated trail captures management events and the required S3 object data events.
- 2EventBridge matches the decoy. Rules identify use of the honeytoken access key, access to the decoy bucket, or inspection of the decoy secret.
- 3A notifier sends a normalized event. A generated Lambda function sends the trigger, AWS event name, observed principal or access key, source IP, resource, timestamp, and original event context to the ops0 ingest route.
- 4ops0 opens or updates an incident. The service verifies the project token, enriches public source IPs when location data is available, and upserts a
honeypot_tripincident at the configured P1 or P2 severity. A new incident flows through the existing incident alert path.
Each honeypot project receives a cryptographically random token. ops0 stores its SHA-256 hash and uses a constant-time comparison when a trip arrives. This authenticates the project reporting the event; it is not a claim that the underlying CloudTrail event identifies the human behind a stolen session.
What Responders Can See
The incident records the latest observed actor context: source IP, AWS principal or access key when present, event name, timestamp, resource, and available CloudTrail detail.
Public source IPs can be enriched with approximate country, region, city, network, and proxy or hosting indicators. These values describe the network origin observed by AWS, not necessarily the physical location of an attacker. VPNs, proxies, Tor, NAT, anycast, and cloud-hosted infrastructure can mask or distort location.
Across the organization, ops0 aggregates trips into a threat map showing observed origins, affected honeypot projects, event types, severity, first and last observation, and trip volume.
Responders can also request an IP threat score. When AbuseIPDB is configured, ops0 uses its reputation data and folds in proxy or hosting indicators. Without that provider, the product falls back to a local heuristic based on available network signals. The score is context for investigation, not proof that an IP belongs to a specific threat actor.
Testing the Workflow Honestly
The product includes a test-trip action that creates a simulated honeypot incident and exercises the ops0 incident and alert path. It is useful for confirming that the project is recognized as a honeypot and that responders can receive and inspect the incident.
The current test does not originate inside AWS and does not traverse CloudTrail, EventBridge, or the generated notifier Lambda. Teams that need full end-to-end assurance should separately perform an authorized test against a deployed decoy and confirm that the AWS event reaches ops0.
Where Honeypots Fit in Cloud Security
A honeypot is a detective control. It can surface suspicious activity early and give responders useful context, but it does not guarantee that an attacker will touch a decoy. It also does not replace preventive policy, least-privilege IAM, posture scanning, vulnerability management, logging, runtime detection, or incident response.
The strongest design uses layers:
- Prevent unsafe infrastructure changes with policy and review.
- Detect exposed resources, drift, vulnerable workloads, and excessive permissions.
- Monitor real activity through CloudTrail, GuardDuty, workload telemetry, and other detection systems.
- Place decoys where unauthorized discovery or credential use is likely to touch them.
- Route every high-confidence trip into an incident process somebody owns.
Deception is valuable because it gives the security program another kind of evidence. Posture tools explain what could be exploited. A well-placed honeypot can reveal that somebody or something has started exploring.
Current Boundaries
AWS first. The verified blueprint currently generates AWS IAM, S3, Secrets Manager, CloudTrail, EventBridge, and Lambda resources.
Deployment is required. Creating the project alone does not activate detection. The generated infrastructure must be successfully applied in a connected AWS account.
Delivery is part of the control. Detection depends on CloudTrail recording the relevant event, EventBridge matching it, the notifier running, and the notifier reaching the ops0 ingest URL.
Location and reputation are supporting evidence. They help prioritize investigation but should not be treated as attribution.
Canary decoys are the verified scope. The audited generator creates IAM, S3, and Secrets Manager decoys; this article does not claim an interactive SSH environment.
From Cloud Posture to an Investigable Signal
Cloud posture tells you whether controls and configurations meet expectations. Deception answers a narrower operational question: did anything interact with a resource that nobody should use?
With ops0, that control is generated as code, reviewed, deployed, observed, and connected to the incident pipeline. The important outcome is not that a fake bucket exists. It is that suspicious access becomes a structured event with enough context for a responder to investigate quickly.
To deploy one, open the IaC blueprint catalog in ops0, select Honeypot (deception), choose the AWS region and decoys, set the incident severity, review the generated infrastructure, and apply it through the normal governed deployment flow.
What is an AWS honeypot?
An AWS honeypot is a decoy identity, credential, resource, or environment with no legitimate production use. Access to it creates a high-confidence signal of suspicious activity that should be investigated.
Is a honeytoken the same as a honeypot?
A honeytoken is a fake credential, key, record, or identifier. A honeypot is the broader deception system or environment. Honeytokens can be one component of a honeypot strategy.
Does a honeypot prove that an AWS account was breached?
No. A trip proves that a decoy was accessed or a fake credential was attempted. It is a high-confidence reason to investigate, but responders must examine CloudTrail and surrounding evidence before concluding that an account was compromised.
Does an AWS honeypot replace GuardDuty or CSPM?
No. Honeypots complement GuardDuty, CloudTrail, CSPM, IAM controls, vulnerability management, and incident response. They provide a different signal based on interaction with resources that should remain untouched.
What decoys does the ops0 honeypot blueprint deploy?
The verified AWS blueprint can generate an IAM user and honeytoken access key with no attached policies, a private S3 bucket containing dummy data, and a Secrets Manager secret containing fake values.