AWS Fargate vs Lambda for Containerized Microservices

Someone eventually has to decide: does this run on Lambda, or on Fargate? Both get marketed as "serverless," and that single word hides the fact that they solve different problems and break in different ways when traffic doesn't behave. AWS's own decision guide treats them as distinct enough to need a dedicated comparison: Fargate is a serverless compute engine built for containers running long-lived processes, and Lambda is a function-as-a-service that runs code in response to events, capped at 15 minutes per invocation. The real question for any engineering team is whether the workload needs a container or just a function, and whether that workload runs continuously or fires in response to events. Get that match wrong, and the cost doesn't show up on a features checklist. You see it later, in latency spikes, billing surprises, and debugging sessions that take longer than they should.

How Fargate and Lambda execute code

Fargate and Lambda start from opposite assumptions about what a workload looks like. Fargate runs full Docker containers as long-lived services, and those containers can hold state in memory across many requests, because the process just keeps running. Lambda does the opposite: it spins up an isolated function handler for a single event, runs it, and tears it down almost immediately after.

The resource ceilings reflect that split. AWS documents Fargate as continuous compute with no hard execution time limit, memory allocation up to 244 GiB, and CPU up to 32 vCPU, with each ECS task or EKS pod running in its own isolated environment. Lambda is stateless by design, with memory up to 10 GiB, CPU that scales with memory up to 6 vCPU, and a 15-minute cap per invocation. Anything that needs to persist has to live outside the function, in something like S3, DynamoDB, or EFS.

The isolation models differ too, and not in a minor way. Each Fargate task gets its own elastic network interface and its own security groups, so one task can't see another's processes or files. So you avoid the noisy-neighbor problems you get on shared EC2 clusters, where one workload's resource spike can degrade another's performance. Lambda's concurrency model works per invocation: if two events land at the same moment, Lambda starts two separate instances. That's how it scales horizontally within milliseconds, without anyone provisioning capacity ahead of time.

None of this makes one service a better version of the other. They run on different execution models, and each one fails differently if it meets the wrong kind of workload. That distinction is the foundation everything else in this comparison rests on.

Cold start behavior and scaling speed as a function of workload traffic pattern

Cold starts and scaling speed aren't side notes. They decide whether a service can survive a given traffic pattern at all, and Fargate and Lambda land on opposite ends of both measures.

Lambda cold starts run from a few milliseconds to a few seconds, depending on the runtime and how large the deployment package is. Fargate task starts are slower by an order of magnitude: tens of seconds under normal conditions, sometimes over a minute, and in some cases two minutes or more depending on image size, network conditions, and how busy the underlying infrastructure is. That gap alone rules Fargate out for workloads that need to respond to a cold request in under a second.

Scaling speed follows the same split. Lambda scales per request automatically, so it absorbs a sudden traffic spike without anyone pre-provisioning anything. Fargate scales by launching new tasks, and that process is policy-driven and limited by how fast tasks can launch. A sharp, unpredictable spike will hit Fargate's queue before new capacity comes online to handle it.

Once a Fargate task is running, its performance stays steady and predictable, bounded only by the vCPU and memory assigned to it. Lambda can throttle concurrent executions once an account hits its concurrency limit, which introduces latency spikes during bursts. AWS's own comparison confirms the pattern: Fargate supports predictive scaling, using historical traffic data to scale ahead of expected demand, while Lambda's strength is automatic per-request scaling for traffic that has no predictable shape.

Lambda offers a mitigation for cold starts called provisioned concurrency, which keeps a set number of function instances warm and ready. It eliminates the cold start penalty, but it changes the billing model in the process: provisioned concurrency is billed continuously whether or not traffic arrives, at a reduced per-execution rate, on top of the usual per-request charges. In effect, turning on provisioned concurrency moves Lambda closer to Fargate's standing-capacity model. That's a sign of how closely billing follows workload shape rather than service label: a service with steady, predictable traffic benefits from Fargate's warm baseline, while a service that sits quiet for hours and then spikes suddenly gets more value from Lambda's cold-start tradeoff than from paying to keep capacity warm all day.

The execution time ceiling's effect on workload architecture

Lambda's 15-minute execution ceiling is a hard constraint, not a guideline you can push against if you're careful, and it rules out entire categories of workload before you write any code.

This failure mode plays out often enough to be predictable. If a team migrates a long-running ETL job, a batch transform, or an ML inference pipeline over to Lambda, the 15-minute wall becomes visible mid-project, not in planning. The team burns sprints on a full rearchitecture, and the launch date slips. The lesson for anyone building a decision framework: any workload with a step that routinely runs past 15 minutes is off the table for standard Lambda, full stop, before cost or cold starts even enter the conversation.

AWS does offer an escape hatch. Lambda durable functions extend workflows up to a year, using a checkpoint-and-replay execution model. That's a different programming model from a simple long-running process, requiring you to redesign the workload around checkpoints.

Fargate carries no equivalent ceiling. A containerized batch job, a persistent queue worker, or a long-running data pipeline runs until it finishes or gets stopped, so you don't have to restructure it to fit inside a time box.

Billing Structure and Hidden Costs from Mismatched Workload Shape

The claim that Lambda is the cheaper serverless option holds only under certain conditions, and it flips at a scale that arrives sooner than most teams plan for.

The billing mechanics explain why. Fargate charges per vCPU-hour and per GB-hour for as long as a task runs, so you still pay for idle Fargate capacity even when no requests are coming in. Lambda charges per request and per millisecond of execution, and nothing gets billed while a function sits idle. For a low-volume workload that runs for short bursts, Lambda's per-invocation model wins. But if a service runs steady-state around the clock, Fargate's flat per-resource rate ends up cheaper, because you pay no per-invocation premium on top of the compute cost.

