Pas besoin de scripts ; juste des fichiers de configuration décrivant l’état des hôtes.

Telle était la promesse de CFEngine lorsqu’il émergea dans les années 90. Avec son langage dédié, l’outil devait faciliter la maintenance des environnements BSD et System V (UNIX) en les organisant en classes. Il s’agissait déjà de répondre à la fragmentation des systèmes d’information…

Dans les années 2000, Puppet et Chef sont arrivés sur le même créneau, chacun avec son langage basé sur Ruby. L’un et l’autre fonctionnaient en mode pull, le client contactant régulièrement le serveur pour récupérer la configuration. On ne parlait pas encore de DevOps, mais d’automatisation du travail des sysadmins.

Au début des années 2010, AWS pousse le templating JSON/YAML avec CloudFormation. Ansible décline le concept en playbooks. Terraform l’adopte avec son propre langage (HCL) et le porte à l’échelle de déploiements multifournisseurs.

Face aux limites des langages dédiés et de l’option « tout YAML » apparaissent des outils comme Pulumi, qui adaptent les langages impératifs (Go, Python…) à la gestion d’infrastructure.

La recette IaC déclinée sur l’observabilité…

Avec ce bagage, l’approche « as code » s’est développée sur d’autres pans des systèmes informatiques : documentation, sécurité, politiques organisationnelles… ou encore observabilité. Dashboards, alertes, logs, traces, métriques, SLO/SLI, etc. deviennent autant d’éléments « codifiés » sur le même plan que l’infra ; et, in fine, déployés en parallèle, avec un repo Git comme « source de vérité ».

Corollaire de cette convergence, l’observability as code (OaC) porte globalement les mêmes promesses que l’infrastructure as code (IaC). À commencer par les bénéfices de l’automatisation.
Sur le papier, outre la réduction du potentiel d’erreurs humaines, on a des configurations reproductibles favorisant la cohérence entre environnements et la mise à l’échelle dans le contexte d’architectures dynamiques (microservices, workloads IA). On crée par ailleurs une boucle de rétroaction avec l’IaC, en bénéficiant de la traçabilité de Git – lequel permet aussi, en théorie, une reconstruction rapide de la stack d’observabilité.

… avec un bouquet d’abstractions

En parallèle de leurs API, les principales solutions d’observabilité sont pilotables via Terraform, grâce à un provider. Elles proposent aussi d’empaqueter des configurations en charts Helm et d’utiliser des CRD pour définir des artefacts en tant qu’objets Kubernetes standards.

À cheval entre ces deux univers, il y a le projet Upjet. Celui-ci transforme les providers Terraform en providers Crossplane, tout en générant les contrôleurs de réconciliation et la documentation API avec des exemples de manifestes.

Du côté de Grafana, on expérimente actuellement une fonctionnalité Git Sync. Elle assure une synchronisation bidirectionnelle l’UI et le Git, avec la possibilité d’imposer que les changements réalisés sur l’interface passent par des PR. Pour le moment, certains artefacts ne sont pas pris en charge (alertes, panels…) et seul GitHub est géré (authentification par PAT uniquement).

Grafana a aussi, dans sa boîte à outils, un SDK Foundation orienté sur les langages à typage fort (on définit des dashboards en chaînant des appels de méthodes). Il a également une bibliothèque qui met en œuvre Jsonnet. Cette extension de JSON a été influencée par plusieurs langages de configuration utilisés chez Google. Elle facilite les regroupements logiques de configurations avec ajustement des variables à la volée pour contextualiser les artefacts.

À partir de Jsonnet, Prometheus a créé les mixins. Ce format encapsule des alertes/règles et des dashboards Grafana en compagnie du code avec lequel ils sont déployés.

Autre langage qui a ses racines chez Google : CUE (Configure, Unify, Execute). Il s’est en l’occurrence inspiré du langage utilisé pour configurer Borg, le prédécesseur de Kubernetes. En son cœur, une technique communément exploitée en linguistique informatique pour gérer grammaires et lexiques : l’unification de graphe. Types et valeurs sont fusionnés en un seul concept et ordonnés en une hiérarchie unique.
Associatif, CUE est aussi commutatif et idempotent : peu importe leur ordre, les valeurs produisent toujours le même résultat. On s’en servira typiquement pour la validation de schémas ou de données. Les types agissent alors comme des contraintes, réconciliables depuis plusieurs sources sans avoir à effectuer d’importations.

Des stacks open source aux plates-formes d’observabilité

À petite échelle, un pattern traditionnel de déploiement de l’OaC repose sur la pile open source* Prometheus/Grafana/Loki/Jaeger. Souvent en monorepo avec un dossier pour les artefacts d’observabilité, un déploiement Helm ou CI/CD simple et une synchro par Git Sync ou API/webhooks.

À un deuxième niveau, chaque équipe possède son repo et sa configuration d’observabilité (« You build it, you run it »). Le déploiement peut impliquer Kustomize. Cet outil de gestion intégré à Kubernetes se distingue de Helm en permettant de surcharger toute valeur d’une configuration de base.
À ce même niveau, on voit souvent apparaître une gestion GitOps (réconciliation automatisée avec Flux ou Argo CD). Et le recours au collecteur OpenTelemetry pour standardiser la collecte sans modifier la couche d’instrumentation.

Viennent ensuite les plates-formes d’observabilité. À ce niveau, les identités machine se généralisent dans les pipelines. Et, avec elles, les systèmes de promotion automatisée, le contrôle de cardinalité (liste blanche de tags, politiques d’échantillonnage avec des outils comme Cribl et Vector) voire l’exploitation d’eBPF.

« Tout le monde échantillonne la data. La seule raison pour laquelle on le fait, c’est le coût de stockage », explique à ce sujet Stéphane Estevez, EMEA Market Advisor observabilité chez Splunk. Sa société, poursuit-il, a l’avantage de la taille : « Par rapport à nos concurrents, nos économies d’échelle ne sont pas les mêmes. On peut se permettre d’être compétitif tout en garantissant toutes les données ».

Vodafone en est arrivé à ce dernier stade. Il a plus précisément mis en place des modules d’observabilité Terraform. Ses développeurs consomment en self-service (ils n’ont qu’à déclarer les variables) et peuvent les modifier par PR.
Vu le nombre de développeurs, de services et d’artefacts d’observabilité, il a fallu diviser le fichier d’état (Terraform mettait sinon 17 minutes à s’exécuter).

Accepter la codebase comme « source de vérité »

Que ce soit pour créer un dashboard lors d’un incident ou modifier des seuils afin de « faire taire » des alertes, dans une approche OaC, l’utilisation de l’UI soulève la question de la réconciliation avec la partie as code. Une des réponses consiste à n’autoriser que ce qui passe par cette dernière, au minimum en production. Une autre, à verrouiller les états pour éviter les corruptions.

« Si on pousse la logique OaC, il faut accepter que la source de vérité, c’est ce qui est dans la codebase », confirme Pejman Tabassomi, Field CTO EMEA de Datadog.

Quant à enrichir l’OaC avec du machine learning, ce n’est pas forcément si évident. IBM, qui a son Cloud Pak for AIOps (évolutions des outils de Tivoli), en témoigne par la voie d’Éric Cattoir. L’intéressé fait partie d’une équipe technique au niveau EMEA couvrant les sujets regroupés sous la marque IT Automation. « On a essayé de faire des modèles basés sur l’analyse des logs, explique-t-il. On s’est aperçu que cette fonctionnalité dépend beaucoup de la structure et de la stabilité des fichiers. Chez certains clients, ça a nécessité beaucoup de rééducation des modèles, car il y avait trop de variabilité entre leurs systèmes ».

* Dans le domaine de l’open source, le projet Perses, en sandbox à la CNCF, pousse une spécification ouverte pour la visualisation des données d’observabilité. Pour le moment, métriques Prometheus, traces Tempo, logs Loki et profilage Pyroscope. Il inclut un vérificateur statique, un opérateur Kubernetes et un CLI pour réaliser des actions dans les pipelines CI/CD. Des SDK Go et CUE implémentent l’approche « as code ».

Illustration principale © Aryan – Adobe Stock

The post De l’infra à l’observabilité, mille et une nuances « as code » appeared first on Silicon.fr.

La startup spécialisée dans la recherche par intelligence artificielle vient de conclure un accord stratégique avec Microsoft. Ce partenariat, qui pourrait redéfinir le marché du cloud, intervient dans un contexte de tensions avec Amazon.

— Permalien

Microsoft a publié ses résultats financiers pour le trimestre clos fin décembre 2025, et le contraste est frappant entre les scores de la division gaming… et le reste de la société ! Tandis que le groupe affiche une croissance solide portée par le cloud et l’intelligence artificielle, Xbox …

Lire la suite

Aimez KultureGeek sur Facebook, et suivez-nous sur Twitter

N'oubliez pas de télécharger notre Application gratuite iAddict pour iPhone et iPad (lien App Store)

---

L’article Résultats : Microsoft dépasse les 80 milliards de CA, mais la division gaming s’écroule est apparu en premier sur KultureGeek.

En ce moment, je me pose plein de questions, comme vous, j’imagine, concernant les choix importants qu’on nous demande de réaliser dans notre profession, avec une certaine pression, voire une pression certaine… Quelle solution matérielle choisir pour notre stockage primaire ? Quelle taille et quel type pour nos clusters Compute, et comment les dimensionner ? Quels environnements de sauvegarde ? Et comme si cela ne suffisait pas, il faut aussi choisir notre trajectoire en matière d’hyperviseurs et de logiciels d’administration …

— Permalink

OVHcloud pousse ses pions dans les labos et les campus européens via OCRE : moins de paperasse, plus de cloud, et un angle “souveraineté” qui tombe à pic. Au menu, une quarantaine de services, du PaaS et un discours data protection taillé pour les contraintes des institutions publiques. Cloud souverain et OCRE se croisent rarement […]

L’article OVHcloud intensifie ses efforts dans l’éducation et la recherche européenne est apparu en premier sur InformatiqueNews.fr.

Azure passe la seconde. Après avoir récemment lancé son CPU maison de seconde génération « Cobalt 200 », Microsoft a dévoilé cette semaine la seconde génération de son propre accélérateur d’inférence IA : le Maia 200. Et attention, ça décoiffe… Dans la bataille pour la suprématie de l’infrastructure IA, les hyperscalers ont compris qu’ils ne pouvaient plus dépendre […]

L’article Microsoft dégaine le Maia-200, son nouvel accélérateur IA maison est apparu en premier sur InformatiqueNews.fr.

