レイヤー難易度 標準無料
ある組織では10個のLambda関数がすべて同じサードパーティのロギングライブラリと共通の社内ユーティリティモジュールに依存している。現状は各関数のデプロイパッケージにこれらのコードを個別に同梱しており、ライブラリのバージョンアップのたびに10個すべての関数を再デプロイする必要があり運用負荷が高い。この状況を改善する設計として最も適切なものを選べ。（単一選択）
- Aロギングライブラリと社内ユーティリティを1つのLambdaレイヤーとして発行し、10個の関数それぞれにアタッチする。更新時はレイヤーの新バージョンを発行し、各関数のレイヤー参照を差し替える
- B10個の関数を1つの巨大なモノリシック関数に統合し、共通コードの重複自体をなくす
- C共通コードをS3バケットに配置し、各関数がハンドラー実行のたびにS3からダウンロードしてメモリ上に展開する
- D各関数のデプロイパッケージに共通ライブラリを同梱したまま、CI/CDパイプラインで10関数を並列デプロイして更新時間を短縮する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
Lambdaレイヤーは、複数の関数間で共有したいライブラリ・カスタムランタイム・共通コードを
関数本体のデプロイパッケージとは別の.zipアーカイブとしてパッケージ化し、複数の関数にアタッチできる仕組みである。
- 共通のロギングライブラリと社内ユーティリティを1つのレイヤーとして発行し、10個の関数それぞれにそのレイヤーをアタッチする。
- ライブラリを更新する際はレイヤーの新しいバージョンを発行し、各関数の設定でアタッチするレイヤーのバージョンを更新するだけでよく、 関数本体のコードやデプロイパッケージ自体は変更不要（関数コードと依存関係を分離できる）。
- 関数は最大5つのレイヤーをアタッチでき、関数コード＋全レイヤーの展開後の合計サイズは250MB以内に収める必要がある。
- B関数の責務が混在しコールドスタート時間や単一障害点のリスクが増大する。関数分割の設計原則に反し、共通ライブラリの共有問題の直接的な解決にもならない。
- C呼び出しごとにS3からのダウンロードが発生しレイテンシとコストが増える。レイヤーであればデプロイ時に展開済みのため実行時ダウンロードは不要。
- Dデプロイ時間は短縮できても、共通コードの重複同梱とバージョン管理の煩雑さという根本課題は解決していない。
ひっかけ： 「共通コードをS3に置いて関数から都度ダウンロードする（C）」は実行のたびにレイテンシとAPI呼び出しコストが発生し非効率。
レイヤーはデプロイ時に関数の実行環境の
/opt配下へ展開され、実行時には追加のダウンロードなしで参照できる点が本質的な違い。AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）