Serverless vs containers
vs Kubernetes on AWS.
Choose a compute model from real demand, execution, recovery and team constraints—not a platform trend or an assumed maturity ladder.
There is no universal progression from functions to Kubernetes.
Serverless is useful when work is bounded and demand is variable. Managed containers fit longer-running services and established runtimes. Kubernetes earns its operational cost when a genuine multi-workload platform need exists. Virtual machines remain valid where compatibility or migration constraints require host control. Begin with the workload, not the destination.
Match the delivery shape to the evidence you have.
Scroll horizontally to compare the options →
| Delivery shape | Useful when | Primary advantage | Evidence to demand |
|---|---|---|---|
| Serverless functions and events | Short-lived APIs, scheduled work, file processing and variable or event-driven demand | Low infrastructure management and fine-grained scaling | Execution limits, event retries, concurrency, observability and service coupling |
| Managed containers | Web services, workers and existing runtimes that benefit from portable packaging | Runtime control without managing a cluster or individual servers | Image lifecycle, task sizing, networking, scaling signals and startup behaviour |
| Managed application platform | Conventional web applications or APIs with a standard deployment shape | A small operational surface and familiar application release model | Platform constraints, scaling assumptions and an untested exit route |
| Kubernetes | Several teams or workloads with a justified need for its APIs and ecosystem | A consistent platform for complex container estates and specialist workloads | Creating a platform team and operational burden for one ordinary application |
| Virtual machines | Operating-system dependencies, commercial software or staged migration needing host control | Compatibility and an incremental route away from existing infrastructure | Carrying patching, images, capacity and recovery responsibility without a plan |
Let workload constraints eliminate the wrong options.
How does demand arrive?
Measure baseline, peaks, duration, concurrency, latency and scheduled or event-driven work using representative traffic and jobs.
What must the runtime do?
Record execution duration, protocols, dependencies, local state, hardware, background processing and operating-system constraints.
How should it fail and recover?
Define retry safety, dependency behaviour, availability, data-loss tolerance, restore, rollback and failure isolation.
Who will operate it?
Match deployment, security, observability and incident responsibilities to the real skills and capacity of the owning team.
What is the whole-life cost?
Include cloud consumption, environments, logs, support, platform engineering, patching and the cost of changing the architecture later.
Managed does not mean responsibility disappears.
Design the event contract
Functions remove server management but retain application responsibility. Model duplicate events, retries, partial failure, concurrency, permissions, cold starts and observability across asynchronous paths.
Own the service lifecycle
Managed container services reduce cluster work, but images, base dependencies, task sizing, networking, scaling, secrets, health checks and deployment rollback remain deliberate choices.
Fund a platform capability
Kubernetes introduces powerful APIs and a broad ecosystem alongside policy, upgrades, workload identity, ingress, observability and platform support. Name the platform owner before naming the cluster.
Architecture is the evidence behind continuing responsibilities.
Operational excellence
Versioned change, observable releases, actionable runbooks and learning from incidents and usage.
Security
Least privilege, data protection, audit, vulnerability response and an exercised incident path.
Reliability
Explicit service and recovery objectives, tested backups, dependency behaviour and safe rollback.
Performance and cost
Representative load, useful latency measures, scaling signals, budgets and cost per useful transaction.
The official AWS Well-Architected Framework provides a structured way to review these trade-offs across the workload lifecycle.
AWS compute architecture FAQ.
Is serverless always cheaper than containers on AWS?
No. Serverless can be economical for intermittent, variable or event-driven work, but duration, concurrency, invocation volume, data transfer and observability still matter. A continuously busy workload may cost less or behave more predictably on a right-sized managed container service. Compare representative demand and include operating effort.
When should an application use managed containers?
Managed containers suit web services, workers and existing runtimes that benefit from portable packaging or need more execution control than a function provides. They are particularly useful when the team wants container consistency without owning Kubernetes control planes, node groups and a larger platform toolchain.
When is Kubernetes justified?
Kubernetes is most defensible when several teams or workloads already need its APIs, ecosystem, scheduling model, policy controls or a consistent platform across environments. It is rarely justified by the presence of one conventional web application alone because it creates additional release, security, observability and platform responsibilities.
Do microservices require Kubernetes?
No. Services can run on managed container platforms, serverless functions, managed application services or other compute models. Microservice boundaries and runtime orchestration are separate decisions. Choose service boundaries for independent ownership, release, scaling or failure isolation, then select the lightest runtime that supports them.
Can one application combine serverless and containers?
Yes. A web application might run as a managed container while scheduled jobs, file processing or asynchronous events use serverless functions and queues. A mixed architecture is useful when each part has a distinct demand or execution shape, provided monitoring, identity, data ownership and failure handling remain coherent.
Bring one application, not a target platform.
ORBN can profile the workload, compare viable AWS shapes and prove the weakest performance, recovery, security or cost assumption.