Serverless with AWS Lambda — Where It Makes Sense and Where It Doesn't

Serverless promises zero infrastructure management, automatic scaling, and pay-only-for-actual-compute pricing. After a year of running Lambda functions in production, we share what works and what doesn’t.

Where Lambda Excels¶

• Event processing — S3 upload triggers, SQS processing, DynamoDB streams
• API backends — simple CRUD APIs with API Gateway
• Scheduled tasks — CloudWatch Events cron jobs
• Spike workloads — automatic scaling from 0 to thousands of instances

Cold Start — The Elephant in the Room¶

Lambda functions in Java/JVM: cold start of 3-10 seconds. Node.js: 100-500ms. Python: 200-800ms. For synchronous APIs, cold start is a problem. We solve it with provisioned concurrency (expensive) or runtime optimization.

Where Lambda Doesn’t Work¶

Long-running processes — 15 min timeout. Stateful applications — no local state. Constant load — EC2/ECS is cheaper. Complex orchestration — Step Functions help, but complexity grows.

Vendor Lock-in¶

Lambda functions depend on S3, DynamoDB, SQS, API Gateway… Migration to another cloud would mean rewriting most of the code. The upside is that the investment in the AWS ecosystem usually pays off.

Serverless Is a Tool, Not an Architecture¶

Lambda is excellent for event-driven workloads and spike patterns. But it’s not a silver bullet — for constant load and complex applications, we stay with Kubernetes.