コンテナイメージを使用した 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 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 関数の状態」を参照してください。