AWS Daily Intelligence #29 - The 15-minute limit is gone, in one mode, on one compute type

Executive summary

On 9 September AWS raised the Lambda function timeout to 90 minutes, a 6x increase on the 15-minute limit that has been one of the best-known constraints in the service. The qualifications matter more than the number.

It applies to asynchronous and event source mapping invocations on Lambda Managed Instances. Synchronous invocations keep the 15-minute maximum. And Lambda Managed Instances is not a setting on your existing functions — it is a different compute type, with EC2 instances underneath, a different scaling model, and a billing model in which execution duration is no longer a line item.

That last point is the interesting one, because it explains the first. On the default compute type you are billed per GB-second of duration, so a 90-minute invocation is a 90-minute bill for one request. On Managed Instances you are billed for the instances, one environment serves many invocations at once, and duration is not charged per request at all. The limit could move because the meter changed.

What changed

One number moved, on a specific path. Everything else about the default Lambda compute type is unaffected.

The invocation modes that got the increase are the ones already designed for it. Asynchronous and ESM invocations have a queue in front of them and a retry story behind them; nobody is holding a connection open waiting. A 90-minute synchronous call would need a client prepared to wait 90 minutes, which is not a thing worth building.

Architecture

Four properties of Managed Instances decide whether a long-running function belongs there, and none of them is the timeout.

One environment, many invocations. Each execution environment handles multiple invocations simultaneously, where traditional Lambda processes one request per environment. This is what makes instance-based billing economical, and it is a real change for your code: AWS states the model requires attention to thread safety, state management, and context isolation depending on your runtime. A handler that has been quietly relying on having its environment to itself is now sharing it.

The capacity provider is a security boundary. A capacity provider defines the VPC configuration, instance requirements and scaling policies — and AWS is explicit that it is also the trust boundary: all functions assigned to the same capacity provider must be mutually trusted. That is a sentence with organisational consequences. Functions from different teams, or different data classifications, are not automatically safe to co-locate. The lambda:PassCapacityProvider permission exists as the gate over who can place what where.

Scaling is not on-demand. Managed Instances scale asynchronously on CPU utilisation rather than when invocations arrive. The upside is that cold starts are eliminated. The cost is that a spike outruns the scaler: AWS warns that if traffic more than doubles within 5 minutes, you may be throttled while capacity catches up.

You are paying for capacity, not work. EC2 instance pricing, a 15% management fee on the on-demand price, $0.20 per million requests, and no separate duration charge. Compute Savings Plans and Reserved Instances apply, which is unusual for anything with Lambda in the name.

Business value

The value is a category of job that had to leave Lambda and can now stay. AWS names them: data-intensive work such as AI inference, media transcoding, scientific modeling and financial calculations that did not fit inside 15 minutes. Every one of those previously became a Step Functions state machine with artificial chunking, an ECS task, or a Batch job — each a different operational surface for what is conceptually one function.

The second value is quieter: for steady-state workloads, the EC2 pricing model with Savings Plans applied can beat per-GB-second billing outright. Duration-priced compute is excellent for spiky, short work and poor for sustained load, which is the shape most long-running jobs have.

Security considerations

The mutual-trust requirement on capacity providers is the item to take to a design review. On the default compute type, isolation between functions is a property you inherit for free and never think about. Here, co-location is a choice you make when you assign a function to a capacity provider, and the boundary is the provider rather than the function.

Treat lambda:PassCapacityProvider the way you would treat iam:PassRole — as the permission that decides what runs next to what. A capacity provider per trust domain is the conservative default, and the cost of getting it wrong is not a bill, it is a boundary.

Multi-concurrency deserves the same attention for a different reason. Code written for one invocation per environment may hold request state in module scope safely today and unsafely on Managed Instances. That is a correctness problem before it is a security one, but it becomes a security one the moment the state is a credential or a customer identifier.

Cost considerations

The billing inversion cuts both ways. Removing the per-request duration charge is what makes a 90-minute invocation viable; it also means an underused capacity provider bills for instances that are doing nothing. Default Lambda charges nothing when idle. Managed Instances charges EC2 rates plus 15%.

So the economics favour sustained utilisation and punish burstiness — the opposite of the default compute type. A workload that runs 90-minute jobs continuously is a good fit. One that runs three of them a week is paying for a week of instances to do four and a half hours of work, and would have been cheaper chunked on the default type.

Operational considerations

A 90-minute timeout is a 90-minute blast radius. AWS's own guidance in the launch post is worth following: for jobs where re-execution is costly, combine the extended timeout with durable functions for checkpointing. A function that fails at minute 88 and restarts from zero has converted a long timeout into a long outage.

The scaling warning is the other thing to rehearse before production. "More than doubles within 5 minutes" is not an exotic traffic pattern — it describes a batch window opening, a queue draining after an incident, or a scheduled job fanning out. If that is your shape, test it, because the failure is a throttle rather than a slow start.

Tradeoffs

Implementation guidance

Start from the invocation path rather than the timeout. If the work is triggered synchronously, nothing here applies and the 15-minute limit still governs. If it is asynchronous or driven by an event source mapping, it is a candidate.

Then audit the handler for shared-environment safety before moving it. Module-level caches, global clients holding per-request context, temporary files written to fixed paths — all are safe under one-invocation-per-environment and all are suspect under multi-concurrency.

Create a capacity provider per trust domain rather than one for the account, gate assignment with lambda:PassCapacityProvider, and load-test a doubling of traffic inside five minutes before you rely on it.

Best practices

• Checkpoint long jobs. A 90-minute function without durable state turns a late failure into a full re-run.
• One capacity provider per trust domain. Co-location is a decision now, and AWS requires mutual trust within a provider.
• Review handlers for thread safety before migrating. The environment is shared in a way it never was.
• Apply Compute Savings Plans or Reserved Instances. The instances are ordinary EC2 and the discounts are real.
• Model the idle cost. Scale-to-zero is the thing you are giving up, and for occasional jobs it was the whole value.

Who should adopt this

Teams who have already built a chunking workaround for a job that is conceptually one unit of work, and teams running sustained inference or media processing where cold starts and duration billing were both hurting. For those, this collapses an orchestration layer back into a function.

Everyone else should note it and leave it alone. If your functions finish in seconds, scale to zero between bursts, and cost you very little, Managed Instances asks you to pay for capacity and manage a trust boundary in exchange for a limit you were not hitting.

Key takeaways

• 90 minutes applies to asynchronous and ESM invocations on Lambda Managed Instances only. Synchronous stays at 15 minutes everywhere.
• The limit moved because the meter did: Managed Instances bills EC2 instances plus 15%, and does not charge separately for execution duration.
• One environment now serves many invocations, which requires thread safety, state management and context isolation the default type never demanded.
• A capacity provider is a security boundary — all functions on one must be mutually trusted, gated by lambda:PassCapacityProvider.
• Scaling is CPU-based and asynchronous: no cold starts, but traffic more than doubling within 5 minutes may be throttled.

Official AWS references

• AWS Lambda now supports 90-minute function timeout on Lambda Managed Instances — 9 September 2026
• Announcing 90-minute function timeout on AWS Lambda Managed Instances
• Lambda Managed Instances core concepts — capacity providers, scaling and multi-concurrency
• AWS Lambda pricing — the Managed Instances components