Les services natifs du cloud provider pour les métriques et les alertes, OpenTelemetry pour les traces.

Un article paru il y a quelques semaines dans l’International Journal of Computer Techniques propose cette stratégie d’observabilité pour le serverless. On le doit à une ancienne de Microsoft, qui fut notamment directrice scientifique au sein de l’activité Azure AI.

Son analyse porte plus précisément sur un sous-ensemble du calcul sans serveur : le FaaS (functions as a service). Dans ces environnements, les ressources sont généralement éphémères, distribuées et à haute concurrence. Les points d’intégration peuvent par ailleurs être nombreux… et inclure des services managés « en boîte noire » qui exigent de l’instrumentation.

Natif, full OpenTelemetry ou hybride ?

Les conclusions n’ont pas valeur de vérité absolue : l’expérimentation a été effectuée à petite échelle – de sorte qu’on peut la reproduire en local ou dans un compte de test – et tous les paramètres étaient sous contrôle.

Le cas d’usage exploré reposait sur des traces synthétiques de type e-commerce. Le workflow – présenté uniquement à haut niveau – comprenait 4 étapes : passerelle API -> fonction A -> fonction B (appel HTTP à une API externe non spécifiée) -> DynamoDB. Il s’agissait d’y adosser diverses stratégies d’observabilité, en mesurant 4 indicateurs :

• Allongement médian de la durée d’exécution des fonctions
• Proportion de traces complètes
• Délai médian pour découvrir la cause racine sur des simulations d’erreurs à partir de la télémétrie disponible
• Coût par million de requêtes (base : tarification publique de X-Ray et CloudWatch + estimations pour un back-end Jaeger autohébergé)

La première stratégie évaluée reposait intégralement sur les outils d’observabilité d’AWS (CloudWatch pour métriques et alertes, X-Ray pour les traces). La deuxième était full OpenTelemetry. La troisième, hybride, associait CloudWatch (télémétrie pilotée par les SLO) et OpenTelemetry (back-end Jaeger/Tempo ou managé), avec un échantillonnage adaptatif.

	Overhead	Traces complètes	MTRC	Coût
Natif	9 – 12 ms	82 %	18 min	6,20 $
OTel	18 – 25 ms	95 %	9 min	4,80 $
Hybride	11 – 15 ms	93 %	10 min	5,10 $

 

La méthode native est celle qui entraîne le moins de surcharge. Mais elle produit le plus de traces incomplètes, sauf à ajouter de l’instrumentation. Et s’il simplifie l’exploitation, X-Ray implique un certain verrouillage (limites de portabilité et de conservation de la télémétrie).
En centralisant sur OpenTelemetry, les traces sont plus « riches ». Mais l’overhead augmente. Comme les coûts, en plus des compétences nécessaires.
L’approche hybride orientée SLO (on ne collecte en haute fidélité que pour les éléments critiques de ce point de vue) n’est ni la plus « légère », ni la plus précise, ni la plus économique. Mais elle constitue un compromis.

À consulter en complément, une étude universitaire qui pointe – et chiffre – divers facteurs techniques et contractuels générateurs de surcoûts sur les principales plates-formes serverless.

Illustration © Aryan – Adobe Stock

The post Serverless : faut-il privilégier l’observabilité native ? appeared first on Silicon.fr.

Capturer sélectivement des paquets réseau sans tout transmettre vers l’espace utilisateur : telle fut la première raison d’être de BPF (Berkeley Packet Filter). C’était dans les années 90, sur les systèmes UNIX-BSD. La technologie permettait, à l’appui d’un jeu d’instructions virtuel RISC-like et d’un interpréteur, d’injecter des programmes dans le noyau pour en étendre les capacités à l’exécution.

Les premiers usages au-delà du réseau avaient émergé au début des années 2010. À commencer par l’outil seccomp-bpf, servant à filtrer les syscalls. Les travaux de modernisation lancés dans ce contexte aboutirent à eBPF (extended BPF). Cette nouvelle incarnation fut intégrée à Linux en 2014. À la clé, entre autres, des instructions et des structures de données supplémentaires, davantage de registres, un compilateur JIT et des points d’attache additionnels pour les programmes. La promesse demeurait : apporter de l’extensibilité au kernel sans passer par des modules ou changer le code source.

Sur ce socle, des projets sont d’abord nés dans le domaine du traçage. Des couches d’abstraction ont pris corps en parallèle, comme la boîte à outils BCC (BPF Compiler Collection), associant front-end Python/Lua et back-end C pour faciliter l’écriture de programmes. Tandis que le compilateur fut intégré dans LLVM.

Cilium, une couche d’abstraction devenue référente

Facebook fut l’un des premiers à industrialiser eBPF, avec un équilibreur de charge L4 pour ses datacenters : Katran, aujourd’hui open source. La possibilité d’attacher eBPF très en amont sur le chemin de réception – en l’occurrence, au niveau du piote NIC – permet d’effectuer le load balancing à la source, sans NAT (paquets traités avant interception par le noyau).

Google a quant à lui contribué à faire avancer les choses dans le champ de la sécurité. Dans le cadre de l’extension de son offre Kubernetes vers les infrastructures sur site (sous les marques Anthos et GDC), il a donné naissance au framework BPF LSM. Celui-ci adapte le principe des modules de sécurité à l’écosystème eBPF, en permettant d’utiliser les mêmes hooks (points d’attache) que SELinux.

Pour rendre la technologie plus accessible, le projet Cilium fut lancé en 2016. Avec, pour le porter, une société aujourd’hui référente dans l’écosystème eBPF : Isovalent, qui appartient à Cisco depuis 2024. Il assurait initialement la mise en réseau de conteneurs. Dans ces environnements où les adresses IP tournent beaucoup, ses tables de hachage en ont fait une alternative plus « élastique » à Iptables/netfilter.

Et vint l’observabilité

Après la mise en réseau vint l’observabilité, favorisée par la multiplicité des points d’attache exploitables. En plus de ceux prédéfinis (appels système, entrées/sorties de fonctions, tracepoints…), on peut utiliser des sondes noyau (kprobes) et utilisateur (uprobes). Mais aussi des fonctions arbitraires, en les étiquetant. L’exécution est orientée événements : les programmes eBPF se déclenchent lorsque le noyau ou une application passe par ces hooks.

Ce modèle ouvre la porte à la collecte de données sans instrumentation (pas de modification du code des applications ou des agents d’observabilité) et consommant potentiellement moins de ressources système. Cilium l’implémente via une plate-forme intégrée : Hubble, qui cartographie les services et donne une visibilité des flux grâce aux identités de workloads. Il y a ajouté une brique pour sécuriser l’exécution : Tetragon, qui met en œuvre des politiques de contrôle d’accès sur les fonctions noyau, les syscalls, etc.

S’économiser l’instrumentation… dans certains cas

Datadog aussi a un usage assez transversal d’eBPF : analyse de performance des applications (Universal Service Monitoring), visibilité sur le trafic réseau (Cloud Network Monitoring), détection des menaces (Workload Protection), supervision d’intégrité des fichiers (application de règles pour limiter les envois)…

« Sans eBPF, on aurait probablement besoin de consentir un effort de modification de la configuration des agents », fait remarquer Pejman Tabassomi, Field CTO EMEA, concernant le monitoring réseau. Sur la partie APM (surveillance des performances des applications), l’approche traditionnelle d’instrumentation « permet d’aller loin dans les détails, mais c’est contraignant parce qu’on est dépendant d’un framework ou d’un runtime », explique l’intéressé. eBPF « permet d’arriver à un objectif par tout à fait identique mais comparable, sans avoir à recourir à une librairie », déclare-t-il.

Pas tout à fait identique, donc. « Il y a une sorte de compromis entre le niveau d’introspection et la facilité de mise en œuvre », résume Pejman Tabassomi. Il l’illustre par un cas d’observation des temps de réponse entre deux services. Pour mesurer le nombre et la durée des appels, eBPF peut suffire. En revanche, s’il y a besoin de comprendre les lignes de code qui peuvent poser problème, les appels de fonctions et de méthodes qui sont en cause, « à ce moment-là, on va plutôt faire de l’APM. » Non sans surveiller des initiatives communautaires tel le profiler de code en cours de développement dans l’univers OpenTelemetry.

Chez Splunk, « l’histoire avec eBPF a démarré lors du rachat de Flowmill » en 2020, fait savoir Stéphane Estevez, EMEA Market Advisor pour l’observabilité. Cet outil de monitoring réseau a alimenté la stratégie « full OpenTelemetry » de l’éditeur. « Être chez Cisco nous a donné l’accès à Isovalent pour l’observabilité et la sécurité », précise Stéphane Estevez. Tetragon, par exemple, alimente des dashboards TCP et DNS dans la composante Network Explorer.

Chez IBM, Instana est le principal terrain d’implémentation d’eBPF. La technologie présente une utilité particulière pour la détection des crashs système, selon Éric Cattoir, membre d’une équipe au niveau EMEA qui couvre les sujets regroupés sous la bannière IT Automation. En écho à Pejman Tabassomi, il déclare, sur le volet instrumentation : « Ça rend la vie plus facile pour notre produit : on a moins à suivre l’évolution des technologies (nouvelles versions de langages, de compilateurs…) ». Instana a toujours eu une approche d’auto-instrumentation, rappelle-t-il, « mais c’est difficile à mettre en place pour certains langages : eBPF facilite cela en permettant d’obtenir de manière standard des informations de profilage ».

On trouve aussi de l’eBPF dans le produit SevOne (observabilité réseau), pour la couche overlay de Kubernetes.

Des programmes composables et portables

Avec les années, les programmes eBPF sont devenus composables : ils peuvent appeler des fonctions (forme de gosub)… et d’autres programmes en remplaçant le contexte d’exécution (goto). Un mécanisme CO-RE (« Compile Once, Run Everywhere ») a été instauré à partir d’un format spécifique de métadonnées (BTF, BPF Type Format) pour procurer une portabilité entre les versions du kernel. Et des passerelles se sont créées avec l’espace utilisateur, à travers une des structures de données que gère eBPF : les magasins clé-valeur dits maps. Des outils sont par ailleurs apparus pour exécuter des programmes en userspace (rBPF, uBPF, bpftime). Ils ont accompagné l’émergence de langages de jaut niveau tel bpftrace – inspiré de DTrace, avec LLVM en back-end et BCC pour interagir avec le sous-système eBPF.

Sauf à activer le mode sans privilèges avec accès limité au noyau, les processus qui chargent des programmes eBPF doivent s’exécuter en mode admin ou avoir la capacité CAP_BPF. La mémoire est protégée en lecture seule et les accès sont masqués pour limiter les effets secondaires observables de l’exécution spéculative. Si une entité tente de modifier le programme, le noyau plante.

