How to make AWS notification emails readable

Forward them to a dedicated address, and nothing else. The notices come back summarised, with the customer and the AWS account already worked out, in one inbox.

  • Nothing changes on the AWS side — no access keys, no IAM permissions. All you set up is a forwarding rule in your mailbox
  • A summary and an explanation of what is going to happen, what it affects and what to do, with a severity. If the original states a deadline, that comes too
  • The summary and explanation in the inbox are on Free ($0, 1 seat, 7 days of history). Delivery to Slack starts at Team ($19 per month, tax excluded)

AWS notification emails arrive dense and technical, and if you look after several accounts they pile up mixed together in one mailbox. Forward them to a dedicated address and Sabaki adds a plain summary and explanation, a severity and a deadline, then delivers them to an inbox and to Slack. Nothing changes on the AWS side.

Last updated: 2026-09-22

Why AWS notices pile up unread

AWS sends maintenance windows, certificate renewals, runtime deprecations, billing and security alerts, and much else besides, all by email. The subject line rarely says whether anything has to be done, and the body is a wall of 12-digit account IDs and resource IDs.

With one account you can simply read them. An MSP or a dev shop holding several accounts per customer ends up checking each notice against a spreadsheet to find out whose it is, and then leaves it for later. The usual failure is that the one notice that needed action is buried among the marketing mail.

What happens to a notice you forward

In Sabaki each customer is a group, and creating one issues a forwarding address that belongs to it (@in.sabaki.cloud). A forwarding rule in Gmail or Microsoft 365 that sends mail from AWS to that address is the whole of the setup. Nothing has to change about where your root email is received, and the AWS console stays closed.

Each mail that arrives is checked against its DKIM signature first, to see whether AWS really sent it, and the verdict is shown on every message. The AWS account IDs in the body are then extracted and matched automatically against the customers and accounts already registered. Finally Anthropic's Claude, on Amazon Bedrock, writes the summary and the explanation of what is happening, what it affects and what to do, and sets a severity (Critical, Action required or Info) and a deadline.

What changes once they are readable

Instead of subject lines there is one plain sentence per notice, so running your eye down the inbox is enough to see what has to be dealt with today. Notices with a deadline show it, and whether they were handled is written into the response ledger. So is who decided that no action was needed, and when, so if the person in charge changes, whoever takes over knows what was decided.

  • Critical: an account suspension notice, a failed payment, a security breach — act now
  • Action required: a maintenance reboot, a certificate expiring, a runtime being retired — act before the deadline
  • Info: the bill closing, a feature announcement — reading it is enough

Example: the mail that arrives, and what Sabaki shows

The subject and body imitate a real notification. Account IDs and dates are fictional.

The mail that arrives (English)
From
Amazon Web Services <no-reply-aws@amazon.com>
Subject
Amazon EC2 Maintenance Notification [AWS Account: 123456789012]

Dear Amazon Web Services Customer,

One or more of your Amazon EC2 instances associated with your AWS account (123456789012) in the ap-northeast-1 region is scheduled for maintenance between 2026-10-05 17:00 UTC and 2026-10-05 19:00 UTC. During this window the instance i-0a1b2c3d4e5f67890 will be rebooted.

If you would like to reboot the instance at a more convenient time, you may do so before the scheduled window and the maintenance will be cancelled.

What Sabaki shows (English)
Action requiredCompany A (online shop)123456789012 (Company A, production)Due: 2026-10-06 02:00 (UTC+9)

The EC2 instance i-0a1b2c3d4e5f67890 in Company A's production account will be rebooted during maintenance on 6 October, between 02:00 and 04:00 (UTC+9).

This is maintenance on AWS's own hardware: the instance will be rebooted once inside that window. Reboot it yourself before then, at a time that suits you, and the reboot in that window is cancelled. For a service that runs continuously, the safe move is to tell the customer first and reboot by hand outside business hours.

When you are done, mark it “Handled” in the inbox and it goes into the ledger. If it is a staging environment where a reboot changes nothing, pick “No action needed” and add a one-line reason.

Getting started is three steps

It takes about 10 minutes. Once the forwarding rule exists, the next notice that arrives comes back explained.

  • Sign in to Sabaki and add a group for that customer: its forwarding address is issued straight away
  • In Gmail or Microsoft 365, create a rule that forwards mail sent by AWS to that address (the steps are in the help pages)
  • Check the inbox, and register a Slack channel or an email address as a destination if you want automatic delivery

Pricing

The inbox and the summary and explanation are on the Free plan ($0: 1 seat, 1 AWS account). Automatic delivery to Slack or email, several accounts and sharing with your team start at Team ($19 per month, tax excluded).

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

Related guides

If this helps, pass it on to someone who needs it.