On September 9, 2026, AWS quietly added Graviton5 support to Lambda Managed Instances, letting functions run on C9g, C9gd, M9g, and M9gd instances for up to 25% better compute performance than the Graviton4 generation. The instance-family update is the headline. The part that matters to whoever owns the bill is quieter: serverless now has two pricing models, and they behave nothing alike.
Classic Lambda bills by the millisecond. You pay $0.20 per million requests plus a duration charge of $0.0000133334 per GB-second on Arm, roughly 20% below the x86 rate, per CloudZero’s 2026 pricing breakdown. Scale to zero when idle, pay nothing. That model rewards spiky, event-driven work and punishes anything that runs flat out around the clock.
Lambda Managed Instances, which AWS launched on November 30, 2025, throws that meter out. Your functions run on EC2 instances that AWS provisions, patches, and autoscales for you, and you pay standard EC2 instance prices instead of duration. The Graviton5 announcement is the moment the cheaper, faster hardware showed up inside that model. Whether it saves you money depends entirely on the shape of your workload, and the break-even is yours to calculate because AWS does not ship a calculator for it.
The bill stops counting milliseconds
Under Managed Instances there are three charges: $0.20 per million requests, standard on-demand EC2 pricing for the instances Lambda runs on your behalf, and a 15% management fee layered on top of that EC2 price. Duration is not billed at all. That single omission is the whole story.
With per-millisecond billing, a function that runs continuously pays for every one of those milliseconds. With instance billing, you pay for the box whether it handles one request per second or four hundred. The economics flip depending on how busy the box stays. A function sitting near full utilization was already paying near-continuous duration under the old model, so moving it to an instance you were effectively renting full-time changes little about what you consume and a lot about how it is priced. A function that fires a few thousand times a day and sleeps the rest is a disaster on an always-on instance and belongs on the classic meter.
Where the 15% management fee actually lands
The management fee has a detail worth reading twice. It is calculated on the on-demand EC2 price, and it stays there even when you apply a Compute Savings Plan or Reserved Instance discount to the underlying instance, per CloudZero. Buy a Savings Plan that cuts your EC2 rate 40%, and your instance usage drops accordingly, but the 15% surcharge is still figured against the full on-demand number.
That does not make the fee a bad deal. You are buying away instance lifecycle management, OS patching, routing, load balancing, and autoscaling, which is real operational cost you would otherwise carry. It does mean the headline “just apply your Savings Plan” understates the true rate by a few points. When you model a migration, apply the discount to the instance line, then add 15% of the pre-discount price back on top. That is the number your forecast has to survive.
The upside is genuine, though: because the EC2 portion is standard EC2, Compute Savings Plans and Reserved Instances apply to serverless compute for the first time. Teams that already run a commitment portfolio can fold steady Lambda load into it. If you are still deciding how to structure those commitments, the reserved instances versus savings plans trade-off carries straight over to this workload.
The always-on math that makes this worth it
Take a single function pinned at 1,769 MB, the memory setting where Lambda allocates roughly one full vCPU. Run it continuously for a 30-day month and it consumes about 4.47 million GB-seconds. At the Arm duration rate that is close to $60 a month in duration alone, before requests, for one unit of always-on concurrency. Need ten concurrent executions held open around the clock and you are near $600 a month in duration, and that line grows linearly with every additional concurrent slot you keep warm.
That is the spend Managed Instances is built to undercut. Once a workload is genuinely always-on, you stop paying for time and start paying for a box, and a right-sized Graviton5 instance covered by a Savings Plan can land well under the equivalent duration bill. This is the same instinct behind rooting out idle GPU pods in Kubernetes: the moment compute stops scaling to zero, per-second pricing quietly becomes the most expensive option on the menu.
I have watched this exact surprise land on a finance team. In a fractional COO engagement through Ops Harmony, a client had ported a steady internal API to serverless expecting the pay-per-use story, then opened a bill dominated by duration on a function that never actually idled. The workload was serverless in deployment and always-on in reality. Nobody had checked which one the pricing model assumed.
Three ways this backfires
Managed Instances is not a free upgrade, and three workload shapes make it more expensive, not less.
Spiky or bursty traffic loses. If your function idles most of the day and spikes at intervals, classic Lambda’s scale-to-zero is the feature you are paying for. An instance sitting idle between bursts bills the whole time.
Low-volume functions lose on the floor. Managed Instances does not scale to zero, so a dev, staging, and production trio carries a baseline instance cost even at zero traffic, plus VPC plumbing. The tradeoff analysis at RanTheBuilder puts a NAT gateway near $32 a month and CloudWatch and X-Ray endpoints at another $28 to $40, a fixed toll three times over across environments before a single request arrives.
Over-provisioned instances lose silently. Per-millisecond billing punished bloated memory settings immediately and visibly. Instance billing hides the same waste inside a box you have already committed to, so a function that needs half a vCPU running on an instance sized for four is invisible drag until someone audits utilization.
What Graviton5 changes about the decision
The September 9 update does not change the model. It sharpens the trade-off. Graviton5 delivers up to 25% better compute performance than Graviton4, with AWS citing up to 35% for web applications and machine learning inference and up to 30% for databases. More performance per instance means a steady workload can often fit on a smaller box, and a smaller box lowers both the EC2 line and the 15% fee riding on it.
You enable it by naming a Graviton5 type when you create a capacity provider, or by leaving the instance type on default and letting Lambda fold Graviton5 into the pool it selects from based on your function’s architecture, memory, and memory-to-vCPU ratio. For an always-on function already worth moving off duration billing, Graviton5 is the version of that move that costs the least. It does nothing for a bursty function, because that function should never have left the classic meter.
The number to watch before you migrate
The decision comes down to one ratio: how close does this function run to full utilization, and how steadily. Pull duration and concurrency for the candidate function over a representative month. If it is billing near-continuous duration and holding warm concurrency around the clock, model the Managed Instances cost with the instance line, the request line, and 15% of the pre-discount EC2 price, then compare. If it idles, spikes, or runs at a fraction of capacity, leave it where it is.
AWS did not replace serverless pricing. It forked it, and handed the fork to whoever reads the bill. The teams that win here are the ones that already know, per function, whether the thing they call serverless actually behaves that way. That habit of matching the pricing model to the real usage curve is the whole of what FinOps asks of a technology organization, and it is the same discipline behind treating cloud commitments as a portfolio rather than a default. The tooling to automate the call will come; AWS is already writing optimization agents for exactly this kind of decision. Until then, the math is manual, and it is worth doing before the invoice does it for you.