What actually happens when a Lambda function hits its fifteen-minute ceiling in the middle of a payroll run? That single question explains why the Fargate-versus-Lambda debate refuses to die. Both services hide servers from you. Both bill by consumption. Yet they solve fundamentally different problems, and picking the wrong one shows up months later as rewrites, surprise bills, or brittle workarounds. This guide walks through the architecture decisions that matter, framed for teams planning workloads into 2027.
Two Services, Two Very Different Bets
AWS Lambda arrived in November 2014 as an event-driven compute service: you upload code, an event fires, the function runs, and it disappears. Fargate followed in November 2017 as serverless compute for containers, initially for Amazon ECS, with support for Amazon EKS arriving in 2019. The launch dates matter less than the philosophy behind each. (Common aws fargate mistakes avoid when running containers)
Lambda bets that your work fits inside a function: short, event-triggered, stateless. Fargate bets that your work fits inside a container: a long-running process with its own runtime, dependencies, and lifecycle. The official overview of how Lambda’s execution model works is worth reading before you commit either way.
The practical consequence is simple. Lambda handles a webhook in milliseconds and charges you for those milliseconds. Fargate keeps a container warm for hours and charges for every second it exists. Neither is better. They are different shapes of compute.
The Hard Limits That Force the Decision
Most teams do not choose between Lambda and Fargate on philosophy. They choose because one of them physically cannot run the workload. Lambda’s quotas do the deciding for you, and they are stricter than people remember:
| Constraint | Lambda limit | What it means in practice |
|---|---|---|
| Maximum execution time | 15 minutes (900 seconds) | Long batch jobs, video encoding, and report generation often exceed it |
| Synchronous payload | 6 MB | Large API responses need another delivery path |
| Asynchronous payload | 256 KB | Event payloads must stay small |
| Deployment package | 50 MB zipped, 250 MB unzipped | Heavy dependencies push you toward container images |
| Container image size | Up to 10 GB | The escape hatch for fat runtimes |
Fargate’s constraints are gentler but real. Tasks are sized by CPU and memory combinations, from small 0.25 vCPU configurations up to 16 vCPU and 120 GB of memory, and you are billed per vCPU-second and GB-second. Storage is ephemeral, with a default allocation that can be expanded, but nothing persists after the task stops.
Here is the rule that saves the most pain: if a job routinely runs past ten minutes, prototype it on Fargate, not Lambda. Teams that ignore this end up chaining functions together or splitting work into awkward chunks, and both fixes add complexity that never goes away. For a deeper look at where these limits bite, this breakdown of the AWS Lambda production mistakes that quietly break your system is a sobering read.
Cold Starts, Concurrency, and the Latency Budget
Lambda’s scaling story is its strongest selling point and its most misunderstood feature. Each function scales through concurrency, with a default account-level limit per region that AWS has adjusted over time, so check the current figure rather than trusting a blog post from 2022. When traffic spikes faster than environments can initialize, you get cold starts: fresh execution environments that must load your code before handling the first request.
Provisioned concurrency, introduced in 2019, pre-initializes environments to keep latency flat. It works. It also costs money whether or not requests arrive, which quietly turns a pay-per-use model into a reserved-capacity model for your hottest functions.
Fargate sidesteps cold starts because containers stay running. The trade-off is that scaling is coarser: you add tasks, each with a startup time measured in tens of seconds, and you pay for idle capacity between requests. For a public API with steady traffic, that is fine. For a workload that is silent for twenty hours a day, it is waste.
A pattern that works well in practice: run latency-sensitive request handling on provisioned Lambda, and run steady background processing on Fargate. Mixing the two is not indecision. It is matching each workload to its billing model.
State, Storage, and the Stateless Assumption
Both services push you toward stateless design, but they push differently. Lambda functions are expected to assume nothing survives between invocations, though in reality a warm environment may reuse temporary files. Relying on that is a classic mistake, because the next invocation may land in a brand-new environment.
Fargate tasks can hold local state for the life of the task. That makes them a natural fit for workloads that need a scratch disk, a long-running connection pool, or a process that builds up memory over hours. The storage is still ephemeral, so anything you need later belongs in S3, a database, or a queue.
The architecture decision here is about where truth lives. If your design already puts durable state in managed services, Lambda is comfortable. If your application assumes a filesystem and a persistent process, Fargate will cost you far less refactoring.
Cost Models That Reward Different Traffic Shapes
Nobody enjoys cost modeling, but the two services punish different mistakes. Lambda charges per request and per gigabyte-second of execution, so a fast function called a million times is cheap, and a slow function called a million times is not. Fargate charges for provisioned resources per second, so a container that idles overnight still appears on the invoice.
The trap is assuming Lambda is always cheaper because you only pay when code runs. A function that runs for fourteen minutes on every invocation, or one that fans out into thousands of parallel executions, can outspend a modest Fargate service. Conversely, a Fargate task that sits at low utilization for most of the day is pure overhead.
Two habits separate teams that get this right from teams that get surprised:
- Model the workload in its real traffic shape, including nightly quiet periods and monthly spikes.
- Revisit the model after launch, because the first estimate is almost always wrong in one direction.
If you want the numbers behind the second habit, this analysis of what AWS Fargate really costs a small project or business covers the line items people forget. And if your workloads are function-based, the same exercise applied to AWS Lambda costs for small projects and businesses is worth an hour of your time. (What is AWS Lambda?)
Operational Complexity Is the Hidden Variable
Lambda wins on operations for small teams. There are no clusters, no task definitions, no container images to patch, and no capacity planning. You deploy code and move on. That simplicity is genuine, and it is why so many startups ship their first product entirely on functions.
Fargate asks more. You build and version images, define task definitions, manage service discovery, and think about networking in ways Lambda hides from you. The payoff is control: custom runtimes, native binaries, background workers, and processes that behave like ordinary servers.
There is a middle path worth knowing. Running containers on Kubernetes gives you portability and a rich ecosystem, but it also hands you a control plane to operate. Understanding how the Kubernetes architecture splits control plane and worker nodes helps you judge whether that overhead is worth it before you adopt it. Many teams discover they wanted Fargate’s simplicity, not Kubernetes’ flexibility.
Where Each Service Genuinely Belongs
After enough migrations, patterns emerge. Lambda fits event-driven glue: webhooks, file processing triggered by uploads, scheduled cleanups, API backends with spiky traffic, and anything that reacts to a queue. Fargate fits long-running services: background workers, batch pipelines that exceed the timeout, containerized legacy applications, and workloads that need a specific runtime or native library.
A useful test before committing: describe the workload in one sentence. If it starts with “when X happens,” Lambda is probably right. If it starts with “continuously” or “for the next several hours,” reach for Fargate.
The architecture also matters beyond the compute choice. Event-driven designs change how you handle retries, ordering, and failure isolation, and a solid grounding in serverless computing architecture and event-driven functions pays off regardless of which runtime you pick.
Mistakes That Show Up in Production
Some errors repeat so often they deserve naming. Chaining Lambda functions to dodge the fifteen-minute limit creates fragile pipelines where one failure cascades. Ignoring concurrency limits means a traffic spike throttles your entire account, including unrelated functions. Deploying oversized Fargate tasks “just to be safe” inflates the bill without improving performance. Forgetting that Fargate tasks restart means in-memory caches vanish without warning.
The teams that avoid these mistakes share a habit: they test failure modes before launch. They throttle their own functions deliberately, kill containers mid-task, and watch what happens. A review of the AWS Fargate production mistakes teams keep making covers several of these failure patterns in detail, and the common Fargate mistakes to avoid when running containers is a good companion checklist.
One more practical tip: keep your deployment artifacts small and your startup paths short. Whether that means trimming a Lambda package or slimming a container image, startup time is the silent tax on both services.
What Changes by 2027 and What Does Not
Predicting AWS roadmaps is a fool’s game, and no credible source promises specific features by 2027. What is safe to say is that the underlying constraints change slowly. Timeout ceilings, payload limits, and billing granularity have shifted over the years, but the fundamental split between event-driven functions and long-running containers has held for a decade.
The decisions that will still matter are architectural, not tactical. Keep business logic separate from the compute runtime so you can move a workload between Lambda and Fargate without a rewrite. Put durable state in managed services. Measure real traffic before you optimize. Those choices age well; instance types and pricing tiers do not.
Conclusion
Fargate versus Lambda is not a rivalry, and treating it as one leads to bad architecture. Lambda is the right answer for short, event-driven, spiky work where operational simplicity matters. Fargate is the right answer for long-running, stateful-ish, container-shaped work where control matters more than convenience. Most mature systems end up using both, with a clear line between them.
The teams that get this right ask three questions before writing code: How long does the work take? What shape does the traffic have? How much operational overhead can we absorb? Answer those honestly, and the choice usually makes itself.
Frequently Asked Questions
Can I run the same code on both Lambda and Fargate?
Yes, if you design for it. Keep business logic in plain functions or modules, avoid depending on runtime-specific APIs, and treat the compute layer as a thin wrapper. Container images work on both, since Lambda accepts images up to 10 GB. The portability pays off the first time a workload outgrows its original home.
What happens when a Lambda function exceeds fifteen minutes?
The invocation is terminated. There is no graceful extension. Teams work around it by splitting work into chunks, moving the job to Fargate, or using Step Functions to orchestrate stages. If a job regularly approaches the limit, that is a signal to migrate rather than engineer around it.
Is Fargate always more expensive than Lambda?
No. Fargate costs more for spiky, low-volume workloads because you pay for idle capacity. Lambda costs more for long-running or high-volume-heavy workloads because execution time adds up. The only reliable answer comes from modeling your actual traffic shape, not from general rules.
Do cold starts make Lambda unsuitable for APIs?
Not necessarily. Provisioned concurrency keeps environments warm for latency-sensitive endpoints, at an extra cost. Many APIs run fine on standard Lambda, especially when functions stay small and initialization is fast. Measure your p95 latency before assuming cold starts are the problem.
Can Fargate tasks store data locally?
Only for the life of the task. Fargate provides ephemeral storage with a default allocation that can be expanded, but it disappears when the task stops. Anything that must survive belongs in S3, a database, or another durable service.
Which one should a small team start with?
Start with Lambda if the workload is event-driven and short. It has the lowest operational overhead and the fastest path to production. Move to Fargate when you hit a hard limit or need a long-running process. Starting simple and migrating deliberately beats over-engineering on day one.
