この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

SESから送ったメールの証跡をCloudTrailで追おうとしたら、SendEmailやSendRawEmailのイベントが一件も出てこなかった。結論から言うと、これは設定ミスとかではなく仕様だった。

何が見えて何が見えないか

CloudTrailはSESのAPIコールをすべて同じように記録しているわけではない。大きく分けると以下の2種類がある。

• 管理系のAPI：GetSendQuota、ListContactLists、ID検証や設定変更など。こっちは通常のイベントとしてCloudTrailに記録される。
• 送信系のAPI：SendEmail、SendRawEmail（テンプレート送信系のSendTemplatedEmail、SendBulkTemplatedEmailも含む）。こっちはCloudTrailの記録対象から外れている。

なので、コンソールのイベント履歴やTrailのログを見て「管理系のAPIコールはあるのに送信系だけない」という状態になっていたら、それはバグでもフィルタ漏れでもなく、そもそもSESが送信系のAPIコールをCloudTrailに渡していないのが原因ということになる。

SMTP経由の送信はそもそも対象外

もう一つ、SESにはAPIを直接叩く方法とは別にSMTPインターフェース経由で送る方法があって、こっちを使っている場合は当然SendEmail/SendRawEmailのAPIコール自体が発生しない。なのでCloudTrail云々の前に、そもそも記録されるべきイベントが存在しないことになる。

IAMでSMTP用の認証情報を発行しているからといって、それだけで「今SMTP経由で送っている」と断定はできない。実際に使われているかどうかは、アプリケーション側の設定やソースコード、環境変数などSMTPエンドポイントへの接続設定を直接確認するのが確実だった。

見分け方のポイント

• CloudTrailに送信系のイベントが出ないのは正常な挙動（管理系APIだけが対象）
• SMTP経由の送信は今回のCloudTrailの話とは別軸で、そもそも記録対象になり得ない
• 送信の証跡自体を追いたいなら、CloudTrailではなくSESのイベント発行（バウンス・苦情・配信など）をCloudWatch LogsやSNS、Kinesis Data Firehoseに流す構成が必要

CloudTrailのイベント履歴は保持期間が90日で、それを超える分はS3に保存したログやAthenaでのクエリで追う形になる。ここはSESに限らずCloudTrail全般の話。

追記（2025年4月の変更について）

この記事を書いた時点（2024年8月）ではSendEmail・SendRawEmailはCloudTrailの記録対象外だったが、2025年4月にSESの仕様が変わって、CloudTrailのデータイベントとしてSendEmail・SendRawEmail・SendTemplatedEmail・SendBulkTemplatedEmail（SES v2ではSendEmail・SendBulkEmail）を記録できるようになったらしい。

ただし自動で有効になるわけではなく、データイベントはCloudTrailのデフォルトでは記録されない区分なので、Trail側で明示的に有効化する必要があり、追加課金の対象にもなる。またSMTPインターフェース経由の送信は、この変更後も引き続きCloudTrailの記録対象外のままとのこと（未確認、公式ドキュメントの記載ベース）。