Skip to main content
The AWS CloudWatch integration turns CloudWatch alarms into scaling.cloud incidents. When an alarm transitions to ALARM, scaling.cloud opens a new incident on the mapped component. When it returns to OK, the matching open incident is resolved.
AWS CloudWatch integration

An AWS integration connected to a scaling.cloud component

​
How it works

  1. You create an AWS integration in scaling.cloud and pick a component it maps to. scaling.cloud issues a unique webhook URL.
  2. In AWS, you create an SNS topic, subscribe the webhook URL to it, and route your CloudWatch alarms to that topic.
  3. scaling.cloud verifies every incoming SNS notification’s signature, pins the topic ARN on first delivery, and ingests the alarm.
  4. OK → ALARM opens a new incident on the mapped component. ALARM → OK resolves the matching open incident. INSUFFICIENT_DATA is ignored.

​
State handling

The opened incident flows through the same pipeline as any other incident: it can have an escalation policy attached, page on-call responders, post to Slack, and appear on a published status page.

​
Security model

  • HMAC signature verification — every SNS notification is verified against AWS’s published signing certificate. Notifications with invalid signatures are rejected. scaling.cloud requires SignatureVersion=2 (RSA-SHA256); RSA-SHA1 (the SNS default) is no longer accepted.
  • Topic ARN pinning — the first valid SubscriptionConfirmation pins the topic ARN on the integration. Subsequent notifications with a different TopicArn are rejected.
  • Webhook tokens are revealed once — when you create the integration, the webhook URL is shown one time only. scaling.cloud stores only a SHA-256 hash; if you lose the URL you must delete and recreate the integration.
  • No payload logging — scaling.cloud does not log raw SNS payloads at info level. Structured logs reference only orgId and integrationId.
Keep your webhook URL secret. Anyone with the URL who can publish a valid signed SNS notification can open incidents in your organization. Rotate the integration if you suspect the URL has been exposed.

​
Setup

For a step-by-step walkthrough, see Ingest CloudWatch alarms. If your alarms are defined in AWS CDK, see Ingest CloudWatch alarms with AWS CDK for the TypeScript patterns that wire both ALARM and OK transitions. In short:
1

Create the integration in scaling.cloud

Go to Settings → Integrations → AWS and click Add integration. Choose a name and the component you want alarms to open incidents on. Copy the webhook URL on the one-time reveal screen.
2

Create an SNS topic in AWS

In the AWS console, create a new SNS topic (Standard, not FIFO) in the region where your alarms live.
3

Subscribe the webhook URL

Add an HTTPS subscription to the topic, pasting the webhook URL you copied from scaling.cloud. Set the subscription’s SignatureVersion to 2 (RSA-SHA256) — the SNS default of 1 (RSA-SHA1) is no longer accepted. scaling.cloud will auto-confirm the subscription on first delivery.
4

Route alarms to the topic

On each CloudWatch alarm you want forwarded, set the topic as a notification target for In alarm and OK state changes.

​
One integration per topic

Each AWS integration is bound to one mapped component. If you want different alarms to open incidents on different components, create one integration (and one SNS topic) per component.
A common pattern is one SNS topic per service in AWS, with the service’s most important alarms routed there, and one matching scaling.cloud integration mapping that topic to the service’s component. This keeps the open-incident signal tight and easy to reason about.

​
Removing an integration

Deleting an integration in scaling.cloud stops ingestion immediately — any further deliveries to the webhook URL return 404. To stop AWS from retrying, remove the HTTPS subscription from the SNS topic on the AWS side.