AWS環境でAmazon SESにてバルクメール送信をする際の勘所をまとめてみた
こんにちは！クラウド事業本部のおつまみです。
AWS環境でバルクメール（一斉大量配信）を実装しようとしたとき、「とりあえずSMTPでSESに繋いで送ればいいか」と思っていませんか？
実はSMTPで素直に実装するとスケールしたときに痛い目を見ます。
今回は、実際に起きた「6,000件送信に30分以上かかった」ケースをもとに、SESでバルク送信を正しく実装する方法と、SESだけでは難しいケースでの外部サービス（SendGrid）との使い分けを解説します。
3行まとめ
- SMTPで1通ずつ直列送信するとコネクション確立コストが積み重なり、数千件規模で処理時間が膨大になる
- SES v2の
SendBulkEmailAPI（1コールで最大50宛先）または並列化で大幅に改善できる - バウンス管理・到達率を重視するなら、クラスメソッドがパートナー提供するSendGridという選択肢もある
なぜSMTP直列送信ではダメなのか
SESへの接続にSMTPを使う場合、1通送信するたびに以下の処理が発生します。
1通あたり数百ミリ秒〜1秒程度かかるこの処理が、バルク送信では件数分だけ積み重なります。
実際に起きたケース
社内他案件での実測値ですが、6,000件のメール送信をSMTPで直列実装したところ、30分以上かかったという事例があります。
別のメール配信サービスでは同じ件数を15分程度で処理できており、差は歴然でした。
2,000〜3,000件規模であっても、SMTPの直列実装だと10〜15分以上かかる計算になります。「夜間バッチで送るから問題ない」という判断もありますが、急ぎのお知らせ配信やイベント直前の案内には向きません。
SESでバルク送信を高速化する2つの方法
方法1：SES v2 の SendBulkEmail API を使う
SES v2には SendBulkEmail というAPIがあり、1回のAPIコールで最大50宛先に同一テンプレートのメールをバッチ送信できます。
SMTPが「1通→応答待ち→1通→応答待ち…」と直列処理するのに対し、SendBulkEmail はSES側でバッチ処理してくれるため、APIコール数自体が大幅に減ります。
2,000件の場合、SendBulkEmail では最小40回のAPIコールで済みます（2,000 ÷ 50 = 40）。
宛先ごとに件名や本文の一部を変えたい場合は、テンプレート変数（{{変数名}}）で対応できます。また、受信者ごとにOpen/Clickトラッキングの有効・無効を個別に制御できるため、GDPR等のオプトイン管理にも対応できます。
方法2：並列化で送信レートを使い切る
既存実装をSMTPから大きく変えられない場合は、送信処理を5〜10並列に分けるだけでも大幅な改善が見込めます。
SESには「1秒あたりの送信レート上限」がありますが、SMTPで直列処理しているとこのレートを使い切れていないことがほとんどです。並列化することでスループットを引き上げられます。
なお、現在の送信レート上限はSESコンソールの「最大送信レート」から確認できます。
また上限の引き上げはAWSサポートケース経由で申請可能です。ただし、徐々に引き上げを行う必要があります。
参考：AWS SESのメール送信数のクォータの上限引き上げについて | AWS re:Post
SES利用時に押さえておきたい注意点
サンドボックス解除（プロダクションアクセス申請）が必須
SESはデフォルトでサンドボックス状態（1日200通・1秒1通）になっています。バルク送信を行うには本番アクセスの申請が必要です。
申請時に必要な情報は以下のとおりです。
- 希望する1日あたりの送信クォータ（件数）
- 送信元ドメインの検証済みID
- SPF / DKIM / DMARCの設定
- 送信メールのタイプ（トランザクション or マーケティング）
- 送信理由の具体的な説明
申請後は通常24時間以内に初回応答が来ます。
弊社内では1日50,000通規模での緩和申請を通した実績もあり、2,000〜3,000件規模であれば問題なく対応できる範囲です。
バウンス率・苦情率の管理
SESはバウンス率・苦情率が悪化すると送信が制限されます。送信停止になりうる水準の目安は以下のとおりです。
| 指標 | 推奨維持値 | 危険水準（停止リスク） |
|---|---|---|
| バウンス率 | 5%未満 | 10%超 |
| 苦情率 | 0.1%未満 | 0.5%超 |
これらの指標は CloudWatch のメトリクス（Reputation.BounceRate / Reputation.ComplaintRate）で監視できます。しきい値を超えたときにSNS経由でアラートを飛ばすCloudWatch Alarmの設定をあわせて構築することを推奨します。
バルク送信前には送信先リストの精査（無効アドレスの除去）も必ず実施してください。
SESだけでは難しいケースはSendGridも検討する
SESは安価で高スループットなメール送信基盤ですが、以下のようなケースでは外部メール送信サービスの利用が現実的です。
- バウンス管理・配信停止リストの自動管理をアプリ側で実装したくない
- 開封率・クリック率などのレポートをダッシュボードで手軽に確認したい
- スケジュール配信・ABテストなどのMA的な機能が必要
こういったケースに向く選択肢の一つがSendGridです。
SES と SendGrid の比較
| 項目 | Amazon SES | SendGrid |
|---|---|---|
| 単価（目安） | 約0.16 USD / 1,000件 | 約0.42 USD / 1,000件 |
| バウンス・配信停止管理 | アプリ側で実装が必要 | 自動管理（サプレッションリスト含む） |
| 開封率・クリック率レポート | 別途設定が必要 | 標準ダッシュボードで確認可能 |
| スケジュール配信・ABテスト | アプリ実装が必要 | 標準機能として対応 |
| 到達率（公称値） | 標準的 | 99% |
| クォーター管理 | AWS申請が必要 | プラン選択で対応 |
クラスメソッドはSendGridのパートナーとして請求代行・技術サポートを提供しています。
申し込みから約2週間で利用開始できるため、ご興味があればお気軽にご相談ください。
まとめ
AWS環境でバルクメール送信を実装する際のポイントをおさらいします。
- SMTPの直列送信はコネクション確立コストが積み重なり、数千件規模では処理時間が膨大になる
- SES v2の
SendBulkEmailAPI（1コールで最大50宛先）への切り替え、または5〜10並列化で大幅に改善できる - SES利用にはサンドボックス解除申請が必須。バウンス率・苦情率の監視（CloudWatch Alarm）もあわせて設定する
- バウンス管理・レポート機能・MA機能を重視する場合はSendGridも有力な選択肢
最後までお読みいただきありがとうございました。
どなたかのお役に立てれば幸いです。
以上、おつまみ（＠AWS11077）でした！
