デプロイパッケージをコンテナイメージとしたAWS Lambda関数をローカルで動かす（curlでの動作確認＋AWS SAM）

これは、なにをしたくて書いたもの？

AWS Lambda関数のデプロイパッケージにはzipファイルとコンテナイメージがあります。

このうちzipファイルしか使ったことがなかったので、コンテナイメージを使ってみたいと思います。で、ローカルで動かしてみます。

AWS Lambdaのデプロイパッケージ

AWS Lambdaのデプロイパッケージには、zipファイルとコンテナイメージがあります。

Lambda の主要な概念を理解する / デプロイパッケージ

AWS Lambda関数をコンテナイメージで作成するには、以下の3種類の方法があるようです。

AWS Lambda関数用のAWSベースイメージを使用する
- Node.js、TypeScript、Python、Java、Go、.NET、Rubyに対してベースイメージがAmazon ECRリポジトリーから提供
- 各言語向けのベースイメージはAmazon Linux 2023のベースイメージ上に構築されている
AWSのOS専用ベースイメージを使用する
- GoやRustのような実行時に言語のランタイムが不要な言語の場合や、AWS Lambda関数がベースイメージを提供していない言語の場合に利用
- Amazon Linux 2023またはAmazon Linux 2から選択し、ランタイムインターフェイスクライアントをイメージに含める必要がある
- カスタムランタイムとして構築することも可能
非AWSベースイメージを使用する
- Docker Image Manifest V2 Schema 2またはOpen Container Initiative（OCI）仕様に準拠するイメージである必要がある
- ランタイムインターフェイスクライアントをイメージに含める必要がある

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

各言語向けにも、コンテナイメージを使ったAWS Lambda関数の構築方法が書かれています。

Node.js Lambda 関数をコンテナイメージとともにデプロイする - AWS Lambda

コンテナイメージを使用して、トランスパイルされた TypeScript コードを Lambda にデプロイする - AWS Lambda

コンテナイメージで Python Lambda 関数をデプロイする - AWS Lambda

コンテナイメージで Ruby Lambda 関数をデプロイする - AWS Lambda

コンテナイメージを使用した Java Lambda 関数のデプロイ - AWS Lambda

コンテナイメージを使用して Go Lambda 関数をデプロイする - AWS Lambda

コンテナイメージを使用して.NET の Lambda 関数をデプロイする - AWS Lambda

今回はPythonを使おうと思います。

コンテナイメージを使ったAWS Lambda関数をローカルで動かすには？

ローカルでAWSに関するサービスをエミュレーションででも動かそうと思うと、LocalStackを使うことが個人的には多いです。

なのですが、コンテナイメージを使うにはLocalStackの有償版を使う必要があります。

AWS Service Feature Coverage | Docs

どうしようかな？と思ったのですが、AWS SAMではコンテナイメージであってもローカルで動かせそうな感じだったので今回はこちらを
使ってみることにしました。

あと、そもそも各言語のコンテナイメージに関するページに、curlを使った確認方法が書かれているのでこちらでも試してみましょう。

今回はコンテナイメージを使ったAWS Lambda関数のビルド、動作確認を中心にするので、あまり凝ったことはやりません。

環境

今回の環境はこちら。

$ python3 --version
Python 3.12.3


$ pip3 --version
pip 24.0 from /usr/lib/python3/dist-packages/pip (python 3.12)

Docker。

$ docker version
Client: Docker Engine - Community
 Version:           27.3.1
 API version:       1.47
 Go version:        go1.22.7
 Git commit:        ce12230
 Built:             Fri Sep 20 11:40:59 2024
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          27.3.1
  API version:      1.47 (minimum version 1.24)
  Go version:       go1.22.7
  Git commit:       41ca978
  Built:            Fri Sep 20 11:40:59 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.24
  GitCommit:        88bf19b2105c8b17560993bee28a01ddc2f97182
 runc:
  Version:          1.2.2
  GitCommit:        v1.2.2-0-g7cb3632
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

AWS SAM。

$ sam --version
SAM CLI, version 1.131.0

AWS CLI。

