AWS Lambda SnapStart : réduire les cold starts Java en production

Les développeurs Java qui s’appuient sur AWS Lambda connaissent bien ce moment de frustration : la première invocation d’une fonction après une période d’inactivité prend deux, trois, voire cinq secondes avant de répondre. Pour une API exposée à des utilisateurs réels, c’est rédhibitoire. Ce phénomène — le cold start — est l’un des principaux freins à l’adoption du serverless Java en production.

La JVM est une plateforme extraordinairement capable, mais elle a un prix : son démarrage est long. Charger les classes, initialiser les frameworks, établir les connexions aux bases de données, chauffer les caches internes… tout cela se cumule. Quand on ajoute Spring Boot par-dessus, les temps d’initialisation peuvent facilement dépasser trois secondes sur une fonction Lambda standard. Python ou Node.js démarrent en quelques dizaines de millisecondes dans les mêmes conditions.

AWS Lambda SnapStart, annoncé à re:Invent 2022, répond directement à ce problème. En exploitant une mécanique de snapshot au niveau de la microVM, il permet d’atteindre des temps de démarrage sub-seconde pour les fonctions Java — sans surcoût, et généralement sans modifier son code. Ce guide explore le mécanisme en profondeur, les précautions à prendre, les techniques d’optimisation avancées, et les cas où SnapStart est (ou n’est pas) le bon outil.

Pourquoi les cold starts Java sont-ils si pénalisants ?

Pour comprendre pourquoi SnapStart est une avancée aussi significative, il faut d’abord disséquer précisément ce qui se passe lors d’un cold start Lambda classique. La séquence comporte plusieurs phases distinctes, chacune ajoutant sa latence propre.

La première phase est le provisionnement de l’environnement d’exécution. AWS Lambda doit allouer une microVM Firecracker, charger le système d’exploitation de base et préparer l’environnement isolé pour votre fonction. Cette étape est entièrement gérée par AWS et est déjà très optimisée — elle ne représente qu’une fraction mineure du temps total sur une fonction Java bien configurée.

La deuxième phase, et de loin la plus longue, est l’initialisation de la JVM elle-même et de votre code applicatif. Le JVM doit démarrer, le classloader doit charger et vérifier tous les bytecodes nécessaires, le compilateur JIT (Just-In-Time) doit compiler les chemins chauds, et enfin votre code d’initialisation (static blocks, constructeurs de beans Spring, ouverture de pools de connexions, chargement de configuration) s’exécute. C’est ici que Spring Boot prend parfois deux à quatre secondes à lui seul.

La troisième phase est le traitement de la requête elle-même. Cette partie est identique entre un cold start et un warm start : c’est votre logique métier pure.

En production, les cold starts surviennent dans trois scénarios principaux : lors du premier appel après une période d’inactivité (Lambda recycle les environnements inactifs après environ 15 minutes), lors d’une montée en charge rapide qui force Lambda à créer de nouvelles instances en parallèle, et lors des déploiements qui renouvellent les instances existantes. Dans une architecture microservices avec plusieurs dizaines de fonctions Lambda Java, ces pics de latence peuvent se propager en cascade et dégrader significativement l’expérience utilisateur.

La gravité du problème dépend aussi du profil de trafic. Une fonction invoquée des milliers de fois par seconde en permanence restera chaude en permanence. En revanche, une API métier utilisée en heures de bureau, avec des pauses la nuit et le week-end, subira des cold starts réguliers et visibles. C’est justement ce profil — courant en contexte PME et entreprise — que SnapStart cible en priorité.

Comment fonctionne AWS Lambda SnapStart : la magie du snapshot Firecracker

Le principe de SnapStart repose sur une idée élégante : puisque l’initialisation Java est lente, exécutons-la une seule fois et capturons son résultat sous forme d’un snapshot qu’on pourra réutiliser à chaque invocation froide. Ce n’est pas une idée nouvelle dans le monde de l’informatique, mais son implémentation dans Lambda est remarquablement bien intégrée.

Concrètement, quand vous activez SnapStart et publiez une version de votre fonction Lambda, AWS ne se contente pas d’enregistrer votre code. Il exécute intégralement la phase d’initialisation de votre fonction — démarrage de la JVM, chargement des classes, exécution de votre handler d’initialisation — puis prend un snapshot complet de la microVM Firecracker qui exécute ce code. Ce snapshot capture l’état mémoire et disque de l’environnement d’exécution au moment où l’initialisation est terminée. Le snapshot est ensuite chiffré et mis en cache de façon intelligente par AWS pour minimiser la latence de récupération.

