In October we laid out why we build client backends on AWS Lambda, API Gateway, DynamoDB and S3: start at a few dollars a month, scale without rewriting. That post also carried two quiet caveats we did not dwell on. Lambda has cold starts, and at high steady traffic its per-millisecond pricing stops being the cheapest option. And any workflow with more than one step, especially one that waits on a human, meant reaching for Step Functions and a state machine.
It is re:Invent week, and AWS has answered both. Lambda Managed Instances and Lambda durable functions are the two announcements we care about most, because they change what "serverless" can mean for a client at different stages of growth.
Managed Instances: Lambda's Code, EC2's Economics
Standard Lambda runs your function in an execution environment that handles one request at a time and disappears when idle. That is why it is cheap at low traffic and why the first request after a quiet spell is slow.
Managed Instances keep the function exactly as it is and run it on EC2 instances inside your account instead. AWS still does the boring parts: provisioning the instances, patching the operating system, load balancing, scaling up and down, and recycling every instance within 14 days. What changes underneath:
- Multiple concurrent requests per environment. One warm process serves many requests, the way a traditional server does.
- No cold starts. Environments are provisioned ahead of demand.
- Your choice of hardware. The latest EC2 generations, including Graviton4, and you can include or exclude instance types.
- Different pricing. $0.20 per million invocations, plus the EC2 instance cost, plus a 15% management fee on the on-demand price. There is no per-millisecond duration charge. Compute Savings Plans and Reserved Instances apply, which AWS says can take up to 72% off the instance component.
Setup is a capacity provider that defines the VPC, subnets, security groups, instance types and a maximum vCPU count. You attach a function to it by ARN and pick a memory-to-vCPU ratio. It works from the console, the CLI, CloudFormation, SAM, CDK and Terraform. Existing functions move over without code changes, with one condition we will come back to.
When We Would Switch a Client Over
This is a Cruise & Maintenance decision, not a day-one one.
In our October post we described the growth phases of a typical client backend. In the MVP and early traction phases, standard Lambda wins by a mile. You pay for milliseconds of compute you actually use, and there is not enough traffic for cold starts to matter.
Managed Instances become interesting around the product-market fit phase, when traffic is steady enough that an instance would be busy most of the time. At that point the per-invocation plus instance model can undercut per-millisecond pricing, and the absence of cold starts fixes the p99 latency complaints that show up the same week. The best part is that the migration is a configuration change on the same function. No rewrite, no second codebase, no "we outgrew serverless" conversation.
The condition: the function has to be thread safe. Standard Lambda let people get away with global variables and temp files that assumed one request at a time. Under multi-concurrency those become bugs. We write functions stateless from the start, so for our builds this is a checklist item, not a project.
Durable Functions: Multi-Step Workflows Without a State Machine
The second announcement solves a different problem. A lot of what we build under AI Automation is a sequence: receive a request, call a model, wait for a person to approve, call another system, retry if it fails, finish days later. Lambda's 15-minute limit made that impossible in one function, so the answer was a Step Functions state machine wired around several small ones.
Durable functions are ordinary Lambda functions with a checkpoint-and-replay runtime underneath. You write normal code and wrap the important bits:
context.step()marks a unit of work. It is checkpointed, so if the function fails and replays, completed steps are skipped, and it retries automatically.context.wait()pauses for a duration. The function stops running, you stop paying for compute, and it resumes later.create_callback()waits for an outside event, such as a human clicking approve or a payment provider calling back.wait_for_condition()polls until something is true.parallel()andmap()fan work out.
A function can stay suspended for up to a year, and AWS charges nothing for compute while it waits. Node.js 22 and 24 and Python 3.13 and 3.14 are supported at launch, with open source SDKs.
For the assistants and automations we build, this is the missing piece. An approval flow becomes one readable file: call the model, checkpoint, wait for the approver's callback, checkpoint, act. An agent loop that talks to three external APIs gets retries and resumability for free. The logic lives in code a developer can read, rather than in a JSON state machine that only the person who wrote it understands.
The Catches
Neither feature is ready for an Australian client this week, and it is worth being straight about that.
Regions. Managed Instances launched in Northern Virginia, Ohio, Oregon, Tokyo and Ireland. Durable functions launched in Ohio only. There is no Sydney for either. For a client with data residency requirements, or one whose users are in Australia and would notice the round trip, we wait for the regional rollout.
Durable execution is a creation-time setting. You cannot flip an existing function to durable. It has to be created that way, so the decision belongs in the architecture overview, not in a later sprint.
Replay needs discipline. Because durable functions replay from checkpoints, changing the code of a function with in-flight executions can break the replay. AWS's guidance is to use function versions in production. That is a deployment practice, and it needs to be in the CI/CD pipeline from the start.
Thread safety, as above, for anything moving to Managed Instances.
What Changes in Our Flight Plans
Starting this week, the architecture overview we produce in a Flight Plan carries two new options.
For the API layer: standard Lambda to start, with a note on the traffic level at which Managed Instances become the cheaper choice and a plan to switch without a rewrite.
For workflows: durable functions as the default for approvals, long-running agent tasks and anything that waits on the outside world, once the Sydney region lands. Until then, Step Functions where residency matters and durable functions where it does not.
Same code, more room to grow. That has always been the promise of serverless, and this week it got closer to true.
Let's Build Your Backend on the New Lambda
At Dev Force One, we design AWS backends that start small and scale without a rewrite, and re:Invent just gave us two more ways to keep that promise.
What we bring:
- Serverless architectures on Lambda, API Gateway, DynamoDB and S3, with a growth path to Managed Instances
- AI Automation workflows built as readable durable functions rather than state machines
- Cost and performance tuning in Cruise & Maintenance, so infrastructure spend tracks your traffic
Planning a build, or wondering whether your current backend will hold? Book a Pre-flight call and we will walk through it together.