$ aws --version
aws-cli/2.22.12 Python/3.12.6 Linux/6.8.0-49-generic exe/x86_64.ubuntu.24

クレデンシャルはダミーの値を環境変数で設定しておきます。

$ export AWS_ACCESS_KEY_ID=dummy
$ export AWS_SECRET_ACCESS_KEY=dummy
$ export AWS_DEFAULT_REGION=ap-northeast-1

AWS Lambda関数をコンテナイメージで作成してcurlで動作確認する

最初はPython向けのガイドに従っていきましょう。

コンテナイメージで Python Lambda 関数をデプロイする - AWS Lambda

Pythonは3.12を使うので、ベースイメージもPython 3.12のものになります。なお、Python 3.12からベースイメージがAmazon Linux 2023に
なるようです（3.11以前はAmazon Linux 2）。

Python 3.12 以降のベースイメージは、Amazon Linux 2023 の最小コンテナイメージに基づいています。Python 3.8～3.11 のベースイメージは、Amazon Linux 2 のイメージに基づいています。AL2023 ベースのイメージには、デプロイのフットプリントが小さいことや、glibc などのライブラリのバージョンが更新されていることなど、Amazon Linux 2 に比べていくつかの利点があります。

コンテナイメージで Python Lambda 関数をデプロイする / Python の AWS ベースイメージ

ベースイメージにパッケージを追加したい場合は、microdnfを使うようです。

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」を参照してください。

また、このあたりも注意ですね。

コードで import ステートメントを使用すると、Python ランタイムはモジュールまたはパッケージが見つかるまで検索パス内のディレクトリを検索します。デフォルトでは、ランタイムは {LAMBDA_TASK_ROOT} ディレクトリを先に検索します。ランタイムに含まれるライブラリのバージョンをイメージに含める場合、そのバージョンが、ランタイムに含まれるバージョンよりも優先されます。

ランタイムに含まれるライブラリーとpipを使ってインストールしたライブラリーは、ベースイメージのバージョンによって優先順位が
違うようです。Python 3.11以降のベースイメージであれば、pipでインストールするとランタイムに含まれるライブラリーをオーバーライドする
ことになるようです。

Python 3.11 以降: ランタイムに含まれるライブラリと pip でインストールされるライブラリは /var/lang/lib/python3.11/site-packages ディレクトリにインストールされます。このディレクトリは、検索パス内で /var/runtime よりも優先されます。pip を使用して新しいバージョンをインストールすることで、SDK をオーバーライドできます。pip を使用して、ランタイムに含まれる SDK とその依存関係が、インストールする任意のパッケージと互換性があることを確認できます。

Python 3.8-3.10: ランタイムに含まれるライブラリは /var/runtime ディレクトリにインストールされます。pip でインストールされるライブラリは /var/lang/lib/python3.x/site-packages ディレクトリにインストールされます。/var/runtime ディレクトリは検索パス内で /var/lang/lib/python3.x/site-packages より優先されます。

3.10以前だと関係が逆になっているのでちょっと注意でしょうか…。

ランタイムインターフェイスクライアントと非AWSベースイメージを使った例も書かれていますが、今回はAWS Lambda関数用の
AWSベースイメージを使用していきます。

ドキュメントのサンプルでは依存関係がないので、適当にPyYAMLを使っておきましょう。

$ pip3 install pyyaml

インストールされたライブラリー一覧。

$ pip3 list
Package Version
------- -------
pip     24.0
PyYAML  6.0.2

requirements.txtも必要になるので、作成しておきます。

$ pip3 freeze > requirements.txt

こんなAWS Lambda関数を作成。

app.py

import yaml

def lambda_handler(event, context):
    print(f"event = {event}")
    print(f"context = {context}")

    return yaml.dump({"message": event["message"]})

Dockerfileを作成。

Dockerfile

FROM public.ecr.aws/lambda/python:3.12

COPY requirements.txt ${LAMBDA_TASK_ROOT}

RUN pip install -r requirements.txt --no-cache-dir

COPY app.py ${LAMBDA_TASK_ROOT}

CMD [ "app.lambda_handler" ]

コンテナイメージを作成。

