SNS
Last updated: Sep 23, 2026
Rationale
Amazon SNS (Simple Notification Service) is the service we use for publish and subscribe notifications in the cloud. A publisher sends a message to a topic once, and every subscriber of the topic receives it.
The main reasons why we chose it over other alternatives are:
- It is a fully managed serverless service. There is nothing to provision, and we pay per message.
- It complies with several certifications from ISO and CSA. Many of these certifications are focused on ensuring that the entity follows best practices regarding secure cloud-based environments and information security.
- It is the notification target of other AWS services, such as CloudWatch alarms and AWS Budgets, so an alert can reach people without writing any code.
- It supports email subscriptions, which is the delivery channel our engineers already watch.
- It can be published to from Lambda with the AWS SDK, so a scheduled function can turn raw findings into a readable digest.
- It supports server-side encryption with KMS and topic policies that restrict which services may publish.
- Resources can be written as code using Terraform.
Alternatives
No alternatives are currently being considered, as SNS is the built-in destination of the AWS services that raise our alerts, and the notifications it carries are internal to the engineering team.
Usage
We use Amazon SNS for:
- Notifying the engineering team by email when AWS Budgets forecasts or exceeds the monthly account budget and the Bedrock budget.
- Delivering a daily digest of Amazon Inspector findings, compiled by a scheduled Lambda.
- Delivering a digest of least-privilege recommendations from IAM Access Analyzer, compiled by a scheduled Lambda.
- Emailing the CloudWatch alarms of our GitLab bot, which fire when its SQS dead-letter queue receives a message or its queue stops draining.
We do not use Amazon SNS for:
- Sending email to platform users, which we do with SendGrid.
- Routing events between AWS services, which we do with EventBridge.