AWS Lambdaの対応言語の中でもPythonはコード実行までの手間と学習コスト的にもお手軽で利用率が高いようです。私の主要言語はJavaなのですが、手っ取り早くLambdaを使いたいときは不慣れであってもお手軽なPythonを使いたくなります。
　そして、Lambdaで外部ライブラリの力を借りたくなった時はレイヤーというものを用意する必要があります。AWSが予め用意してくれているレイヤーで事足りればよいのですが、そうではない場合は自前でレイヤーを用意しなければなりません。しかし、実際に手を動かしてみるとPythonの環境構築（OpenSSL絡み）でハマってしまい大変でした。そこで、大変なPython環境構築には手を出したくないのでdockerを使い、面倒なコマンド作業をシェルにして実行できたらいいなと思い、レイヤー作成ツールを作ってみました。
　レイヤー作成ツールのdockerコンテナをどこで実行するべきなのかについては、紆余曲折を経てAWS Batchで実行することにしました。イメージのビルドにはCodeBuildを用います。そしてCodeBuildとAWS Batch環境構築用にCloudFormationテンプレートを用意しました。

本稿のAWS Batchを試す前に以下を全て試しましたが、そもそも無理だったり、出来たとしても納得ができるものではなかったので断念しました。

LambdaのレイヤーをLambdaで作成出来たら便利で面白いなと思って試してみました。
Lambdaをコンテナで実行しているときは/tmpディレクトリにしか書き込みができません。pip installでインストール先を/tmpにしましたが、結局インストールの管理情報の書き込みが/tmp以外のディレクトリに対して行われるのでエラーになってしまい断念しました。

参考までに、コンテナ開発者向けの AWS Lambdaの「コンテナの制約」に以下の記載があります。

コンテナは読み取り専用のルートファイルシステムで実行されます（ /tmp は書き込み可能な唯一のパスです）

標準でdockerが使えて無料なのでいいなと思って試してみました。
CloudShell自体のCPUアーキテクチャーがx86_64だけしかなさそうで、Amazonが推しているarm64で作成したイメージのコンテナ実行ができなかったため断念しました。docker用クロスプラットフォームエミュレーターを入れてみても上手くいきませんでした。

arm64のインスタンスを用意したので、当然arm64で作成したイメージのコンテナ実行はできました。しかし、都度利用するには手順が多くて、インスタンス稼働時間も純粋にコンテナ実行時間のみにはできずコストが勿体ないので、AWS Batchがよさそうだと思いました。

レイヤー作成ツールを作ってみました。とにかくdockerさえ利用できればどこでも利用可能です。ローカル開発環境でも利用できます。

• PublishPythonLambdaLayer.sh

一般的にPythonのLambdaレイヤーを作成および登録する手順は以下の通りです。

1. Pythonライブラリインストールコマンドを実行します
   • 対象ライブラリを列挙したrequirements.txtファイルを用意します
   • python -m pip install [options] -r <requirements file> [package-index-options] ...
2. レイヤー（zipファイル）を作成します
   • 定められたディレクトリ構成で用意してzipファイルに圧縮しなければなりません
     • python
     • python/lib/python3.x/site-packages (サイトディレクトリ)
3. レイヤー（zipファイル）をS3にアップロードします
   • AWS CLIだとs3 cp
   • AWSマネジメントコンソール操作ではレイヤー作成時に直接レイヤーのzipファイルをアップロードできますが、10MBを超える場合はS3に置いてアップロードする必要があります
4. Lambdaレイヤーを登録します
   • AWS CLIだとpublish-layer-version

レイヤー作成シェルではこれらを一気通貫で実施します。なお、Python自作モジュールも併せて含めたLambdaレイヤーの作成には対応していません。

作成したLambdaレイヤーアップロード先のS3バケット名を指定しない場合はレイヤー作成までを行います。実行している環境からはS3に接続できないことが予めわかっている、といった場合でもレイヤー作成までは利用できるようにするためです。レイヤー（zipファイル）さえ作成できてファイルが手元にあれば、あとは手作業でなんとか対応できますよね。

また、普通にPythonが利用できる環境であれば、レイヤー作成シェルのみを直接利用してレイヤーを作成できます。

レイヤー作成シェルの使い方の詳細は以下のようなコマンドで確認できます。

./PublishPythonLambdaLayer.sh -h