Quand une invocation froide survient plus tard, Lambda ne repart plus de zéro. Au lieu de redémarrer la JVM et de réexécuter votre code d’initialisation, il restaure l’environnement à partir du snapshot. La JVM est déjà démarrée, vos classes sont déjà chargées, vos beans Spring sont déjà initialisés. La restauration prend généralement quelques dizaines de millisecondes, là où l’initialisation classique prenait plusieurs secondes. Selon la documentation officielle d’AWS, SnapStart peut réduire le temps de démarrage jusqu’à 10 fois par rapport à une fonction Lambda Java standard, avec des latences sub-seconde atteignables même pour des applications Spring Boot lourdes.

La technologie sous-jacente est Firecracker, la technologie de microVM open-source développée par AWS qui propulse aussi bien Lambda que AWS Fargate. Firecracker dispose depuis ses premières versions d’une capacité native de snapshot et restauration de VMs, qui est maintenant exposée au niveau applicatif via SnapStart.

Le protocole qui orchestre tout cela s’appelle CRaC (Coordinated Restore at Checkpoint). CRaC est une extension de OpenJDK qui définit une API standard permettant au code applicatif de s’enregistrer comme ressource à notifier avant le checkpoint et après la restauration. AWS a intégré un contexte CRaC personnalisé dans son runtime Lambda Java managé, ce qui permet à SnapStart de fonctionner sans modification de code dans la majorité des cas — mais aussi de permettre des optimisations avancées quand on en a besoin.

Runtimes supportés et compatibilité

SnapStart a été introduit en novembre 2022 avec le support de Java 11 (Amazon Corretto 11), avant d’être étendu à Java 17 puis à Java 21 dès leur disponibilité. AWS a officiellement annoncé le support de Java 21 sur Lambda en novembre 2023, avec SnapStart disponible immédiatement. Java 21 apporte avec lui les Virtual Threads (Project Loom) et les Record Patterns, des améliorations de performance du JIT, et une meilleure empreinte mémoire — autant d’avantages qui se cumulent avec SnapStart.

En juillet 2024, AWS a étendu SnapStart aux fonctions Lambda tournant sur l’architecture ARM64 (processeurs Graviton2 et Graviton3). Cette combinaison — SnapStart + Graviton — représente aujourd’hui la configuration la plus économique et la plus performante pour du Java sur Lambda. Le coût par milliseconde est inférieur sur ARM64, et les gains de SnapStart s’appliquent indépendamment de l’architecture.

En dehors de Java, SnapStart a également été étendu à d’autres runtimes comme Python et .NET, mais c’est pour Java que le gain est le plus spectaculaire. La JVM a intrinsèquement un coût de démarrage élevé — là où Python démarre en moins de 100ms sans SnapStart, une application Java peut prendre 10 à 30 fois plus longtemps. SnapStart ne fait pas la même différence sur des runtimes qui démarrent déjà rapidement.

Il est important de noter que SnapStart ne fonctionne que sur des versions publiées de vos fonctions Lambda. La version spéciale $LATEST n’est pas supportée. Cela implique d’adopter une pratique de versionnement et d’alias dans votre workflow de déploiement, ce qui est de toute façon une bonne pratique en production. SnapStart est également disponible dans toutes les régions AWS principales, sans restriction géographique particulière.

Les précautions indispensables : gérer l’unicité après restauration

La promesse de SnapStart est séduisante, mais elle introduit une problématique nouvelle que tout développeur doit comprendre avant de l’activer en production : le problème d’unicité. Quand Lambda restaure plusieurs instances à partir du même snapshot, elles partagent exactement le même état initial. Si votre code génère des identifiants uniques, des graines aléatoires ou des secrets pendant la phase d’initialisation, toutes ces instances restaurées démarreront avec les mêmes valeurs — ce qui peut être une faille de sécurité ou une source de collisions.

La documentation officielle de Lambda est explicite sur ce point : pour maintenir l’unicité avec SnapStart, vous devez générer tout contenu unique après la phase d’initialisation, c’est-à-dire dans votre handler d’invocation et non dans votre constructeur ou vos initialiseurs statiques.

