How do you choose serverless compute on AWS?

Start with the shape of the work

Describe how work begins, how long it can run, whether it is synchronous or asynchronous, how much concurrency it needs, and what state or local resources it expects. Compute is a consequence of those constraints, not the starting point of the architecture.

A short handler responding to an API request, queue message, object event, or schedule often fits Lambda. A continuously running consumer, specialized binary, multi-process container, or job that exceeds Lambda's execution model may fit Fargate better.

When AWS Lambda is the stronger fit

Lambda manages execution environments and scales invocations from events. It is useful when work is bounded, stateless between invocations, and naturally connected to AWS event sources or managed service integrations.

When serverless containers are the stronger fit

AWS Fargate supplies compute capacity for containers used with Amazon ECS or Amazon EKS. It removes server provisioning while preserving the container's process model, image, networking choices, and task-level resource configuration.

Use it when the workload needs a long-lived process, more runtime control, a container-oriented deployment model, larger or specialized resource combinations, or migration compatibility that would make a function rewrite artificial.

Make the boundary explicit

Compare latency, duration, concurrency, startup behavior, isolation, network access, deployment size, observability, team skills, and total cost at expected utilization. Include downstream capacity and operational ownership in the comparison.

A system can use both models. Keep each component behind an API, queue, stream, or event contract so its compute model can evolve without changing every producer and consumer.