• Dockerfile

# see https://hub.docker.com/r/amazon/aws-lambda-python/
ARG BASE_IMAGE_TAG=latest

FROM amazon/aws-lambda-python:${BASE_IMAGE_TAG?}

COPY ./PublishPythonLambdaLayer.sh .

RUN <<EOF
chmod +x ./PublishPythonLambdaLayer.sh

# for Amazon Linux 2023 (for python 3.12)
if (type dnf > /dev/null 2>&1); then
  # see https://docs.aws.amazon.com/ja_jp/linux/al2023/ug/deterministic-upgrades-usage.html
  # dnf update -y
  dnf upgrade -y --releasever=latest
  dnf install -y zip unzip
  dnf clean all
  rm -rf /var/cache/dnf/*
# for Amazon Linux 2 (for python 3.11)
elif (type yum > /dev/null 2>&1); then
  yum update -y
  yum install -y zip unzip
  yum clean all
  rm -rf /var/cache/yum/*
else
  echo update failed. unsupported package management tool.
  exit 1
fi

# see https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/getting-started-install.html
if !(type aws > /dev/null 2>&1); then
  CPU_ARCHITECTURE=$(uname -m)
  if [ "$CPU_ARCHITECTURE" = "x86_64" ]; then
    curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
  elif [ "$CPU_ARCHITECTURE" = "aarch64" ]; then
    curl "https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip" -o "awscliv2.zip"
  else
    echo aws cli install failed. unsupported cpu architecture.
    exit 1
  fi
  unzip -qq awscliv2.zip
  ./aws/install > /dev/null 2>&1
  rm -f awscliv2.zip
fi
EOF

ENTRYPOINT [ "bash", "./PublishPythonLambdaLayer.sh" ]
CMD [ "" ]

1. ベースイメージ
   • amazon/aws-lambda-pythonを利用します。AWS Lambda Pythonの実行環境そのものなのでレイヤーを作成するには最適な環境です。
2. ベースイメージタグ
   • docker build時にベースイメージのタグを--build-arg BASE_IMAGE_TAG=<tag>で指定できます。利用したいCPUアーキテクチャやPythonバージョンに見合った環境を柔軟に選択できます。例えば3.11や3.12を指定できます。しかし、Amazon Linux 2ベースのPython3.11ではyum、Amazon Linux 2023ベースのPython3.12ではdnfしか使えず、互換性がありませんでした。そこで、dnfコマンドが通るかどうかをチェックして、dnfとyumの使い分けをするようにして対応しました。
3. インストールなどの初期化処理
   • ヒアドキュメントで書いています。コマンドを頑張って&& \で数珠繋ぎしなくて済むので複雑な処理が書きやすくなり、その結果dockerイメージのレイヤ数も減らしやすくなるのでイメージのサイズを小さくできます。
4. その他
   • AWS CLIのファイル解凍やインストールのログが大量に出て煩わしく感じたのでカットしています。
   • レイヤー作成シェルのオプションは実行時にCMDで上書きできるようにしてあります。

1. S3にソース（レイヤー作成ツール）を置いて
2. CodeBuildでdockerイメージを作成し
3. ECRにpushします

1. AWS BatchでECRからdockerイメージをpullして
2. AWS Batchでコンテナを実行してレイヤーを作成し
3. S3にアップロードして
4. Lambdaにレイヤーを登録します

AWS公式ではLambdaをはじめとするコンピューティングリソースのCPUアーキテクチャにarm64を利用することを強く推しているので、環境作成用のCloudFormationテンプレートのデフォルト値はarm64向けにしてあります。

AWS Batchの環境を作成するための、以下のネットワーク要件を全て満たすサブネットを用意します。
私が以前執筆した「AWS CloudFormationでやさしくネットワーク構築 - IPv6対応、NATゲートウェイ設置切替作業も易しくてお財布にも優しい！」という記事のCloudFormationテンプレートを使うと簡単に用意できます。

• S3に接続可能
  • 外部アクセス不能なS3バケットに接続する場合はプライベートリンクで接続する（Gateway型VPCエンドポイントを用意してルーティングする）必要があります
• IPv4でインターネット接続可能

CodeBuildではS3からソースコードを参照するようにしたので、レイヤー作成ツールソースコードを格納するS3バケットおよびフォルダを用意して、レイヤー作成ツールソースコード（DockerfileとPublishPythonLambdaLayer.sh）を同一階層に格納します。後で利用するrequirements.txtはついでに同じ場所に置いただけですので、他のバケットに置いても構いません。
例として、s3://publish-lambda-layer-tool-pcjkn63zhk/python/に用意しました。
なお、S3バケット作成時の設定「パブリックアクセスをすべて ブロック」はチェックを付けておくことが望ましいです。

作成したLambdaレイヤーをアップロードするS3バケットを用意します。
例として、s3://lambda-layer-pcjkn63zhk/を用意しました。
なお、S3バケット作成時の設定「パブリックアクセスをすべて ブロック」はチェックを付けておくことが望ましいです。

CodeBuildプロジェクトおよびECRリポジトリを作成するCloudFormationテンプレートを用意しました。これを用いてリソースを作成します。

• cfn_codebuild.yaml

以下、arm64向けのパラメータ設定例です。

もちろんx86_64向けも用意できます。以下、パラメータ設定例です。

作成したCodeBuildプロジェクトにてビルドを実行します。
dockerイメージを作成し、ECRリポジトリにpushする処理を書いたbuildspec、およびbuildspec内で参照する環境変数はCloudFormationでプロジェクトを作成した際に既に用意されています。
実行時に設定する環境変数を設定するだけでビルドができます。

version: 0.2
phases:
  pre_build:
    commands:
      - |
        export AWS_ECR_REGISTRY_URL=$AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.$AWS_URL_SUFFIX
        export DOCKER_IMAGE_REPO_NAME_AND_TAG=$IMAGE_REPO_NAME:$IMAGE_TAG
        echo "AWS_ECR_REGISTRY_URL="$AWS_ECR_REGISTRY_URL
        echo "DOCKER_IMAGE_REPO_NAME_AND_TAG="$DOCKER_IMAGE_REPO_NAME_AND_TAG
      - echo "----- login to Amazon ECR Repository -----"
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ECR_REGISTRY_URL
      - |
        if [ -n "$DOCKER_USER" ] && [ -n "$DOCKER_TOKEN" ]; then
          echo "----- login to docker hub -----"
          echo $DOCKER_TOKEN | docker login -u $DOCKER_USER --password-stdin
        fi
  build:
    commands:
      - echo "----- build docker image -----"
      - echo Build started on `date`
      - docker build -t $DOCKER_IMAGE_REPO_NAME_AND_TAG $DOCKER_BUILD_OPTIONS .
      - echo Build completed on `date`
  post_build:
    commands:
      - echo "----- add docker image tag -----"
      - docker tag $DOCKER_IMAGE_REPO_NAME_AND_TAG $AWS_ECR_REGISTRY_URL/$DOCKER_IMAGE_REPO_NAME_AND_TAG
      - echo "----- push docker image to Amazon ECR Repository -----"
      - docker push $AWS_ECR_REGISTRY_URL/$DOCKER_IMAGE_REPO_NAME_AND_TAG

CodeBuildプロジェクトの「編集」->「環境」->「追加設定」->「環境変数」にて設定します。
設定が終わったら「プロジェクトを更新する」を押下します。

以下、arm64向けのパラメータ設定例です。

以下、x86_64向けのパラメータ設定例です。

「ビルドを開始」を押下します。

成功したことを確認します。

イメージがECRリポジトリにpushされていることを確認します。

docker buildコマンドを実行している際にベースイメージのプルが「Too Many Requests.(リクエストが多すぎます)」という全く心当たりのない謎のエラーメッセージでビルドが失敗することがあります（原因は後述します）。この場合はビルドを再実行すれば成功する可能性があります。もし再実行しても失敗が続く場合、あるいはビルドを安定して成功させたい場合は、自分の docker hub ユーザを用意して、CodeBuildの環境変数DOCKER_USERとDOCKER_TOKENを設定します。これらの認証情報は環境変数にプレーンテキストで直接設定せずに、パラメータストアまたはシークレットマネージャーに登録して参照することが望ましいです。

パラメータストア設定例

シークレットマネージャー設定例

CodeBuildの環境変数の設定例

• パラメータストアを参照する場合
  • 値を「マイパラメータの名前」、タイプを「パラメータ」に設定します。
    • 値の設定例：DOCKER_USER
• シークレットマネージャーを参照する場合
  • 値を「シークレットの名前:シークレットキー」、タイプを「Secrets Manager」に設定します。
    • 値の設定例：MyDockerHubAccount:DOCKER_TOKEN

    {
      "ip_prefix": "13.112.191.184/29",
      "region": "ap-northeast-1",
      "service": "CODEBUILD",
      "network_border_group": "ap-northeast-1"
    },
    {
      "ip_prefix": "35.75.131.80/29",
      "region": "ap-northeast-1",
      "service": "CODEBUILD",
      "network_border_group": "ap-northeast-1"
    },

AWS Batch環境を作成するCloudFormationテンプレートを用意しました。これを用いてリソースを作成します。

• cfn_aws_batch.yaml

以下、arm64向けのパラメータ設定例です。

以下、x86_64向けのパラメータ設定例です。

作成したAWS Batch環境にてジョブを作成してLambdaレイヤーを作成します。
AWS Batchの「ジョブ」にて「新しいジョブを送信」ボタンを押下します。

以下を選択します。

• ジョブ定義
  • CloudFormationのパラメータ「prefix」値-job-definition
• ジョブキュー
  • CloudFormationのパラメータ「prefix」値-job-queue

以下はarm64向けの必要最低限のパラメータ設定例です。
DockerfileのCMD [ "" ]を上書きしてレイヤー作成シェルのオプションを設定します。

[ "-p s3://publish-lambda-layer-tool-pcjkn63zhk/python/requirements.txt", "-n http_request_lib_test_python_3_12_arm64", "-s lambda-layer-pcjkn63zhk" ]

レイヤー作成シェルのオプション

例として、s3://publish-lambda-layer-tool-pcjkn63zhk/python/にrequirements.txtを用意しました。
その内容は以下の通りです。

requests == 2.32.3
httpx == 0.27.2

「-p」オプションを使わずrequirements.txtファイルを用意せずに「-r」オプションを使うこともできます。

[ "-r requests == 2.32.3|httpx == 0.27.2", "-n http_request_lib_test_python_3_12_arm64", "-s lambda-layer-pcjkn63zhk" ]

以下はx86_64向けの必要最低限のパラメータ設定例です。

[ "-p s3://publish-lambda-layer-tool-pcjkn63zhk/python/requirements.txt", "-n http_request_lib_test_python_3_12_x86_64", "-s lambda-layer-pcjkn63zhk" ]

ステータスがSucceededになれば成功です。

S3にレイヤーのzipファイルが格納されます。

レイヤーのzipファイルのメタデータにはレイヤーの各種情報が設定されます。

Lambdaレイヤーにも登録されています。

目的のランタイムとアーキテクチャを指定して関数を作成します。

関数にレイヤーを追加します。

Lambdaはタイムアウト時間がデフォルトで3秒なので、念のためこれを1分ぐらいに変更しておきます。

レイヤーで取り込んだモジュール（requests, httpx）を利用してみます。
ついでにplatform.python_version()で、実際に動作しているPythonのバージョンを取得してみます。

import platform
import httpx
import requests

def lambda_handler(event, context):
    python_version = platform.python_version()
    print('[lambda python runtime version] ' + python_version)
    url = 'https://aws.amazon.com/'
    httpx_response = httpx.get(url)
    print('[httpx response]')
    print(httpx_response)
    requests_response = requests.get(url)
    print('[requests response]')
    print(requests_response)
    return python_version

HTTPリクエストが通っており、動作しているPythonバージョンが返されて成功しているのでレイヤーが利用できています。

レイヤー作成のベースイメージ(3.12.7)がリリースされて間もなかったので、実際のLambda(3.12.5)がまだ追い付いていなかったようです。もしPythonのバージョンが違っている状態でうまく動かなかったときは、Pythonバージョンが一致するようにベースイメージを選定し直してレイヤーを作り直してみるとよいかもしれません。

今回はPythonで実現しましたが、レイヤー作成ツールの中身（Dockerfileとシェルのみ）を差し替えれば他のLambda対応言語もこの方式で簡単にレイヤー作成できるのではないかと思います。
そして、イメージ作成環境のCodeBuildおよびコンテナ実行環境のAWS BatchのCloudFormationテンプレートは、レイヤー作成ツールには特化せず汎用的に利用できるように作ったので、これを用いて自由な言語で自由にツールやアプリケーションを用意できると思います。