Les cas concrets à surveiller incluent les UUID générés à l’initialisation et utilisés comme identifiants de session ou de transaction, les générateurs de nombres aléatoires initialisés avec une graine fixe, les timestamps capturés à l’initialisation, et les connexions TLS dont les certificats et clés de session sont établis à l’init. Pour les générateurs cryptographiques basés sur /dev/urandom ou SecureRandom, Lambda restaure automatiquement l’entropie — ce cas est géré nativement.

L’autre problème classique concerne les connexions réseau. Les connexions TCP (vers une base de données RDS, un cache ElastiCache, un endpoint DynamoDB) établies pendant l’initialisation seront dans le snapshot, mais elles peuvent être expirées ou invalides au moment de la restauration. Il faut impérativement implémenter une logique de reconnexion dans le hook de restauration, ou utiliser des patterns de lazy initialization pour les connexions.

Pour les deux problèmes — unicité et connexions — la solution propre passe par les hooks CRaC. En implémentant l’interface Resource du package org.crac, vous pouvez enregistrer des callbacks qui s’exécutent automatiquement juste avant que le snapshot soit pris (beforeCheckpoint) et juste après la restauration (afterRestore). Le hook beforeCheckpoint sert à fermer proprement les connexions avant la capture. Le hook afterRestore sert à les rouvrir, régénérer l’entropie et réinitialiser tout ce qui doit être unique par instance.

import org.crac.Context;
import org.crac.Core;
import org.crac.Resource;

public class DatabaseConnectionManager implements Resource {

    private DataSource dataSource;

    public DatabaseConnectionManager() {
        Core.getGlobalContext().register(this);
        this.dataSource = createDataSource();
    }

    @Override
    public void beforeCheckpoint(Context<? extends Resource> context) {
        // Fermer les connexions avant le snapshot
        dataSource.close();
    }

    @Override
    public void afterRestore(Context<? extends Resource> context) {
        // Rouvrir les connexions après la restauration
        this.dataSource = createDataSource();
    }
}

Les frameworks Java modernes gèrent de plus en plus ces cas automatiquement. Spring Boot 3.2+ inclut un support natif de CRaC. Micronaut, Quarkus et Helidon ont également intégré des adaptateurs SnapStart qui gèrent les connexions et ressources de façon transparente. Si vous utilisez l’un de ces frameworks dans une version récente, la majorité des précautions sont déjà prises en charge.

Le priming : pousser SnapStart à son maximum

SnapStart résout le problème du coût d’initialisation, mais il ne garantit pas à lui seul une latence minimale. Il existe une technique complémentaire appelée priming qui permet de pousser les performances encore plus loin, en forçant certaines opérations habituellement différées à s’exécuter pendant la phase d’initialisation, avant que le snapshot soit pris.

Le principe est simple : plus on inclut d’état préparé dans le snapshot, moins il reste de travail à faire au moment de la restauration. Les JVM modernes utilisent des techniques de compilation Just-In-Time qui compilent le bytecode en code natif au fur et à mesure que les chemins chauds sont détectés. Sans priming, les premiers appels après une restauration peuvent être légèrement plus lents que les appels suivants, le temps que le JIT compile à nouveau les chemins critiques.

Le priming consiste à effectuer des appels factices aux chemins critiques de votre application dans le hook beforeCheckpoint, afin que le JIT ait déjà compilé ces chemins avant que le snapshot soit capturé. Quand la fonction est restaurée, le code natif compilé est déjà en mémoire — la première invocation réelle est aussi rapide que les suivantes.

AWS documente cette technique en détail avec des cas concrets incluant Spring Boot. L’article montre comment effectuer des appels DynamoDB de priming, chauffer les connexions HTTP, ou précharger des données de configuration depuis des services externes. Les gains de priming s’ajoutent aux gains de base de SnapStart et peuvent réduire la latence de restauration à quelques dizaines de millisecondes sur des applications complexes.

Pour les applications Spring Boot, le priming le plus efficace consiste à déclencher une première invocation complète du contexte applicatif dans le beforeCheckpoint. On peut utiliser l’interface ApplicationRunner de Spring Boot pour exécuter ce warm-up automatiquement lors du démarrage, avant que CRaC ne capture le snapshot. L’article de l’équipe AWS Open Source sur le retour d’expérience de Sonar avec Micronaut illustre cette approche en production réelle, avec des résultats mesurables sur des APIs à forte contrainte de latence.

