Serverless Is a Tool, Not a Strategy
Lambda, API Gateway, Step Functions, DynamoDB — the serverless ecosystem is powerful. But we've seen teams force serverless into situations where it makes things harder, not easier. The key is knowing when it fits.
When Serverless Shines
Event-driven workloads
Processing S3 uploads, responding to SQS messages, handling webhook callbacks — these are ideal for Lambda. The work arrives intermittently, and you pay only when it runs.
APIs with variable traffic
If your API goes from 10 requests/hour at night to 10,000/hour during peak, serverless auto-scales without any capacity planning.
Scheduled tasks
Cron jobs that run for seconds or minutes. Why pay for an EC2 instance 24/7 to run a 30-second task once a day?
Prototyping and MVPs
Get something running quickly without provisioning infrastructure. Perfect for validating ideas before investing in production architecture.
When Serverless Doesn't Fit
Long-running processes
Lambda has a 15-minute timeout. If your job takes longer, you need to break it up or use a different compute option.
Consistent high-throughput workloads
If you're running at high utilization 24/7, provisioned compute (EC2 or ECS) is usually cheaper than Lambda at scale.
Complex local state
Applications that need to maintain state between requests, manage connections pools, or keep data in memory don't map well to Lambda's stateless model.
Latency-sensitive applications
Cold starts add latency. For applications where every millisecond matters, provisioned compute gives you more control.
The Hybrid Approach
Most well-architected applications use a mix. We commonly see:
- Lambda for API endpoints and event processing
- ECS or EC2 for background workers and batch jobs
- Step Functions for orchestrating multi-step workflows
- DynamoDB for low-latency data access, RDS for complex queries
The right architecture uses each service where it excels. Don't let "serverless-first" become "serverless-only."