The Lambda service I’m working on has some custom Lambda integration code. Meaning that it typically makes HTTP calls to
$AWS_LAMBDA_RUNTIME_API/2018-06-01/runtime/invocation/next in order to receive the next payload (usually an SQS message). And it uses the same endpoint but with a different path to send responses.
I see that unlike in the AWS Lambda runtime, in LocalStack the
$AWS_LAMBDA_RUNTIME_API environment variable is not defined.
It took me quite a while looking at the LocalStack logs to figure out that the runtime API happens to live under
This isn’t explicitly exposed in any other environment variable. Well, the closest one is
AWS_CONTAINER_CREDENTIALS_FULL_URI which happens to be
One could probably parse this to derive
127.0.0.1:9001. But is that a good idea…?
The way I managed to find port 9001 was by starting Localstack with
LS_LOG=trace and then I found this log line:
[lambda c0aa831e132cdac34629e871ecc35643] time=“2024-01-31T13:42:01Z” level=debug msg=“Runtime API Server listening on 127.0.0.1:9001” func=“go.amzn.com/lambda/rapi.(*Server).Listen” file=“/home/runner/work/lambda-runtime-init/lambda-runtime-init/lambda/rapi/server.go:102”
Hence my attempt to use
127.0.0.1:9001. And indeed, everything works great. My lambda can read requests under
My question is, should this host name (well, localhost) and port be exposed in some environment variable? Probably under
AWS_LAMBDA_RUNTIME_API if you want to allow other companies in a similar situation to have a seamless experience?
You probably already know this but this env var is defined by the AWS lambda runtime and it’s also documented on this AWS page.
Hope this helps anyone else that ran into this.