【Amazon SES】SaaS開発者の悲鳴を止める！「テナント単位の抑制リスト」がついに登場。特定顧客のメール不達が全ユーザーに波及するリスクを完全シャットアウト！

Amazon Simple Email Service (Amazon SES) が、テナント単位での抑制リスト（Tenant-level suppression lists）を新たにサポートしました。これにより、単一の AWS アカウント内で、バウンス（跳ね返り）や苦情（コンプレイント）の抑制リストをテナントごとに分離して管理できるようになります。設定により、抑制スコープを TENANT または ACCOUNT から選択可能で、API を用いてテナントごとの個別管理も可能です。

🚀 SaaSエンジニア必見！「一人のミスで全員停止」からの脱却

これまで SaaS を運用していると、**「ある特定の顧客（テナント）が大量のスパムメールを送ってしまい、その影響でアカウント全体の送信信頼性が低下し、他の健全な顧客のメールまで届かなくなる」**という、まさに地獄のような事態が起こり得ました。今回のアップデートは、この「マルチテナンシーにおける共倒れリスク」を根本から解決する神アプデです。

📍 日本での利用状況：東京・大阪両リージョン対応済み！

リサーチの結果、東京リージョン (ap-northeast-1) および 大阪リージョン (ap-northeast-3) の両方で、この新機能および SES の主要機能が提供されていることを確認済みです。国内のエンジニアも、すぐに導入検討が可能です。

🛠 運用のための技術的アドバイス

• 「抑制スコープ」の設定に注意： TENANT スコープに設定した場合、アカウントレベルの抑制リストはチェックされずスキップされるという挙動に注意が必要です。既存のフローを設計する際、テナントごとに挙動が明確に分かれることを念頭に置いてください。
• セキュリティ（PII）への配慮： API の TenantName パラメータには、顧客のメールアドレスなどの個人情報（PII）を直接入れず、cust-12345 のような内部的な顧客 ID を使用するのがベストプラクティスです。
• クォータ管理： 抑制されたメッセージも1日の送信クォータにカウントされるため、大量のバウンスが発生するテナントがある場合、クキャータの枯渇に注意してください。

🏃 次に何をすべきか？

1. PutTenantSuppressionAttributes API を使用して、現在のテナント管理フローがどのように変わるか検証する。
2. TenantName に PII を含めない設計になっているか、現在の実装を確認する。

参照： Amazon SES documentation (https://docs.aws.amazon.com/ses/latest/dg/sending-email-suppression-list-tenant-level.html)