Persistent Data in Lambda. It Works!

Common wisdom is that a request to a Lambda function lives in a sandbox. It is created and destroyed for each call. False.

One of my teammates asked me if it was possible to persist data between multiple requests to a Lambda function. The general perception is absolutely not! In this serverless environment, Lambda is going to fire up and destroy the resource on demand. Therefore there is no shared state or persistence.

But this isn’t really true in practice.

I explained to my co-worker that, while it can’t be counted on, Amazon will actually re-use the same instance between requests. When Amazon retrieves a Lambda from cold storage, it creates a small instance where this function runs. There it stays in warm storage for some period of time until either the requests stop and AWS returns it to cold storage or more requests come in and it gets scaled out to multiple instances.

But you can see in a very simple example that you can keep data (and even state) around from one call to the next.

You’d expect this function to return an HTTP response with “1” each time, if the Lambda was created and destroyed each time. However, if you put this request in a Lambda with an API Gateway endpoint in front of it, the first time it loads you see “1” as expected. But the second, third, fourth time you refresh the page it will continue to increment!

This will not carry on indefinitely. As soon as it gets cold or scales out it will reset. So it’s not exactly predictable. But pretty cool regardless!

I’m not sure what I’m suggesting for a use case here, but there could be some. Maybe you want to use it to cache something temporarily. Or maybe very short term sessions for Lambdas that don’t get a lot of traffic.

Definitely don’t rely on it always working the way you’d expect. But… hey… it does work!