Le code passe dans tous les cas par un vérificateur statique. Lequel contrôle, en particulier, que le programme est d’une complexité finie, qu’il se terminera bien et qu’il n’entraînera pas de deadlock ni d’accès mémoire hors limites. Dans la pratique, l’outil reste sujet aux faux positifs. Jusqu’à Linux 5.3, les boucles étaient d’ailleurs proscrites dans les programmes eBPF, le vérificateur étant jugé capable de les évaluer efficacement.

Une fondation où convergent les Big Tech

Depuis 2021, il existe une Fondation eBPF. Google, Meta et Isovalent en sont membres platine. CrowdStrike – qui exploite la techno pour détecter les mouvements de données non autorisés – l’est aussi. Ainsi que Huawei, Intel, Microsoft – qui développe eBPF pour Windows tout en l’exploitant en remplacement du fournisseur d’événements AuditD dans Defender pour Linux – et Red Hat. Datadog est membre argent. Netflix, qui avait pris très tôt le train eBPF, l’est aussi.

Conjointement aux initiatives du marché, cette fondation soutient des projets académiques, à l’instar d’eBPF Governor, alternative aux sous-systèmes de gestion de l’alimentation sur Linux. Des recherches sont également en cours sur la vérification formelle des programmes, en complément à la réécriture du vérificateur en Rust.

Plusieurs projets devenus référents dans l’écosystème eBPF sont maintenant sous l’aile de la CNCF (Cloud Native Computing Foundation). Outre Cilium, on peut citer Falco (détection de menaces), confié en 2018 par Sysdig. Dans le champ de l’observabilité, il y a Pixie, que New Relic a reversé à la CNCF en 2021, quelques mois après en avoir fait l’acquisition (il en propose aujourd’hui une version SaaS).

Pièce maîtresse du réseau mondial de Cloudflare, eBPF a aussi investi les clouds hyperscale. À l’instar de Google sur GKE, AWS s’en sert sur son Kubernetes managé (Caretta pour la cartographie réseau, Hubble pour l’analyse du trafic). Il l’a aussi intégré dans CloudWatch (composante Network Flow Monitor) et de GuardDuty (EC2 Runtime Monitoring). Microsoft l’exploite pour contourner Iptables sur les data planes de offre AKS (Azure Kubernetes Services).

Pour le monitoring, Dynatrace a choisi de s’appuyer sur Inspektor Gadget, framework CNCF qui encapsule les programmes eBPF sous forme d’images OCI. Il le met à contribution dans un module de découverte de services.

Chez Elastic, eBPF alimente le profilage continu, ainsi que la protection de Linux et de Kubernetes dans le cadre de l’offre SIEM/XDR.

Illustration principale © kwanchaift – Adobe Stock

The post Observabilité : eBPF, un atout dans la main des DevOps appeared first on Silicon.fr.

La Commission européenne travaillerait sur un nouveau cadre législatif visant à renforcer la souveraineté technologique de l’Union, dans un contexte de tensions commerciales croissantes avec les États-Unis. Selon plusieurs responsables européens, l’objectif ne serait pas d’exclure les entreprises américaines du marché européen, mais de réduire les dépendances stratégiques …

Lire la suite

Aimez KultureGeek sur Facebook, et suivez-nous sur Twitter

N'oubliez pas de télécharger notre Application gratuite iAddict pour iPhone et iPad (lien App Store)

---

L’article L’Union européenne prépare une riposte numérique face aux géants technologiques américains est apparu en premier sur KultureGeek.

Running modern versions of Adobe Photoshop on Linux has long been difficult, mainly because the installation process depends on Adobe Creative Cloud, which has historically failed to work properly through Wine. That situation may now be changing. According to a recent update shared by an independent developer known as PhialsBasement, Photoshop 2021 and 2025 can now be installed and run on Linux in a stable way, thanks to a set […]

Après une journée difficile, Microsoft confirme le rétablissement de ses services cloud ce vendredi, malgré quelques lenteurs résiduelles possibles durant les opérations de maintenance.

Cet article Microsoft 365 : fin de la panne géante pour Outlook et Teams est apparu en premier sur Linformatique.org.

« Et puis il y a eu ce post LinkedIn qui a attiré l’attention d’Octave Klaba […] »

Jérôme Masurel, président de 50 Partners, contextualise ainsi l’acquisition de SEALD par OVHcloud. L’accélérateur connaît bien cette entreprise francilienne : il avait participé, en 2018, à sa levée d’amorçage.

Depuis lors, SEALD est resté sur le même créneau : le chiffrement de bout en bout. Sa technologie se décline en logiciels bureautiques et sous forme de SDK. Elle avait obtenu le visa CSPN en décembre 2020 (trois ans de validité).

Les premières briques de SEALD posées en Californie

Créé en 2016, SEALD s’est d’abord appelé STASH. Ce pendant quelques semaines, le temps qu’une agence marketing française portant le même nom lui adresse une mise en demeure.

Les quatre fondateurs étaient alors dans leur vingtaine. Trois d’entre eux avaient convergé à UC Berkeley, dans le cadre d’un programme en partenariat avec l’École polytechnique. Les jalons de SEALD furent posés sur place par Timothée Rebours (32 ans aujourd’hui), qui prendrait la présidence de l’entreprise. Aux côtés de trois directeurs généraux : Mehdi Kouen (33 ans, CTO), Maxime Huber (34 ans, CPO) et Dan Lousqui (37 ans, directeur de la sécurité informatique).

Quelques semaines avant l’obtention de la CSPN, SEALD avait fait partie des finalistes du prix de l’innovation des Assises de la sécurité. Plus récemment (2023), il a figuré dans les lauréats de l’appel à projets « Suites bureautiques collaboratives cloud », en consortium avec Linagora, WaToo, Wimi et XWiki. Entre-temps, il y avait eu une alerte : une continuation d’activité malgré la perte de la moitié du capital.

Framatome et Stellantis comme références

La déclinaison « bureautique » de SEALD est basée sur une application desktop (Windows, Mac, Linux) qui permet de chiffrer des fichiers, d’assurer leur suivi et de contrôler les accès. La technologie couvre aussi les e-mails et leurs pièces jointes, en éventuelle conjonction avec les moteurs de DLP.

La version « bibliothèque logicielle » permet d’intégrer du chiffrement côté client dans des apps web, mobiles et de bureau. La promesse par rapport aux bibliothèques open source : supprimer les difficultés de gestion des clés, des appareils multiples, des droits d’accès sur les données, etc. Des SDK sont disponibles pour JavaScript, Android, iOS et Flutter.

Framatome y a fait appel pour sécuriser une application interne collectant des données sensibles. L’opérateur télécoms belge Proximus, pour une application de téléconsultation médicale (Doktr). Recare, pour son outil de bed management (orchestration des transferts interhospitaliers). Lovehoney Group, pour protéger une messagerie de couple basée sur CometChat. Stellantis et Lefebvre Sarrut font aussi partie des clients.

Le ticket d’entrée est à 250 €/mois pour 5000 utilisateurs protégés. Au-delà, SEALD facture un supplément dégressif par utilisateur (0,04 €jusqu’à 20 000 ; 0,03 € jusqu’à 50 000 ; 0,02 € au-delà).

« Ensemble, nous allors démocratiser [la] sécurité dans les services [collaboratifs] (et pas que…) », commente Octave Klaba.

Illustration générée par IA

The post SEALD absorbé par OVHcloud : ce qu’apporte cette acquisition appeared first on Silicon.fr.

Hausse tarifaire subie, migration impossible, verrou contractuel, fournisseur incontournable… La dépendance numérique est une réalité devenue ingouvernable. Il est temps que cela change. L’Indice de résilience numérique veut concrétiser cette dépendance sous forme de score comparable, veut transformer ces “accidents” en risques pilotables, ramener la quête d’autonomie à une quête de résilience menée grâce à […]

L’article Un « Indice de Résilience Numérique » (IRN) pour comprendre et piloter ses dépendances technologiques est apparu en premier sur InformatiqueNews.fr.

Au tour d’Argo et de cert-manager de dépasser les 50 % de taux d’usage en production.

C’est tout du moins ce que donne à voir le dernier sondage annuel de la CNCF (Cloud Native Computing Foundation). L’échantillon comprend 628 répondants, interrogés en septembre 2025.

L’édition précédente avait recueilli 750 réponses à l’automne 2024. Six projets CNCF dépassaient alors les 50 % de taux d’usage en production : Kubernetes, Helm, etcd, Prometheus, CoreDNS et containerd.

Les 10 projets de l’écosystème Kubernetes les plus utilisés en production

34 projets ont désormais atteint le plus haut stade de maturité à la CNCF. Le sondage s’en est tenu au 30 premiers à y être arrivés (de Kubernetes en mars 2018 à CubeFS en décembre 2024).

	Taux d’usage en prod 2024	Taux d’usage en prod 2025	Évolution	Nature du projet	Sandbox	Incubation	Gradué
Kubernetes	85 %	87 %	+ 2 pts	Orchestrateur de conteneurs		Mars 2016	Mars 2018
Helm	77 %	81 %	+ 4 pts	Gestionnaire de paquets		Juin 2018	Mai 2020
etcd	70 %	81 %	+ 11 pts	Magasin clé-valeur distribué		Décembre 2018	Novembre 2020
Prometheus	73 %	77 %	+ 4 pts	Monitoring		Mai 2016	Août 2018
CoreDNS	59 %	76 %	+ 17 pts	Serveur DNS	Février 2017	Février 2018	Janvier 2019
containerd	62 %	74 %	+ 12 pts	Runtime		Mars 2017	Février 2019
cert-manager	48 %	58 %	+ 10 pts	Gestionnaire de certificats TLS	Novembre 2020	Septembre 2022	Septembre 2024
Argo	43 %	52 %	+ 9 pts	Déploiement GitOps		Mars 2020	Décembre 2022
Fluentd	39 %	41 %	+ 2 pts	Journalisation		Novembre 2016	Avril 2019
Istio	31 %	36 %	+ 5 pts	Maillage de services		Septembre 2022	Juillet 2023

Les projets classés 11 à 20

	Taux d’usage en prod 2024	Taux d’usage en prod 2025	Évolution	Nature du projet	Sandbox	Incubation	Gradué
