Skip to content
Notifications
Clear all

Beginner mistake I made: Forgetting about the 15-minute Lambda timeout limit.

3 Posts
3 Users
0 Reactions
4 Views
(@kubernetes_cowboy)
Estimable Member
Joined: 2 months ago
Posts: 69
Topic starter   [#2976]

Just deployed a data processing pipeline on Lambda, thinking it was perfect for those sporadic batch jobs. Wrapped it all up in a nice container image, pushed to ECR, and wired it to an S3 event. Everything looked great in dev with small files. 😅

Then it hit production. A larger file triggered the job... and it just vanished after 15 minutes. No error in CloudWatch, the invocation just stopped. Took me an hour to remember the hard timeout.

```yaml
# My serverless.yml snippet before
functions:
processFile:
timeout: 900 # 15 minutes - the MAXIMUM
memorySize: 10240
```

The fix was to break the work into chunks and use Step Functions, but that initial "where did my execution go?" moment was a real facepalm. Anyone else run into this when moving longer tasks from a k8s job to Lambda? What's your go-to pattern for jobs that might exceed the limit?


yaml all the things


   
Quote
(@emilyw)
Estimable Member
Joined: 1 week ago
Posts: 59
 

Oof, that's a rough one. The sudden vanishing act sounds so confusing.

I'm actually curious, how do you decide what the right chunk size is when you split the work for Step Functions? Is it just based on a time estimate, or do you have a way to measure progress within the file itself?

I'm still getting used to Lambda's limits after working with our old on-prem setup, so this is a good heads-up. 😅



   
ReplyQuote
(@jordanh)
Estimable Member
Joined: 1 week ago
Posts: 85
 

Ah, the classic "silent timeout" surprise. It's genuinely disorienting when an invocation just evaporates, isn't it? Like a magic trick where the rabbit never reappears.

While Step Functions are the standard answer, I always find it amusing that we're essentially re-inventing a poor man's scheduler or worker queue with state machines, all to navigate around Lambda's foundational constraint. Sometimes I wonder if we're just using Lambda for tasks it's philosophically opposed to handling.

Have you considered pushing back on the requirement instead? I often ask my team if a 15+ minute job truly *belongs* on Lambda, or if we're just chasing the "serverless" buzzword. For truly sporadic, long-running batch work, a container on Fargate or even a humble EC2 spot instance might be a simpler fit. Or is the attraction purely the S3 event trigger?


🤷


   
ReplyQuote