$ docker image build --platform linux/amd64 -t hello-lambda:0.0.1 .

ドキュメントを見ると、--platform linux/amd64を指定した方がよさそうですね。ARM向けにコンテナイメージを作成する場合は、
--platform linux/arm64を指定します。

作成したコンテナイメージを使って、AWS Lambda関数を起動。

$ docker container run -it --rm --platform linux/amd64 --name lambda-function -p 9000:8080 hello-lambda:0.0.1
08 Dec 2024 07:22:24,604 [INFO] (rapid) exec '/var/runtime/bootstrap' (cwd=/var/task, handler=)

確認してみます。

$ curl localhost:9000/2015-03-31/functions/function/invocations -d '{"message": "Hello Lambda"}'
"message: Hello Lambda\n"

なんか最後に改行がついてますが…まあいいでしょう。ペイロードは-dでそのままJSONを送ればよさそうです。

コンテナ側のログを見ると、ちゃんとペイロードなどを認識しています。

event = {'message': 'Hello Lambda'}
context = LambdaContext([aws_request_id=0c90c2f1-4aee-4d35-b5d9-e463f29e610b,log_group_name=/aws/lambda/Functions,log_stream_name=$LATEST,function_name=test_function,memory_limit_in_mb=3008,function_version=$LATEST,invoked_function_arn=arn:aws:lambda:us-east-1:012345678912:function:test_function,client_context=None,identity=CognitoIdentity([cognito_identity_id=None,cognito_identity_pool_id=None])])

パスは/2015-03-31/functions/function/invocationsなんですね。

ところで、ドキュメントではローカルポートを9000に割り当てているのですが、なにか理由があるのかな？と思って8080ポートに割り当てて
みましたが、特に問題なかったです。

$ docker container run -it --rm --platform linux/amd64 --name lambda-function -p 8080:8080 hello-lambda:0.0.1

結果。

$ curl localhost:8080/2015-03-31/functions/function/invocations -d '{"message": "Hello Lambda"}'
"message: Hello Lambda\n"

ローカルポートにバインドせずに、コンテナのIPに直接アクセスしてもかまいません。

$ docker container run -it --rm --platform linux/amd64 --name lambda-function hello-lambda:0.0.1


$ curl 172.17.0.2:8080/2015-03-31/functions/function/invocations -d '{"message": "Hello Lambda"}'
"message: Hello Lambda\n"

このパートはこんなところでしょうか。

AWS SAMでコンテナイメージで作成して動作確認します

続いては、AWS SAMを使ってみます。AWS SAMでコンテナイメージを使ったAWS Lambda関数の構築について記載があるのは、このあたり
でしょうか。

AWS SAM を使用した構築の概要 - AWS Serverless Application Model

AWS SAM を使用したデフォルトのビルド - AWS Serverless Application Model

まずはAWS SAMプロジェクトを作成してみます。

$ sam init

インタラクティブに入力した場合。

You can preselect a particular runtime or package type when using the `sam init` experience.
Call `sam init --help` to learn more.

Which template source would you like to use?
        1 - AWS Quick Start Templates
        2 - Custom Template Location
Choice: 1

Choose an AWS Quick Start application template
        1 - Hello World Example
        2 - Data processing
        3 - Hello World Example with Powertools for AWS Lambda
        4 - Multi-step workflow
        5 - Scheduled task
        6 - Standalone function
        7 - Serverless API
        8 - Infrastructure event management
        9 - Lambda Response Streaming
        10 - Serverless Connector Hello World Example
        11 - Multi-step workflow with Connectors
        12 - GraphQLApi Hello World Example
        13 - Full Stack
        14 - Lambda EFS example
        15 - DynamoDB Example
        16 - Machine Learning
Template: 1

Use the most popular runtime and package type? (python3.13 and zip) [y/N]: n

