コンテナイメージを使用した Lambda 関数の作成
AWS Lambda 関数のコードは、スクリプトまたはコンパイルされたプログラム、さらにそれらの依存関係で構成されます。デプロイパッケージを使用して、Lambda に関数コードをデプロイします。Lambda は、コンテナイメージと .zip ファイルアーカイブの 2 種類のデプロイパッケージをサポートします。
Lambda 関数のコンテナイメージを構築するには 3 つの方法があります。
-
AWS ベースイメージには、言語ランタイム、Lambda と関数コード間のやり取りを管理するランタイムインターフェイスクライアント、ローカルテスト用のランタイムインターフェイスエミュレーターがプリロードされています。
-
AWS OS 専用ベースイメージ
には、Amazon Linux ディストリビューションおよびランタイムインターフェイスエミュレータ が含まれています。これらのイメージは、Go や Rust などのコンパイル済み言語や、Lambda がベースイメージを提供していない言語または言語バージョン (Node.js 19 など) のコンテナイメージの作成によく使用されます。OS 専用のベースイメージを使用してカスタムランタイムを実装することもできます。イメージに Lambda との互換性を持たせるには、当該言語のランタイムインターフェイスクライアントをイメージに含める必要があります。 -
Alpine Linux や Debian など、別のコンテナレジストリの代替ベースイメージを使用することもできます。組織が作成したカスタムイメージを使用することもできます。イメージに Lambda との互換性を持たせるには、当該言語のランタイムインターフェイスクライアントをイメージに含める必要があります。
ヒント
Lambda コンテナ関数がアクティブになるまでの時間を短縮するには、「Docker ドキュメント」の「マルチステージビルドを使用する
コンテナイメージから Lambda 関数を作成するには、イメージをローカルでビルドして、Amazon Elastic Container Registry (Amazon ECR) リポジトリにアップロードします。次に、関数の作成時にリポジトリ URI を指定します。Amazon ECR リポジトリは Lambda 関数と同じ AWS リージョン に配置されている必要があります。イメージが Lambda 関数と同じリージョンに配置されていれば、別の AWS アカウントのイメージを使用して関数を作成することができます。詳細については、「 Amazon ECR クロスアカウント許可」を参照してください。
注記
Lambda は、コンテナイメージの Amazon ECR FIPS エンドポイントに対応していません。リポジトリ URI に ecr-fips
が含まれていれば、現在 FIPS エンドポイントを使用していることになります。例えば、111122223333.dkr.ecr-fips.us-east-1.amazonaws.com
などです。
このページでは、Lambda 互換のコンテナイメージを作成するためのベースイメージタイプと要件について説明します。
注記
既存の関数のデプロイパッケージタイプ (.zip またはコンテナイメージ) を変更することはできません。例えば、既存のコンテナイメージ関数を、.zip ファイルアーカイブを使用するように変換することはできません。この場合は、新しい関数を作成する必要があります。
トピック
要件
「AWS Command Line Interface (AWS CLI) バージョン 2」および「Docker CLI
-
コンテナイメージには、カスタムランタイムに Lambda ランタイム API を使用する が実装されている必要があります。AWS からの、オープンソースのランタイムインターフェイスクライアントには、この API が実装されています。ランタイムインターフェイスクライアントを必要なベースイメージに追加することで、Lambda と互換性を持たせることができます。
-
コンテナイメージは、読み取り専用のファイルシステム上で実行可能である必要があります。機能コードは、512 MB から 10,240 MB の間で、1 MB 刻みで書き込み可能な
/tmp
ディレクトリにアクセスできます。 -
デフォルトの Lambda ユーザーは、関数コードを実行するために必要なすべてのファイルを読み取ることができる必要があります。Lambda は、最小特権のアクセス許可を持つデフォルトの Linux ユーザーを定義することで、セキュリティのベストプラクティスに従います。つまり、Dockerfile に USER
を指定する必要はありません。ご自身のアプリケーションコードが、外部の Linux ユーザーによる実行が制限されているファイルに依存していないことを確認します。 -
Lambda では、Linux ベースのコンテナイメージのみがサポートされます。
-
Lambda は、マルチアーキテクチャのベースイメージを提供します。ただし、関数用に構築するイメージは、アーキテクチャの 1 つだけをターゲットにする必要があります。Lambda は、マルチアーキテクチャのコンテナイメージを使用する関数をサポートしません。
Lambda の AWS ベースイメージを使用する
Lambda に AWS ベースイメージ
AWS では、Lambda 用の AWS ベースイメージの更新を定期的に実施しています。Dockerfile の FROM プロパティにイメージ名が含まれている場合、Docker クライアントは Amazon ECR リポジトリ
Node.js 20、Python 3.12、Java 21、.NET 8、Ruby 3.3 以降のベースイメージは、Amazon Linux 2023 の最小コンテナイメージに基づいています。以前のベースイメージでは Amazon Linux 2 が使用されています。AL2023 ランタイムには、デプロイのフットプリントが小さいことや、glibc
などのライブラリのバージョンが更新されていることなど、Amazon Linux 2 に比べていくつかの利点があります。
AL2023 ベースのイメージでは、Amazon Linux 2 のデフォルトのパッケージマネージャである yum
の代わりに microdnf
(dnf
としてシンボリックリンク) がパッケージマネージャとして使用されています。microdnf
は dnf
のスタンドアロン実装です。AL2023 ベースのイメージに含まれるパッケージのリストについては、「Comparing packages installed on Amazon Linux 2023 Container Images」の「Minimal Container」列を参照してください。AL2023 と Amazon Linux 2 の違いの詳細については、AWS コンピューティングブログの「Introducing the Amazon Linux 2023 runtime for AWS Lambda
注記
AWS Serverless Application Model (AWS SAM) を含む AL2023 ベースのイメージをローカルで実行するには、Docker バージョン 20.10.10 以降を使用する必要があります。
AWS ベースイメージを使用してコンテナイメージを構築するには、お好みの言語での手順を選択してください。
AWS の OS 専用ベースイメージを使用する
AWS OS 専用ベースイメージ
タグ | ランタイム | オペレーティングシステム | Dockerfile | 廃止 |
---|---|---|---|---|
al2023 |
OS 専用ランタイム | Amazon Linux 2023 | GitHub の OS 専用ランタイムの Dockerfile |
|
al2 |
OS 専用ランタイム | Amazon Linux 2 | GitHub の OS 専用ランタイムの Dockerfile |
Amazon Elastic コンテナレジストリ公開ギャラリー: gallery.ecr.aws/lambda/provided
非 AWS ベースイメージを使用する
Lambda では、次のいずれかのイメージマニフェストの形式に準拠するイメージをサポートしています。
Docker Image Manifest V2 Schema 2 (Docker バージョン 1.10 以降で使用)
Open Container Initiative (OCI) 仕様 (v1.0.0 以降)
Lambda は、すべてのレイヤーを含めて最大 10 GB の非圧縮のイメージサイズをサポートします。
注記
イメージに Lambda との互換性を持たせるには、当該言語のランタイムインターフェイスクライアントをイメージに含める必要があります。
ランタイムインターフェイスクライアント
OS 専用ベースイメージまたは代替のベースイメージを使用する場合、イメージにランタイムインターフェイスクライアントを含める必要があります。ランタイムインターフェイスクライアントは、Lambda と関数コード間のやり取りを管理する カスタムランタイムに Lambda ランタイム API を使用する を拡張する必要があります。AWS では、オープンソースのランタイムインターフェイスクライアントを次の言語で提供しています。
使用している言語に AWS の提供するランタイムインターフェイスクライアントがない場合、独自のランタイムインターフェイスクライアントを作成する必要があります。
Amazon ECR のアクセス許可
コンテナイメージから Lambda 関数を作成する前に、そのイメージをローカルでビルドし、 Amazon ECR リポジトリにアップロードする必要があります。関数の作成時に、Amazon ECR リポジトリ URI を指定します。
関数を作成するユーザーまたはロールのアクセス許可に、GetRepositoryPolicy
および SetRepositoryPolicy
が含まれていることを確認してください。
例えば、IAM コンソールを使用して、次のポリシーでロールを作成します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "ecr:SetRepositoryPolicy", "ecr:GetRepositoryPolicy" ], "Resource": "arn:aws:ecr:
us-east-1
:111122223333
:repository/hello-world
" } ] }
Amazon ECR リポジトリポリシー
Amazon ECR のコンテナイメージと同じアカウント内の関数の場合、Amazon ECR リポジトリポリシーに ecr:BatchGetImage
および ecr:GetDownloadUrlForLayer
のアクセス許可を追加できます。次の例は、最小ポリシーを示しています。
{ "Sid": "LambdaECRImageRetrievalPolicy", "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": [ "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer" ] }
Amazon ECR のリポジトリへのアクセス許可について、詳しくは「Amazon Elastic Container Registry ユーザーガイド」の「プライベートリポジトリポリシー」を参照してください。
Amazon ECR リポジトリにこれらの権限が含まれていない場合、Lambda は ecr:BatchGetImage
および ecr:GetDownloadUrlForLayer
をコンテナイメージリポジトリのアクセス許可に追加します。Lambda は、Lambda を呼び出すプリンシパルに ecr:getRepositoryPolicy
および ecr:setRepositoryPolicy
のアクセス許可がある場合にのみ、これらのアクセス許可を追加できます。
Amazon ECR リポジトリへのアクセス許可を表示または編集するには、「Amazon Elastic Container Registry ユーザーガイド」の「プライベートリポジトリポリシーステートメントの設定」を参照してください。
Amazon ECR クロスアカウント許可
同じリージョン内の別のアカウントで、アカウントが所有するコンテナイメージを使用する関数を作成できます。次の例では、Amazon ECR リポジトリへのアクセス許可ポリシーで、アカウント番号 123456789012 にアクセス権を付与するために、次のステートメントが必要です。
CrossAccountPermission — アカウント 123456789012 が、この ECR リポジトリからイメージを使用する Lambda 関数を作成および更新できるようにします。
LambdaECRImageCrossAccountRetrievalPolicy – Lambda は、関数が長期間呼び出されない場合、最終的に関数の状態を非アクティブに設定します。このステートメントは、123456789012 が所有する関数に代わって Lambda が最適化およびキャッシュのためにコンテナイメージを取得できるようにするために必要です。
例 クロスアカウント許可をリポジトリに追加する
{ "Version": "2012-10-17", "Statement": [ { "Sid": "CrossAccountPermission", "Effect": "Allow", "Action": [ "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer" ], "Principal": { "AWS": "arn:aws:iam::
123456789012
:root" } }, { "Sid": "LambdaECRImageCrossAccountRetrievalPolicy", "Effect": "Allow", "Action": [ "ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer" ], "Principal": { "Service": "lambda.amazonaws.com" }, "Condition": { "StringLike": { "aws:sourceARN": "arn:aws:lambda:us-east-1
:123456789012
:function:*" } } } ] }
複数のアカウントにアクセス権を付与するには、CrossAccountPermission
ポリシーの [Principal] (プリンシパル) リストと LambdaECRImageCrossAccountRetrievalPolicy
の [Condition] (条件) 評価リストにアカウント ID を追加します。
AWS Organization で複数のアカウントを扱う場合は、ECR の許可ポリシーで各アカウント ID を列挙することをお勧めします。このアプローチは、IAM ポリシーで狭い範囲の許可を設定するという AWS セキュリティのベストプラクティスに沿ったものです。
Lambda のアクセス許可に加えて、関数を作成するユーザーまたはロールには、BatchGetImage
および GetDownloadUrlForLayer
アクセス許可も必要です。
関数のライフサイクル
新規または更新済みのコンテナイメージをアップロードすると、Lambda は、関数が呼び出しを処理する前にイメージを最適化します。最適化プロセスには数秒かかる場合があります。この関数は、プロセスが完了するまで Pending
状態のままです。その後、関数は Active
状態に移行します。Pending
状態のときに関数を呼び出すことはできますが、関数に対する他のオペレーションは失敗します。イメージ更新の進行中に発生した呼び出しは、以前のイメージのコードを実行します。
数週間にわたって関数が呼び出されない場合、Lambda は最適化されたバージョンを再利用し、関数は Inactive
状態に移行します。関数を再度アクティブにするには、関数を呼び出す必要があります。Lambda は最初の呼び出しを拒否し、関数は Lambda がイメージを再最適化するまで Pending
状態に入ります。その後、関数は Active
状態に戻ります。
Lambda は、Amazon ECR リポジトリから関連するコンテナイメージを定期的に取得します。対応するコンテナイメージが Amazon ECR に存在しなくなった場合、またはアクセス許可が失効した場合、関数は Failed
状態になり、Lambda が関数呼び出しに対して失敗を返します。
Lambda API を使用して、関数の状態に関する情報を取得できます。詳細については、「Lambda 関数の状態」を参照してください。