1
Cloud
Serverless vs containers for a bursty B2B webhook processor
Cost efficiency ↔ Control
Context
Process webhooks: idle most of the day, 2K/sec bursts at month-end.
Our webhook receiver is idle 25 days a month, then gets hammered during month-end billing runs. We currently run 6 always-on containers "just in case".
Lambda looks perfect on paper. Worries: cold starts, DB connection storms against Postgres, and debugging.
Constraints
- Traffic
- Spiky, 0 → 2K/s
AWS LambdavsContainers (ECS)
Community verdict
AWS Lambda 60%Containers (ECS) 40%
10 engineers · 3 opinions
With these constraints, what would you choose?
One choice per engineer. You can change it any time.
AWS Lambda
Containers (ECS)
Control →
Trade-offs
Dimensions
AWS LambdaContainers (ECS)out of 5
- Cost when idle
- 5AWS Lambda scores 5 of 52Containers (ECS) scores 2 of 5
- Control
- 2AWS Lambda scores 2 of 55Containers (ECS) scores 5 of 5
- Burst scaling
- 5AWS Lambda scores 5 of 5
Community discussion
3 comments
Have you made this decision in production? Share your reasoning.
Sign in to commentPut SQS between the webhook endpoint and the processor. Lambda with reserved concurrency drains the queue at a rate Postgres can handle, and RDS Proxy fixes the connection storms.
Bursty webhook traffic is the textbook Lambda case. Put SQS in front so a partner's retry storm becomes a queue, not a scaling event, and set reserved concurrency so you never overwhelm the database.
ECS with target-tracking autoscaling on queue depth gets you 80% of the savings and keeps your existing container tooling. Scale to 1 task when idle.