AWS Lambda gagne 90 minutes d’exécution et les instances Graviton5 sur ses instances managées

9 septembre 2026. AWS touche à deux verrous historiques de Lambda en même temps : le timeout des fonctions passe de 15 à 90 minutes sur Lambda Managed Instances (LMI), et le service accueille les instances Graviton5 (C9g, C9gd, M9g, M9gd), annoncées jusqu’à 25 % plus performantes que la génération Graviton4. Pourquoi c’est important : c’est la fin du détour architectural que des milliers d’équipes faisaient pour contourner la limite des 15 minutes, et un pas de plus vers l’effacement de la frontière entre serverless et EC2.

Rappel : ce que sont les Lambda Managed Instances

Lambda Managed Instances, lancées à re:Invent 2025, permettent d’exécuter des fonctions Lambda sur du calcul EC2 tout en conservant l’expérience serverless : AWS gère le cycle de vie des instances, le patching de l’OS et des runtimes, le routage, le load balancing et l’auto-scaling. Le développeur écrit du code ; l’infrastructure reste abstraite.

Le modèle économique est explicite : le coût d’une LMI égale le prix EC2 à la demande, plus une marge de gestion de 15 % et 0,20 $ par million de requêtes — les frais de durée propres à Lambda disparaissent. Les Savings Plans et les Reserved Instances s’appliquent, ce qui n’existe pas sur Lambda classique. En clair, AWS a enfin chiffré ce que coûte « ne pas gérer de serveurs » : 15 % au-dessus de l’EC2.

Le positionnement est limpide : les charges prévisibles ou stables qui veulent garder la simplicité serverless sans payer la prime au millième de seconde de Lambda basculent sur LMI. Les charges sporadiques et sensibles à la latence restent sur Lambda classique.

Le timeout passe de 15 à 90 minutes

La limite des 15 minutes était le talon d’Achille de Lambda : dès qu’un traitement dépassait ce plafond — transcodage vidéo, simulations Monte-Carlo, inférence IA, calculs financiers — il fallait découper le travail en morceaux, orchestrer des invocations en chaîne ou sortir du serverless vers ECS, Batch ou une VM.

AWS lève le verrou, mais de façon ciblée. Le timeout de 90 minutes — six fois l’ancienne limite — ne s’applique qu’aux invocations asynchrones et aux event source mappings (ESM), sur LMI. Les invocations synchrones conservent leur plafond de 15 minutes. La nuance compte : un appel synchrone est bloqué sur une réponse HTTP, un appel asynchrone peut attendre en file. C’est exactement le bon découpage.

Le changement s’étend aux Lambda durable functions, ces exécutions qui peuvent checkpointer et rejouer des étapes : une exécution durable multi-étapes déclenchée en asynchrone peut désormais courir jusqu’à 1 an. C’est la fin du bricolage de la machine à états artisanale pour les workflows longs.

Graviton5 : l’argument économique de l’Arm

La seconde annonce du 9 septembre branche LMI sur les instances Graviton5. Les types C9g, C9gd, M9g et M9gd deviennent sélectionnables, avec un gain annoncé jusqu’à 25 % de performances calcul par rapport à Graviton4. Le paramétrage se fait au niveau du capacity provider : on fixe un type d’instance, ou on laisse Lambda choisir automatiquement dans sa liste selon l’architecture, la mémoire et le ratio mémoire/vCPU de la fonction.

L’enjeu n’est pas la vitesse brute mais le coût par unité de calcul. Graviton est historiquement le levier de réduction de coûts d’AWS sur EC2 ; l’intégrer à LMI revient à offrir le tarif Arm sans quitter le confort serverless. Pour une charge longue et prévisible — un pipeline de transcodage nocturne, un batch de simulation — la combinaison 90 minutes + Graviton5 + Savings Plans fait mécaniquement baisser la facture par rapport à un Lambda classique plafonné à 15 minutes, ou à un EC2 géré à la main.