Le priming a cependant une limite : tout ce qui est “chauffé” dans le snapshot doit rester valide au moment de la restauration. On ne peut pas pré-ouvrir des connexions de base de données et espérer qu’elles soient encore valides des heures plus tard. Le priming s’applique donc en priorité aux opérations purement locales (compilation JIT, chargement de classes, préallocation de structures de données) et aux appels réseau de configuration qui produisent des données stables.

SnapStart vs Provisioned Concurrency : choisir la bonne stratégie

Avant SnapStart, la réponse standard au problème des cold starts Lambda était la Provisioned Concurrency. Ces deux fonctionnalités répondent au même problème mais avec des approches radicalement différentes, et elles sont mutuellement exclusives sur une même version de fonction — vous ne pouvez pas activer les deux simultanément.

La Provisioned Concurrency fonctionne en maintenant un nombre prédéfini d’environnements Lambda déjà initialisés et prêts à traiter des invocations. Il n’y a techniquement aucun cold start pour ces instances : elles sont toujours chaudes. En contrepartie, vous payez ces environnements en permanence, même quand votre trafic est faible ou nul. La facturation s’applique à la durée totale de disponibilité provisionnée, indépendamment du nombre d’invocations réelles.

SnapStart fonctionne différemment : il réduit drastiquement la durée du cold start (de plusieurs secondes à quelques dizaines de millisecondes), mais un cold start a toujours lieu lors de chaque nouvelle instance. Le coût supplémentaire est nul — vous payez uniquement les invocations standard, sans frais pour le temps de restauration du snapshot.

Le bon choix dépend de votre profil de trafic et de vos exigences de latence. Pour les applications à trafic imprévisible ou fortement variable — pics ponctuels, trafic en heures de bureau, campagnes marketing aléatoires — SnapStart est généralement la meilleure option. La Provisioned Concurrency serait sous-utilisée la plupart du temps, générant des coûts sans bénéfice réel. SnapStart garantit une bonne performance lors des pics sans coût permanent.

Pour les applications à trafic constant et élevé où la latence maximale admissible est très basse (quelques millisecondes) et où le budget le permet, la Provisioned Concurrency reste pertinente. Elle garantit un démarrage en zéro milliseconde pour les instances provisionnées, là où SnapStart donnera toujours quelques dizaines de millisecondes de restauration. Pour les APIs financières ou les systèmes de paiement en temps réel avec des SLAs stricts, cette différence peut être significative.

Une stratégie hybride souvent adoptée en pratique consiste à utiliser SnapStart comme protection de base contre les cold starts, et à combiner cela avec des Scheduled Events CloudWatch pour maintenir quelques instances actives aux heures de pointe. Cette approche ne nécessite pas de Provisioned Concurrency et reste économique. Pour aller plus loin dans la maîtrise de vos coûts Lambda, l’article sur les 7 leviers pour optimiser vos coûts AWS détaille des stratégies complémentaires.

Configurer SnapStart : SAM, CDK, Terraform et Console

Activer SnapStart est remarquablement simple. Quelle que soit votre méthode de déploiement, la configuration se résume à deux éléments : activer l’option SnapStart sur votre fonction, et publier une version (car SnapStart ne s’applique qu’aux versions publiées, pas à $LATEST).

Via AWS SAM, c’est la configuration la plus concise :

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: java21
      Handler: com.example.Handler::handleRequest
      SnapStart:
        ApplyOn: PublishedVersions
      AutoPublishAlias: live

L’option AutoPublishAlias assure qu’à chaque déploiement SAM, une nouvelle version est publiée et l’alias live est mis à jour. C’est cet alias que vos consommateurs (API Gateway, EventBridge, etc.) doivent pointer plutôt que directement sur la fonction.

Via AWS CDK (TypeScript) :

const fn = new lambda.Function(this, 'MyFunction', {
  runtime: lambda.Runtime.JAVA_21,
  handler: 'com.example.Handler::handleRequest',
  code: lambda.Code.fromAsset('target/function.jar'),
  snapStart: lambda.SnapStartConf.ON_PUBLISHED_VERSIONS,
});

const version = fn.currentVersion;
new lambda.Alias(this, 'LiveAlias', {
  aliasName: 'live',
  version,
});

