Lambdaを別アカウントへ移行する方法｜ZIPとAWS SAMの違い・設定漏れの確認

Lambdaを別のAWSアカウントへ移行するときは、移行先に関数を作成し、コードと設定を再配置してから呼び出し元を切り替えます。ここで見落としやすいのが、コードのZIPをコピーしても、メモリやタイムアウトなどの設定までコピーされるわけではないという点です。

この記事ではZIP形式の関数を対象に、デプロイパッケージを使う方法とAWS SAMを使う方法を比較します。コンテナイメージ形式の関数は、ECRのイメージを使う別のデプロイ手順になります。

まず「コードだけ」か「設定も管理する」かを決める

どちらも「旧アカウントの関数をそのまま移動する」操作ではありません。移行先では関数ARNが変わるため、呼び出し元や周辺リソースとの接続まで確認して初めて移行が完了します。

方法1：ZIPを使ってコードを移す

Lambdaコンソールでは、関数コードのZIPとAWS SAMファイルをダウンロードできます。コンソールからのコードダウンロードは未発行の$LATESTが対象です。エイリアスが特定バージョンを指している本番環境では、取得したコードと実際に稼働しているコードが一致するかを先に確認します。操作はZIP形式のLambda関数の公式手順を参照してください。

1. 移行対象のコード、ランタイム、アーキテクチャ、ハンドラーと設定を記録する。
2. 移行元のコードZIPを取得する。
3. 移行先アカウントに実行ロールと関数を作成し、対応するコードをアップロードする。
4. メモリ、タイムアウト、環境変数、レイヤー、VPCなどを設定する。
5. テストイベントで実行し、ログと処理結果を確認する。

この方法は作業の入口が簡単ですが、関数の数が増えると設定漏れを起こしやすくなります。ZIPの配置完了を移行完了とせず、旧環境との設定比較を作業に含めてください。

方法2：AWS SAMでコードと設定を再デプロイする

AWS SAMでは、AWS::Serverless::Functionにメモリやタイムアウトなどの設定を記述できます。テンプレートに含めた設定を移行先でも再現できるため、変更管理や再実行に向いています。既にSAMで管理しているなら、その管理元テンプレートを起点にします。

コンソールから取得したSAMファイルを使う場合も、内容を確認してから移行します。テンプレートに記載されていないリソースや外部の設定まで自動的に移るわけではありません。特に、旧アカウントの実行ロールARNやサブネットIDが残っていないかを確認します。

1. SAMテンプレートと、テンプレートが参照するコードを用意する。
2. 環境ごとに異なる値をパラメーター化し、移行先のリソースへ置き換える。
3. 移行先アカウント・リージョンを確認して、SAM CLIでデプロイする。
4. CloudFormationの変更セットと作成結果を確認する。
5. 関数の実行結果に加えて、イベント連携と権限を確認する。

設定可能な項目はAWS::Serverless::Function、配置方法はSAMのデプロイ手順にまとまっています。

移行前後で照合したい設定

環境変数は関数の設定です。扱いは環境変数の公式資料を確認してください。また、SQSやDynamoDB Streamsなどを使う場合は、イベントソースマッピングも移行対象として整理します。

本番切替は「新旧両方が動く時間」を設計する

新しい関数がテストに成功しても、旧関数をすぐに削除する必要はありません。先に呼び出し元の切替方法と戻し方を決めます。特に更新処理や通知処理では、新旧のトリガーを同時に有効化すると二重処理につながる可能性があります。

切替時には、旧側の起動条件を止めるタイミング、処理中イベントや滞留メッセージの扱い、新側の起動確認を順番に整理します。切替後はエラー数だけでなく、保存されたデータや通知先などの業務結果も確認します。問題があった場合にどこまで戻すかも、データ更新の有無に合わせて決めておきましょう。

関連するアカウント移行

• DynamoDBを別アカウントへ移行する方法
• EFSを別アカウントへ移行する方法