How I Discovered That the AWS Lambda Runtime Might Be Written in Go
Have you ever wondered how your Lambda function code is triggered?
Each runtime has to conform to the AWS Lambda runtime API.
In managed runtimes, you don’t need to take care of that; that’s the whole point of using a managed runtime! AWS takes care of that for you.
It’s hard to say because it’s not clearly documented. However, while I was conducting some unrelated experiments, I made a very cool discovery! I think you’ll find it interesting too!
If you’re working with Go and care about performance, you might want to look at some important metrics, such as:
- the number of allocations
- the time taken for each init() functions
To do so, you need to setup a environment variable:
And tada 🎉!
In addition to information about the binary I wanted to test, I’m now able to see traces from another binary, which seems to be the one from AWS that conforms to the runtime API.
Here is an example of the output 👀👀👀
init internal/bytealg @0.008 ms, 0 ms clock, 0 bytes, 0 allocs ... init go.amzn.com/lambda/fatalerror @3.7 ms, 0.031 ms clock, 336 bytes, 2 allocs ... init go.amzn.com/lambda/interop @6.5 ms, 0.023 ms clock, 1128 bytes, 32 allocs init go.amzn.com/lambda/telemetry @6.5 ms, 0.067 ms clock, 16 bytes, 1 allocs init go.amzn.com/lambda/core @6.6 ms, 0.007 ms clock, 224 bytes, 12 allocs init go.amzn.com/lambda/rapi/rendering @6.7 ms, 0.086 ms clock, 16 bytes, 1 allocs init go.amzn.com/lambda/rapi/handler @6.8 ms, 0 ms clock, 256 bytes, 2 allocs init go.amzn.com/lambda/rapid @6.8 ms, 0.099 ms clock, 16 bytes, 1 allocs ... INIT_START Runtime Version: nodejs:18.v9 Runtime Version ARN: arn:aws:lambda:us-east-1::runtime:7d5f06b69c951da8a48b926ce280a9daf2e8bb1a74fc4a2672580c787d608206
Here, we can clearly see some explicit package names coming from AWS.
Another important thing to note is that those logs are output BEFORE the
INIT_START log line, which provides further evidence that it might be how AWS Lambda is managing your code!
Voila! 🎉 What do you think?