CRI-O	25 %	34%	+ 9 pts	Interface de runtime		Avril 2019	Juillet 2023
Envoy	22 %	33 %	+ 11 pts	Proxy		Septembre 2017	Novembre 2018
Harbor	20 %	32 %	+ 12 pts	Registre	Juillet 2018	Novembre 2018	Juin 2020
Cilium	20 %	29 %	+ 9 pts	Mise en réseau		Octobre 2021	Octobre 2023
Open Policy Agent	18 %	25 %	+ 7 pts	Moteur de politiques	Mars 2018	Avril 2019	Janvier 2021
Flux	17 %	23 %	+ 6 pts	Déploiement GitOps	Juillet 2019	Mars 2021	Novembre 2022
Jaeger	14 %	22 %	+ 8 pts	Traçage distribué		Septembre 2017	Octobre 2019
KEDA	16 %	22 %	+ 6 %	Autoscaler piloté par les événements	Mars 2020	Août 2021	Août 2023
Falco	8 %	13 %	+ 5 pts	Détection d’intrusions	Octobre 2018	Janvier 2020	Février 2024
Rook	6 %	12 %	+ 6 pts	Orchestration du stockage	Janvier 2018	Septembre 2018	Octobre 2020

Les projets classés 21 à 30

	Taux d’usage en prod 2024	Taux d’usage en prod 2025	Évolution	Nature du projet	Sandbox	Incubation	Gradué
Linkerd	8 %	11 %	+ 3 pts	Maillage de services	Janvier 2017	Avril 2018	Juillet 2021
CloudEvents	5 %	9 %	+ 4 pts	Spécification pour la description de données d’événements	Mai 2018	Octobre 2019	Janvier 2024
KubeEdge	6 %	5 %	– 1 pt	Kubernetes pour l’edge	Mars 2019	Septembre 2020	Septembre 2024
SPIFFE	5 %	5 %	=	Framework de gestion des identités	Mars 2018	Octobre 2019	Janvier 2024
Dapr	3 %	5 %	+ 2 pts	Runtime piloté par les événements		Novembre 2021	Octobre 2024
CubeFS	2 %	3 %	+ 1 pt	Stockage distribué	Décembre 2019	Juin 2022	Décembre 2024
SPIRE	3 %	3 %	=	Mise en œuvre de référence de SPIFFE	Mars 2018	Juin 2020	Août 2022
Vitess	1 %	3 %	+ 2 pts	Base de données compatible MySQL		Février 2018	Novembre 2019
TUF	2 %	2 %	=	Framework de sécurisation des systèmes de mise à jour logicielles		Octobre 2017	Décembre 2019
TiKV	1 %	2 %	+ 1 pt	Base de données clé-valeur		Août 2018	Septembre 2020

Pour quelques projets, le taux d’expérimentation (pilotes/tests) a aussi augmenté. En tête de liste :

• KEDA (+ 5 pts, à 16 %)
• Open Policy Agent (+ 3 pts, à 20 %)
• Harbor (+ 3 pts, à 12 %)

À consulter en complément sur le sujet Kubernetes :

Les premières distros Kubernetes « certifiées IA »
L’arrivée à maturité de Knative, couche serverless pour Kubernetes
Les choix de Databricks pour le load balancing Kubernetes
Michelin a réinternalisé son Kubernetes après 3 ans chez VMware

The post Kubernetes : les projets CNCF les plus déployés en production appeared first on Silicon.fr.

La principale contrainte pour traiter des données à haut débit n’est plus le calcul ni le stockage, mais le réseau.

En 2017, les équipes d’AWS avaient contextualisé ainsi un article présentant les choix de conception de la base de données Aurora, lancée deux ans plus tôt.

Voilà cet article cité dans un autre, émanant de l’université technique de Munich. Ses auteurs ont analysé l’évolution des spécifications matérielles du cloud public entre 2015 et 2025. S’ils mentionnent le cas Aurora, c’est parce que, selon eux, le postulat d’alors ne tient plus. Sur la période en question, à coût normalisé, la bande passante réseau proposée par AWS a crû sans commune mesure avec les performances CPU et NVMe. Dans ce contexte, Aurora, conçu pour minimiser le trafic réseau, gagnerait peut-être à être réarchitecturé…

Une analyse axée bases de données

L’analyse n’est pas exhaustive, reconnaissent ses auteurs.

En premier lieu, elle est centrée sur les instances EC2 d’AWS, malgré quelques éléments de comparaison avec d’autres clouds publics et avec les infrastructures sur site.

Ensuite, elle se focalise sur un cas d’usage « base de données ». Aussi, les instances avec accélérateurs et FPGA ont été exclues. Et celles dotées de GPU ont été abordées séparément. N’ont pas non plus été prises en compte les instances à capacité extensible (familles T et flex).

Quant aux prix, la tarification retenue est celle à la demande dans la région us-east-1 (la principale du cloud AWS, et la moins chère). Les instances Spot ne sont pas entrées en ligne de compte en raison de leurs tarifs très variables en fonction de la demande. Les savings plans et les instances réservées n’ont pas non plus été inclus, au motif que les remises sont « largement similaires » entre types d’instances (en les retirant, on ne distord donc pas significativement la structure tarifaire d’ensemble).

L’aspect optimisation logicielle a par ailleurs été laissé de côté.

Ces restrictions appliquées, le périmètre d’analyse a englobé 742 instances, groupées en 98 familles.

CPU : une stagnation pas spécifique aux cloud providers

Comme pour les serveurs on-prem, la gamme de CPU s’est nettement diversifiée en 10 ans. En première ligne, les puces Arm : depuis 2024, plus de la moitié des instances que lance AWS sont équipées en Graviton.
En parallèle, le nombre de cœurs a largement augmenté. Exemple : la famille c4, lancée en 2015, en proposait jusqu’à 18, quand la c7a, introduite en 2023, monte à 192.

La progression du ratio coût-performance se révèle plus limitée. En tout cas sur la foi de trois benchmarks, exécutés sur diverses instances 2xlarge optimisées pour le calcul :

• SPECint 2018
• TPC-H in-memory (facteur d’échelle de 10) sur Umbra
• TPC-C sur Leanstore (25 entrepôts)

Les résultats sont normalisés par rapport au coût et à la performance de l’instance c4.2xlarge. Bilan : sur SPECint, le ratio est multiplié par 3 environ sur la période. On serait plutôt à x2 sans les instances Graviton, vers lesquelles ont d’ailleurs basculé des fournisseurs comme Snowflake.
Sur la partie base de données in-memory,  la progression est similaire (entre x2 et x2,5). La latence de la mémoire et du cache a possiblement beaucoup d’influence, reconnaissent les auteurs de l’étude, qui n’ont pas analysé ces dimensions.

Cette relative stagnation n’apparaît pas pour autant liée aux marges que prennent les cloud providers. En tout cas sur la foi d’une analyse sur les CPU serveur d’AMD sortis entre 2017 et 2025. Sur la base des prix publics, du nombre de cœurs, des fréquences d’horloge et des métriques IPC communiquées, le rapport coût-performance ne double même pas (x 1,7).

Mémoire : peu de gains en capacité comme en bande passante

À coût normalisé, la capacité de DRAM a très peu progressé. Seul changement majeur : l’introduction, en 2016, d’une famille d’instances optimisées pour la mémoire, avec environ 3,3 fois plus de GiB-heures/$ que les meilleures instances optimisées pour le calcul.

La bande passante absolue par socket mono-CPU a significativement augmenté (de 93 à 492 GiB/s). Mais une fois normalisée, le gain n’est que de x2.

Un bond en avant sur le réseau… avec les instances optimisées

En valeur absolue, le plafond de bande passante sur EC2 est passé de 10 Gbit/s en 2015 à 600 Gbit/s en 2025. Surtout, le rapport coût-performance normalisé a décuplé. En toile de fond, la mise à disposition d’instances optimisées pour le réseau. La c5n, première du genre basée sur le système Nitro, fut ajoutée au catalogue en 2018.

Si on exclut ces instances optimisées, le rapport bande passante par dollar a peu évolué entre 2015 et 2025.

Stockage : comparaison défavorable pour AWS

L’analyse s’est focalisée sur les instances avec stockage NVMe local. La première famille du genre (i3) fut introduite en 2016. La première avancée notable en termes de capacité de stockage par dollar fut le lancement de la famille i3en en 2019. Le ratio avait alors doublé. Il a peu évolué depuis.
Même réflexion si on considère le coût des I/O : les i3 demeurent les plus avantageuses, tant en lecture séquentielle qu’aléatoire.

Cette stagnation dans le cloud public contraste avec les tendances de l’on-prem : à coût normalisé, la capacité par dollar a triplé et le coût des I/O a été divisé par 5. L’arrivée de PCIe4 puis de PCIe5 a joué.

Des opportunités dans le hardware spécialisé

Un indicateur est ici analysé : le volume d’opérations 32 bits en virgule flottante à coût normalisé.

Avec les GPU, le rapport coût-performance a été multiplié par environ 4,7 entre les familles d’instances p3 et g6e.

Depuis 2019, AWS a lancé deux générations d’instances inf et trn dotées d’ASIC dédiés au machine learning. Les trn2 délivrent deux fois plus de flops/s par device que les g6e ; et le ratio coût-performance est multiplié par 15,7 par rapport aux p3.
La spécialisation du hardware peut donc se révéler avantageuse… y compris pour le traitement de données (l’étude fait référence à divers travaux* sur ce sujet).

Caches NVMe, cycles processeur… Des questions d’architecture émergent

Combinée à la démultiplication des débits réseau, la stagnation des performances du stockage pose des questions pour des solutions comme Snowflake, qui utilisent des caches NVMe plutôt que de lire directement sur S3.

Autre combinaison, autre enjeu : tandis que la bande passante réseau croît et que la vitesse des processeurs stagne, le budget en cycles CPU par paquet décline. Exploiter pleinement les ressources disponibles pourrait exiger des modifications majeures touchant par exemple au contournement du noyau.

Avec les instances Arm, l’amélioration du rapport coût-performance se constante autant sur le calcul (c8g) que sur le réseau (c8gn), la capacité mémoire (x2gd) et la capacité NVMe (is4gen).

Voir au-delà des hyperscalers

La tendance est la même dans les autres clouds… sauf que, de manière générale, les VM – Arm ou x86 – peuvent être notablement moins chères que chez les hyperscalers. Oracle et OVHcloud sont cités à ce sujet, sur la foi d’une comparaison pour des instances à CPU AMD 16 cœurs, 128 GiB de RAM et sans fonctionnalités spécifiques de type grande bande passante réseau. Hetzner l’est aussi, avec son instance CCX53, 3,7 fois moins chère que la m6a.8xlarge d’AWS. En contrepartie, ces fournisseurs ont un écosystème moins fourni, une couverture géographique plus limitée, une facturation parfois moins granulaire et un éventail plus restreint d’instances spécialisées (susceptibles de faire baisser les coûts pour certains cas d’usage).