A few costs make that crossover arrive faster than expected. Every Lambda invocation writes to CloudWatch, so at high invocation volumes, log ingestion alone turns into a real line item on the bill. You also pay API Gateway's own per-request charge on top of what you already pay for Lambda. Fargate has a comparable trap running the other direction: a service that stays up continuously at low utilization still pays for the vCPU and memory it reserved, whether or not it's doing useful work. Right-sizing tasks and using Fargate Spot for workloads that can tolerate interruption are the usual fixes, and Fargate Spot cuts costs substantially for workloads built to handle that tradeoff.

Most teams land on a hybrid split rather than picking one service for everything, and that split has a real rationale behind it. Lambda handles the bursty, event-driven pieces where per-invocation billing works in its favor. Fargate handles the sustained, always-on pieces, because its flat per-resource billing is cheaper there. AWS's own prescriptive guidance backs this split directly, and that says something about how rarely a single-service answer actually fits a real system.

You tend to see the mismatch between a team's operational model and its compute primitive most clearly right here, in the monthly bill. Platforms that deploy containers directly into a customer's own cloud account can remove the Fargate-versus-Lambda choice from the table entirely, handling orchestration and scaling automatically so a team can think about workload shape instead of memorizing AWS service primitives.

State management requirements as the deciding factor for containerized microservices specifically

For containerized microservices specifically, the question of state tends to settle the Fargate-versus-Lambda decision faster than cost, cold starts, or anything else. Fargate preserves in-memory state for as long as a task runs. Lambda is stateless by design, full stop.

AWS states this directly in its own comparison: Fargate containers can hold state in memory across requests while the container is running, while Lambda requires state to live somewhere external, whether that's S3, DynamoDB, or EFS. When a team pushes a stateful workload onto Lambda anyway, the common response is to bolt on an external state store. That's not a small inconvenience. It adds real complexity to the system and can push total cost well past what a Fargate service would have spent holding that same state natively, in memory, inside the container.

This is where the word "containerized" in this comparison does real work. A microservice that holds open WebSocket connections, tracks session context, or carries per-request state across several processing steps fits poorly into Lambda's stateless invocation model unless a team builds substantial scaffolding around it. Fargate's networking setup makes the same job far simpler: each task gets its own ENI, its own security groups, and its own task role, which supports persistent TCP connections and service-to-service communication patterns that Lambda's event-by-event model doesn't handle naturally.

A team migrating an existing container-based microservice toward serverless compute is choosing whether to pay for state management in infrastructure, by running it on Fargate, or in engineering time, by building and maintaining the scaffolding Lambda needs to fake persistence it wasn't designed to have.

GPU and AI inference workloads: where neither Fargate nor Lambda is the full answer

For AI inference and training workloads, the Fargate-versus-Lambda comparison runs into a wall that neither service can get past: neither one supports GPU compute. So for any team building GPU-dependent services, that single fact changes the shape of the architecture.

Lambda has no GPU resource type to configure, and Fargate doesn't support GPU instances either. Every GPU container workload on AWS needs the EC2 launch type instead, typically through ECS with EC2 capacity providers, EKS with GPU nodes, SageMaker, or Batch.

The pattern that results is hybrid by necessity. Lambda handles orchestration, authentication, preprocessing, and routing. A separate GPU service handles the actual inference or training work. Cold starts in Python ML functions stack on top of inference latency in the orchestration path, so you need to manage Lambda's cold-start behavior more closely here than in a simpler API-only service. Fargate still earns a real role in this pipeline: persistent queue workers, model result caching services, and preprocessing containers that run around the clock are a natural fit for it, even if the inference step itself has to live elsewhere.

Teams building AI microservices should plan from the start for a three-tier setup, Lambda for orchestration, Fargate for sustained non-GPU workers, and EC2-based GPU services for the inference itself, rather than treating this as a binary choice between two options.

Compliance and security posture differences between Fargate and Lambda

For regulated workloads, Fargate and Lambda carry meaningfully different compliance postures, and the choice between them can decide whether a team leans entirely on AWS's built-in certifications or has to build additional controls on top.

Fargate's compliance coverage spans PCI DSS, SOC, FIPS 140-2, FedRAMP, and HIPAA. With the right data protection agreement in place with AWS, a team can process encrypted protected health information inside Fargate-deployed containers, which makes it HIPAA-eligible for that kind of workload. Fargate's isolation model adds another layer of relevance for regulated multi-tenant systems: every ECS task or EKS pod runs on dedicated, single-use, single-tenant compute, which gives it a virtualization boundary that shared-kernel container runtimes don't provide by default.

Lambda's reduced attack surface and AWS-managed patching ease a lot of the compliance burden on their own. But its stateless, shared-kernel model means a team running sensitive multi-tenant workloads has to check carefully whether Lambda's isolation level actually meets the requirements in question, rather than assuming it does because the service is managed by AWS.

Teams running on Porter get SOC 2 and HIPAA compliance handled at the infrastructure layer no matter which AWS primitive the workload deploys to, removing an entire category of compliance work from the decision.

Where Lambda MicroVMs fit

Lambda MicroVMs launched June 22, 2026, and they're a distinct compute primitive, not an update to how Lambda functions already work. They're built for a narrow but real class of workload, mainly session-based, isolated sandboxes for running untrusted code, something neither Fargate nor Lambda handles cleanly on its own.

AWS's own decision guide leaves Lambda MicroVMs out of the Fargate-versus-Lambda comparison, treating them as a separate primitive with their own developer guide. For nearly every team building containerized microservices, the framework laid out here, execution model, cold start behavior, the 15-minute ceiling, billing shape, state management, GPU needs, and compliance posture, still decides the call between Fargate and Lambda. MicroVMs answer a different question, for a different kind of workload, and they don't change that.