Only the start-of-month aggregation fails, every time. The logs show it was cut off mid-run, and rerunning it duplicates the data that had already been written partway through. Jobs that hit the 15-minute execution limit are sometimes discovered this way.
On September 9, 2026, AWS announced a 90-minute timeout on Lambda Managed Instances, six times the previous 15 minutes. However, the limit is not extended for every kind of invocation. If you misunderstand this, design meetings will end up talking past each other.
Which invocations get the longer limit, and which do not
According to AWS's announcement and documentation, it applies to asynchronous invocations and invocations through event source mappings (ESM) on Lambda Managed Instances (LMI). However, event source mappings for Amazon MQ and Amazon DocumentDB remain at 15 minutes. The limit for synchronous invocations also stays at 15 minutes: even if a function's timeout is set longer than 15 minutes, a synchronous invocation is cut off at 15 minutes. All Regions where LMI is available are covered.
Work that keeps the caller waiting behind an API is still cut off at 15 minutes, as before. In other words, "Lambda now allows 90 minutes" is not enough to tell whether the job that is causing you trouble will be saved. First, check how the failing job is invoked.
| Type of processing | Limit | Where to run it |
|---|---|---|
| Synchronous work that holds up an API response | Still 15 minutes | Return only an acknowledgment and move the main work to asynchronous processing |
| Asynchronous work triggered by queues or events | Up to 90 minutes, with conditions (except when triggered by Amazon MQ or DocumentDB) | Consider running on LMI |
| Bulk processing that takes several hours | Even 90 minutes is not enough | Move to a batch platform or run in containers |
Longer runs mean more homework
Longer execution times bring into play assumptions you did not need to think about with short-lived functions. AWS's explanatory blog post also lists points to watch: check that temporary credentials and tokens remain valid for the full execution time or refresh them along the way, and make sure that running the same work twice because of retries or duplicate deliveries does not change the result (idempotency).
Specifically, decide the following four points at design time.
- Connection lifetime. How to reconnect, and where to resume, when a connection to a database or external API drops during the 90 minutes
- Credential expiry. Assume credentials will expire partway through, and have a way to obtain them again
- Idempotency. A design in which a redelivered event does not cause duplicate records or double charges
- Unit of resumption. Decide whether to redo everything or resume partway, based on the cost of a failure
Items 3 and 4 are where long-running batch jobs are prone to incidents. If you extend only the execution time while keeping an "if it fails, just run it again" approach, the damage from a failure also expands to six times as much time.
LMI differs in one more assumption. According to the documentation, when an invocation times out, the function's code is not forcibly terminated and keeps running in the execution environment. Because the caller receives a failure, a retry can overlap with it and the same write can happen twice. It is essential to check the remaining time and build the job so that it can stop at each break between units of work.
Monitoring changes too. When jobs were expected to finish within 15 minutes, timeouts and abnormal exits were enough to detect failures. For a job that runs for 90 minutes, you need to be able to tell from the outside whether it is stuck or making progress. Emit progress, such as the number of items processed, as logs or metrics, and make sure you will notice when a job runs past its expected time before you move it.
Do not overlook the change in how billing works
LMI runs Lambda functions on managed EC2 instances. According to the pricing page, you pay for the EC2 instances provisioned plus a management fee and request charges, and there is no charge for execution time per request. Costs therefore behave differently from standard Lambda, where billing centers on execution time. It is closer to reality to think of it this way: the higher the utilization, the better it pays off, and for jobs that run only occasionally it may not be worth it.
Actual amounts vary by Region and instance type, so this article does not give figures. If you are considering a move, check the current terms on the official pricing page and compare them side by side with measured values from your current setup. We recommend not treating a vendor's case-study figures as your own savings.
Before moving a job, find out why it fails
Even for jobs that hit 15 minutes, it is not unusual for the time to go into repeated fetching or pointless loops. Before changing where a job runs, get a breakdown of its processing time. We cover what to consider when deciding on a serverless migration itself in migrating with Lambda Web Adapter, and how to handle stateful processing in microVMs and stateful processing.
Once the number of jobs grows, managing their order and reruns becomes a bigger issue than where they run. We covered the decision that comes before that in whether to run your own workflow platform.
We checked AWS's announcement, its blog post, the documentation and the pricing page through web searches on September 24, 2026, and organized this research article based on them. We have not run 90-minute executions on LMI or measured costs. Limits, eligibility and pricing may change, so check the official documentation before deciding on your architecture.
For deciding where to run long batch jobs or reviewing designs so that they can withstand reruns, please consult GleamHub.
