AWS Lambda Managed Instances: 90-minute async timeout and Graviton-based instance support

AWS just handed platform teams a new operational model: Lambda Managed Instances can now run asynchronous and event-source-mapping invocations for up to 90 minutes (previously 15 minutes), and those functions can execute on Graviton5-powered C9g/C9gd and M9g/M9gd families. This isn't a small tweak — it's a deliberate move to let serverless workloads behave more like long-running batch workers without forcing you to stitch functions together.

If you run pipeline steps that previously required splitting into multiple invocations — media transcodes, large ETL jobs, inference over many documents — you can now keep the work inside a single Lambda execution. That simplifies error handling (no choreography, fewer intermediate queues), reduces per-invocation overhead, and avoids fragile retry interactions between chained functions and ESM backoff windows. And with Arm/Graviton-based instance families available under Lambda Managed Instances, CPU- and memory-heavy jobs get better price/performance, particularly if your code is arm64-native or your container base images support arm64.

But this is not just a win. Longer-lived serverless executions change the mental model that many teams rely on.

Observability and retries: 90 minutes magnifies the consequences of opaque retries and partial failures. Long-running ESM handlers will need precise visibility into processing checkpoints and progress reporting so you don't get swallowed by duplicate work during retries or visibility-timeout collisions with SQS or Kinesis.
Resource planning and limits: Lambda concurrency, account-level quotas, and burst behaviors still apply. A 90-minute worker that consumes memory and CPU for long periods will change effective capacity calculations; your cost-per-completed-job math must include the new tail of long-lived invocations.
Attack surface and blast radius: Long-lived functions are effectively mini VMs. They keep ephemeral state longer, may mount larger container images, and run for far longer windows where credential-exchange logic or agent-based tooling could be exploited. Treat Managed Instances like managed compute you must harden: runtime patching, layered IAM, and secrets lifecycle.

The Graviton/Arm support is the other practical change. If you can move to arm64 containers and ensure native dependencies are compiled for Arm, expect a cost and throughput win. But this also resurrects the familiar compatibility checklist: native libraries, custom runtimes, and benchmarking under the new CPU architecture. Don't assume a 1:1 migration path for container images that were built around x86.

These Lambda news items sit alongside AWS's ongoing AI and platform moves. Amazon Bedrock continues to expand its model catalog and capabilities, and SageMaker keeps adding features to improve inference placement and multi-tenant routing. Together, these trends point toward higher-performing, longer-lived, and more stateful serverless and ML execution patterns across products.

I think the 90-minute timeout and Graviton-based support are the right call — the alternative was teams cobbling fragile choreographies or running ad-hoc EC2 fleets with livereloaded bootstrapping. But AWS shipped capability without simultaneously shipping a new set of guardrails that platform teams urgently need: fine-grained quotas per project, better default checkpointing libraries for ESM handlers, and clearer telemetry to surface long-tail invocation behavior. The getting-started controls AWS has added (spend caps and assisted setup) help control new-account spend, but they're not a substitute for operational controls inside production orgs.

If you're the person who owns platform resiliency: benchmark your workloads on Arm/Graviton images now, add checkpointing to any ESM consumer you plan to run for minutes rather than seconds, and treat long-lived Lambdas like a new class of compute to be secured and observed. This release will move more real workloads into Lambda Managed Instances — which is exactly what AWS intended. Whether your team benefits or gets burned will come down to how fast you update your operability playbook.

Related reading: we covered the timeout change in detail here: AWS Lambda 90-minute async timeout for managed instances (event-source mappings supported).

Prediction: within six months you'll see two kinds of teams emerge — those that use long-lived Lambdas to simplify pipelines and cut costs, and those that learn the hard way that serverless lifecycle assumptions don't scale past a few minutes. The capability is powerful; treating it as more of the same is a mistake.

AWS Lambda Managed Instances: 90-minute async timeout and Graviton-based instance support

Sources

AWS Lambda 90-minute async timeout for managed instances (event-source mappings supported)

Amazon Bedrock adds 'Astra' frontier model; Lambda Managed Instances get Arm Graviton support & 90‑minute async timeout

AWS Lambda SnapStart for container image functions; Amazon Bedrock adds document ACL debugging APIs