Ce qui change pour les équipes

Concrètement, la décision d’architecture se simplifie. Une charge asynchrone longue n’a plus besoin d’être ré-architecturée : elle tient dans une seule fonction. Une charge synchrone à faible latence reste sur Lambda classique. Une charge stable et prévisible bascule sur LMI pour profiter des tarifs EC2 et du calcul Graviton5.

Le revers de la médaille est la complexité du modèle mental. AWS empile désormais plusieurs plans d’exécution — Lambda classique, Lambda sur LMI en asynchrone, LMI avec capacity provider — et le bon choix dépend du caractère synchrone ou asynchrone, de la durée, de la prévisibilité et de l’architecture processeur. Ce n’est plus « serverless ou pas », c’est un menu à quatre dimensions. La courbe d’apprentissage est réelle, mais elle remplace des contournements bien plus coûteux.

Comment configurer le tout

La bascule est volontairement simple, et c’est le point. Le timeout se règle comme n’importe quelle fonction Lambda, en secondes — 5 400 pour les 90 minutes :

aws lambda update-function-configuration \
  --function-name transcode-long-metrage \
  --timeout 5400

La nuance est que ce plafond ne s’applique que si la fonction tourne sur Lambda Managed Instances et qu’elle est invoquée en asynchrone ou via un event source mapping. Une invocation synchrone de la même fonction retombe sur les 15 minutes classiques. Autrement dit, AWS n’a pas assoupli Lambda dans son ensemble : il a créé un deuxième plan d’exécution, plus long et moins cher, à côté du premier.

Côté Graviton5, le choix se fait au niveau du capacity provider : on fixe explicitement un type C9g ou M9g, ou on laisse Lambda sélectionner automatiquement dans sa liste en fonction de l’architecture (arm64), de la mémoire et du ratio mémoire/vCPU. Le passage de x86 à Arm n’est pas toujours transparent : si la fonction embarque des dépendances natives, il faut fournir une image ou un layer arm64. C’est le seul point de friction réel, et il vaut une phase de test avant de basculer un pipeline de production.

Le résultat net est un arbitrage plus fin qu’avant. Là où Lambda classique taxait la durée au millième de seconde, LMI facture l’instance ; là où ECS exigeait de gérer le cluster, LMI garde l’abstraction serverless. Chaque équipe peut désormais choisir son point sur une courbe coût/simplicité qui n’existait pas il y a un an. Enfin, n’oubliez pas la marge de gestion de 15 % : c’est le prix de l’abstraction. Pour une charge vraiment stable et prévisible, un EC2 géré à la main restera toujours moins cher ; LMI achète la simplicité opérationnelle, pas le tarif le plus bas. Et pour les équipes déjà bien installées sur ECS ou Batch, rien n’oblige à migrer : LMI est une option de plus, pas un remplacement.

Verdict

Si vous avez des charges asynchrones longues — transcodage, simulations, inférence par lots — que vous découpiez en tranches de 15 minutes, migrez-les sur LMI avec le nouveau timeout : vous supprimez une classe entière de code d’orchestration. Si vous avez une charge stable et prévisible que vous hésitiez à sortir de Lambda pour des raisons de coût, testez LMI avec Graviton5 et un Savings Plan : c’est le scénario où la facture baisse le plus. Si votre trafic est sporadique et sensible à la latence, restez sur Lambda classique — les 15 minutes synchrones et le scale-to-zero y gardent tout leur sens.

Références

• AWS — « AWS Lambda now supports 90-minute function timeout on Lambda Managed Instances » (9 septembre 2026)
• AWS — « AWS Lambda now supports Graviton5-powered EC2 instances on Lambda Managed Instances » (9 septembre 2026)
• AWS — « Introducing AWS Lambda Managed Instances » (blog officiel)
• AWS — « Announcing AWS Lambda Managed Instances » (re:Invent 2025)