Lambda vs Containers: The Break-Even Is 46% Duty Cycle, Not 15%
Run the two rate cards against each other and Lambda costs 2.15 times Fargate for the same CPU and memory, so it stays cheaper until the function is busy nearly half the time. Lambda Managed Instances lands within 1% of Fargate, which is not where the announcement pointed.
The usual version of this question is “how many invocations before Lambda gets expensive,” and it has no answer, because a 40ms function at 128 MB and an 8 second PDF render at 2 GB are the same invocation count and nowhere near the same bill. The question that does have an answer is what fraction of a continuously running machine your functions add up to.
There is also a newer problem with the question. Lambda is not one pricing model any more. It is five, and three of them did not exist when most of the comparisons on this topic were written. Every rate below came from the AWS price list files for us-east-1 and the Lambda pricing page on 22 August 2026.
Put both rate cards in the same unit
Lambda charges $0.0000166667 per GB-second on x86 and $0.0000133334 on Arm. Multiply by 3,600 and it becomes a familiar shape: $0.06 per GB-hour on x86, $0.048 on Arm, for as long as the function is actually executing.
Fargate charges $0.04048 per vCPU-hour and $0.004445 per GB-hour in us-east-1, with the Arm rates 20% lower at $0.03238 and $0.00356.
The two are still not directly comparable, because Lambda does not sell you CPU. It gives you CPU in proportion to memory, and the AWS docs put the ratio at 1,769 MB per vCPU. So size a Fargate task at the same 1 vCPU and 1.73 GB and compare per hour:
| Same shape, per hour | x86 | Arm |
|---|---|---|
| Lambda while executing | $0.1036 | $0.0829 |
| Fargate, running or not | $0.0482 | $0.0385 |
| Lambda ÷ Fargate | 2.15× | 2.15× |
Lambda costs 2.15 times as much per unit of compute delivered. The architecture discount is identical on both sides, so the ratio does not move. Turn it upside down and you get the number this question actually wants: the break-even is a duty cycle of 46%. Below that, Lambda is cheaper. Above it, you are paying serverless rates for something that never really idles.
You can compute your own without guessing. Take a function’s monthly GB-seconds from Cost Explorer and divide by its memory in GB times 2,628,000, the number of seconds in a 730 hour month. That fraction is the duty cycle. A function at 5% is not worth migrating no matter how many invocations it serves. A function at 60% is a container that has not admitted it yet.
The rule of thumb going around, that Lambda starts losing somewhere above a 10 to 15% duty cycle, is off by a factor of three on compute alone. It only gets close once you add the services standing around Lambda, and those are worth pricing separately rather than folding into one number.
Managed Instances is priced like Fargate, not like EC2
The pitch for Lambda Managed Instances is Lambda’s programming model on EC2 economics: requests at $0.20 per million, standard EC2 instance charges, and a 15% management fee. Savings Plans and Reserved Instances apply, which classic Lambda never allowed.
Price a concrete shape. An m7g.xlarge is 4 vCPU and 16 GB at $0.1632 an hour on demand in us-east-1.
| 4 vCPU, 16 GB, us-east-1 | Per hour | Per 730 hours |
|---|---|---|
EC2 m7g.xlarge on demand | $0.1632 | $119.14 |
| Lambda Managed Instances on that instance | $0.1877 | $137.01 |
| Fargate, Arm, same shape | $0.1865 | $136.13 |
| Fargate, x86, same shape | $0.2330 | $170.12 |
Managed Instances and Fargate land within 0.6% of each other. The framing that Fargate carries a 20 to 30% premium over EC2 does not survive the current rate card either: Arm Fargate is 14% over the equivalent Graviton instance, x86 Fargate 16% over an m7i.xlarge. Two managed container products, priced the same, one of them wearing a Lambda badge.
The Savings Plan story has a wrinkle that AWS’s own worked example makes plain. The management fee is 15% of the on-demand price, not of what you pay. In their example a 3 year Compute Savings Plan takes the instance from $0.1632 to $0.0457 an hour while the fee stays at $0.02448. Over their 2,000 instance-hours that is $91.40 of compute and $48.96 of fee. The 15% premium has quietly become 54% of the compute bill, and the harder you discount the instance, the larger that share gets.
None of which makes it a bad product. If you want the Lambda programming model, event source mappings included, on hardware you choose, this is the only way to buy it. Just do not budget it as EC2 plus a rounding error.
The meters around Lambda, which is where the 15% rule came from
The compute line is rarely the whole bill, and every service below is billed by time or volume rather than by invocation.
API Gateway REST APIs cost $3.50 per million requests for the first 333 million, which is 17.5 times Lambda’s own $0.20 request charge. HTTP APIs are $1.00 per million. On a request-heavy API the gateway can outspend the compute it fronts, and a function URL or an ALB removes the line entirely.
NAT Gateway is $0.045 per hour plus $0.045 per GB processed, so $32.85 a month appears the moment a function needs a VPC to reach a private database. That is a fixed hourly charge attached to the service you chose for having no fixed charges. There is now also a provisioned bandwidth mode at $1.076 per Gbps-hour with no per-GB charge, effective 1 August 2026. At $0.045 per GB, one provisioned Gbps-hour pays for itself at 24 GB, against the 450 GB that a fully used Gbps carries in an hour, so anything moving real volume through NAT should be priced both ways.
CloudWatch Logs ingestion is $0.50 per GB on the standard class and $0.25 on Infrequent Access, with 5 GB a month free, storage at $0.03 per GB-month, and Logs Insights queries at $0.005 per GB scanned. Switching a chatty function’s log group to Infrequent Access halves the largest of those without touching the code.
Provisioned concurrency, the fix for cold starts, is $0.0000041667 per GB-second, which is $0.015 per GB-hour: exactly 25% of the x86 running rate, charged whether or not a request arrives, and you still pay duration on top when one does. It is a fixed cost in serverless clothing.
One last counting rule that surprises people. For asynchronous events you are charged one request per event for the first 256 KB, then one additional request per 64 KB up to 1 MB. A 1 MB event from S3 or EventBridge bills as 13 requests, not one.
Two details in the duration meter itself
Duration is tiered: on x86 the first 6 billion GB-seconds a month are $0.0000166667, the next 9 billion are $0.0000150000, and beyond 15 billion it is $0.0000133334. Arm has the same three steps at 7.5 and 18.75 billion. That is real money only at large scale, but the tiering rule matters sooner than the tiers do, because tiers accumulate per architecture, per region, per account, or across an organization under consolidated billing. A fleet split between x86 and Arm makes progress on two counters instead of one.
And the free tier is still in the price list rather than being a promotional credit: the first million requests and the first 400,000 GB-seconds each month are priced at zero.
What the invoice does not price
Cold starts are the honest cost on the Lambda side. A function that has been idle spins up a fresh execution environment before it answers, and for a heavy runtime inside a VPC that tail can be a second or more. For a nightly job it costs nothing that matters. For a user-facing endpoint with a latency target it is the whole argument, and the standard fix reintroduces the fixed cost above.
Containers charge you in a currency AWS does not invoice: someone owns the base image, the patch cadence, the task sizing, the autoscaling policy. On a three person team that afternoon is worth more than the difference between $60 and $28 a month, which is why the compute break-even is a floor for the decision and not the decision.
The split that usually survives contact with a real system is boring. Spiky, event-driven, low duty cycle work stays on Lambda: webhooks, scheduled jobs, glue between services, anything with a quiet night. Sustained high-throughput work moves to containers, or to Managed Instances if the Lambda programming model is what you are keeping. Nothing rewards going all in either direction.
Pull your three most expensive functions, divide their monthly GB-seconds by memory times 2,628,000, and see where they sit against 46%. If one of them is running hot around the clock, the migration argument is already written.