# コンテナイメージを使用した Lambda 関数の作成
AWS Lambda 関数のコードは、スクリプトまたはコンパイルされたプログラム、さらにそれらの依存関係で構成されます。*デプロイパッケージ*を使用して、Lambda に関数コードをデプロイします。Lambda は、コンテナイメージと .zip ファイルアーカイブの 2 種類のデプロイパッケージをサポートします。
Lambda 関数のコンテナイメージを構築するには 3 つの方法があります。
+ [Lambda の AWS ベースイメージを使用する](#runtimes-images-lp)
[AWS ベースイメージ](#runtimes-images-lp)には、言語ランタイム、Lambda と関数コード間のやり取りを管理するランタイムインターフェースクライアント、ローカルテスト用のランタイムインターフェースエミュレーターがあらかじめロードされています。
+ [AWS の OS 専用ベースイメージを使用する](#runtimes-images-provided)
[AWS OS 専用ベースイメージ](https://gallery.ecr.aws/lambda/provided)には、Amazon Linux ディストリビューションおよび[ランタイムインターフェイスエミュレータ](https://github.com/aws/aws-lambda-runtime-interface-emulator/)が含まれています。これらのイメージは、[Go](go-image.md#go-image-provided) や [Rust](lambda-rust.md) などのコンパイル済み言語や、Lambda がベースイメージを提供していない言語または言語バージョン (Node.js 19 など) のコンテナイメージの作成によく使用されます。OS 専用のベースイメージを使用して[カスタムランタイム](runtimes-custom.md)を実装することもできます。イメージに Lambda との互換性を持たせるには、当該言語の[ランタイムインターフェイスクライアント](#images-ric)をイメージに含める必要があります。
+ [非 AWS ベースイメージを使用する](#images-types)
Alpine Linux や Debian など、別のコンテナレジストリの代替ベースイメージを使用することもできます。組織が作成したカスタムイメージを使用することもできます。イメージに Lambda との互換性を持たせるには、当該言語の[ランタイムインターフェイスクライアント](#images-ric)をイメージに含める必要があります。
**ヒント**
Lambda コンテナ関数がアクティブになるまでの時間を短縮するには、「Docker ドキュメント」の「[マルチステージビルドを使用する](https://docs.docker.com/build/building/multi-stage/)」を参照してください。効率的なコンテナイメージを構築するには、「[Dockerfiles を記述するためのベストプラクティス](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/)」に従ってください。
コンテナイメージから Lambda 関数を作成するには、イメージをローカルでビルドして、Amazon Elastic Container Registry (Amazon ECR) リポジトリにアップロードします。[AWS Marketplace](https://docs.aws.amazon.com/marketplace/latest/userguide/container-based-products.html) 販売者が提供するコンテナイメージを使用している場合、まずイメージをプライベート Amazon ECR リポジトリにクローンする必要があります。次に、関数の作成時にリポジトリ URI を指定します。Amazon ECR リポジトリは Lambda 関数と同じ AWS リージョン に配置されている必要があります。イメージが Lambda 関数と同じリージョンに配置されていれば、別の AWS アカウントのイメージを使用して関数を作成することができます。詳細については、「[Amazon ECR クロスアカウント許可](#configuration-images-xaccount-permissions)」を参照してください。
**注記**
Lambda は、コンテナイメージの Amazon ECR FIPS エンドポイントに対応していません。リポジトリ URI に `ecr-fips` が含まれていれば、現在 FIPS エンドポイントを使用していることになります。例えば、`111122223333.dkr.ecr-fips.us-east-1.amazonaws.com` などです。
このページでは、Lambda 互換のコンテナイメージを作成するためのベースイメージタイプと要件について説明します。
**注記**
既存の関数の[デプロイパッケージタイプ](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-PackageType) (.zip またはコンテナイメージ) を変更することはできません。例えば、既存のコンテナイメージ関数を、.zip ファイルアーカイブを使用するように変換することはできません。この場合は、新しい関数を作成する必要があります。
**Topics**
+ [要件](#images-reqs)
+ [Lambda の AWS ベースイメージを使用する](#runtimes-images-lp)
+ [AWS の OS 専用ベースイメージを使用する](#runtimes-images-provided)
+ [非 AWS ベースイメージを使用する](#images-types)
+ [ランタイムインターフェイスクライアント](#images-ric)
+ [Amazon ECR のアクセス許可](#gettingstarted-images-permissions)
+ [関数のライフサイクル](#images-lifecycle)
## 要件
[AWS CLIバージョン 2](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) および [Docker CLI](https://docs.docker.com/get-docker) をインストールします。さらに、次の各要件にも注意してください。
+ コンテナイメージには、[カスタムランタイムに Lambda ランタイム API を使用する](runtimes-api.md) が実装されている必要があります。AWS からの、オープンソースの[ランタイムインターフェイスクライアント](#images-ric)には、この API が実装されています。ランタイムインターフェイスクライアントを必要なベースイメージに追加することで、Lambda と互換性を持たせることができます。
+ コンテナイメージは、読み取り専用のファイルシステム上で実行可能である必要があります。機能コードは、512 MB から 10,240 MB の間で、1 MB 刻みで書き込み可能な `/tmp` ディレクトリにアクセスできます。
+ デフォルトの Lambda ユーザーは、関数コードを実行するために必要なすべてのファイルを読み取ることができる必要があります。Lambda は、最小特権のアクセス許可を持つデフォルトの Linux ユーザーを定義することで、セキュリティのベストプラクティスに従います。つまり、Dockerfile に [USER](https://docs.docker.com/reference/dockerfile/#user) を指定する必要はありません。ご自身のアプリケーションコードが、外部の Linux ユーザーによる実行が制限されているファイルに依存していないことを確認します。
+ Lambda では、Linux ベースのコンテナイメージのみがサポートされます。
+ Lambda は、マルチアーキテクチャのベースイメージを提供します。ただし、関数用に構築するイメージは、アーキテクチャの 1 つだけをターゲットにする必要があります。Lambda は、マルチアーキテクチャのコンテナイメージを使用する関数をサポートしません。
## Lambda の AWS ベースイメージを使用する
Lambda に [AWS ベースイメージ](https://gallery.ecr.aws/lambda/)の 1 つを使用して、関数コードのコンテナイメージを構築します。ベースイメージには、Lambda でコンテナイメージを実行するために必要な言語ランタイムおよびその他のコンポーネントがプリロードされます。関数コードと依存関係をベースイメージに追加し、コンテナイメージとしてパッケージ化します。
AWS では、Lambda 用の AWS ベースイメージの更新を定期的に実施しています。Dockerfile の FROM プロパティにイメージ名が含まれている場合、Docker クライアントは [Amazon ECR リポジトリ](https://gallery.ecr.aws/lambda/)から最新バージョンのイメージを取り出します。更新されたベースイメージを使用するには、コンテナイメージを再ビルドして、[関数のコードを更新](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/update-function-code.html)する必要があります。
Node.js 20、Python 3.12、Java 21、.NET 8、Ruby 3.3 以降のベースイメージは、[Amazon Linux 2023 の最小コンテナイメージ](https://docs.aws.amazon.com/linux/al2023/ug/minimal-container.html)に基づいています。以前のベースイメージでは 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](https://docs.aws.amazon.com/linux/al2023/ug/al2023-container-image-types.html)」の「**Minimal Container**」列を参照してください。AL2023 と Amazon Linux 2 の違いの詳細については、AWS コンピューティングブログの「[Introducing the Amazon Linux 2023 runtime for AWS Lambda](https://aws.amazon.com/blogs/compute/introducing-the-amazon-linux-2023-runtime-for-aws-lambda/)」を参照してください。
**注記**
AWS Serverless Application Model (AWS SAM) を含む AL2023 ベースのイメージをローカルで実行するには、Docker バージョン 20.10.10 以降を使用する必要があります。
AWS ベースイメージを使用してコンテナイメージを構築するには、お好みの言語での手順を選択してください。
+ [Node.js](nodejs-image.md#nodejs-image-instructions)
+ [TypeScript](typescript-image.md#base-image-typescript) (Node.js ベースイメージを使用)
+ [Python](python-image.md#python-image-instructions)
+ [Java](java-image.md#java-image-instructions)
+ [Go](go-image.md#go-image-provided)
+ [.NET](csharp-image.md#csharp-image-instructions)
+ [Ruby](ruby-image.md#ruby-image-instructions)
## AWS の OS 専用ベースイメージを使用する
[AWS OS 専用ベースイメージ](https://gallery.ecr.aws/lambda/provided)には、Amazon Linux ディストリビューションおよび[ランタイムインターフェイスエミュレータ](https://github.com/aws/aws-lambda-runtime-interface-emulator/)が含まれています。これらのイメージは、[Go](go-image.md#go-image-provided) や [Rust](lambda-rust.md) などのコンパイル済み言語や、Lambda がベースイメージを提供していない言語または言語バージョン (Node.js 19 など) のコンテナイメージの作成によく使用されます。OS 専用のベースイメージを使用して[カスタムランタイム](runtimes-custom.md)を実装することもできます。イメージに Lambda との互換性を持たせるには、当該言語の[ランタイムインターフェイスクライアント](#images-ric)をイメージに含める必要があります。
| タグ | ランタイム | オペレーティングシステム | Dockerfile | 非推奨 |
| --- | --- | --- | --- | --- |
| al2023 | OS 専用ランタイム | Amazon Linux 2023 | [GitHub の OS 専用ランタイムの Dockerfile](https://github.com/aws/aws-lambda-base-images/blob/provided.al2023/Dockerfile.provided.al2023) | 2029 年 6 月 30 日 |
| al2 | OS 専用ランタイム | Amazon Linux 2 | [GitHub の OS 専用ランタイムの Dockerfile](https://github.com/aws/aws-lambda-base-images/blob/provided.al2/Dockerfile.provided.al2) | 2026 年 7 月 31 日 |
Amazon Elastic コンテナレジストリ公開ギャラリー: [gallery.ecr.aws/lambda/provided](https://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 との互換性を持たせるには、当該言語の[ランタイムインターフェイスクライアント](#images-ric)をイメージに含める必要があります。
最適なパフォーマンスを得るには、イメージマニフェストのサイズを 25,400 バイト未満に維持します。イメージマニフェストのサイズを減らすには、イメージ内のレイヤーの数を最小限に抑え、注釈を減らします。
## ランタイムインターフェイスクライアント
[OS 専用ベースイメージ](#runtimes-images-provided)または代替のベースイメージを使用する場合、イメージにランタイムインターフェイスクライアントを含める必要があります。ランタイムインターフェイスクライアントは、Lambda と関数コード間のやり取りを管理する [カスタムランタイムに Lambda ランタイム API を使用する](runtimes-api.md) を拡張する必要があります。AWS では、オープンソースのランタイムインターフェイスクライアントを次の言語で提供しています。
+ [Node.js](nodejs-image.md#nodejs-image-clients)
+ [Python](python-image.md#python-image-clients)
+ [Java](java-image.md#java-image-clients)
+ [.NET](csharp-image.md#csharp-image-clients)
+ [Go](go-image.md#go-image-clients)
+ [Ruby](ruby-image.md#ruby-image-clients)
+ [Rust](lambda-rust.md) –
使用している言語に AWS の提供するランタイムインターフェイスクライアントがない場合、独自のランタイムインターフェイスクライアントを作成する必要があります。
## Amazon ECR のアクセス許可
コンテナイメージから Lambda 関数を作成する前に、そのイメージをローカルでビルドし、 Amazon ECR リポジトリにアップロードする必要があります。関数の作成時に、Amazon ECR リポジトリ URI を指定します。
関数を作成するユーザーまたはロールのアクセス許可に、`GetRepositoryPolicy`、`SetRepositoryPolicy`、`BatchGetImage`、`GetDownloadUrlForLayer` が含まれていることを確認してください。
例えば、IAM コンソールを使用して、次のポリシーでロールを作成します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"ecr:SetRepositoryPolicy",
"ecr:GetRepositoryPolicy",
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"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 のユーザーガイド*」の「[プライベートリポジトリポリシー](https://docs.aws.amazon.com/AmazonECR/latest/userguide/repository-policies.html)」を参照してください。
Amazon ECR リポジトリにこれらのアクセス許可が含まれていない場合、Lambda はその許可を自動的に追加しようとします。Lambda は、Lambda を呼び出すプリンシパルに `ecr:getRepositoryPolicy` および `ecr:setRepositoryPolicy` のアクセス許可がある場合にのみ、アクセス許可を追加できます。
Amazon ECR リポジトリへのアクセス許可を表示または編集するには、「*Amazon Elastic Container Registry のユーザーガイド*」の「[プライベートリポジトリのポリシーステートメントの設定](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html)」の手順に従ってください。
#### Amazon ECR クロスアカウント許可
同じリージョン内の別のアカウントで、アカウントが所有するコンテナイメージを使用する関数を作成できます。次の例では、[Amazon ECR リポジトリへのアクセス許可ポリシー](https://docs.aws.amazon.com/AmazonECR/latest/userguide/set-repository-policy.html)で、アカウント番号 123456789012 にアクセス権を付与するために、次のステートメントが必要です。
+ **CrossAccountPermission** — アカウント 123456789012 が、この ECR リポジトリからイメージを使用する Lambda 関数を作成および更新できるようにします。
+ **LambdaECRImageCrossAccountRetrievalPolicy** – Lambda は、関数が長期間呼び出されない場合、最終的に関数の状態を非アクティブに設定します。このステートメントは、123456789012 が所有する関数に代わって Lambda が最適化およびキャッシュのためにコンテナイメージを取得できるようにするために必要です。
**Example クロスアカウント許可をリポジトリに追加する**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "CrossAccountPermission",
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Resource": "arn:aws:ecr:us-east-1:123456789012:repository/example-lambda-repository"
},
{
"Sid": "LambdaECRImageCrossAccountRetrievalPolicy",
"Effect": "Allow",
"Action": [
"ecr:BatchGetImage",
"ecr:GetDownloadUrlForLayer"
],
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Condition": {
"ArnLike": {
"aws:sourceARN": "arn:aws:lambda:us-east-1:123456789012:function:*"
}
},
"Resource": "arn:aws:ecr:us-east-1:123456789012:repository/example-lambda-repository"
}
]
}
```
複数のアカウントにアクセス権を付与するには、`CrossAccountPermission` ポリシーの [Principal] (プリンシパル) リストと `LambdaECRImageCrossAccountRetrievalPolicy` の [Condition] (条件) 評価リストにアカウント ID を追加します。
AWS Organization で複数のアカウントを扱う場合は、ECR の許可ポリシーで各アカウント ID を列挙することをお勧めします。このアプローチは、IAM ポリシーで狭い範囲の許可を設定するという AWS セキュリティのベストプラクティスに沿ったものです。
Lambda のアクセス許可に加えて、関数を作成するユーザーまたはロールには、`BatchGetImage` および `GetDownloadUrlForLayer` アクセス許可も必要です。
## 関数のライフサイクル
新規または更新済みのコンテナイメージをアップロードすると、Lambda は、関数が呼び出しを処理する前にイメージを最適化します。最適化プロセスには数秒かかる場合があります。この関数は、プロセスが完了するまで `Pending` 状態のままです。完了したら状態は `Active` に変換されます。関数が `Active` 状態になるまで呼び出すことはできません。
数週間にわたって関数が呼び出されない場合、Lambda は最適化されたバージョンを回収し、関数は `Inactive` 状態に移行します。関数を再度アクティブにするには、関数を呼び出す必要があります。Lambda は最初の呼び出しを拒否し、関数は Lambda がイメージを再最適化するまで `Pending` 状態に入ります。その後、関数は `Active` 状態に戻ります。
Lambda は、Amazon ECR リポジトリから関連するコンテナイメージを定期的に取得します。対応するコンテナイメージが Amazon ECR に存在しなくなった場合、またはアクセス許可が失効した場合、関数は `Failed` 状態になり、Lambda が関数呼び出しに対して失敗を返します。
Lambda API を使用して、関数の状態に関する情報を取得できます。詳細については、「[Lambda 関数の状態](functions-states.md)」を参照してください。