IT 技書の森

Lambda Layer

Lambda 関数間で共有ライブラリやカスタムランタイムを再利用する仕組み

AWSサーバーレス

Lambda Layer とは

Lambda Layer は、Lambda 関数間で共有ライブラリ、カスタムランタイム、設定ファイルを再利用する仕組みである。共通の依存関係を Layer として切り出すことで、デプロイパッケージのサイズを削減し、複数の関数で同じライブラリバージョンを統一できる。

Layer の仕組み

Layer は ZIP アーカイブとして Lambda にアップロードされ、関数の実行環境の /opt ディレクトリに展開される。

/opt/
├── nodejs/           ← Node.js の Layer パス
│   └── node_modules/
│       ├── sharp/
│       └── @aws-sdk/
├── python/           ← Python の Layer パス
│   └── lib/python3.12/site-packages/
└── bin/              ← カスタムバイナリ
    └── ffmpeg

Node.js の場合、/opt/nodejs/node_modules が自動的にモジュール解決パスに追加されるため、関数コードから require('sharp') で参照できる。

Layer を使うべきケース

ケース 理由
ネイティブバイナリ (sharp, ffmpeg) ビルドが重く、複数関数で共有したい
カスタムランタイム Deno、Bun などの非標準ランタイム
共通ユーティリティ 認証、ログ、バリデーションの共通コード
大きな依存関係 デプロイパッケージの 250MB 制限を回避

Layer を使うべきでないケース

  • 関数ごとに異なるバージョンが必要な依存関係
  • 頻繁に更新される依存関係 (Layer の更新は全関数に影響)
  • 小さな依存関係 (Layer のオーバーヘッドに見合わない)

制約

  • 1 関数に最大 5 Layer まで
  • Layer を含む展開後の合計サイズは 250MB まで
  • Layer の更新はバージョニングされ、関数は特定バージョンを参照する

よくある落とし穴

Layer のバージョン管理

Layer を更新しても、既存の関数は古いバージョンを参照し続ける。Layer を更新したら、参照する全関数も再デプロイが必要だ。SAM の !Ref を使えば、Layer の最新バージョンが自動的に参照される。

コールドスタートへの影響

Layer のサイズが大きいと、コールドスタート時の展開に時間がかかる。不要なファイルを含めないよう、Layer の内容を最小限にする。

基礎から学ぶなら関連書籍が手がかりになる。

関連用語