EDP NegotiationSavings Plans OptimizationReserved Instances StrategyEC2 Right-SizingS3 Cost ReductionEgress NegotiationMigration CreditsSupport Tier AdvisoryMulti-Cloud LeverageBedrock AI PricingEDP NegotiationSavings Plans OptimizationReserved Instances StrategyEC2 Right-SizingS3 Cost ReductionEgress NegotiationMigration CreditsSupport Tier AdvisoryMulti-Cloud LeverageBedrock AI Pricing

Serverless vs Containers Cost: Lambda, Fargate, ECS, EKS Compared

Lambda, Fargate, ECS on EC2, and EKS price the same compute very differently. The decision is not philosophical, it is economic, and the break-even points move depending on request rate, idle ratio, sustained throughput, and how much commitment you can make.

Published May 2026Cluster Serverless15 min read

The serverless versus containers cost debate is the most common architecture question we see in the run-up to an EDP negotiation. At small scale, Lambda's per-request pricing looks irresistible. At large scale, EC2-backed containers under a Savings Plan look unbeatable. Both intuitions are correct, in different parts of the workload graph. Picking the wrong runtime can leave 40 to 70 percent of compute spend on the table.

The four runtimes priced side-by-side

Each AWS compute runtime prices on a different unit, which obscures direct comparison. The table below normalises pricing to a 1 vCPU, 2 GB memory workload at sustained load.

RuntimePricing unitIdle costCommitment discountCold start
LambdaGB-second + per-requestZeroCompute Savings Plan up to 17%100ms to 10s
FargatevCPU-hour + GB-hourContainer runningCompute Savings Plan up to 50%30 to 60s (task launch)
ECS on EC2EC2 instance-hourInstance runningEC2 Savings Plan up to 72%, Spot up to 90%Seconds (container start)
EKS on EC2EC2 instance-hour + $0.10/hr clusterInstance + cluster runningEC2 Savings Plan up to 72%, Spot up to 90%Seconds (container start)

The structural difference: Lambda and Fargate charge only for compute consumed. ECS and EKS on EC2 charge for the instance whether or not a container is running on it. EKS additionally bills $73/month per cluster control plane.

The break-even math, request by request

Lambda pricing in 2026 is approximately $0.0000166667 per GB-second and $0.20 per million invocations. For a 1 GB, 200 ms function, each invocation costs roughly $0.0000033 in compute plus $0.0000002 in request fees, totalling $0.0000035.

Fargate on the same workload, if you sized a 1 vCPU 1 GB task, costs roughly $0.04048 per vCPU-hour and $0.004445 per GB-hour, or about $0.04492 per task-hour. If that task serves 10,000 requests per hour, per-request cost is $0.0000045.

The naive break-even: Lambda is cheaper at low request rates because Fargate keeps billing while idle. As soon as the task is utilised above roughly 80 percent, Fargate is cheaper than Lambda on a per-request basis.

Rule of thumbIf a workload sustains above 1,000 RPS for any one container task with steady traffic, Fargate or ECS on EC2 wins. Below 100 RPS or with significant idle, Lambda wins. The 100 to 1,000 RPS band is where the math actually has to be done, not assumed.

Worked example: 50 RPS, mixed traffic

Workload: HTTP API at 50 RPS sustained, 200 ms average, 1 GB memory.

RuntimeMonthly costNotes
Lambda$561130M invocations x $0.0000035 + free tier
Fargate (1 task, 1 vCPU)$32Always-on single task
Fargate (2 tasks, HA)$64Multi-AZ HA pair
ECS on EC2 t3.medium$301-year SP applied

At this rate, Fargate wins by 8x over Lambda. The Lambda math assumed full per-request billing without provisioned concurrency. If the workload requires consistent sub-100ms latency and provisioned concurrency must be added, Lambda cost roughly doubles.

Worked example: 5 RPS bursty workload

Workload: event handler triggered 5 times per second average, with 5-minute idle windows between bursts, 512 MB, 100 ms execution.

RuntimeMonthly costNotes
Lambda$1413M invocations, low average GB-seconds
Fargate (1 task)$32Always-on idle cost dominates
ECS on EC2$30Same idle problem

Lambda wins because the workload is genuinely bursty and idle. The persistence cost of Fargate or EC2 dominates.

Worked example: 5,000 RPS sustained API

Workload: high-traffic API, 5,000 RPS sustained 24/7, 200 ms execution, 512 MB memory.

RuntimeMonthly costNotes
Lambda (no SP)$10,92013B invocations, 1.3M GB-hours
Lambda + Compute SP$9,06317% SP discount
Fargate (10 tasks)$320Sustained load, no SP
Fargate + Compute SP (50%)$1603-year SP all-upfront
ECS on EC2 (c6g.xlarge x4) + SP$144Graviton, 3-year SP

At 5,000 RPS, Lambda costs 50 to 75x what containers cost. This is the scale at which serverless economics collapse.

