Lambda vs Fargate

Serverless.

Overview

Lambda versus Fargate is the choice between two AWS serverless models with very different shapes. Lambda is event-driven, sub-15-minute execution, per-millisecond billing, optimised for short-lived functions triggered by events. Fargate is container-based, long-running, per-second billing, optimised for containerised workloads that need a constant footprint or run longer than Lambda’s ceiling. The discipline is matching the workload shape to the right serverless model rather than picking based on familiarity.

• Two AWS serverless models. Per-workload the right serverless choice; Lambda and Fargate solve different problems.
• Lambda: event-driven. Per-event short-lived function; sub-15-minute execution, per-millisecond billing.
• Fargate: containerized. Per-container long-running workload; per-second billing, no per-execution ceiling.
• Per-workload duration plus operational fit. Long-running workloads land on Fargate; event-driven on Lambda; per-team operational preference informs hybrid setups.

The approach

The practical approach is to match Lambda to event-driven short-lived workloads (API endpoints, queue consumers, scheduled jobs under 15 minutes), Fargate to long-running containerised workloads (web servers, background workers, anything beyond Lambda’s ceiling), per-team operational preference where the workload could go either way, and per-service documented rationale committed to the infrastructure repo.

• Workload-driven. Per-workload the serverless choice; the workload shape determines the right model.
• Lambda for event-driven. Per-event short-lived function; the per-millisecond billing rewards short execution.
• Fargate for containerized. Per-container long-running workload; the per-second billing matches sustained execution.
• Per-team operational fit plus documented choice. Per-team operational preference where the workload could go either way; per-service rationale committed for review.

Why this compounds

Serverless discipline compounds across services. Each correct match avoids the painful migration when a Lambda hits the 15-minute ceiling or a Fargate task wastes idle compute. The team builds intuition for serverless economics that pays off on every new workload.

• Better cost efficiency. The right serverless model matches the workload's billing curve. Lambda for spiky event-driven work, Fargate for sustained execution; the bill stops surprising finance.
• Better operational fit. The right serverless model matches the team's reflexes. Container-shop teams own Fargate ergonomics; function-shop teams own Lambda ergonomics; mismatches show up as on-call friction.
• Better engineering culture. Workload-driven decisions replace tribal preference. New services get a written rationale rather than "we always use Lambda" or "we always use Fargate".
• Investigation discipline plus compounding maturity. Each decision teaches serverless patterns; year one lays the foundation, year two onwards the discipline becomes habit. Subsequent picks are routine rather than re-litigation.