Via Terraform :

resource "aws_lambda_function" "my_function" {
  function_name = "my-java-function"
  runtime       = "java21"
  handler       = "com.example.Handler::handleRequest"

  snap_start {
    apply_on = "PublishedVersions"
  }
}

resource "aws_lambda_alias" "live" {
  name             = "live"
  function_name    = aws_lambda_function.my_function.function_name
  function_version = aws_lambda_function.my_function.version
}

Dans tous les cas, notez que le premier déploiement avec SnapStart activé sera légèrement plus long qu’un déploiement standard. AWS doit en effet exécuter l’initialisation complète et créer le snapshot avant de considérer la version comme déployée. Ce délai est un investissement unique par version : tous les cold starts ultérieurs en bénéficieront.

Une fois déployé, vous pouvez surveiller la performance de vos restaurations SnapStart dans Amazon CloudWatch via la métrique InitDuration qui mesure la durée de restauration du snapshot. Une valeur inférieure à 200ms indique généralement une bonne configuration. La métrique Duration mesure quant à elle votre temps d’exécution pur.

Cas d’usage et retours d’expérience en production

L’architecture serverless est particulièrement attractive pour les entreprises qui souhaitent se concentrer sur leur valeur métier plutôt que sur la gestion d’infrastructure. L’article sur le serverless AWS pour les PME explore ce contexte en détail. SnapStart lève le principal frein technique qui empêchait d’utiliser Java dans ces architectures.

Concrètement, les cas d’usage qui bénéficient le plus de SnapStart sont les APIs REST exposées à des utilisateurs finaux via API Gateway ou Lambda Function URLs. Ces APIs ont des contraintes de latence directement visibles et mesurables par l’utilisateur. Un cold start de 3 secondes sur une API de login ou de recherche de produit dégrade directement l’expérience utilisateur.

Les microservices d’orchestration — fonctions Lambda qui agrègent des appels à d’autres services, valident des données, appliquent des règles métier — sont également de très bons candidats. Ces fonctions sont souvent les plus grosses en termes de code et de dépendances (Spring Data, AWS SDK, clients HTTP, parseurs JSON), et donc les plus affectées par les cold starts.

Les pipelines de traitement événementiel consommant des flux SQS ou Kinesis peuvent aussi bénéficier de SnapStart lors des phases de montée en charge. Quand le trafic augmente brusquement, Lambda crée plusieurs instances en parallèle — sans SnapStart, chacune subit un cold start complet, ce qui retarde le traitement de la file.

Le retour d’expérience de Sonar, publié par AWS dans son blog Open Source, illustre bien les bénéfices en conditions réelles. En migrant vers SnapStart avec Micronaut sur leur infrastructure Lambda, ils ont obtenu des améliorations significatives de performance sur leurs APIs internes — avec une mise en œuvre qui n’a nécessité que peu de modifications de leur code existant. Ce type de résultat est représentatif de ce qu’on peut espérer sur des applications Micronaut et Spring Boot bien configurées.

SnapStart et l’écosystème Java moderne : GraalVM, Quarkus, Micronaut

Il est légitime de se demander si SnapStart concurrence ou complète les autres approches de réduction des cold starts Java, notamment la compilation native avec GraalVM Native Image.

GraalVM Native Image compile votre application Java en un binaire natif autonome, sans JVM. Le temps de démarrage est spectaculaire — souvent inférieur à 50ms même pour des applications Spring Boot. L’empreinte mémoire est également réduite. Mais la compilation native a ses propres contraintes : elle nécessite une configuration extensive pour les fonctionnalités basées sur la réflexion (très utilisées dans Spring), augmente considérablement le temps de build (de plusieurs minutes), et peut introduire des comportements différents entre le mode JVM et le mode natif.

SnapStart offre une alternative pragmatique : il ne requiert aucune modification du processus de build, fonctionne avec n’importe quel code Java existant, et donne des résultats sub-seconde qui sont suffisants pour la grande majorité des cas d’usage. Pour une équipe qui maîtrise déjà Spring Boot et souhaite simplement améliorer ses cold starts sans investir dans la compilation native, SnapStart est le chemin de moindre résistance.

