Skip to content

SERVERLESS VS. EKS: WHEN I CHOOSE WHICH

4 MIN READ
awsserverlesskubernetesarchitecture

Serverless vs. EKS: When I Choose Which

I’ve built both: a fully serverless platform for a fintech client (Lambda, API Gateway, DynamoDB, Step Functions) and production EKS clusters running 15+ microservices with real-time MQTT communication. Neither is universally better. The right choice depends on factors that most comparison articles ignore.

The Decision Factors

Team Size and Operational Maturity

Serverless removes the infrastructure management burden. A team of 3 backend engineers can run a production serverless platform without a dedicated DevOps person. They deploy functions, AWS handles patching, scaling, and availability.

EKS requires Kubernetes knowledge. Someone needs to understand node pools, pod scheduling, networking policies, ingress controllers, and the upgrade cycle. If the team doesn’t have that skill, the learning curve becomes a project risk.

Workload Patterns

Variable, spiky traffic favors serverless. A fintech platform that processes 50 requests per minute at 3 AM and 5,000 per minute at market open is a textbook Lambda use case. You pay for exactly what you use.

Steady-state workloads favor EKS. The e-mobility platform I worked on had 15+ Spring Boot services running 24/7, handling continuous MQTT streams from thousands of EV chargers. Those services need to be warm and ready. Cold starts are not acceptable when a charger needs to authorize a charging session in under 500ms.

Protocol Requirements

This is the factor people miss. Lambda sits behind API Gateway or ALB — it speaks HTTP. If your workload needs persistent connections (WebSocket, MQTT, gRPC streaming), you need something that can hold a socket open.

The e-mobility platform used EMQX as an MQTT broker running on EKS. There’s no serverless equivalent for that. You could use AWS IoT Core for MQTT, but once you need custom broker logic, you’re running your own.

When Serverless Wins

  • Event-driven processing — S3 uploads triggering image processing, DynamoDB Streams feeding downstream consumers, scheduled ETL jobs
  • Variable traffic APIs — Pay-per-request beats reserved capacity when traffic is unpredictable
  • Small teams — No infrastructure to manage means fewer operational responsibilities
  • Rapid prototyping — Shipping an API endpoint takes minutes, not a cluster provisioning cycle

The fintech platform ran entirely on Lambda with API Gateway, DynamoDB for storage, and Step Functions for multi-step workflows. The team was small, the traffic was bursty, and they didn’t need to manage a single server. It worked.

When EKS Wins

  • Many microservices — Once you’re past 8-10 services, the coordination overhead of managing individual Lambda deployments exceeds the cost of running a cluster
  • Long-running processes — Lambda’s 15-minute timeout is a hard wall. Background workers, data pipelines, and persistent connections need something else
  • Real-time protocols — MQTT, WebSocket servers, gRPC with streaming — anything that needs persistent connections
  • Existing container investment — If the team already has Dockerized services with health checks, metrics endpoints, and structured logging, moving to Lambda means rewriting that integration layer

The Hybrid Pattern

Some things are always serverless regardless of where the core workload runs. Even on the EKS-based e-mobility platform:

  • S3 event notifications trigger Lambda functions for file processing
  • EventBridge scheduled rules run cleanup and reporting jobs
  • CloudWatch Alarms invoke SNS and Lambda for incident response
  • Step Functions orchestrate one-off migration and batch workflows

The core business logic runs on EKS. The glue runs on Lambda. Trying to force either one to do both is where architectures get painful.

Cost Reality

Serverless is cheaper at low to moderate scale with variable traffic. Once you hit sustained high throughput, Lambda’s per-invocation pricing adds up fast. A service handling 100 million requests per month will almost certainly be cheaper on a few well-sized EKS pods than on Lambda.

But cost isn’t just compute. Factor in the engineering time to manage Kubernetes, the on-call burden for cluster operations, and the risk of misconfigured autoscaling. For a small team, “more expensive per request but zero ops” can be the cheaper option overall.

My Default

I start with serverless until I hit a constraint that forces me off it. That constraint is usually one of: persistent connections, too many services to manage independently, or sustained throughput where Lambda costs exceed container costs.

When that happens, I move to EKS — but I keep the event-driven glue on Lambda. Every architecture I’ve built in the last two years has been a hybrid to some degree.