【AWS】SESを別アカウントへ移行する手順と注意点(認証キー差し替えのみで移行できる?)
AWS環境の再編やアカウント分離などを行う際、既存システムで利用しているAmazon SESを別のAWSアカウントへ移行したいケースがあります。
そこで気になるのが、
という点です。
本記事では2026年8月時点で、この点に絞ってAWS公式ドキュメントを参考にしたSESの移行方法を整理します。
1. SESを別AWSアカウントへ移行することは可能?
結論:可能です
ただし、SESの設定を旧AWSアカウントから新AWSアカウントへそのままコピーするような「アカウント間の一括移行」を行うわけではありません。
基本的には、以下の流れになります。
- 新AWSアカウントでSESをセットアップ
- 送信元ドメインを検証
- 必要に応じて本番アクセスを申請
- 新アカウント用の認証情報を作成
- サーバー側の認証情報を新しいものへ変更
- テスト送信
- 問題がなければ旧アカウント側のSESを停止・整理
AWS公式のSESセットアップでも、送信元となるメールアドレスやドメインの検証、本番アクセスの申請などを行ってからSESを利用する流れになっています。
そのため、今回のようなケースでは、
「SESのデータを移行する」というより、「新AWSアカウントでSESを再構築して、アプリケーションの接続先・認証情報を切り替える」
と考えるのが分かりやすいでしょう。
2. 今回の移行イメージ
今回想定するのは、以下のような構成です。
【切り替え前】
【旧AWSアカウント】
│
│ これまで利用
↓
Amazon SES
│
↓
アプリケーション
これを、以下のように切り替えます。
【切り替え後】
【新AWSアカウント】
│
↓
Amazon SES
│
↓
アプリケーション
重要なのは、アプリケーションそのものを変更するのではなく、SESへ接続するための認証情報を新アカウントのものへ変更するという点です。
SMTPでSESを利用している場合はSMTP認証情報、AWS SDKなどからSES APIを利用している場合はAWS認証情報などを切り替えます。
AWS公式でも、SES APIではAWSアクセスキー、SMTPインターフェイスではSMTP認証情報を使用すると説明されています。
3. AWS公式に沿った移行手順
ここからは、最もシンプルな「新AWSアカウントでSESを再構築して切り替える」方法を説明します。
Step 1. 新AWSアカウントで送信元ドメインを検証する
まず、新AWSアカウントのSESで、現在利用している送信元ドメインを登録します。
例えば、現在、
From: noreply@example.com
としてメールを送信している場合、
example.com
を新AWSアカウント側のSESでアイデンティティとして作成します。
SESではドメイン単位でアイデンティティを検証できます。ドメインを検証すると、そのドメイン配下のメールアドレスから送信できるようになります。
■ DNS設定
ドメインアイデンティティを作成すると、SESからDKIM検証用のDNSレコードが提示されます。例えば、
xxxxxxxxxxxx._domainkey.example.com
のようなCNAMEレコードをDNSへ追加します。
Route 53を利用している場合はRoute 53へ、外部のDNSサービスを利用している場合は、そのDNSサービスへ登録します。検証が完了し、Verified になったことを確認します。
なお、SESのアイデンティティはAWSリージョン単位で管理されます。そのため、旧アカウントで ap-northeast-1 を利用している場合は、新アカウントでも利用するリージョンを確認しておきましょう。
AWS公式でも、同じ送信元を複数リージョンで利用する場合、それぞれのリージョンでアイデンティティを作成・検証する必要があると説明されています。
Step 2. 新AWSアカウントのサンドボックスを確認する
新しく作成したAWSアカウントでSESを利用する場合、最初はサンドボックス状態になっていることがあります。サンドボックス状態では、送信先にも制限があります。
そのため、本番システムで利用する場合は、あらかじめSESの Request production access から本番アクセスを申請します。
AWS公式では、申請後24時間以内にAWS Supportから初回回答があるとされています。ただし、追加情報が必要になる場合もあるため、移行当日に申請するのではなく、余裕を持って事前に申請しておくことをおすすめします。
※ サンドボックス解除と送信クォータは別の概念です。
Step 3. 新AWSアカウントで認証情報を準備する
次に、新AWSアカウントでアプリケーションからSESへ接続するための認証情報を用意します。
■ SMTPでSESを利用している場合
SESのSMTPインターフェイスを利用している場合は、新AWSアカウント側でSMTP認証情報を作成します。
旧AWSアカウント
↓
旧SMTP Username
旧SMTP Password
↓ 切り替え
新AWSアカウント
↓
新SMTP Username
新SMTP Password
SMTP認証情報はAWSアクセスキーとは別の認証情報です。AWS公式でも、SES SMTPインターフェイスではSMTP認証情報を使用し、SES APIではAWSアクセスキーを使用すると説明されています。
■ SES API / AWS SDKを利用している場合
AWS SDKなどからSES APIを呼び出している場合は、新AWSアカウント側で利用するIAM権限・認証情報を準備します。(例: Access Key ID / Secret Access Key)
ただし、アプリケーションからメールを送信するだけであれば、必要以上に広いIAM権限を付与するのではなく、必要最小限のSES送信権限にすることをおすすめします。AmazonSESFullAccess のような広範囲の権限を、そのままアプリケーション用IAMユーザーへ付与することを前提にはしないほうがよいでしょう。
Step 4. サーバー側の認証情報を変更する
新AWSアカウント側のSES準備が完了したら、いよいよアプリケーション側を切り替えます。
環境変数でSESの認証情報を管理している場合の例:
# 【旧SES設定】 AWS_ACCESS_KEY_ID=旧アクセスキー AWS_SECRET_ACCESS_KEY=旧シークレットキー # ↓ 以下に変更 # 【新SES設定】 AWS_ACCESS_KEY_ID=新アクセスキー AWS_SECRET_ACCESS_KEY=新シークレットキー
SMTPの場合も同様に変更します:
# 【旧SMTP設定】 SMTP_USERNAME=旧SMTPユーザー SMTP_PASSWORD=旧SMTPパスワード # ↓ 以下に変更 # 【新SMTP設定】 SMTP_USERNAME=新SMTPユーザー SMTP_PASSWORD=新SMTPパスワード
設定変更後、アプリケーションを再起動または設定をリロードします。
Step 5. テストメールを送信する
切り替え後は、実際にメールを送信して確認します。確認ポイントは以下です。
- メールが正常に送信される
- 宛先にメールが届く
- Fromアドレスが想定どおり
- DKIMなどの認証が正常
- アプリケーション側にSESのエラーが出ていない
- 新AWSアカウント側のSES送信数が増えている
特に重要なのは、「メールが届いた」だけで移行完了と判断しないことです。新AWSアカウント側のSESを経由して送信されていることをコンソール側からもしっかり確認しましょう。
4. 移行時に注意したいポイント
① SESのリージョン
SESはリージョン単位で設定されます。例えば旧アカウントが ap-northeast-1 でSESを利用していた場合、新アカウントでも同じリージョンを利用するのか確認します。SESの送信クォータもAWSリージョンごとに設定されています。
そのため、アカウントだけでなく、「どのAWSアカウントの、どのリージョンのSESを利用しているか」を確認してから移行作業を始めるのがおすすめです。
② 送信クォータは引き継がれない
SESの送信クォータはAWSリージョンごとに設定されています。
例えば旧アカウントで「24時間あたりの送信数:1,000,000 / 送信レート:100/秒」だったとしても、新AWSアカウントで自動的に同じ値になるとは限りません。新アカウント側の送信量に対して十分なクォータが確保されているか、事前に確認しておきましょう。
③ DKIMなどのDNS設定
旧アカウントから新アカウントへ変更する場合、新アカウント側でも送信元ドメインのアイデンティティ検証が必要です。そのため、移行前にDNS設定を確認しておきましょう。また、既存環境でカスタムMAIL FROMなどを利用している場合は、それらの設定も新アカウント側で確認が必要です。
④ Configuration Setを利用している場合
SESでConfiguration Setを利用している場合は注意が必要です。(例: SES → Configuration Set → Event Destination → CloudWatch / SNS / Firehose)
このような連携構成を作っている場合、Configuration SetやEvent Destination、連携先の設定についても新AWSアカウント側で再構築・確認が必要です。単純にSMTP認証情報だけを変更すればよいとは限りません。
⑤ Dedicated IPを利用している場合
Dedicated IP(専用IP)を利用している場合は、通常のSES移行よりも確認事項が増えます。新AWSアカウント側でDedicated IPの構成を改めて用意する必要があるため、「旧アカウントで利用していた送信環境が、そのまま新アカウントへ引き継がれる」とは考えないほうがよいでしょう。大量配信を行っている環境では、IPや送信量の変更によるメール到達性への影響も考慮する必要があります。
5. 移行当日の作業を最小限にするには?
今回のようなSESアカウント移行では、当日にすべての設定を行うのではなく、事前に新アカウント側の準備を終わらせておくことが重要です。理想的には以下の流れにします。
【事前準備】
新AWSアカウント
↓
SES設定
↓
ドメイン検証
↓
本番アクセス申請
↓
送信クォータ確認
↓
SMTP/API認証情報作成
↓
テスト
【移行当日】
サーバー設定変更
↓
アプリケーション再起動
↓
テストメール送信
↓
新AWSアカウントからの送信を確認
このようにしておけば、移行当日の作業を「アプリケーション側の認証情報変更+テスト」だけに絞ることができます。
6. 旧AWSアカウントのSESはすぐ削除しない
新アカウントからの送信が確認できたからといって、すぐに旧アカウントのSES設定を削除する必要はありません。まずは以下を確認します。
- アプリケーションから正常に送信できる
- 定期バッチから正常に送信できる
- 問い合わせフォームなどから正常に送信できる
- バウンスや苦情などの処理が正常
- 新アカウント側のSES送信状況に問題がない
すべての挙動に問題がないことを確認した後、旧アカウント側の不要なIAM認証情報やSES設定を整理しましょう。
まとめ
SESを別AWSアカウントへ移行することは可能です。
ただし、旧AWSアカウントのSES設定をそのまま新AWSアカウントへ移すわけではなく、新AWSアカウントでSESを再構築し、サーバー側の認証情報を切り替えるという手順になります。
💡 ポイントの再確認
「SESの移行=認証キーを変更するだけ」ではありませんが、事前準備として新アカウント側のSES構築(ドメイン検証や本番申請など)を終わらせておけば、当日の作業は認証情報の変更を中心とした最小限の作業に抑えられます。
また、SESはリージョン単位でアイデンティティや送信クォータなどが管理されるため、AWSアカウントだけでなく利用リージョンも移行前に確認することをおすすめします。
■ 参考:AWS公式ドキュメント
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK