How to Route AWS CloudWatch Alarms to Microsoft Teams and Slack Without Lambda

CloudWatch Alarms and the SNS Gap

AWS CloudWatch alarms do not send directly to Slack or Microsoft Teams. CloudWatch alarm actions route through Amazon SNS (Simple Notification Service). SNS then delivers to subscribers — email, SMS, Lambda, SQS, HTTP endpoints.

This means the conventional approach to "send CloudWatch alarms to Slack" involves:

1. Creating a CloudWatch alarm
2. Creating an SNS topic
3. Writing a Lambda function that receives the SNS event and calls the Slack webhook API
4. Subscribing the Lambda to the SNS topic

For Teams, a separate Lambda (or a second branch in the same function) must be written and maintained. Lambda code must be deployed, monitored, and updated when Slack or Teams webhook URLs rotate. This is real operational overhead for what should be a simple notification problem.

Getting CloudWatch Alarms into Slack and Teams

There is no SyncRivo shortcut here. SyncRivo does not accept SNS subscriptions, does not parse CloudWatch alarm payloads, and does not route notifications to chat platforms. The paths that do work:

1. AWS Chatbot (AWS's own service) subscribes to SNS topics and posts CloudWatch alarm notifications to Slack channels and Microsoft Teams channels. For most teams this removes the Lambda entirely.
2. One Lambda, two destinations. If you need custom formatting, a single function subscribed to the SNS topic can post to a Slack incoming webhook and a Teams incoming-webhook or Workflows URL.
3. SNS HTTPS subscription to a relay you host that confirms the subscription and posts to both platforms.

Setup with AWS Chatbot:

1. In the AWS Console, open AWS Chatbot and configure a Slack workspace client and a Microsoft Teams client (each requires an admin on that platform to authorize the app).
2. Create a channel configuration per destination channel and choose the SNS topic(s) it should subscribe to.
3. In CloudWatch, make sure your alarm's Actions send to that SNS topic.
4. Trigger a test state change and confirm the post arrives in both channels.

CloudWatch Event Types Worth Posting

ALARM state (threshold breach): The primary alert event. Post to Slack for the on-call team and Teams for engineering leadership. Include the alarm name, threshold, and current metric value.

OK state (recovery): Post to the same channels so engineers and managers both see recovery without a separate status check.

INSUFFICIENT_DATA: Often indicates a monitoring gap (agent stopped, metric stopped publishing). Slack for the infrastructure team is usually enough. These are not always urgent but should be tracked.

Composite alarm state change: Composite alarms aggregate multiple child alarms. A composite alarm firing means multiple subsystems are degraded simultaneously — high-urgency. Post to both Slack and Teams with composite alarm context.

AWS Health events via EventBridge → SNS: AWS service health events (EC2, RDS, etc.) can flow through the same SNS topic so engineering teams in Slack and infrastructure managers in Teams both receive AWS service disruption notifications.

Where SyncRivo Fits (and Where It Doesn't)

SyncRivo does not relay messages posted by bots or apps. An AWS Chatbot post in Slack #oncall is not copied to Teams by SyncRivo, and vice versa; each channel gets its own alarm post from the path above.

What SyncRivo bridges is the human conversation around the alarm. Connect Slack #oncall to Teams #engineering, and the incident exchange — who is on it, what the blast radius is, when the customer update goes out — is visible on both platforms, in both directions, with threads, edits, files, and @mentions kept in sync. The on-call engineer works in Slack, the engineering manager follows and replies from Teams, and the post-incident timeline is in one place instead of two.

For the CloudWatch and SNS setup walkthrough, see the AWS CloudWatch Alerts in Slack & Teams integration guide.