「登録完了メールが届かない」

それは、SESアカウントが迷惑メールの踏み台になって凍結されていたという事件の始まりだった。
担当不在ななか、元フロントエンドの自分がゼロから調べて解決した全記録です

自分は1ヶ月前までWordPressを触っていたフロントエンジニア。
SESもAthenaもSQLもCloudTrailも、何一つ知らない状態からスタートした。

👣 そもそもやろうと思ったきっかけ

「やらなきゃ」と思ったわけじゃない。
「え、これ何が起きてるの？」っていうただの好奇心だった。

最初はSlackを眺めてるだけだったけど、
気がついたらAthenaでSQL書いてCloudTrailの構造を読んでいた。

気づけば、オフショアチームとの調整、外部CTOへの報告、AWS構成の見直しまで自分が主導していた。

🔍 知識ゼロから始めた調査の流れ

やったことは以下のような流れ。

1. SESが凍結された理由を特定

CloudWatch → GuardDutyの設定を追加
AIに相談しつつ、Athenaでログを探索
SESのSMTP送信はCloudTrailに記録されない罠に気づく
IPアドレス・UserAgentでアクセス元を特定

2. 不審なアクセスを突き止める

GitHub ActionsやAzure VMからの正規アクセスを確認
オフショアチームが.envにキーを保存 → S3に手動アップロード
GCP（外部）からの不正アクセスログがGuardDutyで検出

3. 対応・再設計

SMTP用サービスアカウントのキーを無効化
.env → Secrets Managerへの移行プランを提案
CloudTrail + Athenaでログ基盤を整備
S3バケット全体にアクセスログを有効化
SES異常時にSlack通知が来るよう設定

📜 時系列でのインシデント概要

05/22 メール送信切替のためAPIキー共有（ZIP暗号化）
06/03 オフショアがSMTPキー作成 → .envファイル更新
06/05 本番反映
06/10 SESで迷惑メール検知
06/12 外部GCPからSMTP送信の痕跡（GuardDuty）
06/23 SES凍結（25,000通送信／バウンス率 0.06%）
06/30 サポートからの報告で発覚
07/07 SMTPキー無効化

🧠 工夫したこと

Slackでの共有方法：

「仮説 → 調査 → 結果 → 次のアクション」の形で毎回共有
誰でも追えるよう、AWSの画面キャプチャやAthenaのクエリも貼る
調査ログを流さず、CTOや上司がレビューしやすい構成にした

🤯 実際どうだった？

めちゃくちゃ楽しかった。

「また漏洩しないかな」と思うくらい（笑）
・・・いや、実際は二度と起きてほしくないんですが、それくらい学びが大きくて
調べて分かるたびに、勝手にテンション上がってた。

💡 やってみて分かったこと

「知らないからできない」は思い込みだった
AI（ChatGPT）とログを見れば、ほとんどのことは分かる
やると決めたというより、好奇心で勝手に手が動いてた

📦 使った技術・ツール一覧

AWS SES / IAM / CloudTrail / GuardDuty / Athena / S3
AWS Secrets Manager
ChatGPT（クエリ生成・ログ構造解析・ヘッダ解析）
Slackでの調整・交渉
Markdownドキュメント化と構成整理

🧯 再発防止策（実施済）

✅ CloudTrail + Athenaでログ解析環境整備
✅ GuardDuty → Slack通知連携
✅ S3アクセスログをバケットで有効化
✅ Secrets Managerへの移行プラン提出
✅ ENVファイルDL時 → CloudTrail → Lambda → slack通知

🙌 まとめ

これは優秀なエンジニアの武勇伝ではない。
ただ、現場で誰もやらなかったから自分がやった記録です。

「わからないまま止まらなかった」
それだけが、自分にあった唯一のスキルだった。

🧵 最後に

この件を通して、AWSの設計・運用を引き受けることになりました。
同じように「知識ゼロからでも調べながらなんとかなるかも」と思ってもらえたら嬉しいです。