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

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

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

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

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

要件

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

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

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

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

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

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

Amazon Elastic コンテナレジストリ公開ギャラリー: gallery.ecr.aws/lambda/provided

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

Lambda では、次のいずれかのイメージマニフェストの形式に準拠するイメージをサポートしています。

Lambda は、すべてのレイヤーを含めて最大 10 GB の非圧縮のイメージサイズをサポートします。

ランタイムインターフェイスクライアント

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 にアクセス権を付与するために、次のステートメントが必要です。

{
  "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 関数の状態」を参照してください。