要件 AWS ベースイメージを使用する AWS の OS 専用ベースイメージを使用する非 AWS ベースイメージを使用するランタイムインターフェイスクライアント Amazon ECR のアクセス許可コンテナイメージの設定

Lambda のコンテナイメージを使用する

AWS Lambda 関数のコードは、スクリプトまたはコンパイルされたプログラム、さらにそれらの依存関係で構成されます。デプロイパッケージを使用して、Lambda に関数コードをデプロイします。Lambda は、コンテナイメージと .zip ファイルアーカイブの 2 種類のデプロイパッケージをサポートします。

Lambda 関数のコンテナイメージを構築するには 3 つの方法があります。

Lambda の AWS ベースイメージを使用する

AWS ベースイメージには、言語ランタイム、Lambda と関数コード間のやり取りを管理するランタイムインターフェイスクライアント、ローカルテスト用のランタイムインターフェイスエミュレーターがプリロードされています。
AWS の OS 専用ベースイメージを使用する

AWS OS 専用ベースイメージには、Amazon Linux ディストリビューションおよびランタイムインターフェイスエミュレータが含まれています。これらのイメージは、Go や Rust などのコンパイル済み言語や、Lambda がベースイメージを提供していない言語または言語バージョン (Node.js 19 など) のコンテナイメージの作成によく使用されます。OS 専用のベースイメージを使用してカスタムランタイムを実装することもできます。イメージに Lambda との互換性を持たせるには、当該言語のランタイムインターフェイスクライアントをイメージに含める必要があります。
非 AWS ベースイメージを使用する

Alpine Linux や Debian など、別のコンテナレジストリの代替ベースイメージを使用することもできます。組織が作成したカスタムイメージを使用することもできます。イメージに Lambda との互換性を持たせるには、当該言語のランタイムインターフェイスクライアントをイメージに含める必要があります。

ヒント

Lambda コンテナ関数がアクティブになるまでの時間を短縮するには、「Docker ドキュメント」の「マルチステージビルドを使用する」を参照してください。効率的なコンテナイメージを構築するには、「Dockerfiles を記述するためのベストプラクティス」に従ってください。

コンテナイメージから Lambda 関数を作成するには、イメージをローカルでビルドして、Amazon Elastic Container Registry (Amazon ECR) リポジトリにアップロードします。次に、関数の作成時にリポジトリ URI を指定します。Amazon ECR リポジトリは Lambda 関数と同じ AWS リージョンに配置されている必要があります。イメージが Lambda 関数と同じリージョンに配置されていれば、別の AWS アカウントのイメージを使用して関数を作成することができます。詳細については、「 Amazon ECR クロスアカウント許可」を参照してください。

このページでは、Lambda 互換のコンテナイメージを作成するためのベースイメージタイプと要件について説明します。

注記

既存の関数のデプロイパッケージタイプ (.zip またはコンテナイメージ) を変更することはできません。例えば、コンテナイメージ関数を変換して .zip ファイルアーカイブを使用することはできません。この場合は、新しい関数を作成する必要があります。

要件

「AWS Command Line Interface (AWS CLI) バージョン 2」および「Docker CLI」をインストールします。さらに、次の各要件にも注意してください。

コンテナイメージには、Lambda Runtime API が実装されている必要があります。AWS からの、オープンソースのランタイムインターフェイスクライアントには、この API が実装されています。ランタイムインターフェイスクライアントを必要なベースイメージに追加することで、Lambda と互換性を持たせることができます。
コンテナイメージは、読み取り専用のファイルシステム上で実行可能である必要があります。機能コードは、512 MB から 10,240 MB の間で、1 MB 刻みで書き込み可能な /tmp ディレクトリにアクセスできます。
デフォルトの Lambda ユーザーは、関数コードを実行するために必要なすべてのファイルを読み取ることができる必要があります。Lambda は、最小特権のアクセス許可を持つデフォルトの Linux ユーザーを定義することで、セキュリティのベストプラクティスに従います。ご自身のアプリケーションコードが、外部の Linux ユーザーによる実行が制限されているファイルに依存していないことを確認します。
Lambda では、Linux ベースのコンテナイメージのみがサポートされます。
Lambda は、マルチアーキテクチャのベースイメージを提供します。ただし、関数用に構築するイメージは、アーキテクチャの 1 つだけをターゲットにする必要があります。Lambda は、マルチアーキテクチャのコンテナイメージを使用する関数をサポートしません。

Lambda の AWS ベースイメージを使用する

Lambda に AWS ベースイメージの 1 つを使用して、関数コードのコンテナイメージを構築します。ベースイメージには、Lambda でコンテナイメージを実行するために必要な言語ランタイムおよびその他のコンポーネントがプリロードされます。関数コードと依存関係をベースイメージに追加し、コンテナイメージとしてパッケージ化します。

AWS では、Lambda 用の AWS ベースイメージの更新を定期的に実施しています。Dockerfile の FROM プロパティにイメージ名が含まれている場合、Docker クライアントは Amazon ECR リポジトリから最新バージョンのイメージを取り出します。更新されたベースイメージを使用するには、コンテナイメージを再ビルドして、関数のコードを更新する必要があります。