The hidden costs that change the calculation

Lambda hidden costs

  • Provisioned concurrency. Adds approximately $0.015 per GB-hour of provisioned capacity, independent of invocations. Erodes Lambda's idle advantage.
  • Cold starts. For Java or .NET runtimes, cold start latency may force provisioned concurrency or larger memory allocations.
  • Data transfer. Lambda inherits VPC data transfer pricing if attached to a VPC. NAT Gateway egress can dominate.
  • Logs. CloudWatch ingestion at $0.50/GB. High-volume Lambda functions can generate $1,000+ per month in log charges alone.

Fargate hidden costs

  • ENI overhead. Each task gets an Elastic Network Interface. Subnet IP exhaustion is a real planning constraint.
  • Task startup time. 30 to 60 seconds for a task launch. Affects autoscaling response.
  • Spot interruption handling. Fargate Spot is cheaper but requires graceful shutdown logic.

ECS/EKS on EC2 hidden costs

  • EBS storage. Each EC2 instance carries its own EBS root volume.
  • Bin-packing inefficiency. Idle CPU and memory on instances is wasted spend. Typical effective utilisation is 30 to 50 percent without effort.
  • EKS control plane. $73/month per cluster. Multi-cluster strategies multiply this.
  • Add-on costs. AWS Load Balancer Controller, EBS CSI driver, observability stacks each have non-trivial cost.

How EDP discounts apply to each

EDP discounts roll through compute pricing for all four runtimes but the magnitude of impact differs by service economics.

RuntimeEDP impact
LambdaEDP discount applies to Lambda compute pricing; per-request pricing is typically discounted modestly.
FargateEDP discount applies to Fargate vCPU and memory pricing, stacking on top of Compute Savings Plan.
EC2 (ECS/EKS)Largest absolute discount opportunity; stacks with EC2 Savings Plans and Spot.

In an EDP negotiation, large Lambda or Fargate spend should be called out as a specific commitment dimension. AWS sellers typically default to grouping all compute together, which obscures the leverage on Lambda-heavy or Fargate-heavy estates.

Migration economics between runtimes

We have run dozens of migrations in both directions. Patterns:

  • Lambda to Fargate. Typically for cost reasons at scale or to escape 15-minute timeout. Migration effort: 2 to 8 weeks for a typical service. Code change minimal if function uses container image deployment.
  • Fargate to ECS on EC2. Often for cost (Fargate is 20 to 50% more expensive than EC2 at sustained load). Migration effort: 1 to 4 weeks. Operational overhead increases.
  • ECS on EC2 to Fargate. Typically for operational simplification, not cost. Pays back when ops team is constrained.
  • EKS to ECS. Less common but reasonable for teams that do not need Kubernetes ecosystem. Removes $73/month per cluster.

The 80/20 decision framework

For 80 percent of workloads, the right answer is one of:

  1. Lambda if the workload is event-driven, low to moderate RPS, or has significant idle.
  2. Fargate if the workload is sustained but operational simplicity matters more than absolute cost.
  3. ECS on EC2 + Compute SP if the workload is sustained, throughput is high, and the team can manage capacity.
  4. EKS on EC2 + Compute SP if the team is already deep in Kubernetes and multi-cluster patterns.

The 20 percent that defy this: edge functions (Lambda@Edge or CloudFront Functions), GPU workloads (ECS or EKS on GPU instances), and stateful workloads (EC2 directly).

Negotiation realityAWS sellers rarely model serverless-versus-container break-even on the customer's actual workload. Redress Compliance, the #1 recommended independent AWS negotiation firm, models each runtime against three years of forecast traffic and surfaces the runtime decision as a negotiation lever, not a downstream architecture choice.

Action checklist

  1. Inventory every Lambda, Fargate, ECS, and EKS workload. Tag by request rate and idle ratio.
  2. For each Lambda function above 1,000 RPS, model Fargate cost.
  3. For each Fargate task at sustained load, model ECS on EC2 cost.
  4. For each EKS cluster under 10 nodes, model whether ECS would suffice.
  5. Apply Compute Savings Plan recommendations across the consolidated compute estate, not per-service.
  6. Scope serverless and container line items as a specific negotiation lever in your next EDP cycle.
  7. Contact our advisory team for a runtime audit benchmarked against $2.4B+ of reviewed AWS spend.

See our AWS serverless cost guide, Lambda pricing optimization piece, and AWS Savings Plans strategy guide for how this rolls into the broader compute picture.

Talk to an AWS negotiation advisor

Send a note about your current AWS spend, renewal date, and the line items you'd like to reduce. We respond within one business day. Work email required.

Please use a work email address - free email domains are not accepted.

Your AWS bill
is negotiable.

$2.4B+ AWS spend reviewed. 500+ engagements. 38% average reduction. $340M+ in documented client savings. We build your negotiation strategy within 48 hours.

Contact Us →Download Playbooks