Send GuardDuty Findings to Slack or Teams with Amazon Q Developer

Why bring GuardDuty findings into chat

Amazon GuardDuty detects threats such as compromised credentials, cryptomining and communication with known malicious hosts. Its findings sit in the GuardDuty console until someone looks. For most teams, the place where someone is always looking is a chat channel. Sending the findings that matter into Slack or Microsoft Teams shortens the time between detection and the first person picking up the incident, and gives the responders a shared thread to work in.

The AWS service that does this was called AWS Chatbot. On February 19, 2025, AWS renamed it to Amazon Q Developer in chat applications. Existing configurations, APIs, IAM permissions and the console URL did not change, and the CloudFormation resource types still use the AWS::Chatbot prefix. In chat, the app now appears as Amazon Q, and you mention it with @Amazon Q instead of @aws.

A note on clients: the service supports Slack and Microsoft Teams. Older guides also mention Amazon Chime, but AWS ended support for Amazon Chime on February 20, 2026, so plan for Slack or Teams.

How the pieces fit

The flow has four parts, and each one has a single job:

1. GuardDuty publishes every finding to Amazon EventBridge as an event with source aws.guardduty and detail type GuardDuty Finding.
2. An EventBridge rule matches the findings you care about, for example only High and Critical severity.
3. An Amazon SNS topic is the rule’s target. Amazon Q Developer in chat applications receives notifications only through SNS topics.
4. Amazon Q Developer in chat applications is subscribed to the topic and posts a formatted message to your channel.

GuardDuty sends a new finding to EventBridge in near real time. Repeat occurrences of the same finding are aggregated and sent every 6 hours by default; the GuardDuty administrator account can change that to 15 minutes or 1 hour. In a multi-account organization, build this in the delegated GuardDuty administrator account, which receives events for all member accounts in that Region.

GuardDuty is a Regional service, so you need the rule and topic in every Region where GuardDuty is enabled, or a way to forward events to one Region.

Step 1: Create the SNS topic

Create a standard SNS topic in the same Region as GuardDuty, for example guardduty-alerts. EventBridge must be allowed to publish to it, so the topic’s access policy needs to grant sns:Publish to the events.amazonaws.com service principal. If you encrypt the topic with an AWS KMS customer managed key, the key policy must also allow EventBridge to use the key.

Step 2: Create the EventBridge rule

A rule that sends every GuardDuty finding is noisy. Most teams start with High and Critical findings (severity 7.0 and above) in chat and leave the rest for daily review. EventBridge numeric matching keeps the pattern short:

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

Create the rule on the default event bus with this pattern and choose the SNS topic as the target. From the AWS CLI:

aws events put-rule \
    --name guardduty-high-to-chat \
    --event-pattern file://pattern.json

aws events put-targets \
    --rule guardduty-high-to-chat \
    --targets Id=1,Arn=arn:aws:sns:us-east-1:111122223333:guardduty-alerts

Leave the target input unchanged. Amazon Q Developer in chat applications recognizes GuardDuty events and formats them itself. If you rewrite the event with an input transformer, the message has to follow the service’s custom notification schema instead.

Step 3: Connect Slack or Microsoft Teams

For Slack, the setup tutorial runs like this:

1. A Slack workspace admin approves the Amazon Q Developer app for the workspace.
2. In the Amazon Q Developer in chat applications console (at console.aws.amazon.com/chatbot/), you configure Slack as a chat client and authorize the workspace.
3. In the Slack channel, invite the app with /invite @Amazon Q. Private channels are supported; you paste the channel ID into the console.
4. In the console, configure a new channel: give it a name, pick the channel, choose a role setting and channel guardrail policies, and add the SNS topic from Step 1 under notifications.
5. Use Send test message to confirm the channel receives messages.

Microsoft Teams follows the same pattern: with the app approved by your Teams administrator, you add Amazon Q Developer to the team, configure Microsoft Teams as a client in the console using the channel URL, then set the role, guardrails and SNS topic for the channel. Teams private channels are not supported. You can also define channel configurations as code with AWS CloudFormation (AWS::Chatbot::SlackChannelConfiguration and AWS::Chatbot::MicrosoftTeamsChannelConfiguration).

To test end to end, generate sample findings from the GuardDuty settings page, or a single type with aws guardduty create-sample-findings. AWS documents sample findings as a way to test EventBridge rules; their titles start with [SAMPLE] and their JSON includes "sample": true, so responders can tell them apart.

Step 4: Decide what people can do from the channel

Amazon Q Developer in chat applications can also run AWS CLI commands from Slack and Teams. That is useful during an incident, for example to look up an instance, check an IAM user’s recent keys or run an AWS Systems Manager Automation runbook. It is also a real access path into your accounts, so set it up deliberately:

• Role setting. A channel role gives every member the same IAM permissions. User roles make each person choose their own role, which suits mixed teams.
• Channel guardrails. Guardrail policies cap what anyone in the channel can do, whatever their role allows. For a security alerts channel, start with read-only guardrails.
• Custom actions. You can add buttons to notifications that run a Lambda function or a CLI command you define, such as “get finding details” or “tag instance for isolation”. Keep destructive actions behind a human decision.
• Logging. Turn on CloudWatch Logs for the channel configuration so there is a record of what ran.

Practical tips for incident response

• Route by severity and account. Send Critical and High findings from production accounts to an on-call channel, and everything else to a lower-priority channel or a daily digest.
• Tune before you scale. Use GuardDuty suppression rules for activity you have confirmed as expected, such as a vulnerability scanner. Suppressed findings are archived automatically and are not sent to EventBridge, so they never reach chat.
• Keep a written runbook for the common finding types, linked from the channel topic, so the first responder knows the next step.
• Do not rely on chat alone. Chat is for awareness and coordination. Keep findings flowing to AWS Security Hub CSPM, your SIEM or a ticketing system as the record of what happened and who closed it.

Getting help

9Acts is an AWS Advanced Tier Services Partner and AWS MSP Partner with the AWS Level 1 MSSP Competency. If you want help wiring GuardDuty into your incident response process, see our security and compliance services.