AWS ha esteso a 90 minuti il timeout delle funzioni eseguite su Lambda Managed Instances. La novità, annunciata il 9 settembre 2026, porta il limite massimo da 900 a 5.400 secondi e permette di eseguire elaborazioni più lunghe senza spezzarle artificialmente in molti passaggi.
Il cambiamento non riguarda però tutte le funzioni Lambda: vale per le invocazioni asincrone e per quelle attivate tramite event source mapping su Lambda Managed Instances. Le chiamate sincrone e la modalità Lambda on-demand standard mantengono il limite di 15 minuti. Questa distinzione è essenziale prima di modificare un’architettura.
Cosa cambia con il timeout AWS Lambda di 90 minuti
Lambda Managed Instances combina il modello operativo di Lambda con capacità EC2 gestita. Le funzioni possono elaborare più richieste contemporaneamente sulla stessa istanza, utilizzare configurazioni di calcolo specializzate e beneficiare del modello di costo EC2, senza dover amministrare direttamente server e sistema operativo.
Con il nuovo limite, una funzione asincrona o collegata a una sorgente eventi può rimanere in esecuzione continua fino a 90 minuti. Runtime, handler, ruolo IAM e configurazione VPC restano invariati. AWS specifica inoltre che non è previsto un sovrapprezzo dedicato al timeout esteso: si applicano i normali costi di Lambda Managed Instances.
Il valore si configura come qualsiasi altro timeout Lambda, impostando fino a 5400 secondi tramite console, AWS CLI, CloudFormation o AWS SAM. La modifica si applica alle invocazioni successive; per gli event source mapping può essere necessario attendere alcuni minuti perché la configurazione si propaghi.
I limiti che restano a 15 minuti
Invocazioni sincrone
Una funzione chiamata in modo sincrono continua ad avere un massimo di 15 minuti, anche se nella configurazione è stato impostato un timeout superiore. È il caso da verificare per API, richieste HTTP e processi nei quali il chiamante attende direttamente la risposta.
Fase di inizializzazione
Su Lambda Managed Instances la fase Init resta limitata a 15 minuti. Il nuovo timeout non giustifica quindi inizializzazioni eccessivamente pesanti: caricamento di modelli, dipendenze, configurazioni e connessioni deve comunque essere progettato con attenzione.
Alcune sorgenti evento
Gli event source mapping per Amazon MQ e Amazon DocumentDB con compatibilità MongoDB restano limitati a 15 minuti. Prima di impostare 5.400 secondi bisogna controllare la sorgente specifica e non dedurre il supporto dal solo valore mostrato nella configurazione della funzione.
Quali workload possono beneficiare davvero dei 90 minuti
ETL e trasformazione di dati
Importazioni da fornitori, aggregazioni di dataset e trasformazioni che superano occasionalmente i 15 minuti possono rimanere in una singola funzione. Questo può ridurre orchestrazione, passaggi intermedi e gestione dello stato, soprattutto per processi idempotenti attivati da SQS.
Elaborazione multimediale
Transcodifica video, conversione di documenti e trascrizioni speech-to-text possono richiedere più tempo quando i file sono grandi. Il timeout esteso evita di suddividere forzatamente il lavoro, ma è necessario considerare dimensione dei file temporanei, throughput di rete e possibilità di riprendere un job interrotto.
Inferenza AI e calcoli scientifici
AWS cita test di modelli, inferenza con ragionamento, simulazioni Monte Carlo e calcoli finanziari. Il fatto che un’elaborazione possa durare 90 minuti non significa però che Lambda sia sempre la piattaforma più economica: memoria, CPU, acceleratori richiesti, frequenza dei job e utilizzo stabile devono essere confrontati con container, AWS Batch o istanze dedicate.
Trasferimenti e integrazioni lente
Un processo che scarica grandi set di file da servizi esterni o attende API lente può ora completarsi senza raggiungere il limite dei 15 minuti. In questi casi il rischio si sposta sulle connessioni: timeout intermedi, credenziali temporanee, DNS e limiti del fornitore esterno possono interrompere il lavoro molto prima dei 90 minuti.
Timeout più lungo non significa maggiore affidabilità
Una funzione che rimane attiva più a lungo amplia la finestra nella quale possono verificarsi errori di rete, scadenza dei token, riavvii o consegne duplicate. Lambda non garantisce l’elaborazione exactly once: le operazioni devono essere idempotenti, in particolare quando aggiornano ordini, pagamenti, database o sistemi esterni.
Per SQS, AWS raccomanda di impostare il visibility timeout della coda ad almeno sei volte il timeout della funzione. Con una funzione configurata per 90 minuti, questo parametro diventa quindi particolarmente rilevante. Se visibility timeout e durata non sono coerenti, lo stesso messaggio può tornare disponibile mentre l’elaborazione precedente è ancora in corso.
Per batch contenenti più record è opportuno attivare la segnalazione dei fallimenti parziali, quando supportata. In questo modo vengono ritentati soltanto i record falliti e non l’intero batch già elaborato.
Quando aggiungere Lambda Durable Functions
Il timeout della singola funzione e la durata dell’esecuzione durevole sono concetti diversi. AWS Lambda Durable Functions utilizza checkpoint per registrare lo stato e riprendere il processo, saltando i passaggi già completati durante il replay.
Un’esecuzione durevole asincrona può estendersi complessivamente fino a un anno, mentre ogni invocazione continua su Managed Instances può ora durare fino a 90 minuti. Per un job idempotente e relativamente economico da ripetere, il solo timeout esteso può bastare. Per un’elaborazione da 60 minuti che sarebbe costoso ricominciare da zero dopo un errore al minuto 55, i checkpoint possono essere più importanti del tempo massimo.
Lambda Managed Instances, container o AWS Batch?
Lambda Managed Instances è interessante quando il workload è guidato da eventi, la durata varia, si vuole conservare il modello Lambda e il team preferisce evitare la gestione diretta dell’infrastruttura.
Container su ECS o EKS possono essere più adatti quando servono controllo sul processo, dipendenze particolari, servizi persistenti, porte in ascolto o durate non legate a una singola invocazione.
AWS Batch resta una scelta naturale per code di calcolo, pianificazione di job, elaborazioni HPC, dipendenze tra attività e selezione dinamica delle risorse. Il limite di 90 minuti riduce una barriera, ma non trasforma Lambda in un sostituto universale di container e batch.
Checklist prima di portare una funzione a 90 minuti
- Confermare che la funzione utilizzi Lambda Managed Instances, non la modalità on-demand standard.
- Verificare che l’invocazione sia asincrona o basata su un event source mapping supportato.
- Controllare che nessun client o proxy attenda una risposta sincrona oltre 15 minuti.
- Impostare timeout coerenti su database, API, load balancer, NAT e connessioni persistenti.
- Verificare la durata di credenziali, token OAuth e URL firmati utilizzati durante il job.
- Rendere idempotenti scritture e chiamate esterne per gestire retry e consegne duplicate.
- Per SQS, riallineare visibility timeout, retry policy e dead-letter queue.
- Abilitare i fallimenti parziali dei batch dove disponibili.
- Valutare checkpoint con Durable Functions se ripetere il lavoro è costoso.
- Aggiornare allarmi CloudWatch, dashboard, log retention e soglie operative.
- Confrontare costo e prestazioni con ECS, EKS, AWS Batch o Step Functions.
- Eseguire prove di interruzione per verificare recupero, replay e pulizia delle risorse.
Osservabilità e rete: cosa cambia operativamente
CloudWatch, CloudTrail e AWS X-Ray continuano a registrare l’intero ciclo dell’invocazione. Le soglie esistenti devono però essere riviste: un allarme progettato per segnalare una funzione oltre dieci minuti potrebbe diventare rumore dopo il cambio.
AWS richiama anche il timeout inattivo di 350 secondi del NAT Gateway. Le applicazioni che mantengono connessioni inutilizzate devono prevedere keep-alive o riconnessione. I client HTTP personalizzati devono rispettare i TTL DNS e non conservare indefinitamente indirizzi diventati obsoleti.
Lo stesso approccio prudente vale per database e storage. L’approfondimento EP Consulting sull’upgrade di Amazon RDS per MariaDB mostra perché driver, TLS e test reali contano quanto la disponibilità nominale di una funzione. Per i dati che devono restare immutabili, è disponibile anche la guida sulla retention variabile di Amazon S3 Object Lock.
FAQ su AWS Lambda e timeout di 90 minuti
Tutte le funzioni AWS Lambda possono durare 90 minuti?
No. Il limite esteso riguarda le funzioni su Lambda Managed Instances invocate in modo asincrono o tramite event source mapping supportato. Le invocazioni sincrone e Lambda on-demand restano a 15 minuti.
Serve modificare il codice?
AWS indica che il timeout può essere aumentato senza modificare runtime, handler, ruolo IAM o VPC. Il codice deve comunque essere verificato per idempotenza, durata delle credenziali, connessioni e gestione degli errori.
Ci sono costi aggiuntivi specifici?
AWS non applica un supplemento dedicato al timeout da 90 minuti. Rimangono i normali costi di Lambda Managed Instances e delle risorse collegate.
Una Durable Function può durare un anno?
L’esecuzione durevole asincrona complessiva può arrivare fino a un anno, ma le singole invocazioni continue su Managed Instances sono limitate a 90 minuti. I checkpoint permettono di riprendere i passaggi senza rifare tutto il lavoro.
Conviene migrare subito dai container?
Non automaticamente. Occorre confrontare frequenza, durata, risorse, dipendenze, necessità di controllo e costi. Il vantaggio principale è mantenere il modello event-driven di Lambda per workload prima esclusi dal limite dei 15 minuti.
Fonti ufficiali
- AWS Compute Blog, “Announcing 90-minute function timeout on AWS Lambda Managed Instances”, 9 settembre 2026.
- AWS Lambda Developer Guide, Lambda Managed Instances.
Le caratteristiche descritte riflettono la documentazione AWS disponibile il 10 settembre 2026. Regioni, sorgenti evento supportate e condizioni economiche vanno verificate prima della distribuzione.