Amazon SES Mail Manager SMTPでVPCエンドポイント集約構成を維持できるか整理してみた
はじめに
2026年7月、Amazon Simple Email Service（Amazon SES）に、Mail Managerを利用したSMTP送信環境のガイド付きセットアップが追加されました。
ガイド付きセットアップでは、SMTP送信に必要な以下のリソースや認証情報が自動的に作成および設定されます。
- 認証済みイングレスエンドポイント
- トラフィックポリシー
- ルールセット
- IAMロール
- SMTP認証情報
以下の記事では、ガイド付きセットアップを利用したMail Manager SMTP環境の構築と、SMTPクライアントからのメール送信を確認しています。
従来のSES SMTPでは、IAMユーザーのアクセスキーから生成したSMTP認証情報を使用します。
一方、Mail Manager SMTPでは、認証済みイングレスエンドポイントへの接続にMail ManagerのSMTP認証情報を使用し、メールの送信にはルールセットに設定されたIAMロールを使用します。
AWSのドキュメントでも、従来のIAMユーザー認証情報フローとMail Managerの両方を利用できるリージョンでは、Mail Managerの使用が推奨されています。従来のIAMユーザー認証情報フローも引き続き利用できます。
ここで気になったのが、マルチアカウント環境でSES SMTP用VPCエンドポイントを集約している場合です。
以下の記事では、1つのAWSアカウントにSES SMTP用VPCエンドポイントを配置し、複数のAWSアカウントから利用する構成を紹介しています。
本記事では、この集約構成を維持したまま、従来のSES SMTPからMail Manager SMTPへ移行できるかを、2026年8月時点の公開ドキュメントをもとに整理します。
本記事では、各AWSアカウントを以下のように表現します。
| 呼称 | 役割 |
|---|---|
| 集約アカウント | SES SMTP用VPCエンドポイントやAmazon Route 53プライベートホストゾーンを配置するAWSアカウント |
| ワークロードアカウント | メール送信元のアプリケーションやAmazon SESを配置するAWSアカウント |
結論
公開ドキュメント上の標準的な構成では、以下の2つを両方とも維持したまま、Mail Manager SMTPへ移行することはできません。なお、本記事では、SESの送信承認を利用するクロスアカウント送信構成は対象外とします。
- SMTP用VPCエンドポイントを集約アカウントに配置する
- SESの送信クォータや評価メトリクスをワークロードアカウントごとに分離する
Mail Manager SMTPへ移行する場合は、次のいずれかの構成変更が必要です。
| 移行後の方針 | 必要な構成変更 |
|---|---|
| SESの送信クォータや評価メトリクスをワークロードアカウントごとに分離する | Mail Manager用VPCエンドポイントや認証済みイングレスエンドポイントをワークロードアカウントごとに配置する |
| VPCエンドポイントの集約を維持する | Mail ManagerとAmazon SESの送信基盤を集約アカウントに配置する |
現在の「VPCエンドポイントは集約アカウントに配置し、SESの送信クォータや評価メトリクスはワークロードアカウントごとに分離する」という構成を維持する場合は、従来のSES SMTPを継続することになります。
現在のVPCエンドポイント集約構成
前提とする構成では、集約アカウントに以下のリソースを配置します。
- SES SMTP用VPCエンドポイント
- VPCエンドポイント用のセキュリティグループ
- Amazon Route 53プライベートホストゾーン
各ワークロードアカウントには、以下のリソースを配置します。
- メール送信元のアプリケーション
- SESの検証済みID
- IAMユーザー由来のSMTP認証情報
ワークロードアカウントAからメールを送信する場合の流れは以下です。
ワークロードアカウントA
メール送信元アプリケーション
↓ SMTP認証情報Aを使用
集約アカウントのSES SMTP用VPCエンドポイント
↓
Amazon SES SMTPインターフェイス
↓ SMTP認証情報Aに対応するIAMユーザーの権限で送信
ワークロードアカウントAのAmazon SES
↓
インターネットへ送信
ワークロードアカウントBからメールを送信する場合も、同じVPCエンドポイントを利用します。
ワークロードアカウントB
メール送信元アプリケーション
↓ SMTP認証情報Bを使用
集約アカウントのSES SMTP用VPCエンドポイント
↓
Amazon SES SMTPインターフェイス
↓ SMTP認証情報Bに対応するIAMユーザーの権限で送信
ワークロードアカウントBのAmazon SES
↓
インターネットへ送信
集約アカウントのVPCエンドポイントは、SMTP接続のネットワーク経路として利用されます。
一方、メール送信に使用するIAMユーザーとSMTP認証情報は、ワークロードアカウントごとに異なります。
従来のSES SMTP認証情報は、ワークロードアカウントに作成したIAMユーザーのアクセスキーを基に生成します。
SMTPクライアントがこの認証情報を使用すると、対応するIAMユーザーの権限でメールが送信されます。そのため、集約アカウントのVPCエンドポイントを経由しても、メール送信に使用するAmazon SESはSMTP認証情報を作成したワークロードアカウント側になります。
ワークロードアカウントAのIAMユーザー
↓ アクセスキーを基に生成
SMTP認証情報A
↓ SMTPクライアントが認証に使用
ワークロードアカウントAの権限でメールを送信
この構成では、SES SMTP用VPCエンドポイントを集約しながら、メール送信に使用するAmazon SESをワークロードアカウントごとに分けられます。
SESの送信クォータは、AWSアカウントとAWSリージョンごとに設定されます。また、バウンス率や苦情率などの評価メトリクスも、メールを送信したAWSアカウント単位で管理されます。
Mail Manager SMTPの処理
Mail Manager SMTPをプライベート接続で利用する場合、SMTPクライアントから送信されたメールは以下のように処理されます。
SMTPクライアント
↓ STARTTLS・SMTP AUTH
Mail Manager用VPCエンドポイント
↓
認証済みイングレスエンドポイント
↓
トラフィックポリシーで許可または拒否
↓ 許可されたメール
ルールセット
↓
「インターネットに送信」アクション
↓ 指定したIAMロールの権限でSendRawEmail APIを実行
Amazon SES
↓
インターネットへ送信
認証済みイングレスエンドポイント（Authenticated ingress endpoint）は、SMTPクライアントから認証付きでメールを受け付けます。
SMTP認証に使用する情報は以下です。
| 項目 | 設定値 |
|---|---|
| ユーザー名 | イングレスエンドポイントID |
| パスワード | イングレスエンドポイントに設定したパスワード、またはAWS Secrets Managerのシークレット |
プライベート接続では、SMTPクライアントはMail Manager用VPCエンドポイントが提供するDNS名に接続します。
認証済みイングレスエンドポイントではポート25と587、およびSTARTTLSがサポートされています。SMTP AUTHの方式はAUTH LOGINとAUTH PLAINです。
トラフィックポリシーでは、送信元IPアドレス、TLS、送信者、受信者などの条件をもとに、メールを許可または拒否します。
許可されたメールには、イングレスエンドポイントに関連付けられたルールセットが適用されます。ルールの条件に一致すると、ルールに設定したアクションが実行されます。
今回利用する「インターネットに送信」アクションは、指定されたIAMロールの権限を使用し、Amazon SESのSendRawEmail APIでメールを送信します。
SendActionのRoleArnは必須項目です。指定するIAMロールには、ses:SendRawEmailを実行する権限が必要です。
SMTP認証情報とIAMロールの役割を整理すると以下です。
| 項目 | 役割 |
|---|---|
| SMTP認証情報 | 認証済みイングレスエンドポイントへの接続を認証する |
| IAMロール | 「インターネットに送信」アクションがAmazon SESを呼び出すための権限を提供する |
従来のSES SMTPでは、SMTP認証情報に対応するIAMユーザーの権限でメールを送信します。
従来のSES SMTP
SMTP認証情報
↓
SES SMTPインターフェイスへの接続を認証
↓
対応するIAMユーザーの権限でメールを送信
一方、Mail Manager SMTPでは、SMTP認証情報はイングレスエンドポイントへの接続認証に使用されます。メールの送信には、ルールセットに設定されたIAMロールが使用されます。
Mail Manager SMTP
SMTP認証情報
↓
認証済みイングレスエンドポイントへの接続を認証
↓
ルールセットに設定されたIAMロールの権限でメールを送信
この違いが、現在のVPCエンドポイント集約構成をそのまま移行できない理由です。
VPCエンドポイント集約時に関係する制約
VPCエンドポイントとイングレスエンドポイントは同じアカウントで所有する
Mail Managerのプライベートイングレスエンドポイントを利用する場合、Mail Manager用VPCエンドポイントとイングレスエンドポイントは、同じAWSアカウントで所有する必要があります。
クロスアカウントでの関連付けはサポートされていません。
配置できる組み合わせは以下です。
| Mail Manager用VPCエンドポイント | イングレスエンドポイント | 関連付け |
|---|---|---|
| 集約アカウント | 集約アカウント | 可能 |
| ワークロードアカウント | ワークロードアカウント | 可能 |
| 集約アカウント | ワークロードアカウント | 不可 |
| ワークロードアカウント | 集約アカウント | 不可 |
そのため、Mail Manager用VPCエンドポイントを集約アカウントに配置する場合、認証済みイングレスエンドポイントも集約アカウントに配置する必要があります。
ただし、SMTPクライアントまで集約アカウントに配置する必要があるという意味ではありません。
ネットワーク到達性、セキュリティグループ、ルーティングおよび名前解決を適切に設定すれば、ワークロードアカウントのアプリケーションから、集約アカウントのVPCエンドポイントへ接続する構成は可能と考えられます。
VPCエンドポイントとイングレスエンドポイントは1対1で関連付ける
1つのMail Manager用VPCエンドポイントに関連付けられるイングレスエンドポイントは1つです。
Mail Manager用VPCエンドポイントA
↓
イングレスエンドポイントA
別のイングレスエンドポイントを作成する場合は、別のVPCエンドポイントが必要です。
Mail Manager用VPCエンドポイントB
↓
イングレスエンドポイントB
この制約は、1つのイングレスエンドポイントを複数のSMTPクライアントから利用できないという意味ではありません。
複数のワークロードアカウントから、集約アカウントに配置した同じVPCエンドポイントとイングレスエンドポイントへ接続する構成が考えられます。
ただし、接続後に使用されるルールセットとIAMロールは、集約アカウント側のMail Managerに設定されたものです。
送信用IAMロールはMail Managerと同じアカウントに配置する
Mail Managerの「インターネットに送信」アクションでは、Amazon SESのSendRawEmail APIを実行できるIAMロールを指定します。
このIAMロールには、Amazon SESがロールを引き受けるための信頼ポリシーと、メールを送信するための権限ポリシーが必要です。
IAMロールをAWSサービスに渡すiam:PassRoleは、ロールを渡すAWSサービスと同じAWSアカウントのIAMロールに対して使用します。
アカウントAのIAMロールを、アカウントBのAWSサービスへ直接渡すことはできません。
したがって、集約アカウントにMail Managerを配置する場合、ルールセットに設定するIAMロールも集約アカウントに配置します。
集約アカウント
Mail Managerのルールセット
↓
「インターネットに送信」アクション
↓ 集約アカウントのIAMロールの権限でSendRawEmail APIを実行
Amazon SES
↓
インターネットへ送信
SMTPクライアントがどのワークロードアカウントから接続したかにかかわらず、メール送信にはルールセットに設定されたIAMロールが使用されます。
移行後の構成案
VPCエンドポイントを集約アカウントに維持する場合
VPCエンドポイントの集約を維持する場合は、Mail Managerの関連リソースも集約アカウントに配置します。
構成とメール送信の流れは以下です。
各ワークロードアカウント
メール送信元アプリケーション
↓ STARTTLS・SMTP AUTH
集約アカウントのMail Manager用VPCエンドポイント
↓
集約アカウントの認証済みイングレスエンドポイント
↓
トラフィックポリシーで許可または拒否
↓ 許可されたメール
ルールセット
↓
「インターネットに送信」アクション
↓ 集約アカウントのIAMロールの権限でSendRawEmail APIを実行
集約アカウントのAmazon SES
↓
インターネットへ送信
この構成では、集約アカウントに配置したMail Manager用VPCエンドポイントと認証済みイングレスエンドポイントを、複数のワークロードアカウントから利用します。
ただし、SMTP認証情報は認証済みイングレスエンドポイントへの接続認証に使用するものです。従来のSES SMTP認証情報のように、メール送信に使用するAWSアカウントを切り替えるものではありません。
メール送信には、集約アカウントのルールセットに設定されたIAMロールが使用されます。そのため、本記事で扱う標準的な構成では、Amazon SESも集約アカウント側で利用します。
以下の設定やメトリクスも、集約アカウント側で管理する構成になります。
- SESの検証済みID
- サンドボックス解除状態
- 送信クォータ
- バウンス率
- 苦情率
各ワークロードアカウントから送信したメールは、いずれも集約アカウントの送信クォータと評価メトリクスに反映されます。
例えば、あるワークロードから送信したメールによってバウンス率や苦情率が上昇した場合、同じ集約アカウントのAmazon SESを利用する他のワークロードにも影響する可能性があります。
したがって、この案はSMTPの接続先だけを変更するものではなく、Amazon SESの送信基盤も集約アカウントへ移す構成変更です。
SESの送信クォータや評価メトリクスをワークロードアカウントごとに分離する場合
各ワークロードアカウントのAmazon SESから引き続きメールを送信する場合は、Mail Managerの関連リソースもワークロードアカウントごとに配置します。
各ワークロードアカウントの構成とメール送信の流れは以下です。
各ワークロードアカウント
メール送信元アプリケーション
↓ STARTTLS・SMTP AUTH
Mail Manager用VPCエンドポイント
↓
認証済みイングレスエンドポイント
↓
トラフィックポリシーで許可または拒否
↓ 許可されたメール
ルールセット
↓
「インターネットに送信」アクション
↓ 同じワークロードアカウントのIAMロールの権限でSendRawEmail APIを実行
同じワークロードアカウントのAmazon SES
↓
インターネットへ送信
この一連のリソースを、ワークロードアカウントごとに作成します。
ワークロードアカウントA
└─ Mail ManagerとAmazon SESを配置
ワークロードアカウントB
└─ Mail ManagerとAmazon SESを配置
この構成では、以下をワークロードアカウントごとに分けられます。
- SESの検証済みID
- サンドボックス解除状態
- 送信クォータ
- バウンス率
- 苦情率
- SESの送信停止による影響範囲
一方、Mail Manager用VPCエンドポイントと認証済みイングレスエンドポイントも、ワークロードアカウントごとに必要です。
そのため、現在のVPCエンドポイント集約構成は維持できません。また、VPCエンドポイントの利用料金や管理対象も、ワークロードアカウントの数に応じて増加します。
構成案の比較
移行案を整理すると以下です。
| 構成案 | VPCエンドポイント | SESの送信クォータと評価メトリクス | IAM SMTPユーザー | 主な変更 |
|---|---|---|---|---|
| 従来のSES SMTPを継続 | 集約アカウントに配置 | 各ワークロードアカウントで管理 | 継続利用 | 構成変更なし |
| Mail Managerを各ワークロードアカウントに配置 | 各ワークロードアカウントに配置 | 各ワークロードアカウントで管理 | 不要 | ワークロードアカウントごとにMail Manager用VPCエンドポイント、認証済みイングレスエンドポイント、ルールセット、IAMロールなどを作成する |
| Mail Managerを集約アカウントに配置 | 集約アカウントに配置 | 集約アカウントで管理 | 不要 | SESの検証済みID、送信クォータ、評価メトリクスなども集約アカウントで管理する |
現在の構成をそのまま維持する場合は、従来のSES SMTPを継続することになります。
Mail Managerを各ワークロードアカウントに配置すれば、SESの送信クォータや評価メトリクスをワークロードアカウントごとに分離できますが、VPCエンドポイントの集約は維持できません。
Mail Managerを集約アカウントに配置すれば、VPCエンドポイントの集約は維持できますが、SESの送信クォータや評価メトリクスも集約アカウント側で管理することになります。
まとめ
現在の「VPCエンドポイントは集約アカウントに配置し、SESの送信クォータや評価メトリクスはワークロードアカウントごとに分離する」という構成は、Mail Manager SMTPへそのまま移行できません。
移行時は、次のどちらを優先するか判断する必要があります。
- VPCエンドポイントを集約アカウントに維持する
- SESの送信クォータや評価メトリクスをワークロードアカウントごとに分離する
両方を維持する場合は、現時点では従来のSES SMTPを継続するのがよさそうです。
