Frequently asked questions

Yes. Sabaki uses AWS STS AssumeRole to temporarily assume a read-only IAM role that you create. Access keys and secret keys are never sent or stored.

The role's trust policy allows only Sabaki's AWS account together with the External ID issued to your workspace, which also covers the confused-deputy problem.

No. You only forward AWS notifications to the dedicated address Sabaki issues. A forwarding rule works, and so does forwarding by hand when needed.

You never hand over your root email to Sabaki; stop forwarding and the connection ends immediately.

Account IDs and ARNs in the notification body are extracted and matched against the accounts filed under each group.

An account ID seen for the first time is shown as unlinked; link it to a group once and it is recognised from then on. You can also assign accounts by hand from the AWS accounts page.

Industry surveys (Flexera's State of the Cloud, among others) estimate that just under 30% of cloud spend goes to unused or oversized resources. Results depend on your environment.

With the current checks (unattached EBS volumes, unused Elastic IPs, idle EC2 and RDS) 5–15% of monthly AWS spend typically surfaces. On Pro, AWS's own right-sizing, Reserved Instance and Savings Plans recommendations are imported into the list too.

Yes. The Free plan allows one account; Team and above are unlimited. Separate production and staging accounts, or several customers' accounts, can all be managed together.

No. Notifications can go to a Slack channel, an email address, or both.

Destinations can differ per client, and an email destination receives nothing until its owner confirms it. Customers who do not use Slack can be served as they are.

Yes, at any time. Cancel with one click, keep using the plan until the end of the period, and move to Free automatically. There are no cancellation fees.

Sabaki runs in the AWS us-east-1 region and stores cost aggregates, forwarded notifications and their explanations.

Detailed resource configuration inside your AWS account (security group rules, for example) is not stored.

Invoices are issued automatically through Stripe. For large deployments, bank-transfer invoicing or SSO, contact us and we will arrange it individually.

No rule is required. You can leave your mailbox untouched and forward just the notifications you want explained, one at a time, to the forwarding address. They are identified, translated and explained exactly as automatically forwarded mail is: they appear in the inbox, and reach Slack or email if you have set up destinations. With no rule there is also no Gmail forwarding confirmation to complete.

Use your mail client's ordinary Forward. As long as the original is in the body, it is classified. Avoid "Forward as attachment": the original cannot be read, so the notification is either filed as not AWS-related or, if the subject still carries an AWS word, gets a thin explanation built from the subject alone and delivered as though it were complete. Sending a large backlog at once also exceeds the receiving limit, and the excess is dropped rather than stored. The limits run in fixed hourly and daily windows, so send the rest in the next window.

Mail you forward by hand is marked an unverified forward: the AWS signature does not survive a manual forward, and that is not a fault. It is still explained and delivered as usual, but the marker also appears in the client-facing share view, and it is what makes keeping the forwarding address secret matter. A notice you forget to forward never reaches Sabaki, so if you need to be sure of catching anything with a deadline, a forwarding rule suits that better.

Adding a client issues a forwarding address (@in.sabaki.cloud). Add it as a forwarding destination under Gmail's Settings → Forwarding and POP/IMAP; Gmail then sends a confirmation code to that address.

Gmail's confirmation email arrives in Sabaki's inbox. Open it and press the approval button shown inside (the confirmation mail carries no code; approval is a link). Once forwarding is on, narrow it with a filter to mail from AWS. Put all three domains in the filter's From field: amazon.com OR aws.com OR amazonaws.com.

Create an Outlook rule that forwards or redirects mail from AWS (amazon.com / aws.com / amazonaws.com) to the forwarding address. If your tenant blocks external forwarding, ask your administrator to allow it.

"Forward" rebuilds the message, so the AWS signature is lost and Sabaki labels it an unverified forward. Use "Redirect" where possible: it keeps the original headers, and the AWS signature can be verified.

Since September 2026, AWS sends billing emails from @aws.com addresses instead of no-reply@amazonaws.com: invoicing@aws.com for invoices, payment@aws.com for payments, billing-subscriptions@aws.com for subscriptions, fraud-prevention@aws.com for fraud prevention and financing@aws.com for financing.

A forwarding rule or filter that matches only amazonaws.com no longer catches them. Add aws.com to the sender condition. Nothing needs changing in Sabaki: mail from the new senders is verified as coming from AWS in the same way.

No, any name works. The CloudFormation template and CLI steps use SabakiCloudReadOnly by default, but change it to fit your naming convention.

What Sabaki checks is not the name but the trust policy (Sabaki's account plus your External ID) and that the role can actually be assumed when you connect it.

Cost Explorer reads (ce:Get*), Describe on EC2 / EBS / EIP / snapshots, RDS and load balancers, CloudWatch metric reads, listing S3 buckets, listing Organizations accounts, and sts:GetCallerIdentity.

All of them are reads; nothing in the role can change or delete a resource. The template is public, so you can review it before applying.

A little. Sabaki calls the Cost Explorer API in the AWS account you connect: to read your cost history and its breakdown by service, to find which regions to scan, and to build reports. On Pro it also fetches AWS's right-sizing, Reserved Instance and Savings Plans recommendations through it. That API costs $0.01 per request, and AWS bills it to the account being queried — yours — separately from what you pay for Sabaki.

Most of the calls happen in the nightly refresh, once a day — somewhere between a few and a dozen or so requests each time. What is fetched is stored and reused rather than requested again. Beyond that, calls are made when you run "Re-analyse now" (up to three times a day per account), when you open the cost screen and the stored data is more than 24 hours old, when you open the breakdown of a member account on Pro, and when a report is built.

AWS does not charge for Describe calls on EC2, EBS and RDS. Reading CloudWatch metrics falls under AWS's free tier of one million API requests a month. Sabaki makes one such request per running EC2 instance and RDS instance each time it analyses the account: in the nightly refresh, when a cost report is delivered, and on a manual re-analysis. In an account that has already used that free tier up, they cost $0.01 per 1,000 requests.

If you only forward mail, no AWS account is connected and nothing is charged on the AWS side.

Connect the management (payer) account and the spend of every member account in the consolidated bill becomes visible through it, on every plan. In the cost trend's account picker they hang under the management account.

The per-service breakdown of a selected member account is a Pro feature; other plans show that member's total spend.

Member accounts shown in grey are ones Sabaki holds no role for. Waste detection and savings recommendations only run against accounts with a role: the management account's role cannot see the resources inside a member, so if you want recommendations for them, create a role in those accounts too and connect them. That is the same on every plan.

It means Sabaki could not confirm from a signature that the mail really came from AWS. Gmail's automatic forwarding and Outlook's "Redirect" keep the AWS DKIM signature, so those are shown as verified; a manual Fwd or Outlook's "Forward" rebuilds the message and the signature is lost.

Unverified mail is still explained and delivered, but the Slack message or email says so, and the reader can weigh it accordingly. Mail that claims to be from AWS without a signature is treated as spoofed and not delivered.

Mail with no mention of AWS is kept in the inbox as "not AWS-related" and is neither analysed nor delivered. Even with an over-broad forwarding rule, unrelated mail never reaches a customer's Slack or email.

There is no way to undo this classification from the inbox yet. If the notification ended up here because it was sent with "Forward as attachment", forward it again with the original in the body.

Yes, per plan. Free: 30 per hour per forwarding address and 50 per day per workspace; Team: 60 per hour and 300 per day; Business: 120 per hour and 1,000 per day; Pro: 300 per hour and 3,000 per day.

Even a busy AWS account produces around 10–30 notifications a week, so normal use does not come near these.

Mail over the limit is not taken in: no analysis, no delivery, and it does not appear in the inbox. The count of dropped mail is shown in the client's diagnostics, so notifications never stop silently.

Limits reset hourly (per address) and daily (per workspace), and the next mail comes through as usual. When this happens, check whether you forwarded a lot by hand at once, or whether the forwarding rule matches more than intended. The windows are fixed, so send the rest in the next one. Contact us if you need a higher limit.

Open the client's diagnostics. It shows the forwarding address status, the last time mail was received, whether a Slack webhook is set, and whether anything was dropped for exceeding a limit, all in one place.

If nothing has ever been received, the forward is not reaching Sabaki yet. If you forwarded by hand, check that the destination is this group's forwarding address and that you did not use "Forward as attachment". If you use a rule, check its destination and, for Gmail, that you pressed the approval button in the confirmation mail that arrived in the inbox. If mail is received but nothing is delivered, check that the destination email is confirmed and the Slack webhook is still valid.

AWS costs take time to settle. Sabaki loads them automatically at 19:00 UTC (4:00 the next morning in Japan) and, if that load fails, tries again at 22:30 UTC. A report only covers days that have been loaded, so a daily report usually covers the day before yesterday. Every report prints the period it covers at the top.

Leaving out a day that has not been loaded is more accurate than calling it zero. A weekly report is always seven days, ending on the most recent day loaded. A monthly one is not sent until the last day of the month is loaded, which can make it arrive on the 2nd rather than the 1st.

If both loads fail, or AWS takes longer than usual to finalise a day, that one day can be missing from the daily report. The amounts are not lost: the dashboard shows them as soon as the data arrives, and opening the dashboard also triggers a load.

Once right after an account is connected, then automatically every night. When you need it sooner — right after fixing the role's permissions, say — use “Re-analyse now” on the AWS Accounts page (up to three times a day per account; the count resets at 00:00 UTC, 9:00 in Japan).

"This month's AWS spend" is the sum of daily data from the 1st of the month to yesterday; today is not included yet.

Archive takes a notification you have finished with out of the inbox. It is not deletion: archived notifications stay in the Archive folder (open it to search them), keep their handling record and notes, and still appear on the customer's share link.

Trash is for notifications you no longer need. For 30 days after moving one there, Restore puts it back in the inbox. After 30 days its content — the original mail, subject, summary and explanation — is permanently deleted and cannot be recovered. Trashed notifications never appear on the share link.

A star is a bookmark. Star anything you want to come back to and it collects in the Starred folder. A star survives archiving and is removed when the message goes to the trash.

Inbox, archive, trash and stars are shared across the workspace: when a colleague archives something it leaves everyone's inbox. The unread count only counts what is still in the inbox.

A deleted notification goes to the trash first and stays there for 30 days. Nothing about it changes in that time, and you can restore it whenever you like.

After 30 days it is permanently deleted. What goes: the original mail we stored, the subject, the sender, the summary, the explanation and the extracted AWS account IDs. The handling history and notes are retained on our side as the record of who decided what and when, but they are no longer reachable from the app.

If you deleted the wrong one, open the trash and press Restore. You can restore several at once.

To remove something before the 30 days are up, press Delete permanently inside the trash, on one notification or on a selection. What goes is the same as the automatic deletion, and it cannot be undone. Only owners and admins can do this.

The 30 days are the same on every plan. How far back the list reaches is set by the plan, though (7 days after arrival on Free), so an older notification leaves the list, trash included, before it is deleted.

Yes. Tick the checkbox on each row, or the one at the top to select the whole page. The selection can then be marked read or unread, starred, archived, deleted (or restored, in the trash) or given a handling status in one go.

Marking notifications as no action needed requires a memo, even in bulk. The memo is recorded on each notification's history.

AWS sometimes sends the same announcement dozens of times. Search for its subject, select all, then archive or delete — that is the quickest way through.

Open a notification and the Handling section has a memo field. Save keeps the memo on its own. Pressing Handled or No action needed with a memo written records the memo with that decision. No action needed requires one: a dismissal without a rationale cannot be told apart from nobody looking.

Memos and status changes appear as one history, with who and when. They cannot be edited afterwards.

Above the list you can filter by handling status (not handled, handled, no action needed) and by “With a memo”. Notifications that have a memo carry a speech-bubble mark in the list.

Open the notification and use “Is this explanation wrong? Tell us” under the explanation to say what is off.

Sending shares that email's original text and the AI's explanation with the Sabaki team, together with your comment. We use them to find and fix the cause. Nothing is shared until you tick the agreement and press Send. Only your comment reaches our notification channel, never the subject or the original. The copy of the original you shared is erased 90 days after the email arrived, like the original itself. When the notification is permanently deleted, or its group or the workspace is deleted, everything you shared goes, your comment included.

There is no way to have the AI re-read a notification it has already read: the same input gives the same result. Retry appears only on a notification whose AI reading failed part-way. A notification that was read but failed to deliver shows Deliver again, which re-sends it without another AI call.

Type into the search box above the inbox and press Enter. Search looks in the subject, the sender, the AWS account IDs, and the summary and explanation in both languages, ignoring case. Japanese text and digits match as substrings; an English word (RDS, Bedrock) matches as a whole word, so "rds" does not hit "onwards".

Separate several words with spaces and only notifications containing all of them are shown (up to five words; single characters are ignored). Search combines with the client and AWS account filters, the folder, and “unread only”.

Search looks within the folder you have open: to find an archived or trashed notification, open that folder first. The original mail body is not searched; open a notification to read it.

No. Sabaki's notification emails carry an auto-submitted header and a Sabaki-specific marker; if one is forwarded back, it is stopped on receipt as a loop and neither analysed nor delivered.

Forwards that rebuild the message (Outlook's "Forward", a manual Fwd) drop the headers, but the marker in the body stops it just the same. As a precaution, narrow your forwarding rule to mail from AWS.

Members of your workspace, in the inbox. The client-facing shared view and the notifications carry only the summary and explanation Sabaki generated, never the original or excerpts of it.

Sabaki's operators read originals only for support work you have asked for, and for notifications you report as wrongly explained by the AI. The report form says, before you send, that the original will be shared.

Classification, translation and explanation run on Anthropic Claude via Amazon Bedrock. Bedrock does not use your data to train models and does not share it with Anthropic.

Processing stays in the same AWS region as Sabaki (us-east-1).

Originals are kept for 90 days and then deleted automatically. Summaries, explanations and your response notes remain as inbox history. A notification you move to the trash goes sooner: its content is permanently deleted 30 days after the move.

Deleting a client disables its forwarding address, and no further mail is accepted for it.

No. Sabaki only presents savings recommendations and the steps to act on them. It never changes or deletes your resources, and without write permissions it could not.