If AWS were to lift two of the most annoying ceilings in serverless — extending Lambda async timeouts to 90 minutes (up from the longstanding 15-minute cap) and increasing asynchronous payload limits from 256 KB to 1 MB for services that feed Lambda — it would change what "do it in Lambda" means.
Start with the timeout: 90 minutes. Previously the 15-minute hard cap pushed engineers toward two uncomfortable paths: move work into stateful container platforms (Fargate, ECS, EKS) or compose choreographies (Step Functions, chunked retries, external checkpoints). Both add operational surface area. Allowing much longer Lambda executions would be the right call for developer ergonomics in many cases: it avoids brittle hacks that jam credentials and state into ephemeral containers.
But there’s a caveat: this increases the surface area for opaque failures and runaway costs. Long-running Lambda executions still run on managed infrastructure with billing that accumulates by duration and provisioned resources. If your retry/backoff semantics, idempotency, or visibility aren't fixed, a 90-minute job that loops or retries aggressively will rack up billable time. Removing the hard timeout does not automatically make these executions observable or cheaper.
The payload increase to 1 MB is the other game-changer. Moving async payloads from 256 KB to 1 MB for services that invoke Lambda or sit in the event bus makes it realistic to pass moderately rich JSON events or small binary blobs directly. That will reduce S3-glue patterns for simple integrations and cut some choreography where teams write payloads to S3 and pass pointers. But the trade-offs are obvious: retries carry larger cost and latency hits, queues can fill faster, and dead-letter queues grow in storage cost.
Operational implications you should act on now
- Update your observability: trace spans and retention assumptions built for sub-15-minute traces will break. Correlate logs with longer-lived invocation ids and emit periodic heartbeats from inside functions so you can see progress without relying only on end-to-end traces.
- Rethink retry policies: exponential backoff windows tuned for short retries are the wrong default for much longer tasks. Add circuit breakers and higher-level job orchestration so retries don't duplicate work or compound costs.
- Audit idempotency and checkpoints: design idempotent commits or checkpoint frequently to durable storage. Larger payloads make it tempting to treat messages as immutable records — version them and validate them on ingest.
If event-source mappings supported much longer async invocations, Kinesis, DynamoDB Streams, and SQS consumers could complete heavier per-record work without splitting it into external workers. For many ETL-style workloads that's a win. For high-throughput, low-latency streaming use cases it's different: long-running consumers reduce parallelism and increase tail-latency risk.
A quick note on related AWS moves: this week also showed continued incremental improvements across AI and infra — Bedrock and SageMaker feature updates expanded model and orchestration options, and AWS kept releasing new Graviton-based instance families for EC2. Those changes are consistent with AWS pushing production-ready AI primitives and cost-performance improvements, but they don't remove the operational work of adapting systems to longer-running serverless workloads.
If you want a deeper walkthrough of how longer timeouts and larger payloads would change platform design, we covered similar trade-offs earlier with implementation notes and links: AWS Lambda Managed Instances: 90-minute async timeout and Graviton-based instance support. Also compare this shift to GCP's work on persistent serverless instances — the boundary between short-lived functions and longer-lived serverless workloads is being redrawn.
Final take: raising the timeout and payload limits would be overdue and sensible — but it's only half the story. Removing a hard technical blocker doesn't remove the engineering responsibility to handle longer execution, larger messages, and the costs that follow. Platform teams that treat this as a feature toggle will get burned. Teams that rework observability, retries, and idempotency could gain a simpler stack and fewer moving parts. Expect a wave of migrations from fragile choreographies into longer-running Lambdas — and then a corresponding wave of postmortems when visibility gaps reveal themselves. That's where the real engineering work starts.