Entre les « trois grands », il y globalement peu d’écart… avec quelques exceptions (AWS a l’avantage sur la bande passante réseau avec les instances c7gn/c8gn, Microsoft ne facture pas le trafic entre zones de disponibilité au sein d’une même région, etc.).

Un outil interactif pour dépasser l’analyse statique

Vu la nature multidimensionnelle de l’univers des instances cloud, une analyse statique est intrinsèquement limitée, admettent les auteurs de l’étude. Ils fournissent donc un outil interactif open source associant moteur SQL et visualisation R. Le service fonctionne intégralement dans le navigateur (pas de dépendance serveur). La base sous-jacente est téléchargeable (fichier DuckDB).

* Boeschen et al., 2024 : « GOLAP: A GPU-in-Data-Path Architecture for High-Speed OLAP »
Kabic et al., 2025 : « Powerful GPUs or Fast Interconnects: Analyzing Relational Workloads on Modern GPUs »
Wu et al., 2025 : « Terabyte-Scale Analytics in the Blink of an Eye »

Illustration générée par IA

The post Dans le cloud public, le rapport coût-performance stagne appeared first on Silicon.fr.

« Non, je ne peux pas le garantir ».

Ces quelques mots du directeur technique et juridique de Microsoft France avaient fait grand bruit en juin dernier. L’intéressé était auditionné au Sénat dans le cadre d’une commission d’enquête sur la commande publique. On venait de lui demander, en substance, s’il pouvait affirmer que les données des citoyens français confiées à son entreprise ne seraient jamais transmises, à la suite d’une injonction du gouvernement américain, sans l’accord explicite des autorités françaises.

AWS ne garantit pas non plus d’immunité totale avec son nouveau « cloud souverain européen ». Il prend, dans les grandes lignes, les mêmes engagements qu’avec son cloud commercial. D’une part, faire au mieux pour rediriger les requêtes gouvernementales directement vers les clients ou, sinon, les notifier autant qu’il est possible. De l’autre, contester ces requêtes s’il y a conflit avec la législation de l’UE ou d’un État membre. Et dans tous les cas, divulguer le strict minimum.

En principe, le contenu des clients et les métadonnées créées par leurs soins (rôles, autorisations, étiquettes de ressources, configurations) ne sortent pas de l’UE. Sauf si un client le demande… ou, donc, si c’est nécessaire pour répondre à une requête gouvernementale fondée.

De « résidents » à « citoyens » de l’UE : une politique RH en transition

Ce « contrat de confiance » lui a valu de décrocher la qualification C5 (le « SecNumCloud allemand ») en combinaison avec d’autres promesses. Parmi elles, l’autonomie opérationnelle : les systèmes et services critiques doivent pouvoir fonctionner même sans connectivité au backbone AWS. Un exercice sera réalisé au moins une fois par an, parallèlement à la définition de stratégies de réponse à incident (SOC dédié) et de reprise après sinistre (y compris en cas d’isolation géopolitique).

Le « cloud souverain européen » a des systèmes indépendants d’IAM, de facturation et de mesure de l’utilisation. Sur la partie réseau, les points de présence Direct Connect sont dans l’UE et l’instance Route 53 est dédiée, avec uniquement des TLD européens pour les serveurs de noms. Une extension territoriale est prévue via des zones locales AWS (Belgique, Pays-Bas, Portugal) qui seront connectées au datacenter principal sur réseau privé.

Tous les membres du personnel d’exploitation sont établis dans l’UE. Interpellé à ce sujet, AWS a entamé une transition pour dépasser cette notion de résidence, en introduisant un critère de citoyenneté dans son processus de recrutement.

Un préavis contractuel d’un an

Concernant les mesures techniques concourant à la « souveraineté », la journalisation est locale, comme les opérations cryptographiques et la gestion des certificats (ce cloud a sa propre racine de confiance). Les clés de chiffrement utilisées sur les services sont sécurisées au niveau logiciel ; celles destinées à la récupération après sinistre le sont au niveau physique (conservation hors ligne).

AWS conserve une réplique du code source nécessaire pour opérer les services. Cette réplique est chiffrée, soumise à des contrôles d’intégrité, cryptographiquement vérifée et mise à jour via un processus de réplication contrôlé.

Sauf si le client s’y oppose, les contrats sont gouvernés par les lois d’un État membre de l’UE. Préférentiellement l’Allemagne, semble-t-il, l’addendum de l’AWS European Sovereign Cloud invitant à s’adresser aux tribunaux de Munich en cas de litige.

On nous promet un préavis d’au moins un an avant toute modification importante des statuts de la société mère – de droit allemand et « contrôlée localement ». Sauf si cette modification est nécessaire pour se conformer à la législation applicable. Ou si le comité consultatif considère, à l’unanimité, que cela n’affecte pas significativement l’indépendance opérationnelle, les contrôles de résidence des données, les structures de gouvernance ou bien les obligations d’AWS.

Deux Français au comité consultatif…

À l’origine, on nous avait annoncé que ce comité se composerait de 4 membres, dont 1 non affilié à Amazon. Ils sont finalement 5, dont 2 non affiliés. Parmi eux, deux ressortissants français : Stéphane Ducable et Philippe Lavigne.

Stéphane Ducable est vice-président des politiques publiques d’AWS pour la région EMEA. Il fut membre fondateur du CISPE, au conseil d’administration duquel il représenta Amazon jusqu’en 2025. Ancien VP adjoint des affaires publiques chez Alcatel, il est aussi passé chez Microsoft. Entre autres comme responsable des affaires extérieures à Bruxelles, ainsi que directeur régional des affaires générales à Singapour puis au Japon).

Philippe Lavigne, général à la retraite, fut notamment chef d’état-major de l’armée de l’air et de l’espace (2018-2021) et commandant suprême allié pour la transformation de l’OTAN (2021-2024).

Les trois autres membres :

• Ian McGarry
  Ressortissant irlandais. Directeur d’Amazon CloudWatch chez AWS. Ancien d’Ericsson et d’Oracle.
• Sinead McSweeney
  Ressortissante irlandaise. Ancienne transcriptrice parlementaire puis conseillère politique au sein du Gouvernement (auprès du ministre de la Justice, notamment). Ensuite directrice des relations publiques pour le service de police d’Irlande du Nord. Puis, chez Twitter, responsable des politiques publiques EMEA puis monde.
• Barbara Scarafia
  Ressortissante allemande. Avocate de formation. Entrée chez Amazon en 1999 comme directrice juridique pour l’Allemagne. Aujourd’hui directrice juridique associée pour l’Europe.

… et un à la direction générale

La société mère a deux DG : Stéphane Israël et Stefan Hoechbauer. Le premier dirige les opérations. Le second supervise les décisions relatives à la gouvernance d’entreprise et à la conformité.

Stéphane Israël, 55 ans, arrive du Boston Consulting Group, où il aura passé moins d’un an.
L’intéressé fut d’abord auditeur puis conseiller référendaire à la Cour des comptes (2001-2007).
Chez EADS (2007-2012), il entra comme conseiller business du P-DG Louis Gallois et termina directeur du volet services du programme européen Copernicus au sein de la filiale satellites.
Directeur de cabinet d’Arnaud Montebourg en 2012-2013, il entra ensuite en fonction chez Arianespace (P-DG entre 2013 et 2017, puis président exécutif jusqu’en 2024). Il préside aujourd’hui la Fondation de l’ENS.

Stefan Hoechbauer, ressortissant allemand, est vice-président des ventes mondiales d’AWS pour l’Allemagne et l’Europe centrale. Il est un ancien de SAP, de PeopleSoft et d’Oracle. Ainsi que de Salesforce, où il fut vice-président exécutif et P-DG pour la zone DACH (Allemagne, Autriche, Suisse).

La nomination de Stéphane Israël avait été officialisée fin septembre 2025. Son binôme annoncé était alors Kathrin Renz. Mais l’ancienne de Siemens (directrice du développement, notamment) et de Nokia (présidente de la branche Enterprise, en particulier) a quitté AWS en décembre.

Illustration principale générée par IA
Portraits © DR, Amazon Web Services

The post Cloud européen d’AWS : la gouvernance et les engagements juridiques appeared first on Silicon.fr.

Une entité dédiée avec une gouvernance spécifique, du personnel résidant dans l’UE, une infrastructure capable de fonctionner pour l’essentiel sans connexion au backbone… Autant d’engagements qui viennent avec le nouveau « cloud souverain européen » d’AWS.

On pourrait s’attendre, dans ce contexte, à des prix plus élevés que pour les régions cloud commerciales. Il apparaît globalement que non, en tout cas par rapport à la région AWS Paris, sur la foi de la tarification publique. En voici une brève revue. Les comparatifs, notamment pour les instances, s’alignent sur la moins chère et la plus chère des options disponibles au catalogue du « cloud souverain européen » d’AWS. Pour la lisibilité, nous arrondissons au centime tout prix supérieur ou égal à 0,10 €/$.

Services de calcul

1. EC2

Les tarifs horaires listés ici valent pour des instances avec système d’exploitation Linux.

Instances à la demande

Type d’instance	Cloud souverain	Paris
Usage général	t4g.nano (2 vCPU + 0,5 GiB + EBS + 5 Gbit) : 0,0047 € m7i.48xlarge (192 vCPU + 768 GiB + EBS + 50 Gbit) : 11,44 €	t4g.nano : 0,0047 $ m7i.48xlarge : 11,29 $
Optimisé calcul	c6g.medium (1 vCPU + 2 GiB + EBS + 10 Gbit) : 0,0383 € c7i.48xlarge (192 vCPU + 384 GiB + EBS + 50Gbit) : 9,65 €	c7i.48xlarge : 10,18 $
Optimisé mémoire	r6g.medium (1 vCPU + 8 GiB + EBS + 10 Gbit) : 0,06 € r7i.metal-48xl (192 vCPU + 1536 GiB + EBS + 50 Gbit) : 15,12 €	r6g.medium : 0,06 $
Optimisé stockage	i4i.large (2 vCPU + 16 GiB + SSD NVMe 468 + 10 Gbit) : 0,20 € i4i.metal (128 vCPU + 1024 GiB + 8 SSD NVMe 3750 + 75 Gbit) : 12,93 €	i4i.large : 0,20 $ i4i.metal : 12,74 $

