コンテナイメージを使用した Lambda 関数の作成 - AWS Lambda
要件AWS ベースイメージを使用するAWS の OS 専用ベースイメージを使用する非 AWS ベースイメージを使用するランタイムインターフェイスクライアントAmazon ECR のアクセス許可関数のライフサイクル

コンテナイメージを使用した Lambda 関数の作成

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

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

ヒント

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

タグ ランタイム オペレーティングシステム 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 Runtime 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 関数の状態」を参照してください。