Which runtime would you like to use?
        1 - dotnet8
        2 - dotnet6
        3 - go (provided.al2)
        4 - go (provided.al2023)
        5 - graalvm.java11 (provided.al2)
        6 - graalvm.java17 (provided.al2)
        7 - java21
        8 - java17
        9 - java11
        10 - java8.al2
        11 - nodejs22.x
        12 - nodejs20.x
        13 - nodejs18.x
        14 - nodejs16.x
        15 - python3.9
        16 - python3.8
        17 - python3.13
        18 - python3.12
        19 - python3.11
        20 - python3.10
        21 - ruby3.3
        22 - ruby3.2
        23 - rust (provided.al2)
        24 - rust (provided.al2023)
Runtime: 18

What package type would you like to use?
        1 - Zip
        2 - Image
Package type: 2

Based on your selections, the only dependency manager available is pip.
We will proceed copying the template using pip.

Would you like to enable X-Ray tracing on the function(s) in your application?  [y/N]: n

Would you like to enable monitoring using CloudWatch Application Insights?
For more info, please view https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-application-insights.html [y/N]: n

Would you like to set Structured Logging in JSON format on your Lambda functions?  [y/N]: y
Structured Logging in JSON format might incur an additional cost. View https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html#monitoring-cloudwatchlogs-pricing for more details

Project name [sam-app]: hello-sam-docker

    -----------------------
    Generating application:
    -----------------------
    Name: hello-sam-docker
    Base Image: amazon/python3.12-base
    Architectures: x86_64
    Dependency Manager: pip
    Output Directory: .
    Configuration file: hello-sam-docker/samconfig.toml

    Next steps can be found in the README file at hello-sam-docker/README.md


Commands you can use next
=========================
[*] Create pipeline: cd hello-sam-docker && sam pipeline init --bootstrap
[*] Validate SAM template: cd hello-sam-docker && sam validate
[*] Test Function in the Cloud: cd hello-sam-docker && sam sync --stack-name {stack-name} --watch

これをsam initのオプションだけで行った場合はこちら。

$ sam init --name hello-sam-docker --base-image amazon/python3.12-base --app-template hello-world-lambda-image --package-type Image --no-tracing --no-application-insights --structured-logging

コンテナイメージを使う場合は、ベースイメージを--base-imageで指定するようです。

コンテナイメージのテンプレートは、そんなに多くはなさそうですね。

$ curl -s https://raw.githubusercontent.com/aws/aws-sam-cli-app-templates/master/manifest-v2.json | jq '."amazon/python3.12-base"'
[
  {
    "directory": "python3.12/hello-img",
    "displayName": "Hello World Lambda Image Example",
    "dependencyManager": "pip",
    "appTemplate": "hello-world-lambda-image",
    "packageType": "Image",
    "useCaseName": "Hello World Example"
  },
  {
    "directory": "python3.12/apigw-scikit",
    "displayName": "Scikit-learn Machine Learning Inference API",
    "dependencyManager": "pip",
    "appTemplate": "ml-apigw-scikit-learn",
    "packageType": "Image",
    "useCaseName": "Machine Learning"
  },
  {
    "directory": "python3.12/apigw-xgboost",
    "displayName": "XGBoost Machine Learning Inference API",
    "dependencyManager": "pip",
    "appTemplate": "ml-apigw-xgboost",
    "packageType": "Image",
    "useCaseName": "Machine Learning"
  }
]

作成したAWS SAMプロジェクト内に移動。

$ cd hello-sam-docker

ディレクトリツリー。

$ tree -a
.
├── .gitignore
├── README.md
├── __init__.py
├── events
│   └── event.json
├── hello_world
│   ├── Dockerfile
│   ├── __init__.py
│   ├── app.py
│   └── requirements.txt
├── samconfig.toml
├── template.yaml
└── tests
    ├── __init__.py
    └── unit
        ├── __init__.py
        └── test_handler.py

5 directories, 13 files

気になるファイルを見てみましょう。

AWS Lambda関数。

hello_world/app.py

import json


def lambda_handler(event, context):
    """Sample pure Lambda function

    Parameters
    ----------
    event: dict, required
        API Gateway Lambda Proxy Input Format

        Event doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html#api-gateway-simple-proxy-for-lambda-input-format

    context: object, required
        Lambda Context runtime methods and attributes

        Context doc: https://docs.aws.amazon.com/lambda/latest/dg/python-context-object.html

    Returns
    ------
    API Gateway Lambda Proxy Output Format: dict

        Return doc: https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-lambda-proxy-integrations.html
    """

    return {
        "statusCode": 200,
        "body": json.dumps(
            {
                "message": "hello world",
            }
        ),
    }