Instances dédiées à la demande

Type d’instance	Cloud souverain	Paris
Usage général	t3.nano (2 vCPU + 0,5 GiB + EBS + 5 Gbit) : 0,0059 € m7i.metal-48xl (192 vCPU + 768 GiB + EBS + 50 Gbit) : 11,44 €	t3.nano : 0,0059 $ m7i.metal-48xl : 11,29 $
Optimisé calcul	c6g.medium : 0,41 € c7i.metal-48xl (192 vCPU + 384 GiB + EBS + 50 Gbit) : 9,65 €	c6g.medium : 0,043 $ c7i.metal-48xl : 10,18 $
Optimisé mémoire	r6g.medium : 0,0636 € r7i.48xlarge (192 vCPU + 1536 GiB + EBS + 50 Gbit) : 15,12 €	r6g.medium : 0,063 $ r7i.48xlarge : 14,92 $
Optimisé stockage	i4i.large : 0,22 € i4i.32xlarge (128 vCPU + 1024 GiB + 8 SSD 3750 + 75 Gbit) : 12,92 €	i4i.large : 0,22 $ i4i.32xlarge : 12,74 $

 

2. Lambda

Version x86

– Sur l’offre de cloud souverain

Le Go-seconde est à 0,0000164477 €/mois pour les 6 premiers milliards ; à 0,0000148029 € pour les 9 milliards suivants ; à 0,0000131582 € au-delà.

Il faut ajouter 0,20 € par million de requêtes.

– Dans la région AWS Paris

Le Go-seconde est à 0,0000166667 $/mois pour les 6 premiers milliards ; à 0,000015 $ pour les 9 milliards suivants ; à 0,0000133334 $ au-delà.

Il faut ajouter 0,20 $ par million de requêtes.

Version Arm

– Sur l’offre de cloud souverain

Le Go-seconde est à 0,0000131582 €/mois pour les 7,5 premiers milliards ; à 0,0000118424 € pour les 9 milliards suivants ; à 0,0000105265 € au-delà.

Il faut ajouter 0,20 € par million de requêtes.

– Dans la région AWS Paris

Le Go-seconde est à 0,0000133334 $/mois pour les 7,5 premiers milliards ; à 0,0000120001 $ pour les 9 milliards suivants ; à 0,0000106667 $ au-delà.

Il faut ajouter 0,20 $ par million de requêtes.

3. Fargate

Version Linux/x86

– Sur l’offre de cloud souverain

0,0459480875 €/vCPU/heure et 0,0050428421 €/Go/heure

– Dans la région AWS Paris

0,0486 $/vCPU/heure et 0,0053 $/Go/heure

Version Linux/Arm

– Sur l’offre de cloud souverain

0,0367604437 €/vCPU/heure et 0,0040362474 €/Go/heure

– Dans la région AWS Paris

0,03888 $/vCPU/heure et 0,00424 $/Go/heure

4. EKS (Elastic Kubernetes Service)

Pour le support de la version standard de Kubernetes, il faut compter 0,098685 €/cluster-heure sur l’offre souveraine, contre 0,10 $ dans la région AWS Paris.

Pour le support étendu des versions de Kubernetes, c’est 0,59 €/cluster-heure sur l’offre souveraine, contre 0,60 $ dans la région AWS Paris.

Services de stockage

1. EBS

Volumes à usage général (gp3)

– Sur l’offre de cloud souverain

Stockage : 0,0939488388 €/Go-mois
IOPS : 3000 gratuites puis 0,0059211453 €/IOPS-mois
Débit : 125 Mo/s gratuits puis 0,047 €/Mo-mois

– Dans la région AWS Paris

Stockage : 0,0928 $/Go-mois
IOPS : 3000 gratuites puis 0,0058 $/IOPS-mois
Débit : 125 Mo/s gratuits puis 0,046 $/Mo-mois

Volumes provisionnés (io2)

– Sur l’offre de cloud souverain

Stockage : 0,15 €/Go-mois
IOPS : 0,077 €/IOPS provisionnées par mois jusqu’à 32 000 ; 0,054 € jusqu’à 64 000 ; 0,038 € au-delà

– Dans la région AWS Paris

Stockage : 0,15 $/Go-mois
IOPS : 0,077 $/IOPS provisionnées par mois jusqu’à 32 000 ; 0,053 $ jusqu’à 64 000 ; 0,037 $ au-delà

Volumes froids (sc1)

Sur l’offre souveraine : 0,0177634359 €/Go-mois de stockage provisionné.
Dans la région AWS Paris : 0,0174 $/Go-mois.

Snapshots

– Sur l’offre de cloud souverain

Standard : 0,0532903077 €/Go/mois (restauration gratuite)
Archive : 0,0133225769 €/Go/mois (restauration : 0,0319741846 € par Go)

– Dans la région AWS Paris

Standard : 0,053 $/Go/mois (restauration gratuite)
Archive : 0,01325 $/Go/mois (restauration : 0,0318 $ par Go)

2. EFS

Régional avec débit élastique

– Sur l’offre de cloud souverain

Stockage

0,36 €/Go-mois (Standard)
0,019737151 €/Go-mois (Standard avec accès peu fréquent)
0,0098685755 €/Go-mois (Archive)

Débit et accès

Lecture : 0,039474302 €/Go
Écriture : 0,0690800285 €/Go
Frais supplémentaires de 0,0118422906 €/Go en lecture pour l’accès peu fréquent ; de 0,0355268718 €/Go pour le niveau archive.

– Dans la région AWS Paris

Stockage

0,33 $/Go-mois (Standard)
0,02 $/Go-mois (Standard avec accès peu fréquent)
0,01 $/Go-mois (Archive)

Débit et accès

Lecture : 0,03 $/Go
Écriture : 0,07 $/Go
Frais supplémentaires de 0,011 $/Go en lecture pour l’accès peu fréquent ; de 0,033 €/Go pour le niveau archive.

Régional avec modes de débit hérités

– Sur l’offre de cloud souverain

Stockage

0,36 €/Go-mois (Standard)
0,0262504108 €/Go-mois (Standard avec accès peu fréquent)

Débit et accès

0,0592 €/Go-mois en sauvegarde tiède ; 0,0118 €/Go-mois à froid
Lectures en accès peu fréquent : 0,0118422906 €/Go-mois

– Dans la région AWS Paris

Stockage

0,33 $/Go-mois (Standard)
0,0261 $/Go-mois (Standard avec accès peu fréquent)

Débit et accès

0,055 $/Go-mois en sauvegarde tiède ; 0,011 $/Go-mois à froid
Lectures en accès peu fréquent : 0,011 $/Go-mois

3. S3

Niveau standard

Sur l’offre de cloud souverain
0,02417801 €/Go pour les 50 premiers To/mois
0,0231911524 € pour les 450 To suivants
0,0222042949 € au-delà

Dans la région AWS Paris
0,024 $/Go pour les 50 premiers To/mois
0,023 $/Go pour les 450 To suivants
0,022 $/Go au-delà

Intelligent tiering

En accès fréquent, les prix sont les mêmes qu’au niveau Standard. Pour le reste :

Sur l’offre de cloud souverain
Accès peu fréquent : 0,0133225769 €/Go
Archive : 0,0049342878 €/Go

Dans la région AWS Paris
Accès peu fréquent : 0,0131 $/Go
Archive : 0,005 $/Go

Requêtes de récupération

– Sur l’offre de cloud souverain

Niveau standard
PUT/COPY/POST/LIST : 0,005329 € par millier de requêtes
GET/SELECT : 0,0004243 € par millier de requêtes

Niveau standard avec accès peu fréquent
PUT/COPY/POST/LIST : 0,0085814 € par millier de requêtes
GET/SELECT : 0,0008581 € par millier de requêtes

– Dans la région AWS Paris

Niveau standard
PUT/COPY/POST/LIST : 0,005 $ le millier de requêtes
GET/SELECT : 0,0004 $ le millier de requêtes

Niveau standard avec accès peu fréquent
PUT/COPY/POST/LIST : 0,01 $ le millier de requêtes
GET/SELECT : 0,001 $ le millier de requêtes

4. AWS Backup

Les prix sont au Go-mois.

Sauvegarde

	Cloud souverain	Paris
Sauvegarde EFS	0,0592 € (à chaud) 0,0118 € (à froid)	0,55 $ (à froid) 0,11 $ (à chaud)
Instantané EBS	0,0533 € (à chaud) 0,0133 € (à froid)	0,053 $ (à chaud) 0,01325 $ (à froid)
Instantané base de données RDS	0,10 €	0,10 $
Instantané cluster Aurora	0,0223 €	0,022 $
Table DynamoDB	0,01208 € (à chaud) 0,0362 € (à froid)	0,011886 $ (à chaud) 0,03566 $ (à froid)
Backup S3	0,0592 € depuis le stockage tiède 0,0231911524 € depuis le stockage tiède à faible coût	0,055 $
Instantané cluster Redshift	0,02417801 € (50 premiers To) 0,0231911524 € (450 To suivants) 0,0222042949 € (au-delà)	0,024 $ (50 premiers To) 0,023 $ (450 To suivants) 0,022 $ (au-delà)

 

Restauration

	Cloud souverain	Paris
EFS	0,0237 € (tiède) 0,0355 € (froid)	0,022 $ (tiède) 0,033 $ (tiède)
EBS	Gratuit (tiède) 0,032 € (froid)	Gratuit (tiède) 0,0318 $ (froid)
RDS	Gratuit (tiède)	Gratuit (tiède)
Aurora	Gratuit (tiède)	Gratuit (tiède)
DynamoDB	0,1812 € (tiède) 0,2416 € (froid)	0,17829 $ (tiède) 0,23772 $ (froid)
S3	0,0237 € (tiède)	0,022 $ (tiède)
Redshift	Gratuit (tiède)	Gratuit (tiède)

Services d’analytique

1. Athena

Une fois n’est pas coutume, sur le prix des requêtes SQL, l’écart de prix est notable : 4,94 € par To analysé sur l’offre de cloud souverain, contre 7 $ dans la région AWS Paris.

2. Redshift

Sur l’offre de cloud souverain, le stockage managé revient à 0,0252635533 €/Go-mois. Il faut compter 0,025 $/Go-mois dans la région AWS Paris.

Sur l’offre de cloud souverain, il en coûte 4,94 €/To pour Spectrum. C’est 5,50 $/To dans la région AWS Paris.

3. Glue

Les tâches Spark / Spark Streaming, Python Shell et les sessions interactives coûtent 0,43 €/DPU-heure sur l’offre de cloud souverain.
Elles coûtent 0,44 $/DPU-heure dans la région AWS Paris.

