Amazon SES (Simple Email Service)

解決する課題

• アプリから確認メール・通知・パスワードリセットなどを送りたい
• 自前のメールサーバーを持たず到達性とスケールを確保したい
• 大量のトランザクション/マーケメールを安価に従量課金で送りたい
• 受信メールを受け取り、後続処理（S3保存やLambda起動）へ流したい

主要概念と用語

• 検証済みID（Verified Identity）: 送信元として使うドメインまたはメールアドレス。送信前に所有を検証する
• サンドボックス: 初期状態の制限モード。検証済み宛先にしか送れない。本番利用は解除申請が必要
• SMTPインターフェース / SES API: メール送信の2つの経路。既存SMTPクライアントからも、API直叩きからも送れる
• 設定セット（Configuration Set）: 送信に紐づけるルールの束。イベント発行やIP管理などをまとめる
• イベント発行: 送信・配信・バウンス・苦情・開封などのイベントをSNSやデータ配信先へ送る仕組み
• バウンス / 苦情（Complaint）: 宛先不達や受信者の迷惑メール報告。放置すると評価が下がる
• 専用IP / 共有IP: 送信に使うIPアドレス。専用IPは評価を自分で管理できる
• SES受信: 受信メールをルールセットでS3保存・Lambda起動・SNS通知などへ振り分ける

仕様・制限・クォータ

• 送信はSES APIまたはSMTPから行う
• アカウントには送信レート（秒あたり）と1日あたり送信上限のクォータがあり、利用実績に応じて拡大される
• 初期のサンドボックスはリージョンごとに 24 時間 200 宛先、毎秒 1 宛先。検証済み宛先だけに送れる
• バウンス率・苦情率には許容上限の目安があり、超えると送信停止のリスクがある
• SES v2 API と SMTP は Base64 化後 40 MB、SES v1 API は 10 MB がメッセージ上限

内部の仕組み

横にスクロール

アプリはAPIまたはSMTPでSESにメッセージを渡し、SESがマネージドな送信基盤から実際のメールを配信します。送信時にはDKIM署名やSPF/DMARCといった認証情報を付与でき、受信側からの信頼を高めて到達性を確保します。

送信の結果として生じる配信・バウンス・苦情・開封・クリックなどのイベントは、設定セットを介してSNSやデータ配信先へ流せます。これにより、不達アドレスの除外やダッシュボード集計といった運用を自動化できます。

受信側では、受信ルールセットにマッチしたメールをS3への保存やLambdaの起動、SNS通知などへ振り分けられ、メールをトリガーにした処理を組めます。

一時エラーは再試行できますが、アプリが応答不明を理由に同じ要求を再送すると重複メールになり得ます。業務イベントIDを送信台帳に記録し、送信要求を一度だけ発行します。メール間の到着順は保証されないため、順序に依存する案内は本文に時刻や状態を含めます。

設計パターン / ベストプラクティス

• アプリ→SES（API/SMTP）でトランザクションメール（登録確認・通知・領収書）を送る
• 設定セット＋イベント発行→SNS/データ配信先でバウンス・苦情を捕捉し、不達アドレスを自動で除外
• 専用IPのウォームアップ: 大量送信前に徐々に量を増やし、IP評価を育てる
• マーケメールとトランザクションメールで送信元・IPを分離し、評価への影響を切り分ける
• 受信フローはSES受信→S3/Lambdaでサーバーレスに処理する
• 認証情報は環境変数やSecrets Managerに置き、コードへ直書きしない

運用・監視

• バウンス率・苦情率を継続監視し、しきい値に近づいたら原因の宛先リストを是正する
• バウンス・苦情イベントを購読し、サプレッションリスト（送信抑止リスト）を活用して不達先への再送を防ぐ
• 送信レート/日次上限の使用状況を把握し、必要に応じて引き上げを申請する
• CloudWatchで送信数・配信・バウンス・苦情などのメトリクスを可視化しアラームを設定する

コスト

• 2026年7月21日以降の新規 SES アカウントと、2025年6月1日以降に利用実績がないアカウント・リージョンの組み合わせは Essentials から開始する
• Essentials は到達性インサイト、Pro は管理型専用IP・メール検証・受信箱配置の可視化、Enterprise は複数リージョン耐障害と評判分離を追加する。従量制へ切り替える選択肢もある
• 送受信数、添付データ、専用IP、データ転送などは選択した料金体系に応じて加算される

セキュリティ

• IAMで送信・受信操作の権限を制御し、SMTPは専用の認証情報を発行して使う
• 送信元IDの検証（ドメイン/アドレス）で、なりすまし送信を防ぐ
• DKIM署名で改ざん検知と認証を行い、SPF/DMARCと組み合わせて信頼性を高める
• VPC内からの送信や、受信メールのS3保存時の暗号化（KMS）を利用できる

Well-Architected の観点

• 運用上の優秀性: イベント発行とサプレッションで、バウンス対応や到達性管理を自動化できる
• 信頼性: マネージドな送信基盤で、スケールと冗長性をAWS側に任せられる
• コスト最適化: 従量課金で、メール基盤の固定費と運用負荷を削減できる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 送信元IDを作成 → サンドボックス内で検証済み宛先へテスト送信
aws sesv2 create-email-identity --email-identity sender@example.com

aws sesv2 send-email \
  --from-email-address sender@example.com \
  --destination "ToAddresses=verified-user@example.com" \
  --content "Simple={Subject={Data=Hello},Body={Text={Data=SES test mail}}}"