Quarkus et Micronaut ont une position intermédiaire intéressante : leurs temps de démarrage sont naturellement plus courts que Spring Boot (grâce à l’injection de dépendances au compile-time plutôt qu’à l’exécution), et ils ont tous les deux un excellent support de SnapStart ET de GraalVM. Pour une nouvelle application Lambda Java, Micronaut est souvent recommandé comme framework de base avec SnapStart activé — le retour d’expérience de Sonar en est une bonne illustration.

Pour les applications AWS Lambda 10 cas d’usage que nous détaillons dans notre article dédié, SnapStart est particulièrement pertinent pour les fonctions exposant des APIs synchrones, moins critique pour les traitements asynchrones en arrière-plan où la latence de démarrage n’est pas visible par l’utilisateur final.

La sélection du bon runtime Java doit également tenir compte du Well-Architected Framework d’AWS, notamment le pilier Performance Efficiency, qui recommande d’évaluer les fonctionnalités gérées comme SnapStart avant d’implémenter des optimisations applicatives complexes. Notre article sur le Well-Architected Framework explore ces principes appliqués aux PME.

Monitoring et mesure des gains avec CloudWatch

Activer SnapStart sans mesurer son impact, c’est comme déployer en aveugle. AWS CloudWatch fournit les métriques nécessaires pour évaluer précisément les gains et détecter d’éventuels problèmes.

La métrique clé est InitDuration, qui mesure la durée de la phase d’initialisation ou de restauration avant le traitement de l’invocation. Avant SnapStart, cette valeur représente votre cold start complet (JVM + init applicatif). Après activation, elle représente uniquement le temps de restauration du snapshot — ce nombre devrait être drastiquement plus bas.

Pour comparer objectivement, créez deux alarmes CloudWatch : une sur le P99 de InitDuration (le 99e percentile, représentatif du pire cas), et une sur le P50 (médiane). L’écart entre ces deux valeurs vous indique la variabilité de vos restaurations. Une forte variabilité peut indiquer que le snapshot est parfois évincé du cache AWS et doit être rechargé depuis le stockage.

La métrique Duration (temps d’exécution pur de votre handler) ne devrait pas changer avec SnapStart. Si elle augmente, c’est le signe que certaines initialisations différées se produisent maintenant dans le handler plutôt que dans l’init — un pattern à corriger avec des hooks afterRestore.

Pour aller plus loin dans l’observabilité, AWS X-Ray trace nativement les phases Initialization et Invocation séparément, ce qui permet de visualiser très précisément la répartition du temps pour chaque invocation, froide ou chaude. Cette intégration est disponible sans configuration supplémentaire dans les runtimes Java managés d’AWS Lambda.

Le couplage entre SnapStart et une bonne stratégie de monitoring CloudWatch est directement lié aux principes d’architecture serverless définis dans le cadre Well-Architected. Le pilier Fiabilité recommande d’instrumenter et de mesurer avant d’optimiser. SnapStart sans monitoring, c’est une optimisation qu’on ne peut pas prouver.

Conclusion

AWS Lambda SnapStart représente une avancée majeure pour les équipes qui souhaitent conserver Java — avec toute sa richesse écosystémique — dans des architectures serverless sans sacrifier la réactivité. En exploitant la capacité de snapshot des microVMs Firecracker via le protocole CRaC, AWS a résolu le problème structurel des cold starts Java d’une façon élégante, transparente et sans surcoût.

La mise en œuvre est accessible : quelques lignes de configuration dans votre SAM template ou votre code CDK, et votre prochaine publication de version bénéficiera automatiquement de démarrages sub-seconde. Les cas où des adaptations de code sont nécessaires — gestion de l’unicité, reconnexion réseau dans les hooks CRaC — sont bien documentés et gérés nativement par les frameworks modernes comme Spring Boot 3.2+, Micronaut et Quarkus.

Pour les équipes dont les applications Lambda Java souffrent de cold starts visibles par les utilisateurs, SnapStart est aujourd’hui la première action à entreprendre, avant même d’envisager la compilation GraalVM ou la Provisioned Concurrency. Le rapport effort/bénéfice est excellent.

Si vous gérez une infrastructure AWS avec des fonctions Lambda Java en production et souhaitez un audit de vos configurations SnapStart, une analyse de vos métriques CloudWatch, ou un accompagnement pour migrer vers Java 21 avec Graviton, notre équipe d’experts AWS certifiés à Mulhouse est disponible pour un premier échange.