Serverless vs Containers for Backends in 2026
How functions like Lambda and containers on Fargate, Cloud Run or Kubernetes differ on cost, latency, limits, local development and lock-in, and how to pick for an API backend.
Serverless and containers are two ways to run the same backend code on someone else's machines. A function platform like AWS Lambda runs a handler per request and bills per invocation. A container platform like ECS Fargate, Cloud Run or Kubernetes runs your server process and bills for the capacity it holds. The choice shapes pricing, latency, what the code is allowed to do, and how the app runs on a laptop.
This guide compares the two for API backends, the most common case, and ends with a decision guide.
Serverless vs containers at a glance
How serverless functions work
Lambda creates an execution environment, loads your code, and passes it one event at a time: an HTTP request through API Gateway or a Function URL, a message from SQS, an object notification from S3. Environments are reused for later requests and discarded when idle, and new ones are created as concurrency rises. Lambda's quotas set the edges: 15 minutes per invocation, up to 10,240 MB of memory, and a regional concurrency limit per account.
The model removes capacity planning: a function that receives ten requests a day costs close to nothing, and one that receives a sudden spike scales out without configuration. The costs appear in the code: each environment handles one request, so a burst of 500 concurrent requests opens 500 database pools, and long work has to be split or moved to Step Functions. The first request on a new environment pays the cold start, which for a small Node.js or Go function is typically a few hundred milliseconds and grows with package size and runtime.
How containers work
A container image packages the whole server, such as an Express, FastAPI or Gin app listening on a port. A platform runs a number of copies behind a load balancer and scales that number on CPU, memory or request count. Fargate runs ECS tasks without servers to manage and bills per second for the vCPU and memory of each running task. Cloud Run bills while instances handle requests and can scale to zero. Kubernetes runs pods on nodes you size and pay for.
One process serves many concurrent requests, so a connection pool, an in-memory cache or a WebSocket connection behaves as it does on a laptop, and there is no per-request time limit on Fargate or Kubernetes, and the image runs anywhere containers run. The costs are on the operations side: you choose task sizes and scaling policies, and you pay for minimum capacity even at night.
Cost: where the lines cross
Functions win when traffic is low or bursty, because idle time is free. Containers win when traffic is steady, because a busy container's per-request cost is lower than Lambda's per-request plus duration price. The crossover depends on the workload, so the useful exercise is to price your own traffic with the Lambda pricing page and the Fargate pricing page: requests per month times average duration and memory for Lambda, against the number of tasks needed at peak and their size for Fargate. API Gateway adds a per-request charge on the function side that is easy to forget, and a load balancer adds a fixed hourly charge on the container side.
Latency and limits
Containers have no cold start on the request path once running, which matters for APIs with latency targets. Functions can avoid most cold starts with provisioned concurrency, which is billed while it is configured and so moves the function toward container pricing. Requests that run longer than 15 minutes, hold WebSocket connections or stream for a long time fit containers. Short, independent handlers for events from S3, SQS or EventBridge fit functions well.
Local development
A container backend runs locally as the same process, with Docker Compose for its database and queue. A function backend needs an emulator such as sam local, which emulates Lambda and API Gateway but not the queues and databases around them, or a deployed dev stage per developer. For a backend with several functions, a database and a queue, the local setup often costs more developer time each day than the hosting choice saves.
Where Encore fits
Encore combines an open source infrastructure SDK with a platform that provisions and deploys into your own AWS or GCP account. It is infrastructure from code for the container side of this decision: services are written in TypeScript or Go, and the databases, Pub/Sub topics, buckets and cron jobs they use are declared in the same code. On AWS, Encore runs the services on Fargate or EKS behind a load balancer and provisions RDS, SNS and SQS, and S3, and it provisions an IAM role for the service. On GCP it uses Cloud Run or GKE with Cloud SQL, Pub/Sub and Cloud Storage, as described in the infrastructure overview.
Two of the container downsides above go away with it. There is no task definition, load balancer or Terraform to write, since the platform derives them from the code, and encore run starts Postgres locally along with the queues and buckets, so the local setup needs no Compose file. Asynchronous work that would be a Lambda behind SQS becomes a Pub/Sub subscription in the same service, and scheduled functions become cron jobs run by the Encore platform.
Encore does not deploy Lambda functions, so if the workload is a handful of event handlers with near-zero traffic, functions remain the cheaper option.
Best fit: teams that have chosen containers for an API backend and want the surrounding infrastructure provisioned from the application in their own AWS or GCP account. See deploying to your own cloud for setup.
How to choose
Pick serverless functions for event handlers, glue code and APIs with low or unpredictable traffic, where idle cost matters more than latency and each request is short. Pick containers for APIs with steady traffic, latency targets, long requests, WebSockets or heavy database use, and for teams that want the same process locally and in production. Cloud Run sits between the two, with containers that scale to zero. Many backends use both: a container API for requests and a few functions for S3 or SQS events.
Related guides
Frequently asked questions
What is the difference between serverless and containers?
Serverless functions such as AWS Lambda run your code per request or event, scale to zero and bill per invocation and duration, with limits on runtime and package size. Containers package the whole server process, run continuously on services such as ECS Fargate, Cloud Run or Kubernetes, and bill for the capacity they reserve, without per-request limits.
Is serverless cheaper than containers?
At low or spiky traffic, usually yes, because functions cost nothing when idle. At steady traffic the per-request price overtakes the cost of a container that is busy most of the time, so a backend serving a constant load is often cheaper on Fargate or Cloud Run. The crossover depends on request duration, memory and how evenly traffic is spread.
Are Cloud Run and Fargate serverless?
Both are serverless in the sense that you do not manage servers, but they run containers. Fargate runs tasks that stay up until you stop them, while Cloud Run can scale container instances down to zero between requests, which places it between Lambda and always-on containers.
How does Encore fit the serverless vs containers decision?
Encore deploys backends as containers on Fargate or EKS on AWS, or Cloud Run or GKE on GCP, in your own account, with the databases, queues, buckets and cron jobs declared in TypeScript or Go code. It suits teams that have chosen containers and want the infrastructure around them provisioned from the application instead of written by hand.
Deploy to your cloud on AWS and Google Cloud
without managing infrastructure
Encore lets developers and agents define application infrastructure directly in code, then automatically provisions it from local development to production in your AWS or GCP account.
