Every team that runs containers on AWS eventually argues about this, and the argument almost never ends in a number. The reason is that Lambda vs Fargate vs EC2 cost cannot be compared directly: one bills GB-seconds of configured memory, one bills vCPU-hours and GB-hours, and one bills instance-hours whether you use them or not. This post normalizes all three to the same unit, prices them against AWS list prices read on 17 September 2026, and gives you the exact point where each one stops being the cheap option. Every number below comes with the arithmetic, so you can re-run it against your own traffic.
The short version, for anyone who wants it before the tables: Lambda wins below roughly 45% busy time, Fargate is no longer the expensive middle option it used to be, and EC2 only pulls decisively ahead once a Savings Plan is involved.
Where These 2026 Prices Came From
Prices are the part of this post that rots, so here is exactly what was read and when.
Prices read 2026-09-17, region us-east-1 (N. Virginia), Linux, public list price
Source: AWS Price List Query API, offer files
AWSLambda publicationDate 2026-09-11T17:35:10Z
AmazonECS (Fargate) publicationDate 2026-09-11T12:44:25Z
AmazonEC2 on-demand publicationDate 2026-09-10T19:55:14Z
AWSComputeSavingsPlan publicationDate 2026-09-10T18:08:14Z
No volume, enterprise, Spot or private-pricing discount applied.
Next scheduled re-read: 2026-12-17
Those files are public and need no credentials. For example:
# Every Lambda rate for us-east-1, straight from the source AWS bills against
curl -s https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AWSLambda/current/us-east-1/index.json \
| grep -o '"description" : "AWS Lambda[^"]*"' | sort -u
Reading the offer file rather than the marketing page matters, because the published pricing pages render their tables in JavaScript and often omit the Arm tier entirely. The offer file carries every rate AWS actually meters, including ones that never appear on a pricing page.
The Three Billing Models, Side by Side
Before any arithmetic, it helps to see what each service is actually selling. The billing unit is the whole story.
| Lambda (default) | Fargate | EC2 | |
|---|---|---|---|
| Billing unit | GB-second of configured memory, per 1 ms | vCPU-hour plus GB-hour, per second | Instance-hour, per second |
| Smallest unit you can buy | 128 MB function | 0.25 vCPU with 0.5 GB task | One instance |
| Scales to zero | Yes | No | No |
| Cost while idle | None | Full task price | Full instance price |
| Cold starts | Yes | Task startup only | None once running |
| OS and runtime patching | AWS | AWS | You |
| 1-year Compute Savings Plan discount | 11.8% | 20.0% | 26% to 28% |
That last row is the one most comparisons get wrong, and it is worth the section it gets later. The headline rates are not the rates a committed team pays.
The Unit That Makes Them Comparable
Lambda does not sell vCPUs, but it does allocate them. AWS documents that “at 1,769 MB, a function has the equivalent of one vCPU (one vCPU-second of credits per second)”, and that CPU is allocated in proportion to memory across the 128 MB to 10,240 MB range.
That single sentence gives us a common denominator. One vCPU plus 2 GB of memory is a unit all three services can quote:
- On Lambda, it is a function configured at 1,769 MB, billed only while it runs.
- On Fargate, it is a task sized at 1 vCPU and 2 GB, billed for its whole lifetime.
- On EC2, it is half of any
.largeinstance with 2 vCPUs and at least 4 GB.
Everything that follows prices that one slot, then adjusts for how much of the time you actually need it.
Lambda Pricing, Read on 17 September 2026
Lambda duration is tiered, and the Arm tier boundaries sit higher than the x86 ones, which is a detail the Lambda pricing page buries. All rates are us-east-1.
| Charge | x86 | Arm (Graviton) |
|---|---|---|
| Duration, tier 1 | $0.0000166667 per GB-s (first 6B) | $0.0000133334 per GB-s (first 7.5B) |
| Duration, tier 2 | $0.0000150000 per GB-s (6B to 15B) | $0.0000120001 per GB-s (7.5B to 18.75B) |
| Duration, tier 3 | $0.0000133334 per GB-s (over 15B) | $0.0000106667 per GB-s (over 18.75B) |
| Requests | $0.20 per million | $0.20 per million |
| Provisioned concurrency | $0.0000041667 per GB-s | $0.0000033334 per GB-s |
| Duration under provisioned concurrency | $0.0000097222 per GB-s | $0.0000077778 per GB-s |
| Ephemeral storage above 512 MB | $0.0000000309 per GB-s | $0.0000000309 per GB-s |
Two things fall out of that table immediately. First, Arm is 20% cheaper on duration at every tier, and requests cost the same, so moving a pure-compute function to Graviton is close to free money. Second, provisioned concurrency inverts the usual advice: with it enabled, duration drops to $0.0000097222 per GB-s but you also pay $0.0000041667 per GB-s around the clock. Consequently, provisioned concurrency only pays for itself above roughly 60% busy time, at which point you should be reading the Fargate section instead.
Fargate Pricing, Read on 17 September 2026
Fargate’s rate card is short, which is most of its appeal.
| Charge | x86 | Arm (Graviton) |
|---|---|---|
| vCPU | $0.04048 per vCPU-hour | $0.03238 per vCPU-hour |
| Memory | $0.004445 per GB-hour | $0.00356 per GB-hour |
| Ephemeral storage above 20 GB | $0.000111 per GB-hour | $0.000111 per GB-hour |
Task sizes are not continuous, though. The ECS documentation fixes the valid combinations: 0.25 vCPU takes 512 MB, 1 GB or 2 GB; 1 vCPU takes 2 GB through 8 GB; 2 vCPU takes 4 GB to 16 GB in 1 GB steps, and so on up to 32 vCPU. Therefore a workload that wants 1 vCPU and 1 GB has to buy 2 GB, and that rounding is real money at scale.
The standard slot used throughout this post, a 1 vCPU and 2 GB task, prices out at $0.049370 per hour on x86 and $0.039500 per hour on Arm, or $36.04 and $28.84 a month at 730 hours.
EC2 Pricing, Read on 17 September 2026
These are on-demand Linux prices for the instances a container workload would realistically land on. The Savings Plan column is a 1-year, no-upfront Compute Savings Plan, pulled from the same API.
| Instance | vCPU | Memory | On-demand /hr | 1-yr no-upfront SP /hr |
|---|---|---|---|---|
| t4g.small | 2 (burstable) | 2 GiB | $0.0168 | $0.0121 |
| t4g.medium | 2 (burstable) | 4 GiB | $0.0336 | not pulled |
| c8g.large | 2 | 4 GiB | $0.07976 | $0.05718 |
| m8g.large | 2 | 8 GiB | $0.08976 | $0.06594 |
| c9g.large | 2 | 4 GiB | $0.08694 | not pulled |
| c8i.large | 2 | 4 GiB | $0.09371 | not pulled |
| m8i.large | 2 | 8 GiB | $0.10584 | not pulled |
Notice that c9g.large, the newer Graviton generation, costs 9% more per hour than c8g.large. Newer is not automatically cheaper per slot; it is cheaper per unit of work only if your workload actually uses the extra performance.
The Crossover Script
Rather than assert break-even points, here is the script that produces them. It is plain POSIX shell and awk, so it runs anywhere without installing anything, and the constants are the only thing you need to touch when prices move.
#!/bin/sh
# aws-compute-crossover.sh -- setup
# us-east-1 list prices, read 2026-09-17 from the AWS Price List Query API.
HOURS=730 # hours in an average month
L_X86=0.0000166667 # Lambda duration, x86, USD per GB-second (first tier)
L_ARM=0.0000133334 # Lambda duration, Arm, USD per GB-second (first tier)
L_REQ=0.0000002 # Lambda, USD per request
F_X86_CPU=0.04048 # Fargate, USD per vCPU-hour, x86
F_X86_MEM=0.004445 # Fargate, USD per GB-hour, x86
F_ARM_CPU=0.03238 # Fargate, USD per vCPU-hour, Arm
F_ARM_MEM=0.00356 # Fargate, USD per GB-hour, Arm
The break-even calculation solves for the busy-time fraction at which a Lambda function costs the same as one always-on Fargate task. Critically, it includes the per-request charge, which many back-of-envelope comparisons drop and which dominates at short durations.
awk -v h=$HOURS -v lx=$L_X86 -v la=$L_ARM -v lr=$L_REQ \
-v fxc=$F_X86_CPU -v fxm=$F_X86_MEM -v fac=$F_ARM_CPU -v fam=$F_ARM_MEM 'BEGIN{
VCPU_MB = 1769; vgb = VCPU_MB/1024 # the Lambda size allocated one full vCPU
fx = fxc + 2*fxm; fa = fac + 2*fam # one Fargate task: 1 vCPU + 2 GB
# Cost of a Lambda hour = duration for the fraction it runs, plus one request per duration
n = split("0.05 0.1 0.2 0.5 1 3", d, " ")
for (i=1; i<=n; i++) {
dur = d[i]+0
cx = fx / (3600*vgb*lx + 3600*lr/dur) # break-even busy fraction, x86
ca = fa / (3600*vgb*la + 3600*lr/dur) # break-even busy fraction, Arm
printf " %-9s %13.1f%% %13.1f%% %12.2f %12.2f\n", dur"s", cx*100, ca*100, cx/dur, ca/dur
}
}'
The packing comparison uses the same constants against a list of instances, dividing each instance price by the number of 1 vCPU and 2 GB slots it can hold. The full script and its raw output follow in the sections below.
Crossover One: Lambda Stops Winning Near 45% Busy Time
Here is the raw output for the first two blocks.
A. ONE UNIT OF ALWAYS-ON COMPUTE (1 vCPU + 2 GB), us-east-1
Fargate x86 $0.049370/hr $ 36.04/mo
Fargate Arm $0.039500/hr $ 28.84/mo
Lambda x86 @1769MB $0.103653/hr $ 75.67/mo (busy 100% of the hour)
Lambda Arm @1769MB $0.082922/hr $ 60.53/mo (busy 100% of the hour)
B. LAMBDA VS FARGATE BREAK-EVEN (Lambda at 1769 MB vs one 1 vCPU + 2 GB task)
avg dur x86 busy-time Arm busy-time x86 req/s Arm req/s
0.05s 41.8% 40.6% 8.36 8.12
0.1s 44.5% 43.8% 4.45 4.38
0.2s 46.0% 45.7% 2.30 2.28
0.5s 47.0% 46.8% 0.94 0.94
1s 47.3% 47.2% 0.47 0.47
3s 47.5% 47.5% 0.16 0.16
Read the middle columns as “the fraction of the wall clock during which your function is actually executing”. Below that fraction, Lambda is cheaper. Above it, one Fargate task doing the same work is cheaper. The number lands between 41% and 48% for every duration tested, which is stable enough to remember as a rule of thumb: Lambda stops being the cheap option somewhere around 45% busy.
The same output, as a table you can scan:
| Average duration | Break-even busy time, x86 | Break-even busy time, Arm | Break-even req/s, x86 | Break-even req/s, Arm |
|---|---|---|---|---|
| 50 ms | 41.8% | 40.6% | 8.36 | 8.12 |
| 100 ms | 44.5% | 43.8% | 4.45 | 4.38 |
| 200 ms | 46.0% | 45.7% | 2.30 | 2.28 |
| 500 ms | 47.0% | 46.8% | 0.94 | 0.94 |
| 1 s | 47.3% | 47.2% | 0.47 | 0.47 |
| 3 s | 47.5% | 47.5% | 0.16 | 0.16 |
The right-hand columns translate that into sustained request rate for a single unit of capacity. At 100 ms average duration, the crossover is 4.45 requests per second on x86, which is about 11.5 million requests a month. Short functions cross earlier because the flat $0.20 per million request charge is a larger share of their bill. At 50 ms, requests account for 12.2% of the Lambda cost; at 3 seconds, they account for 0.2%.
One caveat matters here. This compares one Lambda concurrency unit against one Fargate task, and real services need more than one task for availability. Two tasks double the Fargate side of the ledger, which pushes the crossover to roughly 90% busy time for anything that must survive an availability zone failure. For genuinely spiky traffic, that gap is why serverless Node.js on Lambda remains hard to beat on price.
Crossover Two: Fargate Is Not the Expensive One Any More
Fargate has a reputation as the convenience tax you pay to avoid EC2. At 2026 list prices, that reputation is largely obsolete.
C. FARGATE VS EC2 PER SLOT (one 1 vCPU + 2 GB slot, perfect packing, Linux)
instance vCPU mem GiB slots on-demand per slot vs Fargate
c8g.large 2 4 2 0.07976 0.03988 1.0%
m8g.large 2 8 2 0.08976 0.04488 13.6%
c8i.large 2 4 2 0.09371 0.04686 -5.1%
m8i.large 2 8 2 0.10584 0.05292 7.2%
c8g.xlarge 4 8 4 0.15952 0.03988 1.0%
c9g.large 2 4 2 0.08694 0.04347 10.1%
t4g.medium 2 4 2 0.03360 0.01680 -57.5%
(negative = EC2 cheaper than the matching-architecture Fargate task)
The result is not the one most engineers expect. Against a perfectly packed c8g.large, the equivalent Fargate Arm task is 1% cheaper, not 30% more expensive. Against m8g.large, Fargate is 13.6% cheaper, because you are paying for 8 GiB of memory to run a workload that wanted 4 GiB.
Only two rows favour EC2. The c8i.large wins by 5.1%, and that is an x86-versus-x86 comparison where Fargate’s x86 premium is real. The t4g.medium wins by 57.5%, and that number is a trap rather than a result: burstable instances run on CPU credits, and a container pinned near 100% CPU will exhaust its credits and either throttle or bill unlimited-mode surcharges. Burstable instances are genuinely cheap for genuinely bursty work, which is the same workload shape that favours Lambda anyway.
Two assumptions also flatter EC2 in this table. Perfect packing is not achievable, because the ECS agent, the log router and the operating system take their cut, and because tasks come in discrete sizes that rarely tile an instance exactly. Furthermore, the instance price excludes the EBS root volume, the AMI pipeline and the patching work, all of which are included in the Fargate rate. If you are weighing this for a service that already runs on ECS, the trade-offs are laid out further in the Spring Boot microservices on ECS Fargate guide.
What a Savings Plan Does to Each One
This is the section that actually decides the argument, and it is missing from almost every comparison on the subject. A Compute Savings Plan covers Lambda, Fargate and EC2, but it does not discount them equally.
D. WHAT A 1-YEAR NO-UPFRONT COMPUTE SAVINGS PLAN TAKES OFF
unit on-demand with plan discount
Lambda GB-s x86 0.0000166667 0.0000147000 11.8%
Lambda GB-s Arm 0.0000133334 0.0000117000 12.3%
Fargate vCPU-hr x86 0.040480 0.032384 20.0%
Fargate GB-hr x86 0.004445 0.003556 20.0%
Fargate vCPU-hr Arm 0.032380 0.025500 21.2%
Fargate GB-hr Arm 0.003560 0.002800 21.3%
EC2 t4g.small 0.016800 0.012100 28.0%
EC2 c8g.large 0.079760 0.057180 28.3%
EC2 m8g.large 0.089760 0.065940 26.5%
Fargate Arm slot with plan: $0.031100/hr c8g.large per slot with plan: $0.028590/hr
The pattern is consistent: the more operational work you hand to AWS, the less the plan gives back. Lambda gets about 12%, Fargate gets about 20%, and EC2 gets about 28%. In other words, committing to a year of spend is worth roughly 16 percentage points more on EC2 than on Lambda.
That flips the previous section’s conclusion. On demand, the Fargate Arm slot at $0.0395 beats the c8g.large slot at $0.03988. Under the same 1-year plan, the Fargate slot falls to $0.0311 while the EC2 slot falls to $0.02859, so EC2 becomes 8.1% cheaper. The commitment, not the raw price, is what makes EC2 the budget option.
Two footnotes are worth keeping. Only one Lambda charge is covered at all: duration. Request charges, provisioned concurrency and ephemeral storage are not discounted by a Compute Savings Plan, so a request-heavy function sees far less than 11.8% off its actual bill. Additionally, these are the 1-year no-upfront rates; three-year all-upfront plans discount considerably harder, and they widen the same gap rather than closing it.
Lambda Managed Instances Moves the Line Again
Since late 2025, the three-way comparison is really a four-way one. Lambda Managed Instances runs your functions on EC2 instances in your own account, and AWS states the billing plainly: “Lambda Managed Instances uses EC2-based pricing with a 15% management fee on top of the EC2 instance cost”, with the caveat that “EC2 pricing discounts only apply to the underlying EC2 compute, not to the management fee.”
That 15% is verifiable in the price list. The published management rate for c5.18xlarge is $0.459 per hour against an on-demand price of $3.06, and for m6g.8xlarge it is $0.1848 against $1.232. Both are exactly 15%. The same offer file carries 517 instance types across 65 families, from c5 through r8gd, which is a far wider hardware menu than either Lambda or Fargate normally offers.
Duration disappears from the bill entirely, which is the whole point. However, there is a floor that the pricing calculators tend to skip: AWS “launches three instances by default for AZ resiliency” before marking a function version active.
F. LAMBDA MANAGED INSTANCES FLOOR (EC2 on-demand + 15% fee, 3 instances by default)
instance on-demand +15% fee 1 inst/mo 3 inst/mo slots x3
c8g.large 0.07976 0.09172 66.96 200.88 6
m8g.large 0.08976 0.10322 75.35 226.06 6
c8g.xlarge 0.15952 0.18345 133.92 401.75 12
c8i.large 0.09371 0.10777 78.67 236.01 6
For reference, 6 Fargate Arm tasks of 1 vCPU + 2 GB: $173.01/mo
So the entry price for Managed Instances is about $201 a month on the cheapest sensible instance, against $173 for the equivalent six Fargate tasks. Below that floor, the feature is a cost increase. Above it, once a Savings Plan covers the EC2 portion, it beats both default Lambda and Fargate for steady traffic while keeping the Lambda programming model and losing cold starts. Notably, Managed Instances also supports multiple concurrent invocations per execution environment, so an IO-bound service packs far more work onto the same instance than the default one-invoke-at-a-time model allows.
The Fixed Costs That Decide Small Deployments
For anything under a few hundred dollars a month, the compute comparison above is not what decides the bill. The fixed edges are.
- An Application Load Balancer costs $0.0225 per hour, which is $16.43 a month before a single LCU of traffic, and both Fargate and EC2 normally need one.
- API Gateway HTTP APIs cost $1.00 per million requests for the first 300 million, dropping to $0.90 after that. REST APIs start at $3.50 per million.
- A Lambda function URL costs nothing, which is the cheapest front door on AWS and the one most teams forget exists.
- CloudWatch Logs ingestion is $0.50 per GB in the Standard log class, or $0.25 per GB in Infrequent Access, plus $0.03 per GB-month of storage. A chatty container easily out-costs its own compute here.
- A public IPv4 address costs $0.005 per hour, in use or idle, which is $3.65 a month per address.
Those five lines routinely add up to more than the compute for a small service. If your monthly AWS bill is dominated by this category, the compute choice is close to irrelevant and the advice in the AWS cost optimization guide will move more money than any migration.
A Worked Example: 30 Million Requests a Month
Consider a mid-sized internal API in front of a database, serving about 30 million requests a month at an average of 120 ms, needing 512 MB of memory, with traffic concentrated in business hours. This is the shape most teams are actually arguing about.
E. WORKED EXAMPLE: 30,000,000 requests/month, 120 ms average, 512 MB
billable GB-seconds 1800000
Lambda Arm duration $ 24.00
Lambda requests $ 6.00
Lambda total $ 30.00
API Gateway HTTP API @$1/M $ 30.00
Lambda function URL $ 0.00
2 Fargate Arm tasks $ 57.67
ALB base (no LCU) $ 16.43
2 x t4g.small EC2 $ 24.53
average concurrency 1.3889 (11.6 req/s at a flat rate)
Three readings fall out of that block. First, Lambda behind a function URL costs $30.00 a month, while Lambda behind an HTTP API costs $60.00, because API Gateway doubles the bill at this volume. That single architectural choice outweighs every rate in this post.
Second, the two-task Fargate deployment costs $74.10 with its load balancer, roughly 2.5 times the Lambda option. Average concurrency is only 1.39, so the function is idle most of the time and Lambda’s ability to bill nothing for that idleness is decisive. Third, the EC2 option at $40.96 with the same load balancer sits between the two, but it buys that saving with patching, AMI rebuilds and capacity decisions that neither of the others require.
Change one assumption and the ranking inverts. If the same 30 million requests arrive as sustained load rather than business-hours spikes, average concurrency rises toward the number of vCPUs you need continuously, and the Fargate and EC2 lines stay flat while the Lambda line climbs in direct proportion. That is the crossover from the first table, restated in dollars.
When to Use Lambda, Fargate or EC2
The decision follows from busy time, commitment appetite and how much operational work you want to own.
Reach for Lambda when
- Your workload is genuinely spiky, and average busy time sits below about 45%
- Traffic can drop to zero overnight, at weekends or between batch runs
- A function URL or an existing event source removes the need for a load balancer
- Request volume is low enough that the $0.20 per million charge stays a small share of the bill
- The team has no appetite for patching, AMIs or capacity planning
Choose Fargate when
- Load is steady enough to keep a task busy more than half the time
- The workload is already containerized and wants no rewrite
- Startup work is expensive enough that cold starts hurt, but not expensive enough to justify provisioned concurrency
- Task sizes tile neatly onto the vCPU and memory combinations Fargate actually sells
- Nobody on the team wants to own an EC2 fleet for a handful of services
Stay on EC2 when
- A Savings Plan or Reserved Instance commitment is already in place, or is politically possible
- You can pack instances above roughly 80%, which usually means many services sharing a cluster
- The workload needs hardware Fargate does not offer, such as GPUs, local NVMe or very high network throughput
- Long-running processes, background threads or persistent connections do not fit the request model
When NOT to Use Lambda, Fargate or EC2
Each option has a failure mode that shows up on the invoice rather than in the architecture diagram.
Skip Lambda if
- The function is busy most of the hour, which makes it roughly twice the price of the equivalent Fargate task
- You are about to enable provisioned concurrency across the fleet to hide cold starts, since that is Fargate with extra steps
- Requests are tiny and enormously numerous, so the flat per-request charge dominates
- Work regularly runs past the 15-minute limit, or needs more than 10,240 MB
Rule out Fargate if
- The service needs less than 0.25 vCPU, because that is the smallest task you can buy
- Your task sizes force large memory rounding, as in the m8g.large row above
- The fleet is large, committed and well-packed, where EC2’s deeper Savings Plan discount compounds
- You need hardware that Fargate does not offer at any price
Avoid EC2 if
- Nobody owns patching, AMI rebuilds or autoscaling policy, because the cheapest instance price is not the cheapest total cost
- Utilization sits below roughly 50%, at which point you are paying for idle capacity that Fargate would not charge for
- The only instance that fits is burstable and the workload is CPU-steady, since credit exhaustion turns a cheap instance into a slow one
- The saving on paper is under 10%, which is inside the margin of error on packing efficiency
Common Mistakes with Lambda vs Fargate vs EC2 Cost
- Comparing on-demand prices when the account already holds a Savings Plan, which understates EC2 by roughly 16 percentage points against Lambda
- Leaving the per-request charge out of the Lambda side, which shifts the crossover by several percentage points for functions under 100 ms
- Pricing the compute but not the front door, when API Gateway can cost as much as the entire Lambda bill
- Assuming Fargate carries a large premium over EC2, which at 2026 Graviton list prices is no longer true
- Running x86 out of habit, when Arm is 20% cheaper on both Lambda duration and Fargate, with no code change for most interpreted runtimes
- Sizing Lambda memory for memory, when memory is the CPU dial, and a 1,769 MB function that finishes in half the time of a 900 MB one costs the same
- Treating burstable instance prices as comparable to dedicated ones without accounting for CPU credits
- Forgetting that Lambda Managed Instances starts three instances by default, so its floor is three times what a single-instance estimate suggests
What These Tables Do Not Include
A cost comparison with unstated limits is a trap, so here are the limits.
Every price is us-east-1 list price on 17 September 2026. Other regions differ, sometimes by more than the gaps measured here. Spot pricing is excluded entirely, which is a large omission for batch and fault-tolerant work: Fargate Spot and EC2 Spot both change these conclusions dramatically, and neither has a stable price to quote.
Data transfer, NAT gateway charges, EBS volumes, ECR storage, ALB capacity units and the EKS control plane fee are all excluded. NAT gateways in particular can dwarf compute for chatty private-subnet services. Engineering time is excluded too, and it is usually the largest line item of all.
Finally, this is a cost comparison, not a performance one. Cold start latency, tail latency under burst, and startup time for large container images are real differences between these three, and they are not priced here. Image size does affect startup on both Lambda and Fargate, which is covered in the measured Docker base image size comparison.
Conclusion
The Lambda vs Fargate vs EC2 cost question has three stable answers at 2026 prices. Below roughly 45% busy time, Lambda is cheapest and nothing else is close. Above it, Fargate and EC2 converge to within a percent or two on list price, and the Savings Plan discount, at about 20% versus 28%, is what actually separates them. Lambda Managed Instances sits above a floor of roughly $201 a month and wins for steady, high-volume work that wants the Lambda programming model on EC2 economics.
The practical next step is to take the busy-time number from your own CloudWatch metrics, divide it into the table in the crossover section, and check whether your current choice is on the right side of the line. If it is not, and the gap is under 10%, leave it alone and go fix your API Gateway and log ingestion instead. For choosing the tooling to deploy whichever one you land on, the comparison of Serverless Framework, AWS SAM and SST covers the trade-offs, and the same dated-pricing approach applied to model APIs is in the LLM cost per task breakdown.
Prices in this post were read on 17 September 2026 and are scheduled for re-reading on 17 December 2026.