Services d’IA

1. Bedrock

Modèles Nova

– Sur l’offre de cloud souverain

Deux modèles Amazon sont proposés : Nova Lite et Nova Pro.

Les tarifs de Nova Lite
Input : 0,0000769749 € pour 1000 jetons (0,0000192437 € depuis le cache ; 0,0000384874 € en batch)
Output : 0,0003078996 € pour 1000 jetons (0,0001539498 € en batch)

Les tarifs de Nova Pro
Input : 0,0010362004 € pour 1000 jetons (0,0002590501 € depuis le cache ; 0,000518002 € en batch)
Output : 0,0041448017 € pour 1000 jetons (0,0020724009 € en batch)

– Dans la région AWS Paris

Nova Lite : 0,000088 $ pour 1000 jetons d’entrée et 0,000352 $ pour 1000 jetons de sortie.

Nova Pro : 0,00118 $ en entrée et 0,00472 $ en sortie

Guardrails

– Sur l’offre de cloud souverain

Filtres de contenu et sujets refusés (niveau classique) : 0,26 € pour 1000 unités de texte
Filtres d’informations sensibles et vérification de l’ancrage contextuel : 0,17 € pour 1000 unités de texte

– Dans la région AWS Paris

Filtres de contenu et sujets refusés (niveau classique) : 0,15 $ pour 1000 unités de texte
Filtres d’informations sensibles et vérification de l’ancrage contextuel : 0,10 $ pour 1000 unités de texte

2. SageMaker AI

	Cloud souverain	Paris
JupyterLab	ml.t3.medium (2 vCPU + 4 GiB) : 0,056842995 €/heure ml.m7i.48xlarge (192 vCPU + 768 GiB) : 13,73 €/heure	ml.t3.medium : 0,057 $/heure ml.m7i.48xlarge : 13,55 $
Entraînement	ml.t3.large (2 vCPU + 8 GiB) : 0,11 €/heure ml.m7i.48xlarge : 13,73 €/heure	ml.t3.large : 0,11 $/heure ml.m7i.48xlarge : 13,46 $/heure
Inférence (temps réel)	ml.m6g.large (2 vCPU + 8 GiB) : 0,11 €/heure ml.m7i.48xlarge : 13,73 €/heure	ml.m6g.large : 0,22 $/heure ml.m7i.48xlarge : 13,46 $/heure

Services de sécurité/identité/conformité

1. KMS

– Sur l’offre de cloud souverain

Demandes impliquant des clés RSA 2048 : 0,03 € les 10 000
Demandes ECC GenerateKeyDataPair : 0,10 € les 10 000
Demandes asymétriques sauf RSA 2048 : 0,15 € les 10 000
Demandes RSA GenerateDataKeyPair : 12 € les 10 000

– Dans la région AWS Paris

Demandes impliquant des clés RSA 2048 : 0,03 $ les 10 000
Demandes ECC GenerateKeyDataPair : 0,10 $ les 10 000
Demandes asymétriques sauf RSA 2048 : 0,15 $ les 10 000
Demandes RSA GenerateDataKeyPair : 12 $ les 10 000

2. Secrets Manager

Sur l’offre de cloud souverain, c’est 0,39 €/secret-mois et 0,049343 € pour 10 000 appels API.
Dans la région AWS Paris, c’est 0,40 $/secret-mois et 0,05 $ pour 10 000 appels API.

3. WAF

	Cloud souverain	Paris
ACL web	4,93 €/mois	5 $/mois
Règle	0,99 €/mois	1 $/mois
Demandes	0,59 € le million	0,60 $ le million
Protection DDoS	0,15 € le million de demandes	0,15 $ le million de demandes

4. GuardDuty

Analyse d’événements CloudTrail Management

Cloud souverain : 4,54 €/million-mois
Paris : 4,40 $

Analyse des journaux de flux VPC et de requêtes DNS

Cloud souverain
1,13 €/Go (500 premiers Go/mois)
0,57 €/Go (2000 Go suivants)
0,29 €/Go (7500 Go suivants)
0,17 €/Go (au-delà)

Paris
1,10 $/Go (500 premiers Go/mois)
0,55 $/Go (2000 Go suivants)
0,28 $/Go (7500 Go suivants)
0,17 $/Go (au-delà)

Protection S3

Cloud souverain
1,03 € par million d’événements (500 premiers millions/mois)
0,51 € par million pour les 4500 millions/mois suivants
0,26 € par million au-delà

Paris
1 $ par million d’événements (500 premiers millions/mois)
0,50 $ par million pour les 4500 millions/mois suivants
0,25 $ par million au-delà

Protection EKS

Cloud souverain
2,20 € par million d’événements (100 premiers millions/mois)
1,11 € par million pour les 100 millions suivants
0,28 € au-delà

Paris
2,29 $ par million d’événements (100 premiers millions/mois)
1,15 $ par million pour les 100 millions suivants
0,29 $ au-delà

Surveillance de l’exécution d’EKS, ECS et EC2

Cloud souverain
1,89 € par processeur virtuel (500 premiers/mois)
0,95 € pour les 4500 suivants
0,32 € au-delà

Paris
2,04 $ par processeur virtuel (500 premiers/mois)
1,20 $ pour les 4500 suivants
0,34 $ au-delà

Analyse de volumes EBS

Sur l’offre de cloud souverain, c’est 0,039474302 €/Go.
Dans la région AWS Paris, c’est 0,04 $/Go.

Analyse de scans d’objets S3

Cloud souverain : 0,13 €/Go et 0,30 € pour 1000 objets.
AWS Paris : 0,14 $/Go et 0,33 $/1000 objets.

Analyse du journal d’activité Lambda

Cloud souverain
1,13 €/Go (500 premiers Go-mois)
0,57 €/Go (2000 Go suivants)
0,29 €/Go (7500 Go suivants)
0,17 €/Go (au-delà)

Paris
1,10 $/Go (500 premiers Go-mois)
0,55 $/Go (2000 Go suivants)
0,28 $/Go (7500 Go suivants)
0,17 $/Go (au-delà)

Services de bases de données

1. DocumentDB

	Cloud souverain	Paris
Instances à usage général	dg.t4g.medium (2 vCPU + 4 GiB) : 0,088 €/heure (Standard) ou 0,097 € (version optimisée E/S) db.t3.medium (2 vCPU + 4 GiB) : 0,091 € (Standard) ou 0,10 € (E/S)	dg.t4g.medium : 0,085 $ (Standard) ou 0,094 $ (E/S) db.t3.medium : 0,088 $ (Standard) ou 0,097 $ (E/S)
Instances optimisées mémoire	db.r6g.large (2 vCPU + 16 GiB) : 0,313 € (Standard) ou 0,344 € (E/S) db.r8g.16xlarge (64 vCPU + 512 GiB) : 10,52 € (Standard) ou 11,57 € (E/S)	db.r6g.large : 0,30 $ (Standard) ou 0,33 $ (E/S)
Instances NVMe	db.r6gd.large (4 vCPU + 32 GiB + SSD 237) : 0,764 € db.r6gd.16xlarge (64 vCPU + 512 GiB + 2 SSD 1900) : 12,23 €	db.r6gd.16xlarge : 11,87 $
Stockage	0,12 €/Go-mois (Standard) ou 0,35 €/Go-mois (E/S)	0,12 $/Go-mois (Standard) ou 0,35 $/Go-mois (E/S)
I/O	0,22 € par million de demandes (Standard)	0,23 $ par million de demandes (Standard)

2. DynamoDB

	Cloud souverain	Paris
Lectures/écritures	0,75 € par million d’unités d’écriture 0,15 € par million d’unités de lecture	0,74 $ par million d’unités d’écriture 0,15 $ par million d’unités de lecture
Stockage	Standard : 0,30 €/Go-mois au-delà de 25 Go Standard avec accès peu fréquent : 0,12 €/Go-mois	Standard : 0,30 $/Go-mois au-delà de 25 Go Standard avec accès peu fréquent : 0,12 $/Go-mois
Sauvegarde à la demande	0,12 €/Go-mois (à chaud) 0,0362374092 €/Go-mois (à froid)	0,12 $/Go-mois (à chaud) 0,03566 $/Go-mois (à froid)
Restauration de table	0,18 €/Go-mois (à chaud) 0,24 €/Go-mois (à froid)	0,18 $/Go-mois (à chaud) 0,24 $/Go-mois (à froid)
Export/import S3	Import : 0,18 €/Go Export : 0,12 €/Go	Import : 0,18 $/Go Export : 0,12 $/Go

3. ElastiCache

Version serverless

– Sur l’offre de cloud souverain

Valkey : 0,0996726126 €/Go-heure + 0,0027 € par million d’unités de traitement
Memcached et Redis OSS : 0,15 €/Go-heure et 0,004 € par million d’unités de traitement

– Dans la région AWS Paris

Valkey : 0,098 $/Go-heure + 0,0027 $ par million d’unités de traitement
Memcached et Redis OSS : 0,15 $/Go-heure et 0,004 $ par million d’unités de traitement

Nœuds à la demande

	Cloud souverain	Paris
Standards	cache.t4g.micro (2 vCPU + 0,5 GiB + 5 Gbit) : 0,01421007487 €/heure cache.m7g.16xlarge (64 vCPU + 210 GiB + 22,5 Gbit) : 4,73 €/heure	cache.t4g.micro : 0,0144 $/heure cache.m7g.16xlarge : 4,64 $/heure
Optimisés mémoire	cache.r7g.large (2 vCPU + 13 GiB + 12,5 Gbit) : 0,21 €/heure cache.r7g.16xlarge (64 vCPU + 419 GiB + 30 Gbit) : 6,63 €/heure	cache.r7g.large : 0,20 $/heure cache.r7g.16xlarge : 6,52 $/heure

Illustration générée par IA

The post Le « cloud souverain européen » d’AWS, combien ça coûte ? appeared first on Silicon.fr.

En cas de litige, prière de vous adresser aux tribunaux de Munich.

AWS impose cette règle aux clients de son « cloud souverain européen ». Il faut dire que l’offre a son épicentre en Allemagne. L’entité qui la porte y est basée, comme l’infrastructure initiale.

Plus de deux ans après son annonce, la démarche se concrétise : le lancement commercial vient d’être acté.

AWS fait une promesse d’équivalence fonctionnelle avec le reste de son cloud. Il ne faut toutefois pas s’attendre à retrouver immédiatement les mêmes services. En voici quelques-uns effectivement disponibles. Avec, pour chacun, les principales fonctionnalités utilisables… et celles qui ne le sont pas encore.

