Lambda Gets Some Love
By Chris Dobson
Hello, you!
Hot on the heels of last week’s issue of we’re back in record time for another AWSCQ.
This time we’ve got Returning comsum speaker, Oasis devotee and all round brilliant bloke, Chris Dobson.
Chris is a Senior Software Engineer at Trustpilot, AWS Community Builder and AWS Certified Solutions Architect Pro. It’s fair to say the man knows his onions - so we’ve super thankful for his contribution.
Before we hand over the reigns just a wee reminder that we’ve our first AWS Community Summit: Birmingham this June. Early Bird tickets available on the comsum site!
Righto - thats enough plugging from us!
Ok over to you, Chris!
Introduction
I’ve resisted the urge to write something to do with AI. I know it’s 2026 and there doesn’t seem to be anything else going on in the world of software but I’ve managed to find something interesting, or at least I find it interesting. So I’m going to look at one of my favourite things - AWS Lambda - and how it’s been getting some love during its tween years. I’m going to look at a couple of big releases from re:Invent along with something that seems to have flown under the radar, and then see if there’s anything in the roadmap that gives away what may be coming next as it approaches those difficult teenage years…
I will take a look at three recent releases for Lambda; Lambda Managed Instances, Lambda Durable Functions and Tenant Isolation.
Lambda Managed Instances
I remember a few years ago following a P1 incident reading something written by a platform engineer that the cause of the incident was that ‘Lambda was evil’; I’ll be honest I thought evil was probably a bit much but the crux of the statement was that cold starts along with having no control over the execution environment meant that using Lambda over, presumably, containers was causing a problem.
I’m not sure how true that statement actually was but if it was then Lambda Managed Instances ought to go some way to allaying those concerns.
Lambda Managed Instances combine the serverless Lambda programming model that we all know and love with the flexibility of EC2 instances. Put simply it allows you to run your Lambda functions on a range of EC2 instances that you can select depending on the compute you require. Unlike a regular Lambda function an EC2 execution environment can handle multiple function executions concurrently which should reduce cold starts and maybe help anyone who thinks Lambda is evil change their opinion! Also unlike a regular Lambda you’ll be paying for uptime rather than execution time which may well only make sense when running a continuous high throughput.
Currently in my organisation we use two different methods of consuming SQS messages - one being a regular Lambda using an SQS event source and services running inside an ECS container that have to handle the reading and deleting of messages themselves. The containers are generally used for large volume/performance critical queues and I’m looking forward to testing out whether we could replace these with Lambda Managed Instances which would meant that we wouldn’t have to worry about the message handling code and if we discovered that, in fact, the process would still perform well and cost effectively without the instance then the same code could simply be deployed as a ‘regular’ Lambda.
What you need to know about Lambda Managed Instances
Introducing Managed instances in the Cloud
Lambda Durable Functions
Have you ever been authoring a Step Function State Machine in the designer and trying to do something a little complex with some of the Flow States (Choice, Pass etc.) and thought I wish I could write this in code? Then, of course, you go to the Code tab in the designer and try and edit the ASL and start losing the will to live so go back into the designer and end up with something like this:
The good news is that if you’re like me and would love to have the orchestration capabilities of Step Functions but be able to author using a language you know and love now you can (as long as that language is Javascript or Python anyway!).
The Durable Function extension to Lambda adds capabilities to a Lambda execution to do pretty much everything a Step Function can - simple steps, wait for duration, wait for callback, execute in parallel, execute a map along with a neat way to poll until a condition is met.
All of these get retry and error handling capabilities as well.
Like Step Functions a Durable Function can also run for up to a year. “How much will that cost?” I hear you cry - the Checkpoint/Relay execution model solves this by allowing the function to pause execution while waiting meaning that it’s only executing and therefore charging when doing something. It does mean we have to be a bit careful with idempotency but we always are aren’t we?
To deploy a Lambda as a Durable Function is pretty simple:
From the console there’s a checkbox to ‘Enable durable execution’
The CLI has a new flag; `--durable-config`
CDK adds a `durableConfig` parameter
CloudFormation adds the same parameter except in Pascal Case!
Some time ago my team was asked to implement a workflow that would span around 60 days performing different actions at various points. Our team’s first thought was, quite naturally, that this sounds like a Step Function right up until we read the fine print (or requirements if you prefer to call it that) and, as so often happens, our product manager had decided to spoil our fun. There was a requirement that if there was a change made to the workflow then any currently executing workflows would need to run the new version; unfortunately Step Functions doesn’t support such a thing. When I was first experimenting with Durable Functions that project popped into my mind and given how the Checkpoint/Relay execution model works I figured it ought to be possible - and it was! So if you’re executing the $LATEST or an alias to $LATEST then any changes made to that version of the Lambda will be used in the next Replay - including anything added to execute prior to the last checkpoint - which has made me very happy. Equally if you don’t want this then execute a specific version number and your workflow will always run that one.
You can probably tell I’ve become quite a fan of Durable Functions and they are a very welcome addition to my toolkit.
Migrating a Lambda to a Durable Function
Workflow orchestration with Lambda Durable Functions
Building AI Video Generation Pipelines with AWS Lambda Durable Functions
Tenant Isolation
This release seems to have flown under the radar a little; at least I’ve not seen it mentioned too much but it sounds like a good addition.
Often in multi-tenant SAAS applications dealing with private or sensitive data there can be a requirement to have strict isolation when processing data for individual tenants or even specific users. This has generally made multi-tenant apps with these requirements quite tricky to build but this is where Lambs Tenant Isolation comes in.
A ‘tenant identifier’ is used to route requests to execution environments isolated to that specific tenant - so if an environment for that tenant already exists then that is used otherwise a new one is created that will only be used for that tenant.
How do I invoke a function with a ‘tenant identifier’?, well it depends how you’re invoking the function - the SDKs and CLI have been updated to accept a tenant id parameter, the API accepts a new X-Amz-Tenant-Id header and when using API Gateway you can map a custom header to the X-Amz-Tenant-Id header. The tenant id is a string so you can create it as fine-grained as you like - for instance a JWT token could be used to isolate by user. If you’re worried about cold starts be careful how fine-grained you go though as the more different tenant IDs you’re using the less likely there is to be an execution environment waiting, also functions using Provisioned Concurrency and SnapStart aren’t supported so you can’t rely on those!
All in all Tenant Isolation looks to be a really useful addition for those of us building multi-tenant SAAS.
Understanding Lambda Tenant Isolation
AWS Lambda Tenant Isolation - Simply Explained
What’s next?
Looking at the Lambda roadmap that has beeb published on Github on interesting item that is now in developer preview is the Java SDK for Durable Functions so if you’d rather not use Javascript or Python to build your Durable Functions you’ll soon have another option.
A few things have caught my eye in the ‘Researching’ lane:
Better OTel support would be awesome - currently the only way seems to be adding a layer containing a server which takes some time to start up only making those cold start woes worse.
I’ve done my best not to mention anything around AI but the Managed Serverless MCP Server certainly sounds interesting
CloudEvents and custom event schemas
Rust and Go SDKs for Durable Functions adding more options when building a Durable Function - no sign of .NET yet though
Adding a Cold Start option to the console sounds like a small thing that could reduce that all important developer feedback loop
Final Thoughts
I think that with all of the talk around AI - which I love using by the way, I’m most definitely not a hater of anything that makes me that much more productive - it’s great to see that Lambda has been getting some serious enhancements that are dealing with real problems. As Lambda turns 12 this year I’ll be very interested to see if this investment in it continues as it becomes a teenager or should we just expect a new ItsSoUnfairException error to be thrown when trying to make it execute before midday?
And that’s all for another AWSCQ!
Huge thanks to Chris for putting this all together.
We’ll see you all soon for another fantastic issue soon.
Thanks as always to our fabulous sponsors!
