Every AWS team building containerized or event-driven workloads eventually asks the same question: run it on AWS Fargate or hand it to AWS Lambda? Both remove the server from the equation. Neither asks you to patch an EC2 instance or size an Auto Scaling group. But they solve different problems, bill in different units, and fail differently under load. In 2026, with AWS still publishing per-second Fargate pricing at $0.04048 per vCPU-hour and Lambda holding its $0.20-per-million-requests rate, the Fargate vs Lambda decision is less about hype and more about matching a workload’s shape to the right billing model.
This comparison pulls current AWS pricing, published AWS case studies from BILL, Upside, and Smartsheet, an independent 47-workload benchmark from LeanOps, and the operational limits that actually decide architecture reviews: timeouts, memory ceilings, concurrency, and cold starts. By the end, you will have a specs table, a pricing table, a migration path, and a verdict you can defend to a staff engineer.
The question comes up constantly because both services sit under the same “serverless” umbrella but were built to solve different problems five years apart. Lambda launched in 2014 as a way to run small pieces of code without managing a server at all. Fargate arrived later as AWS’s answer to teams who already had containers and wanted the same no-server promise without rewriting everything as individual functions. That history still shapes how each one behaves today, and it explains why so many teams end up running both rather than picking a single winner.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Is AWS Fargate?
AWS Fargate is a serverless compute engine for containers. It is not an orchestrator on its own. Instead, it is a launch type you choose underneath Amazon ECS or Amazon EKS, meaning you still define a task or a pod, but you never provision, patch, or scale the underlying EC2 instances that run it. AWS pulls your container image, starts the task, and bills you for the vCPU and memory you requested from the moment the image download begins until the task or pod terminates, rounded up to the nearest second with a one-minute minimum charge, according to the AWS Fargate pricing page.
That distinction matters because it shapes how Fargate behaves under load. A Fargate task keeps running for as long as your application needs it to. There is no built-in maximum runtime the way Lambda enforces one. That makes Fargate the natural home for long-running API servers, background workers that process a queue continuously, and any service that needs a persistent process rather than a short burst of execution. Fargate tasks can also mount an Amazon EFS file system, join a VPC with full networking control, and run sidecar containers alongside the main application, none of which Lambda supports natively.
Fargate ships in two pricing modes. On-demand is the default: predictable, always available, and priced at a flat rate per second. Fargate Spot taps into unused capacity at a steep discount, in exchange for the possibility AWS reclaims the task with two minutes of warning. AWS’s own BILL case study describes Fargate Spot running interruption-tolerant tasks at up to a 70 percent discount compared with on-demand Fargate pricing, which is why most teams reserve Spot for nonproduction environments, batch jobs, and anything that can tolerate a restart.
Fargate also supports both Linux and Windows containers, and both x86 and Arm-based Graviton processors, with Graviton pricing running roughly 20 percent below equivalent x86 rates. In practice, most teams reach Fargate the same way: they already have a Dockerfile, a working ECS or EKS setup, and no interest in rewriting a service as a set of individual functions just to save a few dollars a month. Fargate lets that container run exactly as it does today, just without a fleet of EC2 instances behind it.
What Is AWS Lambda?
AWS Lambda is a function-as-a-service platform. You upload code, not a container image (though Lambda does support container images as a packaging format), and AWS invokes it in response to an event: an API Gateway request, an S3 upload, an SQS message, a scheduled CloudWatch rule, or hundreds of other triggers. Lambda charges $0.20 per million requests plus $0.0000166667 per GB-second of compute on x86, or $0.0000133334 per GB-second on Arm-based Graviton2, which AWS lists as roughly 20 percent cheaper per the AWS Lambda pricing page. The free tier covers the first 1 million requests and 400,000 GB-seconds every month, which is generous enough that plenty of side projects and internal tools never see a Lambda bill at all.
Lambda’s defining trait is that it disappears when it is not running. There is no idle cost, no reserved capacity, and no process sitting around waiting for the next request unless you explicitly pay for Provisioned Concurrency. That makes it exceptionally cheap for spiky, unpredictable, or low-volume workloads. It also comes with hard boundaries: a maximum execution timeout of 15 minutes, a maximum memory allocation of 10,240 MB, and a default account concurrency limit of 1,000 simultaneous executions per Region. Ephemeral storage at /tmp defaults to 512 MB and can be configured up to 10,240 MB if a function needs more scratch space.
For Java functions specifically, AWS offers SnapStart, a feature that initializes the function ahead of time and restores it from a snapshot at invoke time instead of running the full JVM startup on the cold path. AWS has described SnapStart as cutting Java cold-start latency by up to 10x in its own materials, which matters because Java historically had some of the worst cold-start behavior of any Lambda runtime.
Lambda supports a wide range of managed runtimes out of the box, including Node.js, Python, Java, .NET, Go, and Ruby, plus a custom runtime interface for anything else. Because AWS owns patching and scaling entirely, the only decisions left to a developer are memory allocation, timeout, and which event source triggers the function. That narrow surface area is exactly why Lambda became the default starting point for so many serverless architectures. There is simply less to configure before code ships.
AWS Fargate vs Lambda: Full Specs Comparison
Here is the side-by-side that most engineers actually want before reading another paragraph of prose. Treat it as a reference table you can return to, not a replacement for the sections that follow.
| Dimension | AWS Fargate | AWS Lambda |
|---|---|---|
| Compute model | Serverless containers (ECS/EKS launch type) | Serverless functions (event-driven) |
| Maximum execution time | No hard timeout, runs as long as the task is alive | 15 minutes (900 seconds) |
| Maximum memory | Configurable per task, well beyond Lambda’s ceiling | 10,240 MB |
| Billing unit | Per vCPU-second and GB-second | Per request plus per GB-second |
| On-demand rate (Linux/x86, us-east-1) | $0.04048/vCPU-hr, $0.004445/GB-hr | $0.20/1M requests, $0.0000166667/GB-sec |
| Arm/Graviton rate | $0.03238/vCPU-hr, $0.00356/GB-hr | $0.0000133334/GB-sec (~20% cheaper) |
| Discounted capacity option | Fargate Spot, up to 70% off on-demand | No spot equivalent |
| Free tier | None | 1M requests + 400,000 GB-seconds/month |
| Default concurrency limit | Governed by service desired count, not a hard account cap | 1,000 concurrent executions per Region |
| Ephemeral storage | Configurable, plus optional EFS mounts | 512 MB default, up to 10,240 MB |
| Cold starts | Task launch measured in seconds | Milliseconds to low seconds, near-zero if kept warm |
| Networking | Full VPC placement, security groups, ENIs | Optional VPC attachment, adds latency |
| Runs containers natively | Yes, by design | Yes, via container image packaging, still bound by the 15-minute limit |
| Orchestrator integration | Amazon ECS and Amazon EKS | Standalone, or triggered by Step Functions, EventBridge, SQS, API Gateway |
| Best for | Long-running services, steady traffic, sidecars | Bursty, event-driven, short-lived tasks |
Notice that the two rarely compete for the exact same workload. A 13-row comparison like this one exists to show where the lines actually sit, not to declare a single universal winner. The next few sections unpack the rows that cause the most expensive mistakes: pricing, cold starts, and limits.
Pricing Breakdown: Fargate vs Lambda Costs in 2026
Pricing is where the Fargate vs Lambda debate gets concrete. Both services charge for exactly what you consume, but the unit of consumption is different enough that the same workload can cost wildly different amounts depending on which one runs it.
| Pricing component | AWS Fargate | AWS Lambda |
|---|---|---|
| Compute (Linux/x86, on-demand, us-east-1) | $0.04048 per vCPU-hour | $0.0000166667 per GB-second |
| Compute (Linux/Arm, on-demand, us-east-1) | $0.03238 per vCPU-hour | $0.0000133334 per GB-second |
| Memory (on-demand, us-east-1) | $0.004445 per GB-hour | Included in GB-second rate |
| Spot / discounted rate | $0.0124419 per vCPU-hour (Linux/x86 Spot) | Not applicable |
| Request charge | None | $0.20 per 1 million requests |
| Free tier | None | 1M requests + 400,000 GB-seconds/month |
| Billing granularity | Per second, 1-minute minimum | Per millisecond of execution |
| High-volume discount | Compute Savings Plans (up to ~50% for committed use) | Tiered rate drops after 6 billion GB-seconds/month |
Run the math on a concrete example. A lightweight API endpoint that responds in 200 milliseconds and gets invoked 5 million times a month, at 0.5 GB of memory, comes out to about $9.33 on Lambda before any free-tier credit is applied. Run that same traffic pattern as a small Fargate task sized at 0.25 vCPU and 0.5 GB, kept running 24/7 to handle bursts at any moment, and the bill lands at roughly $9.01 a month, before you add a load balancer. At this volume the two are nearly identical, and Lambda would actually come out cheaper once its free tier of 1 million requests and 400,000 GB-seconds is subtracted from that bill. The gap opens up at the extremes. A background job that runs continuously for hours is nearly always cheaper on Fargate, because Lambda’s per-GB-second rate compounds with every second of runtime, while Fargate’s hourly rate stays flat regardless of how continuously the task is used.
A rough way to sanity-check either bill before committing to an architecture:
# Lambda monthly estimate
requests_per_month = 5_000_000
avg_duration_sec = 0.2
memory_gb = 0.5
gb_seconds = requests_per_month * avg_duration_sec * memory_gb
lambda_cost = (requests_per_month / 1_000_000 * 0.20) + (gb_seconds * 0.0000166667)
# Fargate monthly estimate (task running 24/7)
vcpu = 0.25
memory_gb_fargate = 0.5
hours_per_month = 730
fargate_cost = (vcpu * 0.04048 * hours_per_month) + (memory_gb_fargate * 0.004445 * hours_per_month)
print(lambda_cost, fargate_cost)Plug in your own request volume, average duration, and memory size, and the crossover point becomes obvious fast. Short, spiky, and idle-heavy favors Lambda. Long-running and steady favors Fargate, especially once you layer in Fargate Spot for anything that tolerates interruption.
Scale the same comparison up to a steadier workload and the gap widens quickly. A queue-processing worker that needs to run continuously, sized at 1 vCPU and 2 GB of memory, costs about $0.0494 an hour on Fargate on-demand ($0.04048 for the vCPU plus 2 times $0.004445 for memory), which works out to roughly $36 a month running all 730 hours in an average month. Model that same continuous workload as a Lambda function invoked back-to-back with essentially no idle time, and the GB-second charges at 2 GB of memory add up to around $88 a month, close to two and a half times the Fargate cost for the identical resource footprint. That gap is the entire argument for Fargate in one comparison: Lambda prices convenience for short bursts, while Fargate prices a dedicated process that never has to spin down and back up again.
Cold Starts and Performance
Cold starts are the most misunderstood part of this comparison. Lambda’s cold start happens when there is no warm execution environment available and AWS has to initialize one from scratch: download the code, start the runtime, and run any module-level initialization before your handler executes. For lightweight runtimes like Node.js or Python, this typically adds low hundreds of milliseconds. For JVM-based runtimes it used to be dramatically worse, which is exactly why AWS built SnapStart, a feature that restores a pre-initialized snapshot instead of booting the JVM from zero, which AWS describes as reducing Java cold starts by up to 10x.
Fargate’s equivalent event is a task launch, and it behaves nothing like a Lambda cold start. Starting a new Fargate task means AWS has to place it on available capacity, pull the container image, and start the process, which typically takes tens of seconds rather than milliseconds. That is not a flaw. It reflects a different design goal. Fargate tasks are meant to stay running, so a slow launch is a one-time cost amortized over hours or days of uptime. Lambda functions are meant to scale to zero and back, so a slow cold start is a recurring tax paid on every fresh invocation.
An independent benchmark from cloud cost firm LeanOps audited 47 production workloads across Google Cloud Run, AWS Fargate, and AWS Lambda in the first quarter of 2026. The result: Lambda was the cost-optimal choice for 36 percent of workloads, almost entirely short, event-driven tasks, while Fargate came out ahead for 23 percent, typically steadier services with predictable resource needs. The remaining share went to Cloud Run, a reminder that the real decision axis is workload duration and traffic shape, not brand loyalty to one AWS service over another.
Execution Limits: Timeouts, Memory, and Ephemeral Storage
Lambda’s 15-minute maximum execution timeout is the single most common reason teams migrate a function to Fargate. Any job that might legitimately run longer, a large file transformation, a slow third-party API call chained several times, a data backfill, will eventually hit that wall and start failing intermittently as data volume grows. Fargate has no equivalent ceiling. A task keeps running until your application exits or you stop it.
Memory tells a similar story. Lambda tops out at 10,240 MB, which comfortably covers the overwhelming majority of functions but rules out memory-hungry workloads like large in-memory caches, bigger machine learning inference batches, or data processing jobs that need to hold a large dataset in RAM. Fargate task memory is configurable well past that ceiling, scaling with the vCPU allocation you choose, which makes it the default choice once a workload’s memory footprint grows past what a function can hold.
Ephemeral storage is a smaller but still relevant gap. Lambda’s /tmp directory defaults to 512 MB and can be configured up to 10,240 MB, which covers most temporary-file use cases like resizing an image or unpacking a small archive. Fargate tasks can attach much larger ephemeral volumes and, when needed, mount a persistent Amazon EFS file system directly, something Lambda does support but with more networking overhead involved. If your workload needs to read and write large files repeatedly across invocations, that persistent mount tips the decision toward Fargate before pricing even enters the conversation.
Scaling, Concurrency, and Networking
Lambda’s scaling model is close to instantaneous. A traffic spike from ten requests a second to ten thousand triggers AWS to spin up new execution environments automatically, up to the account’s concurrency limit, which defaults to 1,000 simultaneous executions per Region and can be raised through a support request. That default is generous for most applications but has burned teams running high-traffic APIs who assumed Lambda scales infinitely without checking their account’s actual quota first.
Fargate scales differently. You define a desired count for an ECS service or a replica count for an EKS deployment, and Application Auto Scaling adjusts that count based on CPU, memory, or custom CloudWatch metrics. It is not instantaneous the way Lambda’s scaling is, since each new task still has to launch, but it gives you direct control over minimum and maximum task counts, which matters for cost predictability. You will never wake up to a surprise bill from an unbounded Fargate service the way an unthrottled Lambda function tied to a runaway event source can generate one.
Networking is where Fargate has the clearer edge. Every Fargate task gets its own elastic network interface inside your VPC by default, with full control over security groups, subnets, and routing. Lambda functions run outside a VPC unless you explicitly attach one, and attaching a VPC to reach a private resource like an RDS database adds latency and complexity that Fargate simply does not introduce, because Fargate tasks are VPC-native from the start.
Integration With ECS, EKS, and Container Workflows
Fargate is not a standalone product. It is a launch type you select inside Amazon ECS or Amazon EKS, which means adopting it requires you to already be thinking in terms of task definitions, services, and container images. Teams already running ECS or EKS workloads can typically switch a service from EC2 to Fargate with a configuration change rather than a rewrite, since the container image and application code stay identical. The tradeoff is losing some of the fine-grained control EC2 launch types offer, like GPU instances or custom kernel parameters, in exchange for not managing servers at all.
Lambda integrates with a completely different set of AWS services. It is the default compute target for API Gateway REST and HTTP APIs, the standard handler for S3 event notifications, and a common worker behind SQS queues and EventBridge rules. For multi-step workflows, AWS Step Functions can orchestrate a sequence of Lambda invocations with retries, branching, and error handling built in, which is a common alternative to writing that coordination logic by hand. Our Step Functions vs Airflow comparison covers that orchestration layer in more depth if you are choosing between AWS-native and open-source options.
One point of confusion worth clearing up directly: Lambda does support container images as a packaging format, which leads some teams to assume “Lambda now runs containers” makes it a Fargate replacement. It does not. A containerized Lambda function is still bound by the 15-minute timeout and the 10,240 MB memory ceiling. The container image format is just a convenient way to package dependencies. It does not change Lambda’s execution model into Fargate’s.
Security, Monitoring, and Operational Overhead
Pricing and limits get most of the attention in any Fargate vs Lambda debate, but day-to-day operational overhead is what teams actually feel every week. Two areas make the biggest difference: how permissions work, and how much visibility you get once something breaks in production.
IAM and permissions model
Both services rely on IAM roles rather than long-lived credentials, which is standard AWS practice at this point. A Lambda function gets an execution role that grants it access to exactly the resources it needs, an S3 bucket, a DynamoDB table, a specific SQS queue, nothing more. Fargate tasks work the same way through task roles, applied at the task-definition level so every container in that task shares one identity. The practical difference shows up at the network layer. Fargate tasks live inside your VPC with security groups controlling inbound and outbound traffic the same way an EC2 instance would, giving you the same firewall-style controls your networking team already understands. Lambda functions sit outside a VPC by default, relying on IAM policies and resource-based policies rather than network-level rules unless you explicitly attach one, which is simpler to reason about but less familiar to teams coming from a traditional networking background.
Logging, tracing, and observability
Both services send logs to Amazon CloudWatch Logs by default, and both support AWS X-Ray for distributed tracing across a request. The difference is in what you have to set up to get useful signal. Lambda automatically reports invocation count, duration, error rate, and throttles per function with no extra configuration, which is part of why it feels so lightweight to operate at small scale. Fargate needs a bit more assembly: CloudWatch Container Insights has to be enabled explicitly to get per-task CPU, memory, and network metrics, and most teams pair it with a dedicated observability platform once they are running more than a handful of services, since raw CloudWatch dashboards get unwieldy fast across dozens of containers. Neither gap is disqualifying, but it is one more reason Lambda tends to feel simpler for a single function and Fargate tends to feel more like running a small platform, because in a meaningful sense, it is one.
Real-World Examples: Fargate and Lambda in Production
Published case studies make the abstract pricing and performance differences concrete. Here are five documented examples of how real companies apply these services.
- BILL runs Amazon ECS on AWS Fargate and layers in Fargate Spot for nonproduction environments, achieving up to a 70 percent discount versus standard Fargate pricing for interruption-tolerant tasks, according to the AWS case study.
- Upside, a cashback marketplace app, cut daily compute costs by 80 percent after switching to Amazon ECS with Fargate and Fargate Spot. Some asynchronous workloads dropped from $100 a day to $10 a day while the architecture kept handling peak traffic without manual intervention, per AWS’s published case study.
- Smartsheet scaled its capacity by 50x within a year on Fargate and, after adopting AWS Graviton processors for its Fargate deployments, saw a 20 percent reduction in compute cost on top of that scaling headroom, according to AWS’s case study.
- A fintech engineering team documented in a Digicraft case study cut monthly cloud spend from $15,000 to $9,000, a 40 percent reduction, after moving to ECS and Fargate. Deployment time fell from roughly three hours to 15 minutes, infrastructure utilization rose from 45 percent to over 85 percent, and the new setup handled peak traffic of up to 100 transactions per second without downtime.
- The LeanOps benchmark referenced earlier found Lambda was the cheapest option for 36 percent of the 47 workloads it tested, mostly short, bursty, event-driven tasks, while Fargate won on 23 percent, generally steadier services, showing that the choice is workload-specific rather than universal.
The pattern across every one of these examples is consistent. Nobody reports switching to Fargate or Lambda in isolation and calling it done. Each case pairs the base service with a cost lever, Spot capacity, Graviton processors, or right-sizing, and the savings numbers reflect that combination rather than the platform alone.
It is also worth pointing out what these examples have in common structurally. BILL, Upside, Smartsheet, and the Digicraft fintech client were all already running containerized services before they optimized them. None of them describe rewriting a container into a set of Lambda functions to save money. That is a strong signal on its own. Once a workload is containerized and running steadily, the cheaper path is almost always to optimize within Fargate, through Spot, Graviton, or right-sizing, rather than to re-architect it around a fundamentally different execution model.
Decision Framework: Which One Should You Choose?
Strip away the marketing and the choice comes down to four questions you can answer about any workload in under a minute.
How long does a single unit of work run? Under 15 minutes, Lambda is eligible. Anything that might exceed that, even occasionally, needs Fargate or another compute option.
How steady is the traffic? Spiky and unpredictable favors Lambda, since you pay nothing during idle periods. Steady, continuous load favors Fargate, since its flat hourly rate beats Lambda’s per-invocation charge once utilization is high.
Does the workload need persistent state, large memory, or custom networking? Large in-memory datasets, sidecar containers, or fine-grained VPC control all point toward Fargate. A stateless handler reacting to one event at a time is a natural fit for Lambda.
What does your team already operate? A team already running ECS or EKS services gains little from bolting on a second compute paradigm just to save a few dollars on a low-traffic function. A team with zero container tooling in place may find standing up a Fargate task definition, cluster, and service is more operational overhead than a single Lambda function justifies for a small job.
Most production systems, in practice, use both. A typical architecture puts Lambda in front of API Gateway for request handling and event processing, while Fargate runs the always-on services behind it, like a search index, a websocket server, or a queue consumer that needs to hold a persistent connection.
5 Use Cases and Which Compute Model Fits Best
1. REST APIs with unpredictable traffic
A public API that might sit idle overnight and spike during business hours is close to the textbook Lambda use case. You pay only for actual requests, and Lambda’s automatic scaling absorbs the spike without any capacity planning on your part.
2. Long-running background workers
A worker that continuously pulls from a queue, processes messages, and never really stops running is a poor fit for a 15-minute timeout. Fargate, sized to the workload and paired with Fargate Spot where interruption is tolerable, handles this pattern at a flat, predictable rate.
3. Scheduled batch or ETL jobs
Short jobs that run on a schedule and finish in minutes fit Lambda well, especially triggered through EventBridge. Once a job’s runtime creeps past 15 minutes as data volume grows, which is a common failure mode for ETL pipelines, migrating that specific job to a scheduled Fargate task removes the timeout risk entirely.
4. Websocket and persistent-connection services
Anything that holds a long-lived connection, a websocket gateway, a gRPC streaming service, or a game server, needs a process that stays alive, which rules Lambda out structurally. Fargate’s persistent tasks are built for exactly this.
5. Machine learning inference at variable scale
Lightweight inference with small models and quick response times can run on Lambda, particularly with Graviton2’s 20 percent lower compute rate. Larger models that need more memory than Lambda’s 10,240 MB ceiling allows, or that benefit from keeping a model loaded in memory across requests to avoid reloading it every time, generally move to Fargate or a dedicated inference service instead.
Migration Guide: Moving Between Fargate and Lambda
Migrations tend to run in one direction more than the other: from Lambda to Fargate, as a function outgrows the timeout or memory ceiling. Here is the practical sequence for that path.
Step 1, containerize the existing handler. Wrap your Lambda function’s business logic in a standard Docker image with a long-running process instead of a single handler invocation. If the function already uses Lambda’s container image packaging, most of this work is done already.
Step 2, replace the event trigger with a queue or a service. A Lambda function triggered by SQS becomes an ECS or EKS service that polls the same queue in a loop. A Lambda triggered by API Gateway becomes a Fargate task behind an Application Load Balancer.
Step 3, define the task and pick a size. Start conservatively, something like 0.5 vCPU and 1 GB of memory for a lightweight service, and scale up based on actual CloudWatch metrics rather than guessing. Oversized tasks are the most common source of Fargate bill shock.
Step 4, set up Application Auto Scaling. Configure minimum and maximum task counts and a target tracking policy on CPU or memory utilization so the service scales the way Lambda used to, without a person watching a dashboard.
Step 5, layer in Fargate Spot for tolerant workloads. Anything that can survive a task restart with two minutes of warning should run on Fargate Spot, capturing the up to 70 percent discount that BILL and other AWS customers report using in production.
The reverse migration, Fargate to Lambda, mostly happens for cost reasons when a service turns out to run far less often than expected. If a task is idle the vast majority of the time, extracting its logic into a Lambda function triggered on demand usually beats paying for a task that sits mostly unused.
Pros and Cons of Each Platform
AWS Fargate
Pros: no execution timeout, memory scales well past Lambda’s ceiling, native VPC networking, supports sidecar containers and persistent EFS mounts, Fargate Spot cuts costs up to 70 percent for tolerant workloads, integrates cleanly with existing ECS or EKS investments.
Cons: no free tier, you pay for idle time if a task sits underutilized, task launches take tens of seconds rather than milliseconds, requires container packaging and orchestration knowledge, no automatic scale-to-zero without extra configuration.
AWS Lambda
Pros: generous free tier of 1 million requests and 400,000 GB-seconds monthly, true scale-to-zero with no idle cost, near-instant scaling to handle traffic spikes, minimal operational overhead, deep native integration with API Gateway, S3, SQS, and EventBridge.
Cons: hard 15-minute execution ceiling, 10,240 MB memory limit, cold starts add latency for infrequently invoked functions, default concurrency limit of 1,000 per Region can surprise teams at scale, VPC attachment adds networking latency and complexity.
The Verdict: Fargate vs Lambda in 2026
There is no single winner in AWS Fargate vs Lambda, and every credible data point backs that up. The LeanOps benchmark split cost-optimal workloads across three services rather than crowning one, with Lambda ahead on 36 percent of tested workloads and Fargate on 23 percent. AWS’s own customer stories point the same way. BILL, Upside, and Smartsheet all built on Fargate because their workloads were containerized services with steady or scheduled demand, not bursty single-purpose functions.
Default to Lambda when a job finishes in minutes, traffic is unpredictable, and you want to avoid managing any infrastructure at all. Default to Fargate when a process needs to stay alive, memory or storage needs exceed Lambda’s ceilings, or you are already operating ECS or EKS and want to keep workloads on infrastructure you understand. The 15-minute timeout and the 10,240 MB memory cap are the two numbers that end most debates in practice. If a workload is nowhere near either limit today but might grow into them, building on Fargate from the start avoids a migration later. If it clearly never will, Lambda’s free tier and zero idle cost are difficult to beat.
The honest answer, backed by every data point in this comparison, is that asking “which one is better” is the wrong framing. AWS did not build Fargate to replace Lambda or Lambda to replace Fargate. It built two different answers to two different shapes of workload, and the LeanOps benchmark’s split result, 36 percent to 23 percent with the remainder going elsewhere, reflects that reality better than any single verdict could. Pick based on execution time, traffic shape, and what your team already operates, and the right answer tends to be obvious well before the pricing spreadsheet comes out.
Frequently Asked Questions
Is AWS Fargate serverless?
Yes. AWS markets Fargate as serverless because you never provision or patch EC2 instances. You still define container tasks and pay for the vCPU and memory they consume, but the underlying servers are entirely managed by AWS.
Can AWS Lambda run containers?
Yes, Lambda supports packaging function code as a container image up to 10 GB. This is a packaging convenience, not a change to Lambda’s execution model. A containerized Lambda function still faces the same 15-minute timeout and 10,240 MB memory limit as a standard function.
Which is cheaper, Fargate or Lambda?
It depends entirely on the workload’s duration and traffic pattern. Short, bursty, low-volume workloads are almost always cheaper on Lambda because of its free tier and zero idle cost. Long-running or steady, high-utilization workloads are usually cheaper on Fargate, especially with Fargate Spot, because its flat hourly rate does not compound the way Lambda’s per-invocation billing does over long durations.
What is the maximum execution time for Lambda vs Fargate?
Lambda enforces a hard 15-minute maximum execution timeout on every invocation. Fargate has no equivalent limit. A Fargate task can run continuously for as long as your application and its underlying process stay alive.
Does Fargate have cold starts like Lambda?
Fargate has an equivalent event, task launch time, but it behaves differently. Launching a new Fargate task typically takes tens of seconds because AWS has to place it on capacity and pull the container image, versus Lambda’s cold starts that typically add low hundreds of milliseconds. Fargate tasks are designed to stay running rather than launch on every request, so the launch delay is a one-time cost rather than a recurring one.
Can you use Fargate and Lambda together in the same application?
Yes, and many production architectures do exactly that. A common pattern uses Lambda behind API Gateway for request-response handling and event processing, while Fargate runs the always-on components behind it, such as a websocket server, a search index, or a persistent queue consumer.
What is Fargate Spot and how much does it save?
Fargate Spot runs interruption-tolerant tasks on spare AWS capacity at a steep discount. AWS’s published BILL case study describes savings of up to 70 percent compared with standard on-demand Fargate pricing, in exchange for the possibility a task is reclaimed with roughly two minutes of warning.
Should I migrate from Lambda to Fargate as my workload grows?
Migrate when you consistently approach Lambda’s 15-minute timeout or 10,240 MB memory ceiling, or when sustained high traffic makes Lambda’s per-invocation pricing more expensive than Fargate’s flat hourly rate. If your function comfortably stays within Lambda’s limits and traffic remains bursty, there is little reason to add the operational overhead of containers and orchestration.
Do Fargate or Lambda support GPU workloads?
Neither service currently offers GPU-backed compute. Teams that need GPU acceleration for machine learning inference or training typically turn to GPU-equipped EC2 instances, Amazon SageMaker endpoints, or Amazon ECS and EKS running on GPU-enabled EC2 launch types instead of the Fargate launch type. If GPU access is a hard requirement, that rules out both services in their current form.
Is there a pricing difference between Fargate on ECS and Fargate on EKS?
The underlying Fargate compute rate, per vCPU-hour and per GB-hour, is the same whether it backs an ECS task or an EKS pod. The cost difference between the two comes from the orchestrator layer sitting on top, not from Fargate itself. Amazon EKS adds a separate cluster fee on top of whatever Fargate compute the pods consume, while Amazon ECS has no equivalent control-plane charge, which is why teams choosing purely on cost, with no need for Kubernetes specifically, often default to ECS on Fargate rather than EKS on Fargate.
Related Coverage
- ECS vs EKS vs Fargate: $0 vs $73/mo Control Plane [2026]
- How to Build an AWS Lambda API: 12 Steps, 60 Min [2026]
- Cloudflare Workers vs Lambda 2026: 240x Cold Start Gap
- AWS Reserved vs Savings Plans vs Spot: 90% Off [2026]
- Step Functions vs Airflow: $0 vs $357/mo Floor [2026]
- AWS FinOps Agent Launches Free in $16.5B Market [2026]
- More Cloud Computing coverage