Compute

Sur EC2, AWS a activé, entre autres, les hôtes dédiés, les réservations de capacité, les groupes de placement de clusters et de partitions, l’hibernation, les instances Spot et les Savings Plans, l’optimisation CPU, ainsi que l’importation/exportation de VM.
En revanche, pas de SEV-SNP, de Credential Guard, d’enclaves Nitro, de configuration de la bande passante des instances, de blocs de capacité ML et de mise à l’échelle prédictive. Sur EC2 Image Builder, la gestion de cycle de vie n’est pas activée, comme la détection de vulnérabilité et l’intégration CloudFormation.

Sur Lambda, on peut notamment utiliser l’invocation asynchrone, la console d’édition de code, les extensions et SnapStart. Les images de conteneurs sont supportées, comme les puces Graviton.
Il faudra en revanche attendre pour les fonctions Lambda durables.

Stockage

AWS Backup gère pour le moment Aurora, CloudFormation, DynamoDB, EBS, EC2, EFS, RDS, Redshift et S3.
Aurora DSQL est sur la feuille de route, comme DocumentDB, FSx pour Lustre/ONTAP/OpenZFS, Neptune, RDS multi-AZ, Redshift Serverless, Storage Gateway, VMware et Windows VSS.

Sur EBS (Elastic Block Storage), l’essentiel des fonctionnalités sont disponibles : chiffrement, clonage, gestion du cycle de vie des données, corbeille, snapshots, etc.

Sur EFS (Elastic File Storage), les politiques de cycle de vie sont activées, comme le pilote CSI, l’IPv6, le mode Max I/O et plusieurs classes de stockage (Archive, Standard, Standard Infrequent Access).
En revanche, pas de classes de stockage One Zone et One Zone Infrequent Access. Ni de réplication intercomptes ou d’intégrations avec ECS et Lambda.

Sur la partie FSx, la version Lustre n’a pas de chiffrement au repos, de support des EFA (Elastic Fabric Adapter), ni des classes de stockage HDD et SSD.
Pour les versions ONTAP et OpenZFS, pas d’intégration AD, de chiffrement au repos, d’IPv6, de WORM, de classe SSD et de certains déploiements (multi-AZ, scale-out, haute disponibilité en mono-AZ).

S3 version European Sovereign Cloud gère les écritures et les copies conditionnelles, les listes de contrôle d’accès, les opérations par lots, les politiques et clés de buckets, la réplication interrégions, le tiering intelligent, l’inventaire et le cycle de vie, le verrouillage et l’étiquetage d’objets, ainsi que Glacier et Storage Lens.
Il faudra attendre pour les tables et les vecteurs S3, les autorisations d’accès individuelles, les métadonnées, la fonction Select et la classe de stockage Express One Zone.

Réseau

Sur API Gateway, REST est activé. Pas encore HTTP, ni WebSockets.

Les fonctionnalités principales de Cloud Map sont disponibles, dont l’intercomptes, la gestion des endpoints dual-stack et les attributs de services. Même réflexion pour Direct Connect, qui ne gère toutefois pas encore PrivateLink, comme beaucoup d’autres services.

Avec Route 53 aussi, l’essentiel du socle est disponible, à l’exception des domaines et – pour le DNS public – de la signature DNSSEC.
Sur les VPC, le blocage de l’accès public est activé, comme les journaux de flux, la gestion des adresses IP et la mise en miroir du trafic. La brique Route Server ne l’est pas, comme l’analyse de la connectivité et des accès réseau.

Bases de données

Aurora n’est pas encore disponible pour DSQL. Il l’est en revanche pour MySQL et PostgreSQL, y compris en version serverless. Les déploiements blue-green sont pris en charge, comme les proxys RDS et la connexion zero-ETL avec Redshift.

Les briques essentielles de DocumentDB sont disponibles. Pas de clusters globaux, cependant, ni de clusters élastiques.

Sur DynamoDB, on peut bénéficier du contrôle d’accès à base de rôles et d’attributs, des points de restauration, de l’importation/exportation S3, des index secondaires globaux ou locaux, des classes de stockage Standard et Standard Infrequent Access et du débit à la demande ou provisionné.
Le service de cache Accelerator n’est pas disponible.

ElastiCache est disponible en serverless, avec le support du JSON. Mais pour le moment sans tiering des données ni data store global.
Les principales fonctionnalités de Neptune sont accessibles, mais pas les instances serverless ni celles optimisées I/O.

Sur RDS pour MariaDB, MySQL, PostgreSQL et SQL Server, les déploiements blue-green sont pris en charge, ainsi que les lectures optimisées (sauf pour Postgre) et les proxys RDS. Les réplicas en lecture interrégions sont sur la roadmap, comme la connexion zero-ETL avec Redshift (mais pas pour MariaDB).

Analytics

Le « gros » d’Athena est disponible : console, contrôle d’accès granulaire, requêtes fédérées, réservation de capacité, etc. Même chose pour EMR, mais sans les versions EKS et serverless. Et pour Kinesis Data Strams (contrôle d’accès basé sur les attributs, accès intercomptes, quotas de service, connectivité et sécurité réseau).

Data Firehose accepte OpenSearch, Redshift, S3, Snowflake, Iceberg et HTTP en destination. Il gère l’IPv6, la transformation de données, l’ingestion PUT et le partitionnement dynamique.
L’intégration avec Secrets Manager n’est pas encore activée, ni Splunk comme destination.

Le Flink managé d’AWS est largement opérationnel, mais sans possibilité d’apporter ses propres clés. Sur le Kafka managé, c’est le serverless qui manque, ainsi que les briques Connect et Replicator.

Le cœur fonctionnel de Glue est disponible (console, connecteurs, jobs, sessions interactives).

Quantité de fonctionnalités d’OpenSearch Service sont disponibles : support du 3-AZ, détection d’anomalies, recherche asynchrone, recherche entre clusters, dictionnaires personnalisés, SAML, chiffrement au repos et en transit, supervision/alertes, compression HTTP, gestion de l’état des index, snapshots quotidiens, domaines VPC…
Il y a aussi des manques : serverless, alertes interclusters, recherche interrégions, réplication entre clusters, plug-in tiers, authentification Kibana avec Cognito, requêtage SQL, requêtes directe sur Security Lake, recherche par similarité cosinus…

Sur Redshift, l’optimisation automatique des tables et la gestion automatique des workloads sont activées. Idem pour les requêtes entre bases de données, les snapshots et les points de restauration, les procédures stockées et les fonctions définies par l’utilisateur.
Il faudra patienter pour la version serverless, l’édition et la fédération de requêtes, ainsi que l’intégration avec Bedrock.

IA/ML

Bedrock est signalé comme disponible. Mais beaucoup de composantes manquent à l’appel : agents, RAG, marketplace, évaluations, apprentissage par renforcement, gestion et optimisation des prompts…

SageMaker AI est disponible pour l’inférence et l’entraînement, avec SDK Python, JupyterLab, registre de modèles, pipelines, recherche et conteneurs deep learning.
Pas de personnalisation des modèles, ni de batching pour l’entraînement.

Conteneurs

ECR (Elastic Container Registry) est disponible avec chiffrement double couche, scan d’images, IPv6, réplication intercomptes et intégrations CloudTrail/CloudWatch.

ECS (Elastic Container Service) l’est avec gestion de Fargate et de l’attachement de tâches EBS. Pas de déploiements blue-green, en revanche, ni de découverte de services.

Les nœuds hybrides et les groupes de nœuds managés sont disponibles sur EKS (Elastic Kubernetes Service). Comme IPv6, OIDC et les add-on.
Fargate n’est pas encore pris en charge.

Sécurité, identité, conformité

L’essentiel des fonctionnalités de Cognito sont disponibles. Même chose pour GuardDuty, mais sans la console ni la connexion avec Detective et Security Hub.

Sur Certificate Manager, la supervision des certificats est disponible comme la validation DNS, l’émission et l’exportation de certificats publics, leur importation, le renouvellement managé et la création de certificats TLS privés via l’autorité de certification AWS.
La validation HTTP n’est pas disponible. Il en va de même pour la validation e-mail.

Avec Directory Service, la suprervision, l’administration et le partage d’annuaire sont activés. Même chose pour le MFA, les politiques de mots de passe, l’extension de schéma et les snapshots quotidiens.
La remontée des métriques de contrôleurs de domaine dans CloudWatch n’est pas disponible. Comme la gestion des utilisateurs et des groupes.

Sur la partie IAM, la composante STS (Security Token Service) est disponible. Comme la récupération de compte et la centralisation des accès root.
Les passkeys ne le sont pas encore. La fédération non plus. Idem pour la gestion de principaux et la simulation de politiques.

En version « cloud souverain européen », AWS KMS gère les magasins de clés externes, mais pas les magasins personnalisés.

Sur Secrets Manager, l’essentiel est activé : récupération par lots, rotation automatique, contrôle d’accès avec IAM, métriques CloudWatch, réplication interrégions, génération de mots de passe, étiquetage et chiffrement des secrets…
La sécurité post-quantique pour TLS fait exception. Il faudra aussi attendre pour pouvoir déployer Secrets Manager avec AppConfig.

Le WAF (v2) est bien disponible, mais il manque notamment la protection contre le DDoS, les bots et la fraude. Ainsi que les intégrations App Runner, AppSync et Amplify.

Gestion, gouvernance

Le service AWS Auto Scaling gère, entre autres cibles, les services ECS, les clusters EMR, les réplicas Aurora, les ressources personnalisées, les tables et les index secondaires globaux DynamoDB et les groupes de réplication ElastiCache (Redis OSS et Valkey).
Les clusters Neptune sont sur la feuille de route, comme les flottes AppStream et les tables Keyspaces pour Cassandra.

Le cœur fonctionnel de CloudFormation est disponible (hooks, générateur IaC, StackSets, quotas de service…), mais la synchro Git ne l’est pas.

Avec CloudTrail, on accède à l’historique d’événements, à la piste d’audit et au serveur MCP. Pas aux insights ni aux événements agrégés.

Sur CloudWatch, métriques, dashboard et alarmes sont activés, comme l’extension Lambda Insights. Pipeline, signaux d’applications et RUM ne le sont pas. Sur la partie logs, pas mal d’éléments manquent encore : observabilité de la GenAI, indexation de champs, enrichissement, intégration des tables S3, centralisation entre comptes et régions…

Illustration générée par IA

The post AWS lance son « cloud souverain européen » : les services disponibles appeared first on Silicon.fr.