これはふつうのテンプレートですね。

requirements.txtｄはrequestsをインストールするようになっています。

hello_world/requirements.txt

requests

Dockerfile。

hello_world/Dockerfile

FROM public.ecr.aws/lambda/python:3.12

COPY app.py requirements.txt ./

RUN python3.12 -m pip install -r requirements.txt -t .

# Command can be overwritten by providing a different command in the template directly.
CMD ["app.lambda_handler"]

AWS SAMのテンプレートファイル。

template.yaml

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
  python3.12

  Sample SAM Template for hello-sam-docker

# More info about Globals: https://github.com/awslabs/serverless-application-model/blob/master/docs/globals.rst
Globals:
  Function:
    Timeout: 3

    # You can add LoggingConfig parameters such as the Logformat, Log Group, and SystemLogLevel or ApplicationLogLevel. Learn more here https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-resource-function.html#sam-function-loggingconfig.
    LoggingConfig:
      LogFormat: JSON
Resources:
  HelloWorldFunction:
    Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
    Properties:
      PackageType: Image
      Architectures:
      - x86_64
      Events:
        HelloWorld:
          Type: Api # More info about API Event Source: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
          Properties:
            Path: /hello
            Method: get
    Metadata:
      Dockerfile: Dockerfile
      DockerContext: ./hello_world
      DockerTag: python3.12-v1

Outputs:
  # ServerlessRestApi is an implicit API created out of Events key under Serverless::Function
  # Find out more about other implicit resources you can reference within SAM
  # https://github.com/awslabs/serverless-application-model/blob/master/docs/internals/generated_resources.rst#api
  HelloWorldApi:
    Description: API Gateway endpoint URL for Prod stage for Hello World function
    Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/"
  HelloWorldFunction:
    Description: Hello World Lambda Function ARN
    Value: !GetAtt HelloWorldFunction.Arn
  HelloWorldFunctionIamRole:
    Description: Implicit IAM Role created for Hello World function
    Value: !GetAtt HelloWorldFunctionRole.Arn

AWS Lambda関数の部分を見てみましょう。

  HelloWorldFunction:
    Type: AWS::Serverless::Function # More info about Function Resource: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction
    Properties:
      PackageType: Image
      Architectures:
      - x86_64
      Events:
        HelloWorld:
          Type: Api # More info about API Event Source: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
          Properties:
            Path: /hello
            Method: get
    Metadata:
      Dockerfile: Dockerfile
      DockerContext: ./hello_world
      DockerTag: python3.12-v1

PackageTypeがImageになっていること、MetadataにDocker関係の情報が記述されているところがポイントでしょうか。

このあたりはこちらに書かれています。

AWS SAM を使用したデフォルトのビルド / コンテナイメージの構築

リソースの方には特に書かれていないようです。

AWS::Serverless::Function - AWS Serverless Application Model

テンプレートから生成されたAWS Lambda関数は特にパラメーターを受け取らないので、少しだけ変更しておきました。

    return {
        "statusCode": 200,
        "body": json.dumps(
            {
                "message": json.loads(event["body"])["message"],
            }
        ),
    }

HTTPメソッドはpostにしておきます。

      Events:
        HelloWorld:
          Type: Api # More info about API Event Source: https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#api
          Properties:
            Path: /hello
            Method: post

では、ビルドします。

$ sam build

zipファイルパッケージをビルドしている時とは、様子が変わりました。

Building codeuri: /path/to/hello-sam-docker runtime: None architecture: x86_64 functions: HelloWorldFunction
Building image for HelloWorldFunction function
Setting DockerBuildArgs for HelloWorldFunction function

コンテナイメージができたみたいです。

Successfully tagged helloworldfunction:python3.12-v1

ちなみにタグは2つできました。

$ docker image ls | grep helloworldfunction
helloworldfunction                          rapid-x86_64         810fef517975   16 minutes ago   519MB
helloworldfunction                          python3.12-v1        92efcda2a0ac   16 minutes ago   501MB

