AWS User Notifications and Sabaki: what is different
AWS User Notifications and Sabaki solve different problems. User Notifications is AWS's own feature for delivering the notifications of one AWS account (or one organization) to the console, to email, to chat and elsewhere, and managing them in one place; it costs nothing extra. Sabaki takes the notification emails that arrive from AWS, works out which of your customers each one is about — even when those customers have nothing to do with one another — adds a summary and an explanation, and keeps a record of how it was handled. If what you want is to tidy up where notifications are delivered, User Notifications is the one; if the notifications that already arrive sit mixed together across customers and go unread, Sabaki is. And the two work side by side.
Last updated: 2026-09-22
What AWS User Notifications does
AWS User Notifications is the feature that brings the management of AWS notifications into one place. It works with two kinds of notification.
The first kind is the notifications AWS generates by itself (AWS managed notifications). They cover AWS Health, AWS Billing and Cost Management (billing, payments and account activity), AWS Marketplace and a few more; they appear in the console's notification centre with nothing to configure, and they reach the account's contact email address. Destinations can be added, and delivery to those contact addresses adjusted.
The second kind is the notifications you generate yourself by creating a notification configuration. From Amazon EventBridge events, CloudWatch alarms, support cases and others can be turned into notifications, naming the service, the event type and the region.
The destinations are the console's notification centre, email, chat (Slack, Microsoft Teams and others, through Amazon Q Developer in chat applications), push notifications in the AWS Console Mobile Application, and the API. There is an aggregation setting that groups notifications of the same kind, and for AWS Health the aggregation can span accounts within one organization.
What falls outside User Notifications
User Notifications generates notifications, delivers them and lists them. What comes after — reading them, deciding, and somebody dealing with it — is left to you.
The text of a notification itself can be shown in several languages (in the notification centre and through the API: GetNotificationEvent takes a locale). What it does not do is judge each notice that arrives — what it affects, what has to be done and by when — or put a severity and a deadline on it. Nor is it its job to record each notification as “Not handled” or “Handled” and share that with the team.
The unit of management is the AWS account, or one AWS Organizations organization. If you look after the accounts of several customers who have nothing to do with one another, as an MSP or a dev shop does, you end up with as many separate User Notifications as you have customers. Lining up every customer's notifications on one screen and sorting them by “which customer is this about” is not a use it was designed for.
Feature by feature
This is as of September 2026. AWS updates its features, so check the AWS documentation for the current list of covered services and destinations.
| Item | AWS User Notifications | Sabaki |
|---|---|---|
| What it does | Generates, delivers and lists AWS notifications | Sorts the AWS notification emails that arrive by customer, explains them, and records how they were handled |
| Input | The notifications AWS generates by itself (Health, billing and so on) and notifications built from EventBridge events | The emails that arrive from AWS (forwarded to each customer's own address) |
| Unit of management | An AWS account, or one organization | The customer. Accounts not tied together by an organization still sit in one inbox |
| Working out which customer it is about | Not covered (a separate screen per account or per organization) | Identifies the customer automatically from the account ID in the mail |
| What the reader gets in their language | The notification's own text can be shown in several languages (with a locale) | A summary and an explanation of each notice that arrives (what is going to happen, what it affects, what to do, the deadline, and a severity) |
| Response ledger | None | Not handled or Handled state, notes, and sharing with the team |
| Immediate alerting on alarms and events | Its strength (from the event to chat or mobile almost instantly) | Not covered (an event that never becomes an email cannot arrive, and going through mail costs a few minutes) |
| Setup on the AWS side | The default notifications need no setup; anything else needs a notification configuration | None (just a forwarding rule in your mailbox) |
| Price | No additional charge | Free $0 (1 seat, 1 account, 7 days of history). Groups and per-customer sorting are on every plan; Slack and email delivery start at Team ($19 per month, tax excluded) |
What Sabaki does not do
Sabaki does not receive AWS events directly. Pushing a CloudWatch alarm or an EventBridge event that never becomes an email into chat is User Notifications' territory. And because everything goes through a mail forward, there is no second-by-second immediacy either. Leave the first detection of an incident to monitoring and alarms, and use Sabaki for what it is for: that no mail which arrives goes unread, and that who dealt with it is written down.
And if you work inside a single organization and your team is happy reading the notices exactly as AWS writes them, User Notifications on its own will usually be enough.
Dividing the work when you use both
The two do not compete. A notification User Notifications delivered to the contact email address can be forwarded on to Sabaki as it is. The split looks like this.
- CloudWatch alarms, and deployment, scaling and similar events → straight to chat or mobile, through User Notifications
- Notification emails with a deadline, such as maintenance notices, certificate renewals, runtime deprecations and billing messages → sorted by customer in Sabaki, read there, and the handling recorded
- AWS Health → take the urgent ones instantly through User Notifications, and forward the mail to Sabaki as well, to take in what it says and keep the record
Getting started
To start with Sabaki, issue a forwarding address for each customer and add one forwarding rule in the mailbox where the AWS notifications already land. Nothing has to change on the AWS side. The steps are in the initial setup.
Forward one AWS notification and it comes back explained
The Free plan covers one account and one seat, with no credit card. Nothing changes on the AWS side, and no access keys are registered.
Related questions
- Does explaining notifications require changes on the AWS side?
- How do you tell which customer and account a notification belongs to?
- Can I connect more than one AWS account?
- Where do notifications go? Is Slack required?
- What happens if I forward mail that has nothing to do with AWS?
- How long is forwarded mail kept?
Related guides
If this helps, pass it on to someone who needs it.