What is AWS re:Invent?
re:Invent is the big one. It is the annual AWS conference where new services land, existing ones get the features people have been asking for, and Amazon tips its hand on where compute is heading next. Keynotes, deep dives, hands-on labs, and a firehose of launches over a few days in Las Vegas.
re:Invent 2025 opened with one that is worth your attention if you run anything on Lambda: Lambda Managed Instances. The short version is that your Lambda functions can now run on managed EC2 instances. You keep the serverless operational model, and you get access to specific hardware, EC2 pricing, and cost control on steady workloads.
If you have ever had to pull a workload off Lambda because the economics or the hardware did not work, this is aimed squarely at you.
What AWS Announced
You attach a Lambda function to a capacity provider, which is just a managed pool of EC2 instances. You tell AWS what you want:
- Instance types (or include all of them for broad coverage)
- VPC, subnets, and security groups
- Scaling parameters such as max vCPUs or CPU-based policies
From there AWS runs the operational side: provisioning instances, patching the OS, applying security updates, load balancing, and scaling. Instances rotate on a 14-day schedule. Lambda routes requests straight to environments that are already provisioned, so cold starts go away.
There is also multiconcurrency, which means a single execution environment can handle more than one request at a time. That shares resources better and cuts the number of environments you need to serve the same traffic. It is also the part most likely to bite you, but more on that below.
Pricing Model
Three cost components, and it is worth being precise about them:
- Standard Lambda invocation charges
- Standard EC2 instance charges, with full support for Reserved Instances and Compute Savings Plans
- A 15% management fee on top of the EC2 on-demand price
Notice what is missing: there are no duration-based Lambda charges. Compute is billed against EC2, not per-invocation milliseconds. For an always-on or steady workload, that math usually lands in your favor, especially once Savings Plans or RIs are in play.
Why This Matters for AWS Users
More workloads can stay on Lambda
If you moved a workload off Lambda for specialized compute or to cut the per-invocation bill, you no longer have to. You can stay serverless and still get current EC2 hardware, Graviton4 included.
A real middle ground between serverless and EC2
This sits between event-driven Lambda and a fully managed EC2 fleet. You keep serverless operations, with no servers to patch or scale yourself, while still picking the compute characteristics you actually need.
A better fit for steady or predictable traffic
Multiconcurrency plus EC2-based capacity plus long-term pricing is a good combination for workloads with stable traffic or tight cost requirements. This is not the model for spiky, occasional invocations.
Some code will need changes
Here is the catch. Multiple requests can run inside the same execution environment, so any code that leans on shared state can produce concurrency bugs that never showed up under one-request-per-environment Lambda. Audit for that before you migrate anything. It is the single most important thing to check.
How It Scales
When traffic climbs, AWS adds EC2 instances to the capacity provider within seconds. It absorbs up to a 50% increase without scaling at all. Built-in circuit breakers only start throttling once the provider hits its maximum capacity during an extreme surge.
Your monitoring, permissions, and deployment workflows do not change. They are the same as standard Lambda. The first release supports Node.js, Python, Java, and .NET.
Who Might Benefit Most
This is a good fit if you run:
- High-traffic applications with predictable load
- Data-intensive or network-heavy workloads
- Architectures built on newer hardware like Graviton4
- Workloads where Savings Plans or RIs actually move the bill
- Functions that have outgrown the standard concurrency model
It does not replace standard Lambda or EC2. It is another point on the compute spectrum, and a useful one.
A Meaningful Expansion of Serverless
The interesting part is what this does to the word “serverless.” AWS is no longer tying it to one execution engine. Serverless becomes an operational contract: AWS runs the infrastructure, whatever that infrastructure happens to be.
That widens the set of applications that can use Lambda patterns without surrendering compute flexibility or cost control. If it matures the way it looks like it will, expect it to change how teams design and run cloud-native workloads.
Trying to figure out whether your Lambda workloads belong on Managed Instances, or whether the concurrency changes are worth the migration? That is the kind of call we make every week. Forged Concepts’ AWS DevOps services can help you check the economics, audit your code for shared-state issues, and move what makes sense. Contact us and we will take a look at your setup.