Node.js 20、Python 3.12、Java 21、AL2023 以降のベースイメージは、Amazon Linux 2023 の最小コンテナイメージに基づいています。以前のベースイメージでは Amazon Linux 2 を使用しています。AL2023 ランタイムには、デプロイのフットプリントが小さいことや、glibc などのライブラリのバージョンが更新されていることなど、Amazon Linux 2 に比べていくつかの利点があります。

AL2023-basedイメージでは、Amazon Linux 2 のデフォルトのパッケージマネージャーであるではなくyum、 microdnf ( としてシンボリックにリンクされたdnf) をパッケージマネージャーとして使用します。 microdnfはのスタンドアロン実装ですdnf。AL2023-basedイメージに含まれるパッケージのリストについては、「Amazon Linux 2023 コンテナイメージにインストールされているパッケージの比較」の「最小コンテナ列」を参照してください。 https://docs.aws.amazon.com/linux/al2023/ug/al2023-container-image-types.htmlAL2023 と Amazon Linux 2 の違いの詳細については、 AWS Compute Blog の「Introducing the Amazon Linux 2023 runtime for AWS Lambda 」を参照してください。

注記

AWS Serverless Application Model (AWS SAM) を含む AL2023-basedイメージをローカルで実行するには、Docker バージョン 20.10.10 以降を使用する必要があります。

AWS ベースイメージを使用してコンテナイメージを構築するには、お好みの言語での手順を選択してください。

Node.js
TypeScript (Node.js ベースイメージを使用）
Python
Java
Go
.NET
Ruby

AWS の OS 専用ベースイメージを使用する

AWS OS 専用ベースイメージには、Amazon Linux ディストリビューションおよびランタイムインターフェイスエミュレータが含まれています。これらのイメージは、Go や Rust などのコンパイル済み言語や、Lambda がベースイメージを提供していない言語または言語バージョン (Node.js 19 など) のコンテナイメージの作成によく使用されます。OS 専用のベースイメージを使用してカスタムランタイムを実装することもできます。イメージに Lambda との互換性を持たせるには、当該言語のランタイムインターフェイスクライアントをイメージに含める必要があります。

タグ	ランタイム	オペレーティングシステム	Dockerfile	廃止
al2023	OS 専用ランタイム	Amazon Linux 2023	での OS 専用ランタイム用の Dockerfile GitHub
al2	OS 専用ランタイム	Amazon Linux 2	での OS 専用ランタイム用の Dockerfile GitHub

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 Runtime API を拡張する必要があります。AWS では、オープンソースのランタイムインターフェイスクライアントを次の言語で提供しています。

Node.js
Python
Java
.NET
Go
Ruby
Rust — Rust ランタイムクライアントは実験的なパッケージです。これは変更される可能性があり、評価のみを目的としています。

使用している言語に AWS の提供するランタイムインターフェイスクライアントがない場合、独自のランタイムインターフェイスクライアントを作成する必要があります。

Amazon ECR のアクセス許可

コンテナイメージから Lambda 関数を作成する前に、そのイメージをローカルでビルドし、 Amazon ECR リポジトリにアップロードする必要があります。関数の作成時に、Amazon ECR リポジトリ URI を指定します。

関数を作成するユーザーまたはロールの許可に、AWS マネージドポリシーの 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 セキュリティのベストプラクティスに沿ったものです。

コンテナイメージの設定

以下は、一般的なコンテナイメージです。Dockerfile でこれらの設定を使用する場合は、Lambda がこれらの設定をどのように解釈し処理するかに注意してください。

ENTRYPOINT －アプリケーションのエントリポイントへの絶対パスを指定します。
CMD － ENTRYPOINT とともに渡すパラメータを指定します。
WORKDIR －作業ディレクトリへの絶対パスを指定します。
ENV － Lambda 関数の環境変数を指定します。

Docker によるコンテナイメージの使用の詳細については、Docker ドキュメント Web サイトの Dockerfile リファレンスで、「ENTRYPOINT」を参照してください。ENTRYPOINT と CMD の使用の詳細については、AWS Open Source Blog の、「Docker での ENTRYPOINT と CMD を紐解く」を参照してください。

イメージをビルドする際に、Dockerfile 内のコンテナイメージ設定を指定できます。コンソールまたは Lambda API を使用して、これらの設定をオーバーライドすることもできます。設定をオーバーライドすることで、同じコンテナイメージを使用しながら、ランタイム構成が異なる複数の関数をデプロイできるようになります。

警告

Dockerfile 内で、あるいははオーバーライドしながら ENTRYPOINT または CMD を指定する場合は、絶対パスのみを使用します。また、コンテナへのエントリポイントの指定には、シンボリックリンクを使用しないでください。

コンテナイメージの設定値を上書きするには、

Lambda コンソールの [関数ページ] を開きます。
対象の関数を選択します。
[イメージの設定] で、[編集] をクリックします。
必要なオーバーライド設定に新しい値を入力した上で、[保存] をクリックします。
(オプション) 環境変数を追加またはオーバーライドするには、[環境変数] にある [編集] をクリックします。

詳細については、「Lambda 環境変数の使用」を参照してください。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

.zip ファイルアーカイブ

イメージのテスト