Comme chaque année, Ippon Technologies et ses collaborateurs étaient présents pour assister au salon organisé par AWS, au Palais des Congrès de Paris, afin d’y présenter ses nouveautés. Nous vous proposons de revenir sur les principales informations que nous avons retenues et vous donnons un aperçu des différentes présentations auxquelles nous avons assistés.
Keynote
Que serait un salon AWS sans sa traditionnelle keynote, l’occasion pour Julien Groues, Directeur Général d’AWS France de rassurer ses clients européens sur la situation géopolitique actuelle et notamment sur la capacité d’AWS à protéger les données des européens via sa technologie Nitro qui empêche physiquement les données d’être envoyées aux US, réaffirmer leur engagement sur l’économie française, l’environnement et sur l’égalité femme homme (notamment à travers le lancement du programme SISTA AI qui a pour objectif d’accompagner des startups fondées par des femmes dans le domaine de l’IA).
Sans trop de surprise, comme c’était déjà le cas l’année dernière, l’IA est à l’honneur lors de ce Summit. Quelques chiffres nous ont été donnés par Julien Groues afin de faire un état des lieux de l’IA en France. Aujourd’hui, selon les chiffres d’AWS, 30% des entreprises françaises ont adopté l’IA au quotidien et 90% d’entre elles déclarent avoir augmenté leur chiffre d'affaires, c’est notamment le cas de Veritas, Proovstation, La Centrale ou encore AD Creative.
Ensuite, au tour de Mai-Lan Tomsen Bukovec, vice Présidente d’AWS, de présenter un état des lieux de ce qu’AWS met à disposition des entreprises pour faire de l’IA en terme de calcul, stockage et réseau (réseau interne à AWS qui ne fait que grandir ces dernières années). S’en sont suivi différents retours d’expérience de clients et partenaires d’AWS : Owkin, Poolside, Safran et Qonto.
De nouveau cette année, Arthur MENSCH, co-fondateur et Président de Mistral AI, était l’invité d’honneur de cette Keynote, l’occasion de revenir sur la success story de la startup française qui propose aujourd’hui, en plus de modèles d’IA générative performants, une plateforme permettant aux entreprises de créer, personnaliser et déployer des modèles sur différentes infrastructures. Mistral AI travaille aujourd’hui avec des entreprises comme Veolia pour les accompagner sur l’adoption de ces technologies. L’annonce phare de cette intervention d’Arthur MENSCH a été la mise à disposition du nouveau modèle d’analyse d’images de Mistral AI sur Amazon Bedrock en Europe, Pixtral Large.
Enjeux de souveraineté : protéger, contrôler, innover
Speakers: Charles Grenet, Baptiste Cazagou, Tony Baudot
Ecriture: Camille TARIEL Paul BOISSON
La souveraineté est un sujet de préoccupation pour de nombreuses entreprises, d’autant plus avec le contexte actuel de guerre commerciale déclarée par les Etats-Unis et l’importance des GAFAM sur le marché européen. Cette conférence animée par 3 consultants de chez Deloitte France, a abordé ces enjeux de protection, contrôle et d’innovation :
- Charles Grenet, Director Cloud Engineering and Data
- Baptiste Cazagou, AWS Security Lead,
- Tony Baudot, Director in charge of Sovereignty.
Contexte législatif :
Le Cloud Act: Cette loi américaine autorise les autorités américaines à lancer des mandats de perquisition pour récupérer toute donnée qui est stockée sur tout type d’hébergement d’une entreprise américaine. Cette loi est différente du Patriot Act, qui concerne quant à lui le renseignement dans le cadre de la lutte contre le terrorisme et ne nécessite pas d’autorisation judiciaire.
FISA: Loi américaine qui permet aux autorités américaines de surveiller les échanges entre les individus même à l’étranger et sans encadrement par un juge.
Data Privacy Framework: Accord entre l’Union Européenne et les Etats-Unis pour protéger les données personnelles des européens lors des transferts EU/US. Cet accord est souvent remis en question par les américains et risque de bientôt disparaître.
La souveraineté remise sur la table régulièrement suite aux tensions géopolitiques actuelles par les industriels européens, est encadrée par des lois comme le Cloud Act et FISA qui ont toutes pour socle commun les réglementations NIST et 27001. Cependant, juridiquement, le cadre reste flou sur le Cloud. Les européens doivent réfléchir à l’importance de la souveraineté de leurs opérations, de leurs données, de leur logiciel et de leur infrastructure, notamment entre les régions de la Chine et des Etats-Unis.
Les speakers de cette conférence soulignent l’importance de la souveraineté comme n’étant pas qu’un effort de sécurité autour de la donnée mais comme une stratégie commune aux équipes juridiques, techniques et cyber.
C’est pourquoi, les intervenants ont souhaité apporter trois points de vue : technique, juridique et de cybersécurité sur la notion de souveraineté du Cloud en France. D’un point de vue juridique, la souveraineté n’est pas définie. La souveraineté nous vient souvent comme la protection et la réglementation des données. Pour la technique, un travail est nécessaire de balance entre l’innovation et la sécurité. Cela se traduit, du point de vue de la cybersécurité, par le fait de placer leurs équipes comme des “enablers” pour appuyer le dialogue inter-équipes.
Un exemple d’initiative de la souveraineté du Cloud à la française est le SecNumCloud. Il répond aux besoins juridiques français. Cependant les intervenants appuient le fait que l’offre ne suit pas la demande et que souvent les entreprises demandent une infrastructure SecNumCloud ou équivalente. Il est aussi important de définir ce qui est sensible dans ces activités pour répartir son infrastructure entre un cloud plus orienté public ou sécurisé, notamment par les analyses de risques. Malgré un cadre non défini par la législation, nos interlocuteurs soulignent la progression du seuil de sécurité, qui s’améliore chaque année.
L’enjeu aujourd'hui, c'est comment être imperméable aux fluctuations géopolitiques.
La souveraineté des données est au cœur de l’actualité avec l'ère de l’IA. Nos intervenants n’ont pas manqué d’appeler à la prudence lorsqu’on utilise des outils d’IA Générative, car les données fournies pourraient être conservées et utilisées pour améliorer les modèles, posant ainsi des risques pour la confidentialité et la propriété des données.
La sécurité AWS à grande échelle : du développement aux opérations
Speakers: Benjamin Lecoq, Sebastien Maugeais
Ecriture: Florian AYMARD Thomas PIERSSON
Dans cette session, Benjamin Lecoq, Cloud Operations Architect et Sébastien Maugeais, Solutions Architect, nous ont proposé un tour détaillé des possibilités de sécurisation offertes par AWS.
L’objectif principal est de rester aux standards de sécurité tout au long de la vie d’une application, sans que la couche de sécurisation soit un frein à l’innovation.
Nos deux speakers ont rappelé le modèle de partage des responsabilités mis en place par AWS : la sécurité du cloud est à leur charge (143 certifications de sécurité ou de conformité), mais la sécurité dans le cloud est à la charge du client.
Sécurité du cloud
La sécurité du cloud chez AWS démarre dès la conception. Avec les nouvelles puces Graviton 4, les interfaces physiques de transfert profitent d’un chiffrement matériel. En ce qui concerne l’hyperviseur maison, Nitro, la conception basée sur des API permet une gestion fine des droits et une auditabilité optimale des opérations réalisées. À noter qu’aucune API ne permet d’accéder ni aux données utilisateur, ni aux interfaces de connexion aux instances.
Concernant la défense périmétrique, quelques chiffres :
- Un trillion de requêtes DNS par jour
- 124 000 domaines malveillants par jour
- 27 milliards de tentatives de recherche de buckets S3 publics (en 2023)
- 2,7 milliards de recherches de ports ouverts sur des instances EC2 (en 2023)
Sécurité dans le cloud
Malgré les efforts fournis par AWS pour sécuriser les infrastructures, le client doit aussi mettre la main à la pâte pour se protéger des menaces. Cela passe par plusieurs secteurs.
IAM (Identité et droits)
L’accès granulaire (principe du moindre privilège) devient essentiel (qui peut faire quelle action sur quoi). Pour auditer les accès, CloudTrail et Guard Duty restent d’excellents outils.
Protection des données
Les réglementations sur la protection des données évoluent, et ce à des rythmes différents selon les zones géographiques. L’auditabilité et l’automatisation deviennent essentielles.
Il faut donc s’assurer que la construction des infrastructures puisse se faire en respectant les préconisations (au départ, puis pendant la vie de la plateforme).
Parmi ces préconisations, on peut lister : chiffrer le stockage (chiffrement au repos), chiffrer le réseau (chiffrement en transit), utiliser AWS KMS pour gérer les clés de chiffrement afin d’automatiser le chiffrement des données et les rotations de clés grâce aux intégrations natives des différents services AWS (EBS, RDS…).
Sécurité du réseau
Comment sécuriser et optimiser son réseau sur AWS ?
- CloudFront pour utiliser le backbone réseau AWS afin de réduire les frais de transferts (33% de croissance en glissement annuel sur la quantité de points de terminaison), cache, intégration WAF et Shield, Lambda@Edge…
- AWS WAF pour se protéger des requêtes malicieuses (SQLi, XSS…)
- AWS Shield pour se protéger des attaques type DDoS
- AWS Network Firewall et Amazon Route 53 Resolver DNS Firewall pour les protections de type pare-feu sortant
- AWS Verified Access (zero trust) pour la sécurisation des applications avec le principe de moindre privilège, authentification continue et contrôle d’accès à la demande.
De plus, AWS Firewall Manager donne de la visibilité sur la posture de sécurité réseau et permet de mettre en place des politiques de sécurité au niveau de l’organisation.
Détection et réponse
Les défis de la cybersécurité résident évidemment dans la protection vis-à-vis des attaques, mais aussi dans le manque de données sur les évènements cyber, la fragmentation des données et le manque de visibilité.
AWS répond à ces défis par plusieurs pans : détecter les menaces et scanner les vulnérabilités (Guard Duty, Inspector et Macie), investiguer et répondre (Detective, Security Lake). AWS Security Hub se place également en pont entre les deux sections.
Aujourd’hui l’IA générative progresse de plus en plus et devient omniprésente dans nos quotidiens et chez nos clients. Deux questions se posent.
Comment sécuriser l’IA ? Et comment utiliser l’IA au service de la sécurité ?
Sécurité de l’IA générative
Il n’y a pas d’outils magiques permettant de sécuriser l’IA, il faut aborder la sécurité de l’IA avec la même rigueur et les mêmes principes que pour n’importe quel autre système d’information.
Une approche dites “château fort” , couche par couche sur comment aborder la sécurité de l’IA:
- Politiques, procédures et sensibilisation
- Protection réseau
- IAM
- Détections des menaces et réponses
- Protection de l’infra
- Protection APP
- Protection des données
Sans rentrer dans le détail de chaque couche, il est essentiel de comprendre que chaque couche est importante, en partant de l’extérieur du château qui est la sensibilisation des collaborateurs à la sécurité informatique à la protection des données par le chiffrement comme mentionné plus haut.
Plusieurs services AWS viennent en solutions pour chacune de ses couches. Comme AWS Shield Advanced pour la protection réseau en bloquant les attaques DDoS, IAM pour la gestion des accès et identités (qui peut faire quelle action sur quoi), Amazon GuardDuty et AWS Security Hub pour la détection des menaces et réponses ou encore AWS KMS pour le chiffrement des données.
Après avoir vu comment aborder la question de la sécurité de l’IA générative, voyons maintenant comment elle peut-être mise au service de la sécurité.
L’IA est déjà intégrée dans plusieurs services AWS et contribuent au niveau sécurité sur quatre piliers identifiés par AWS:
- Automatisation Simple et réactif
- Résumer les infos sur les menaces; Simplifier les rapports
- Corrélation alertes résultats
- Automatisation SImple et proactif
- L’application de correctifs
- La réponse aux incidents
- Détection des données sensibles
- Détection des mauvaises configurations
- Avancé et réactif
- Création et exécution de playbooks
- Définir des règles
- Orienter les investigations
- Avancé et proactif
- Informations plus approfondies
- Remédiations assistées
- Modélisation prédictives des menaces
Via ces quatres piliers l’IA devient un allié fort pour la sécurité des infrastructures et applications dans AWS. Plusieurs outils sont notamment spécialisés dans un des piliers, l’objectif d’AWS étant d’avoir des outils pouvant répondre aux piliers et de centraliser le tout dans AWS Security Hub.
A de nombreuses reprises nous avons parlé de Amazon GuardDuty, ce service utilise le machine learning pour identifier de potentielles menaces en analysant des flux VPC ou des évenements CloudTrail par exemple.
Amazon Detective, lui, est un service qui va pouvoir analyser les logs de l’infrastructure pour y trouver la root cause d’incidents.
Au niveau des charges de travail, Amazon Inspector va analyser directement les services comme EC2, ECS ou Lambda pour découvrir automatiquement des vulnérabilités et des écarts avec les bonnes pratiques de sécurité.
Pour ce qui est des données, le service Amazon Macie grâce au machine learning et au pattern matching est capable de détecter les données sensibles et de les protéger.
Enfin, AWS IAM Access Analyser nous aide en nous guidant sur tous les privilèges donnés sur les ressources pour être sûr d’appliquer le “least privilege”. Dans tous ces services AWS Security Hub joue le rôle de centralisation pour nous aider à gérer les alertes et les incidents de sécurité avec tous ces services.
D’autres services permettent aussi d’analyser des vulnérabilités directement dans le code des applications. Les services comme Amazon Q developer et CodeGuru eux aussi basé sur l’IA vont pouvoir analyser et détecter du code onéreux.
En intégrant l’IA, AWS fournit de nombreux services utiles permettant d’aider les équipes de sécurité à réagir plus rapidement et efficacement sur les incidents.
Découvrez le Platform Engineering avec Backstage
Speakers: Ziad Osman, Anas Titah, Dimitri Desbois,
Ecriture: Florian AYMARD
Dans cette conférence, Dimitri Desbois (Head of Cloud Platform Engineering chez Safran) a présenté leur portail de développement interne, mis en place pour aider les équipes de Safran dans l’adoption des services AWS. Le portail, basé sur Backstage, utilise le plugin Harmonix développé par AWS afin de proposer une nouvelle manière d’interagir avec le cloud. Un de leurs objectifs (ambitieux) est de pouvoir proposer un onboarding complet, du projet GitLab au compte AWS, en moins de 20 minutes.
Harmonix s’oriente autour des pans suivants :
- Des types d’entité dédiés au Cloud
- Des actions utilisables dans le Scaffolder de Backstage pour interagir avec certains services
- Des modules front-end pour interagir avec des tâches ECS, lire des logs CloudWatch..
Chez Ippon, nous avions déjà pu mettre en place Harmonix en interne avant d’assister à cette conférence et nous suivons le projet de près, avec déjà quelques contributions en cours. Nous étions donc ravis de voir que le projet prend aussi du sens dans des projets à l’échelle.
Nous publierons prochainement du contenu sur cette solution mais aussi sur le Platform Engineering au sens large, alors restez connectés !
Microservices : l’art du dimensionnement pour une performance optimale
Speakers: Yala El Feghaly, Frederic Nowak, Pierre Bougon
Ecriture: Florian AYMARD
Dans cette session, Pierre Bougon (Staff Software Engineer chez Betclic) a exposé le processus qui a amené la célèbre entreprise de paris sportifs vers une architecture micro-services. Il était accompagné par deux collaborateurs AWS : Yala El Feghaly, Cloud Operations Architect et Frédéric Nowak, Solutions Architect.
Introduction : les défis du microservice
Avant de traiter le cas concret de Betclic, les deux architectes AWS ont commencé par exposer ce qui rend les microservices aussi compliqués à mettre en œuvre. La promesse de base est alléchante : découplage, déploiements facilités et accélérés, simplification de la mise à l’échelle.
Cependant, ces architectures que l’on voit souvent être promues par les grands groupes comme Netflix sont-elles toujours la bonne réponse ? Attention à ne pas tomber dans le “syndrome de l’objet brillant” ou le biais du dimensionnement, et de bien prendre garde à ce que le besoin et la solution soient bien alignés.
Parmi les coûts cachés des microservices, la complexité opérationnelle semble être le plus important. Hormis le fait de devoir surveiller une quantité plus ou moins importante de services (versus un seul ou quelques uns dans le cas du monolithe/monolithe distribué), l’analyse des erreurs doit forcément passer par de la corrélation et la sollicitation de multiples équipes (versus une seule dans le cas du monolithe). Il faut donc prendre en compte ces besoins dès la conception et s’assurer d’avoir les ressources nécessaires pour les assumer.
Cas concret : la migration de Betclic
Contexte
Betclic, ce sont des millions de paris par jour, avec des centaines de milliers de joueurs simultanés, des millions de joueurs par mois, des régulations fortes et une nécessité d’assurer la plus faible latence possible (avec les paris en direct, ce serait dangereux de pouvoir parier pour un évènement qui a déjà eu lieu…)
Chaque pays possède son propre catalogue, et il y a un besoin de découpler les différents catalogues tout en partageant la même base métier.
À l’origine, l’architecture consistaient en plusieurs macro-services avec des domaines communs sur une seule base SQL mono-nœud, pas de résilience, pas de séparation des domaines. En plus de cela, cette architecture ne répondait pas aux problématiques de latence.
Pour la nouvelle architecture, les souhaits étaient d’avoir une scalabilité maximale, de favoriser l’agilité, tout en optimisant la performance avec un objectif de latence inférieure à 500ms.
Il fallait donc aller plus loin qu’un simple lift and shift, mais de partir sur une architecture cloud native par conception, avec du Domain Driven Design pour assurer un découplage adapté, et des technologies à l’état de l’art comme Kafka, Redis et gRPC.
Comment découper les services
- Partir du besoin métier
- Trouver les fonctionnalités, le domaine, couplage des entités
- Trouver le bon compromis entre criticité, complexité, besoin transactionnels ou de résilience globaux (qui pourraient amener à ne pas séparer plusieurs domaines pour faciliter les opérations)
Comment découpler les services
- Faire des appels synchrones en chaîne revient à coupler le taux de disponibilité de deux microservices, et donc de rendre inutile le découpage. Les appels entre services peuvent être remplacés par du CDC (change data capture) pour partager les informations sans dépendre des disponibilités mutuelles.
- Quand les communications synchrones sont inévitables, gRPC et les Protocol Buffers/Protobuf permettent d’optimiser les échanges (Betclic a remarqué une performance 4x supérieure entre http/json et grpc/protobuf)
J’ai particulièrement apprécié l’insistance faite entre découper et découpler les services.
Résultat
La nouvelle plateforme de Betclic est maintenant :
- scalable
- découpée et découplée entre domaines (contrats sur les échanges Kafka et Protobuf pour la partie synchrone), avec des bases de données correctement séparées
- avec un temps de réponse 10 fois moins long.
Cela au prix d’un réel effort organisationnel :
- Ratio 70 développeurs/70 microservices
- Évangélisation DevOps (avec la fameuse maxime “you build it, you run it”)
En guise d’exemple, Pierre Bougon a conclu en expliquant que les 18 derniers matchs de la phase de groupes de Ligue des Champions avaient été lancés en même temps, représentant :
- des millions de logins
- des centaines de milliers de joueurs
- des millions de paris sur la soirée
Betclic a été la seule plateforme de paris à proposer 100% de disponibilité sur la soirée.
Points clés
- Ne pas découper pour découper
- Découper ET découpler
- Justifier la complexité
- Découper progressivement
- Avoir assez de développeurs pour supporter la charge
Efficient compute: Booster les performances et réduire les coûts !
Speakers : Romain Legret, Khalil Mouakher, Praajeth Pahitharan
Ecriture: Rainald DURAND
Lors de cette conférence y était présenté le concept de l’efficience compute, les challenges auxquels les entreprises peuvent être confrontées pour l’améliorer, ainsi que différents axes possibles pour y parvenir.
Qu’est ce que l’efficience ?
La conférence a donc commencé par fournir une définition de l’efficience, ou du moins, tenter d’en donner une, puisque l’efficience est davantage un concept abstrait qu’une formule viable et applicable dans chaque contexte.
Elle s’exprime principalement sous la forme d’une formule mettant en relation la notion de valeur et le coût pour générer cette valeur. Que ce soit en termes de ressources computes, de nombre de requêtes API, de token générés par minute, ou tout autre indicateur servant à mesurer ce qui génère de la valeur. Le coût quant à lui inclut tout ce qui est relatif à la génération de cette valeur, comme la main d'œuvre, le coût de l'infrastructure etc…
Même s’il y a plusieurs façons de définir l’efficience, le calcul de celle-ci va toujours donner un résultat soit inférieur ou supérieur à 1. Maximiser l’efficience revient donc à mettre en place des procédés et solutions permettant d’obtenir un score supérieur à 1, ce qui signifierait de générer davantage de valeur que d’argent dépensé pour la générer.
Les enjeux de l’efficience
Suivant le contexte technique dans lequel l’efficience est défini, des difficultés peuvent survenir lorsque l’on essaye de l’améliorer :
- Flexibilité et scalabilité : des applications qui sont, par leur définition, difficilement compatibles avec ces notions. Les applications de type monolithe par exemple bénéficient d’une granularité restreinte dans leur mise à l'échelle puisqu’elle impose de dupliquer des éléments qui ne sont pas nécessaires d’un point de vue performance.
- Les dépendances entre les composants de l’architecture: Composant défini sous forme de bloc (LB + Front + Back par exemple), on peut avoir des problématiques sur la façon dont ces éléments fonctionnent ensemble et donc de devoir dupliquer un certain nombre de composants, ce qui peut engendrer une augmentation de la consommation des ressources.
- Surcouches, duplications et doublons : Lorsque l’on est dans un environnement non conteneurisé, on va embarquer un certain nombre d’éléments qui vont être dupliqués d’une instance à l’autre. Que ce soit la couche OS, des agents nécessaires au monitoring de l’instance, à la gestion des logs, ou des services nécessaires au bon fonctionnement des applications. Ces duplications consomment des ressources, et diminuent l’efficience.
- la performance des applications : En effet, celles-ci ne sont pas toujours optimisées pour tourner sur les plateformes prévues. On peut se retrouver avec des applications plus gourmandes que prévues, dont les requêtes peuvent être optimisées.
Améliorer l’efficience
On est donc en droit de se demander comment, en prenant en compte les 4 enjeux mentionnés, améliorer son efficience.
Tout d’abord, profiter d’être dans un contexte Cloud permet de bénéficier des avantages de “l'élasticité” que cela offre, afin de choisir parmi le type et le nombre d’instances à utiliser suivant votre charge, de les stopper si elles ne sont plus utilisées, et de programmer un arrêt de ces instances dans certaines plages horaires.
Pour se faire, il existe plusieurs mécanismes tels que l’autoscaler, l’utilisation de containers, Karpenter pour un contexte Kubernetes, ou encore le serverless, où les ressources sont allouées uniquement le temps de l’exécution de la fonction.
Ensuite, maximiser l’utilisation de ressources disponibles sur chaque instance. Lorsqu’une instance est déployée, l’entièreté de ses ressources compute ne sont pas utilisées, alors que celles-ci sont facturées, ce qui nuit à l’efficience. Il est nécessaire de connaître les besoins en ressources de ses applications afin de choisir la bonne taille d’instances parmi les 850 types proposés par AWS.
Suivre les recommandations AWS en matière de choix d’instances améliore l’efficience, et notamment dans le choix d’instances équipées de processeurs Graviton.
Graviton, un processeur développé par AWS qui se base sur une architecture arm64. Ce processeur permet de gagner jusqu’à 40% en performance pour le même nombre de CPU, pour des instances Graviton qui sont jusqu’à 20% moins chères et améliorent l'empreinte carbone puisque ces instances équipées de processeurs Graviton sont jusqu’à 60% plus écologiques que leur équivalent équipées d’autres processeurs.
Enfin, privilégier l'utilisation de spot instances plutôt que des saving plans, reserved où on-demand. Bien que les spot instances peuvent être récupérées à tout instant par AWS, elles restent intéressantes pour des applications stateless et permettent d'obtenir une réduction des coûts de l'utilisation de ces ressources allant jusqu'à 90%.
Appliquer ces 5 recommandations améliore les performances applicatives tout améliorant l’efficience. Cependant cela implique de changer l’existant. Si vos composants ne sont pas compatibles avec un environnement conteneurisé, ou que vos applications ont besoin de communiquer avec un processeur particulier, il peut être compliqué de tirer bénéfices des points abordés précédemment. Enfin, même si votre environnement est compatible avec l’utilisation de Graviton et de Kubernetes, gérer une flotte d’instances pour votre cluster, dans les bonnes dimensions, flexible et scalable est en soit un défi au quotidien.
L'intérêt de Karpenter pour améliorer l’efficience
C’est dans ce contexte qu’intervient Karpenter, un projet créé par AWS et aujourd’hui, opensource, dont l’objectif est de faciliter la gestion du cycle de vie des nœuds de clusters Kubernetes. Grâce à des fonctionnalités spécifiques, cet outil permet de réduire les coûts en optimisant la gestion des nœuds, tout en augmentant la disponibilité des applications car fournit une capacité de mise à l’échelle plus rapide qu’un cluster autoscaler.
Tout comme le cluster autoscaler, Karpenter communique avec les services EC2 pour provisionner des instances, à la différence près qu’il ne communique pas avec l’autoscaling groupe. Cette différence permet plus de flexibilité dans le choix des instances. Où, avec le cluster autoscaler on ne pouvait créer que des nœuds d’un même type, Karpenter lui sélectionne, grâce à des filtres qu’on lui donne, le meilleur type d’instance pour le contexte dans lequel la montée en charge doit se faire.
Karpenter bénéficie également d’une fonctionnalité appelée “la consolidation” qui est en grande partie la raison pour laquelle cet outil est de plus en plus populaire. La consolidation permet à Karpenter d’identifier la quantité de ressources utilisées sur chaque noeud, et de déplacer de façon optimisée les conteneurs d’un noeud à l’autre afin de maximiser la quantité de ressources utilisées sur chaque noeud, et de décommissionner les noeuds sur lesquels il n’y a plus de conteneurs.
Cette action vise donc à optimiser le nombre d’instances présentes dans un cluster, tout en s’assurant que les ressources mises à disposition dans celles-ci soient utilisées de façon maximale. Pendant cette opération, Karpenter peut également décider de modifier la taille des instances afin de correspondre au maximum à la consommation réelle des applications présentes dans le cluster.
Cet outil facilite également la gestion des spot instances. Capable de détecter automatiquement les notifications de décommissionnement des spots instances, ce dernier anticipe l’arrêt d’un nœud en faisant sur un court instant de l’overprovisionning afin de déplacer les conteneurs sur une nouvelle instance avant l’arrêt de l’instance ciblée. Presque transparente pour les utilisateurs, et automatique pour les administrateurs du cluster, cette capacité à anticiper la suppression de nœuds augmente la stabilité au sein du cluster tout en réduisant les coûts.
Agents IA, H Runner, de l’entraînement à l’inférence dans AWS
Speakers: Arturo Mondragon Cardenas, Inès Benito,Philippe Modard,
Ecriture: Hoang Nguyen NGUYEN
La startup française H, fondée en mai 2024 par Charles Kantor et Laurent Sifre, a présenté son approche innovante dans le développement d'agents IA (avec un investissement conséquent de 200 millions). Cette entreprise de 60 employés se concentre sur deux objectifs: développer des agents B2B/B2C comme produits et mener une recherche à long terme sur ce domaine.
H aborde les agents IA comme une évolution des assistants traditionnels vers l'automatisation des tâches. Runner H, leur produit phare, est un agent capable de naviguer sur le web de manière autonome. Il peut comprendre visuellement les interfaces, identifier les éléments interactifs et exécuter des actions pour atteindre des objectifs spécifiés par l'utilisateur.
HN commentaires: Les agents sont nombreux aujourd'hui qui peuvent faire la même chose: Exemple: Claude Code/Desktop avec les serveurs MCPs.
Pour créer ces agents, H a développé ses propres modèles de fondation sur AWS SageMaker HyperPod:
- Un LLM de seulement 2 milliards de paramètres, spécialisé dans la génération de code, le function calling, la prise de décision et la planification
- Un module de vision (+1 milliard de paramètres) pour l'interprétation des interfaces et l'identification des éléments cliquables
⠀Malgré leur taille relativement modeste, ces modèles spécialisés surpassaient des modèles généralistes plus volumineux lors de leur publication en novembre 2024.
HN commentaires: ça joue beaucoup sur le prix de fonctionnement et la vitesse des agents, plus le débit de tokens est élevé, plus ça exécute rapidement des tâches.
L'architecture d'entraînement repose sur AWS SageMaker HyperPod avec un orchestrateur Slurm, des nœuds de calcul équipés de GPU Nvidia H100 (8 par machine) et un système de priorités à trois niveaux. Cette infrastructure a permis à l'équipe d'exécuter environ 200,000 jobs en 10 mois, dont l'entraînement principal de leur LLM nécessitant 6,000 jours GPU de calcul distribué.
Pour le déploiement des modèles, H a privilégié SageMaker Inference Component pour son auto-scaling bidimensionnel et sa capacité de scaling à zéro, essentielle pour maîtriser les coûts des nombreux modèles en phase de test. Leur solution d'inférence a évolué d'un démarrage rapide avec TorchServe vers VLLM pour améliorer les performances avec des requêtes complexes incluant des images. Ils ont également implémenté un mécanisme de "résurrection" des modèles mis à l'échelle à zéro.
Les points forts de cette approche:
1 Spécialisation vs généralisation: L'approche de H, i.e de construire des modèles plus petits mais spécialisés, est particulièrement pertinente pour les agents qui doivent fonctionner avec des contraintes de ressources et de latence.
2 Infrastructure agile: L'utilisation des services AWS permet d'expérimenter rapidement différentes architectures d'agents et de passer à l'échelle au besoin.
3 Multimodalité nécessaire: La capacité de vision et d'interaction avec les interfaces utilisateur représentent une avancée significative par rapport aux agents purement textuels.
4 Optimisation des coûts: Le scaling à zéro et l'auto-scaling sont essentiels pour maintenir des coûts raisonnables dans un environnement de recherche et développement intensif.
⠀Leur équipe est très efficace pour avoir pu sortir un tel produit dans un temps aussi court. Cela démontre le potentiel de SageMaker pour accélérer les projets LLM en général, offrant un exemple inspirant d'innovation française dans le domaine de l'IA.
Sécurisez vos pipelines CI/CD pour les conteneurs
Speakers: Maxim Raya, Aurelien Marie
Ecriture: Sabrina SERRES
Lors de l’AWS Summit Paris, Maxime Raya et Aurélien Marie (Solutions Architects chez AWS) ont abordé le sujet de la sécurisation des pipelines CI/CD pour les conteneurs. Leur approche repose sur trois grandes étapes critiques : écrire, déployer, exécuter. Chaque étape comporte ses risques, et AWS propose des outils adaptés pour chacune de ces étapes.
1. Écrire : sécuriser des le code
La sécurité commence dès l’écriture du code, et c’est là qu’intervient Amazon Q Developer. Cet assistant basé sur la génération d’IA (genAI) développé par AWS s’intègre directement à l’IDE et analyse automatiquement tout le workspace.Il identifie les vulnérabilités, les explique de façon claire, et propose des corrections. Par exemple, si une fonction de hachage est jugée inefficace, Amazon Q suggère une alternative plus robuste. Il permet aussi de comprendre le fonctionnement du code avec la fonction "Explain", de corriger automatiquement les failles avec "Fix", ou encore de générer des tests unitaires via "Test". Grâce à la genAI, Amazon Q agit comme un véritable copilote, rendant la sécurité accessible dès la phase d’écriture.
2. Déployer : sécuriser la pipeline elle-même
Maxime Raya a bien insisté sur la distinction entre la sécurité dans la pipeline et la sécurité de la pipeline. Dans cette présentation, c’est cette seconde dimension qui est abordée. Il s'agit notamment de mettre en œuvre :
- le principe du least privilege
- la détection des modifications sur les pipelines
- des mécanismes d'intervention et de correctif
- la protection des données sensibles manipulées dans les flux
Un des outils clés pour sécuriser la phase de déploiement est le scan d’images via Amazon ECR. Ce service propose deux modes : un scan basique gratuit, déclenché au push ou manuellement, qui détecte les vulnérabilités système les plus courantes, et un scan avancé plus complet, basé sur Amazon Inspector.
Dans le cadre du scan avancé, un flux automatisé a été présenté: lorsqu’une image est poussée dans Amazon ECR, un événement est généré via EventBridge, qui déclenche le scan approfondi d’Inspector. Une Lambda analyse ensuite les résultats (CVE détectées) et décide d’accepter ou de rejeter l’image.
3. Exécuter : surveiller et corriger en production
Une fois le code en production il faut continuer à être vigilant et ils proposent d' évaluer en continu, appliquer les correctifs et surveiller les comportements suspects en utilisant Amazon GuardDuty. Ce service permet une surveillance des logs du control plane spécifique aux conteneurs, tout en couvrant un large éventail de ressources AWS : EC2, EKS, Lambda, S3, RDS, etc.
GuardDuty détecte les anomalies, les activités malveillantes ou inhabituelles et facilite une réponse rapide en production, un aspect crucial pour limiter l’impact d’éventuelles attaques.
Pour en savoir plus voici le replay d’une présentation similaire mais plus détaillée donnée au AWS re:Invent 2024 - Build trust in your CI/CD pipeline: Codify container security at scale qui aborde les points présentés plus haut.
Conclusion
C’est sans trop de surprise que le sujet principal de cette édition du AWS Summit 2025 a été l’IA Générative mais cette fois-ci, nous avons pu ressentir que les préoccupations des européens face à la guerre commerciale déclenchée par les Etats-Unis ne sont pas prises à la légère par AWS. Ses différents représentants veulent se montrer rassurant quant à leur capacité à répondre aux besoins des européens que ce soit en termes de sécurité, de coût et même de service. Cette préoccupation est également montrée par l'intérêt des sujets de conférence qu'ont choisit de voir nos consultants qui étaient pour beaucoup autour de la gouvernance et de la sécurité.
AWS Summit, à l'année prochaine !!
