Instances gérées Lambda : les journaux indispensables
Les fournisseurs de capacité LMI enregistrent les journaux du cycle de vie dans CloudWatch. JSON structuré activé par défaut - l'angle mort entre fonction et flotte se réduit.
Les instances gérées Lambda obtiennent des logs de Capacity Provider dans CloudWatch – au format JSON structuré, activés par défaut. Ceux qui exploitent Serverless sur EC2 peuvent enfin consulter les lancements, les terminaisons et les vérifications de santé, sans avoir à construire leur propre projet d’observabilité.
En bref
- Journaux activés par défaut. Le Capacity Provider enregistre les événements du cycle de vie sous forme de journaux JSON structurés dans CloudWatch.
- Visibilité sur la couche EC2. Les lancements, les terminaisons et les vérifications d’intégrité deviennent filtrables – ce qui permet de localiser plus rapidement les erreurs de provisionnement.
- Pour des charges prévisibles. LMI cible des charges de travail élevées et prévisibles grâce à des profils de calcul spécifiques et à des leviers tarifaires EC2 comme les Savings Plans.
Articles associés :CloudFront 5xx : ce que les équipes gérant les origines VPC doivent vérifier
Les Lambda Managed Instances (LMI) promettent le meilleur des deux mondes : le modèle opérationnel de Lambda et le contrôle d’EC2. En pratique, il manquait souvent cette couche intermédiaire – ce que le Capacity Provider fait exactement lorsque la fonction « se comporte étrangement » en matière de mise à l’échelle.
Pourquoi les LMI sans logs étaient risqués
Les LMI (Lambda Multi-Instance) permettent d’exécuter des fonctions Lambda sur des instances EC2 provisionnées par des Capacity Providers. Cette approche est particulièrement intéressante pour les charges de travail élevées, prévisibles ou nécessitant des ressources de calcul spécialisées. L’angle mort ? En cas de dysfonctionnement du provisioning, on détecte les erreurs des fonctions, mais pas le cycle de vie des hôtes sous-jacents.
C’est précisément là que les nouveaux logs des Capacity Providers entrent en jeu. AWS les enregistre automatiquement dans CloudWatch Logs. Leur format structuré en JSON facilite la création de filtres et d’alertes, sans avoir à développer des parseurs de logs personnalisés.
Ce que les journaux enregistrent concrètement
L’accent est mis sur les activités de mise à l’échelle et le cycle de vie des instances : démarrages, arrêts, vérifications d’intégrité. Grâce à ces journaux, les équipes identifient plus rapidement les opérations échouées et les erreurs de provisionnement. Les journaux sont disponibles dans toutes les régions commerciales AWS où LMI est déployé. Pour tous les fournisseurs de capacité, ils sont activés par défaut.
La configuration reste possible via la console Lambda, l’API, l’interface en ligne de commande (CLI), SAM ou CloudFormation. Les coûts habituels des journaux CloudWatch s’appliquent. Il s’agit d’un chemin de télémétrie standard à budgétiser, au même titre que les journaux des fonctions.
Cinq vérifications avant de faire évoluer votre LMI en production
- Inventorier les fournisseurs de capacité. Quels sont les fournisseurs, les familles d’instances et les limites disponibles ?
- Configurer les groupes de logs et leur rétention. « Activé par défaut » ne signifie pas « conserver indéfiniment ». Définissez une politique de rétention et un budget de coûts.
- Configurer des alertes sur les erreurs de cycle de vie. Les lancements échoués et les terminaisons répétées doivent déclencher une alerte immédiate (via PagerDuty), et non attendre qu’un utilisateur ouvre un ticket.
- Corréler avec les métriques des fonctions. Analysez les throttles, la durée d’exécution et les erreurs en parallèle avec les logs des fournisseurs.
- Évaluer les leviers de coûts. Les Savings Plans et les Reserved Instances ne deviennent rentables qu’une fois que la couche d’instances est stable et observable.
Pour qui cette solution vaut-elle le coup ?
LMI (Lambda Managed Instances) n’est pas un remplacement des fonctions Lambda classiques dans le cas de charges irrégulières ou rares. Il s’agit d’un outil conçu pour des charges de travail prévisibles, élevées et nécessitant des ressources de calcul spécifiques. Les nouveaux logs rendent le cas d’usage plus transparent : une expérience serverless, oui, mais avec une réalité d’hébergement visible dans les logs.
Si vous utilisez déjà LMI et que vous cherchez à identifier des incidents « quelque part entre la fonction et la flotte », il est conseillé d’intégrer dès aujourd’hui la page des Capacity Providers dans la console Lambda ainsi que les filtres CloudWatch associés comme procédure standard dans votre Runbook.
Source : AWS What’s New – Logs des Capacity Providers pour Lambda Managed Instances (24 juillet 2026).
Questions fréquentes
Qu’est-ce que les instances managées Lambda (Lambda Managed Instances, LMI) ?
Les LMI permettent d’exécuter des fonctions Lambda sur des instances EC2 gérées par un Capacity Provider. L’objectif est de prendre en charge des charges de travail prévisibles et intensives, avec des profils de calcul spécifiques et des options de tarification EC2 – tout en bénéficiant d’une gestion opérationnelle similaire à celle de Lambda.
Quelles sont les nouveautés concernant les logs des Capacity Providers ?
AWS génère désormais des logs structurés au format JSON pour le scaling et le cycle de vie des instances (lancements, terminaisons, vérifications de santé), directement dans CloudWatch. Ces logs sont activés par défaut et disponibles dans les régions commerciales où les LMI sont proposées.
Des frais supplémentaires sont-ils facturés ?
La télémétrie est soumise aux tarifs habituels des logs Amazon CloudWatch. Les logs constituent une fonctionnalité standard des Capacity Providers et ne sont pas proposés en tant que module complémentaire distinct.
Comment démarrer avec le monitoring ?
Dans la console Lambda, ouvrez la page des Capacity Providers, vérifiez les groupes de logs, configurez la rétention et créez des alertes pour les événements de cycle de vie échoués. Vous pourrez ensuite associer les métriques des fonctions et les logs des providers au même tableau de bord des incidents.
Sélection de la rédaction
cloudmagazinCloudFront 5xx : les points à vérifier pour les équipes gérant les origines VPCcloudmagazinFaille NGINX : les passerelles Ingress et Gateway sous l’obligation de patchcloudmagazinHuit minutes pour un administrateur AWS : un bucket S3 ouvert comme faillePlus du réseau MBF Media
MyBusinessFutureQuand le workflow de crédit se bloque à la réception des courriersDigital ChiefsComptes orphelins : la faille cyber silencieuseSecurityTodayServiceNow-RCE : six vérifications avant l’ouverture du ticketSource de l’image : générée par IA (juillet 2026)
