あるチームが同一ランタイム（Python 3.12）のLambda関数を複数本デプロイしており、各関数がそれぞれ pandas・numpy などの共通ライブラリを個別にデプロイパッケージに含めている。その結果、デプロイパッケージのサイズが大きくなりすぎてLambdaコンソールでのインラインコード編集ができなくなってしまった。コードを変更せずに、共通ライブラリの管理・更新を一元化して各関数のデプロイパッケージを小さくする方法として最も適切なものはどれか。
- A. ECRにカスタムコンテナイメージとして共通ライブラリをビルドし、全関数でイメージを共有する
- B. 共通ライブラリをElastic File System（EFS）にインストールし、全関数からNFSマウントして利用する
- C. 共通ライブラリをLambdaレイヤーとしてパッケージ化し、各関数にアタッチする
- D. 全関数を1つの巨大なLambda関数に統合し、ハンドラ引数で処理を振り分ける
解答と解説を見る
正解: C
Lambdaレイヤーは、ライブラリ・カスタムランタイム・設定ファイルなどの共通コンポーネントをZIPアーカイブとしてパッケージ化し、複数のLambda関数にアタッチできる仕組みである。1つのレイヤーを更新すれば、それをアタッチしている全関数がアップデートされた依存関係を使えるようになり、管理の一元化が実現できる。選択肢Dの関数統合は管理・テスト・デプロイが複雑化し、責務分離の観点からも悪手である。選択肢BのEFSマウントは大規模なMLモデルファイル等を共有する際には有効だが、単なるPythonライブラリの共有にはオーバーエンジニアリングであり、VPCアタッチメントが必要になるためコールドスタートも悪化する。選択肢AのECRコンテナイメージ共有はコンテナベースデプロイには有効だが、既存のZIPデプロイ関数でイメージを共有することはできず、要件の「コードを変更せず」に反する。
📚 関連サービスの解説: AWS Lambda