AWS SESが停止！キー漏えいから学んだこと
1. はじめに
AWS SESは便利でコストも低いメール送信サービスですが、キー管理や監視が不十分だと簡単にトラブルへ発展します。
本記事では、私が実際に遭遇した
「突然メールが送れなくなる → SESアカウント停止 → コスト急増」
というインシデントの調査から復旧、再発防止までをまとめます。
AWSを利用したシステム運用において、同じミスを防ぐ上で参考になれば幸いです。
2. インシデント発生：突然メールが送れない
ある朝、システムがメール送信エラーを大量に出力していることに気づきました。
調査すると、実は数日前からメールが一切送れていなかったことも判明。
キューは詰まり、ユーザーにもメールが届かない状況でした。
3. ソースコードの確認：異常なし
まずGitログを確認しましたが：
- メール関連コードの変更なし
- ライブラリ更新なし
- デプロイ内容にも問題なし
ソースコード側の問題ではなさそうでした。
4. AWS調査：SES が停止され、コストが急上昇
AWSコンソールを確認すると、SESが Pause Sending（送信停止） の状態に。
さらに、SESの利用料金だけが急増しており、他サービスには異常なし。
これは「SESキーだけが外部に悪用されている可能性が高い」と判断できる状況でした。
5. SESログ確認：Bounce率 > 10% で自動停止
Sending Statistics を確認すると：
- Bounce率が 10% を超過
- これにより AWS が自動的に送信を停止
- 警告メールは rootアカウントのみ に届いていた
- しかし、顧客側で見落とし → Devチームへ共有されていなかった
運用体制の問題が明確になりました。
6. 詳細調査：Bounceされたメールはシステムに存在しない
さらにログを確認すると驚くべき事実が：
- Bounceされたメールアドレスが 弊社システムDBに存在しない
- 送信履歴はシステムのログには残っていない
- 不審な第三者による送信の可能性が高い
→ SES Access Key が外部に漏えいして悪用されたと確定。
7. 原因推定
調査結果から、以下の2つの可能性がありました：
① システムが誤って大量送信した
→ BounceされたメールがDBに存在しないため否定。
② SESキーが漏えいし、第三者に悪用された
→ SESコスト急増
→ Bounce急増
→ ログにもシステム外送信多数
結論：② が確実。
8. 緊急対応（Incident Response）
✔ 1. 漏えいしたSESキーの即時削除
第三者の送信を完全ストップ。
✔ 2. 最小権限IAMで新しいSESキーを発行
許可するのは以下のみ：
- ses:SendEmail
- ses:SendRawEmail
✔ 3. AWSへ送信再開リクエストを提出
内容：
- インシデント説明
- キー削除報告
- 再発防止策の提示
- 運用改善の約束
数回のやり取りの後、Open（解除）されました。
9. 再発防止のための追加対策
🛡 1. Bounce/Complaint の自動処理を導入
不正メールアドレスへの再送を防止。
🛡 2. AWS Budget Alert
SESコスト急増時に即アラート。
🛡 3. rootメールではなくメールグループで通知受信
例：
10. SNS通知設定（Bounce/Complaint）
これを設定していなかったことが今回の大きな反省点。
● ステップ1：SNS Topic作成
- ses-bounce-topic
- ses-complaint-topic
● ステップ2：メール or Slack 等へ購読設定
DevOpsチーム全体に通知が届くようにする。
● ステップ3：SES Identity に Topicを紐付け
Bounce
Complaint
Delivery（任意）
● ステップ4：テスト送信で動作確認
11. DevOps標準セキュリティプロセス（チェックリスト）
【A. Secrets管理】
- Secrets Manager / Parameter Store に一元管理
- Git にキーを残さない
- キーは30日〜90日ごとにローテーション
- 古いキーは速やかに削除
【B. 通知・監視】
- SNS通知（Bounce/Complaint）は必須
- CloudWatchアラームでSES異常を検知
- Budgetアラートでコスト監視
- rootメールのみへの通知は禁止
【C. メール送信ロジック】
- SES Suppression List を必ず有効化
- Bounce済みアドレスへの再送防止
【D. 運用・インシデント対応】
- 鍵の棚卸しを定期実施
- インシデント発生時は即キー削除
- Postmortemの作成
- gitleaks などでキー誤コミット防止
12. 学んだこと
- SESキーの漏えいはコスト急増 → アカウント停止のリスクを伴う
- rootメールのみの通知運用は危険
- Bounce率10%超で強制停止されるため、監視とSNS通知は必須
- 漏えい原因は特定できない場合が多い
- DevOps標準のセキュリティ運用が安全性に直結する
13. まとめ
SESキーの扱いは非常に慎重であるべきで、
小さな設定漏れ・監視漏れが大きな障害につながることを実体験として学びました。
この記事が、AWSの安全な運用に少しでも役立てば幸いです。
ご質問やコメントがあればぜひどうぞ。