Lambda vs Fargate: Choosing Serverless Compute

Infrastructure AWS Cost
5 min read

Even with the container orchestrator settled, one question remains: does this workload need a long-running process at all? If the code only needs to run when an event arrives, Lambda becomes a candidate — and at that moment the comparison is against Fargate. The conclusion up front: short, intermittent event processing goes to Lambda; services with steady traffic and long-running work go to Fargate. The boundary is set by a utilization calculation, not intuition. The Fargate side of the story is covered in ECS Fargate vs EC2. Prices are for us-east-1.

Billing structure: per invocation vs per task #

Lambda bills per invocation: $0.20 per million requests, plus execution time metered in GB-seconds at about $0.0000167 each. Time when no code runs costs nothing, and there is a free tier of 1 million requests and 400,000 GB-seconds per month. You do not pick vCPUs — they scale with memory (about 1,769MB equals 1 vCPU).

Fargate, as covered in the previous post, bills for the time a task is up (about $0.04048 per vCPU-hour and $0.004445 per GB-hour). A task with no traffic still costs money, and in exchange the bill is independent of call volume.

Convert to the same units and the structure shows itself. Lambda’s GB-second rate works out to $0.06 per GB-hour. Run the equivalent of 1 vCPU (about 1.77GB) for a full hour and it is about $0.106 — more than double the same spec on Fargate (1 vCPU/2GB, about $0.049). Lambda’s rate is a premium rate, bundled with the condition that idle time is free.

The threshold: 20〜30% utilization is the boundary #

The decision variable therefore reduces to one thing: the fraction of time compute actually runs. When total execution time exceeds 20〜30% of the day, an always-on task (Fargate) becomes cheaper; below that, Lambda wins. A webhook handler that idles all night runs at single-digit utilization — a Lambda landslide. An API taking dozens of requests per second is effectively always running — Fargate territory.

Note that growth moves you across the boundary. Once call volume climbs into the millions per month, the Lambda line item starts to exceed the cost of a task or two. Starting a new service on Lambda is right — but set an alarm for the point where the monthly Lambda charge crosses the equivalent Fargate task price.

Lambda’s hard limits: filtered out before price matters #

  • 15-minute execution cap: exceed it and the function is killed. Long batches and large transformations go to Fargate (no time limit).
  • 10GB memory maximum: beyond that there is no option.
  • Cold starts: the first invocation after idling adds hundreds of milliseconds to a few seconds. Latency-sensitive APIs can eliminate them with provisioned concurrency, but that option bills during idle time — eating the very reason Lambda exists. If you are paying to erase cold starts, it is time to re-compare against an always-on Fargate task.
  • The execution model: long-lived connections like WebSockets, servers holding state in memory, and GPU work structurally do not fit Lambda.

The strengths run the other way too, and they also come from the structure: instant scaling that absorbs tens of thousands of concurrent invocations with no configuration, event wiring to S3, SQS, and EventBridge (a trigger definition is the pipeline), and zero server or image management. The API Gateway combination is covered in AWS Advanced #4.

Hidden costs: the periphery outgrows the core #

The common mistake in Lambda math is pricing only the function. The real bill brings its neighbors.

  • API Gateway: about $1.00 per million requests on HTTP APIs — at high volume, the same order of magnitude as the Lambda charge itself. For high-traffic APIs there comes a point where an ALB (fixed hourly plus LCU) in front of Fargate is cheaper.
  • CloudWatch Logs ingestion: about $0.50 per GB. A chatty function can spend more on log ingestion than on execution. Manage log level and retention per function.
  • NAT when attached to a VPC: a Lambda that reaches VPC resources and also calls external APIs pays NAT gateway processing fees — the pattern covered in the bill-spike post.

Fargate’s hidden cost points the other way: even the minimum spec (0.25 vCPU) runs about $9 a month as long as the task is up, so keeping a rarely invoked service as a standing task is waste by itself (see the standing checklist).

The selection order #

  1. Filter on hard limits first: over 15 minutes, over 10GB, long-lived connections, or GPU — any one means Fargate.
  2. Estimate utilization: event-driven work that stays below 20〜30% total daily execution time goes to Lambda; steady traffic goes to Fargate.
  3. Check the latency requirement: for low-latency APIs where cold starts are unacceptable, Fargate is the default; keeping Lambda means re-running the math with provisioned concurrency included.
  4. Sum the periphery: compare totals including API Gateway, log ingestion, and NAT. Comparing compute rates alone is half a calculation.
  5. Watch the boundary move: when growth pushes utilization over the line, move to Fargate; when utilization sits at the floor, move to Lambda. With Lambda’s container image support, the same image works in both — the migration cost is smaller than it used to be.

Summary #

  • Lambda bills per invocation, Fargate per task-hour. Lambda’s rate converts to $0.06 per GB-hour — a premium of more than 2x over Fargate — and the payoff is free idle time.
  • The boundary sits at 20〜30% utilization. Intermittent work below it belongs to Lambda; steady traffic belongs to Fargate.
  • The 15-minute cap, 10GB memory, cold starts, and long-lived connections are hard limits that decide before price does.
  • Compare totals including API Gateway, log ingestion, and NAT. Priced on the function alone, a Lambda bill escapes prediction.
  • Utilization changes. Plan the Lambda-to-Fargate migration path from day one.
X