こちらに沿って動かしてみましょう。

sam local コマンドを使用したテストの概要 - AWS Serverless Application Model

sam local invokeから。

sam local invoke を使用したテストの概要 - AWS Serverless Application Model

ペイロードは--event（または-e）オプションでファイルとして渡すのですが、標準入力から与える場合はこうなるようです。

$ echo '{"body": "{\"message\": \"Hello World!!\"}"}' | sam local invoke HelloWorldFunction --event -

HTTPボディを文字列で渡すところが面倒ですね…。

結果。

Reading invoke payload from stdin (you can also pass it from file with --event)
No current session found, using default AWS::AccountId
Invoking Container created from helloworldfunction:python3.12-v1
Building image.................
Using local image: helloworldfunction:rapid-x86_64.

START RequestId: f16edd4a-3c8c-4792-bbb1-9a63cae96adb Version: $LATEST
END RequestId: 75e1ad44-a96d-4a53-a713-7e1d82f3a58c
REPORT RequestId: 75e1ad44-a96d-4a53-a713-7e1d82f3a58c  Init Duration: 0.09 ms  Duration: 51.82 ms      Billed Duration: 52 ms  Memory Size: 128 MB     Max Memory Used: 128 MB
{"statusCode": 200, "body": "{\"message\": \"Hello World!!\"}"}

体感的にはまあまあ重く、5秒くらいかかります。

次はsam local start-api。

sam local start-api を使用したテストの概要 - AWS Serverless Application Model

実行。

$ sam local start-api

Amazon API Gatewayのエミュレーターが起動します。

No current session found, using default AWS::AccountId
Initializing the lambda functions containers.
Building image.................
Using local image: helloworldfunction:rapid-x86_64.

Containers Initialization is done.
Mounting HelloWorldFunction at http://127.0.0.1:3000/hello [POST]
You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions, changes will be reflected
instantly/automatically. If you used sam build before running local commands, you will need to re-run sam build for the changes to be picked up. You only need to restart
SAM CLI if you update your AWS SAM template
2024-12-08 17:14:05 WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on http://127.0.0.1:3000
2024-12-08 17:14:05 Press CTRL+C to quit

確認。

$ curl localhost:3000/hello -d '{"message": "Hello World!!"}'
{"message": "Hello World!!"}

OKですね。

最後はsam local start-lambdaです。

を使用したテストの概要 sam local start-lambda - AWS Serverless Application Model

AWS Lambda環境を起動。

$ sam local start-lambda

これでエンドポイントをhttp://127.0.0.1:3001として、AWS CLIでAWS Lambda関数を呼び出すことができます。

No current session found, using default AWS::AccountId
Initializing the lambda functions containers.
Building image.................
Using local image: helloworldfunction:rapid-x86_64.

Containers Initialization is done.
Starting the Local Lambda Service. You can now invoke your Lambda Functions defined in your template through the endpoint.
2024-12-08 17:15:10 WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on http://127.0.0.1:3001
2024-12-08 17:15:10 Press CTRL+C to quit

呼び出してみます。

$ aws --endpoint-url http://localhost:3001 lambda invoke --function-name HelloWorldFunction --cli-binary-format raw-in-base64-out  --payload '{"body": "{\"message\": \"Hello World!!\"}"}' result.json
{
    "StatusCode": 200
}

OKですね。

$ cat result.json
{"statusCode": 200, "body": "{\"message\": \"Hello World!!\"}"}

おわりに

デプロイパッケージをコンテナイメージとしたAWS Lambda関数をローカルで動かす方法を、いろいろと確認してみました。

LocalStackが使えなかったのでちょっと困ったのですが、Dockerコンテナ単体で確認する方法、AWS SAMを使う方法などの選択肢を
確認できたり、そもそもコンテナイメージをデプロイパッケージにする方法を見てきていなかったのでこの機会に確認できてよかったですね。

ただ、AWS SAMを使うとちょっと重たいのがやや難点でしょうか…。

CLOVER🍀

That was when it all began.