On l’a appris il y a quelques jours : OpenAI a bouclé la plus grande levée de fonds de son histoire, à 110 Md$.
Si NVIDIA et SoftBank ont chacun mis 30 milliards, la plus grosse contribution provient d’AWS. Ce dernier a débloqué 50 milliards. Il en injecte 15 pour commencer et prévoit d’octroyer le reste « dans les prochains mois, sous certaines conditions ».
Parallèlement à cet apport financier, OpenAI promet de dépenser 100 Md$ supplémentaires au cours des 8 prochaines années en ressources de calcul chez AWS*. Un engagement qui s’ajoute à un accord à 38 Md$ signé en novembre 2025.
La perspective d’un runtime « spécial AWS »
L’alliance ne s’arrête pas au compute. AWS sera aussi le « distributeur cloud tiers exclusif » pour Frontier, la couche d’orchestration agentique qu’OpenAI a présentée début février.
Les deux entreprises entendent aussi lancer, « dans les prochains mois », un runtime agentique reposant sur les modèles OpenAI et optimisé pour l’infra AWS (natif à Amazon Bedrock). Elles n’en disent pas beaucoup plus, sinon que cet environnement permettra de conserver le contexte (mémoire, identités, outils…), évitant ainsi une orchestration manuelle.
Le partenariat implique également la conception de modèles personnalisés pour les développeurs d’Amazon. En toile de fond, des LLM maison qui ne font pas l’unanimité en interne.
* AWS parle de consommer 2 GW de capacité Trainium. En novembre 2025, il évoquait l’accès à « des centaines de milliers » de GPU. Et une possibilité d’extension à « des dizaines de millions » de CPU. L’annonce mentionnait les configurations UltraServer dotées en GB200 et GB300.
C'est une information qui n'a pas de précédent. Dans la nuit du 1er au 2 mars 2026, un centre de données d'Amazon Web Services a été physiquement endommagé aux Émirats arabes unis, dans le contexte des représailles iraniennes qui ont suivi les frappes américano-israéliennes sur l'Iran.
Le conflit qui embrase le Moyen-Orient prend des dimensions inédites. Un centre de données d’Amazon a été frappé aux Émirats arabes unis, marquant un tournant historique pour l'industrie de la tech. Le cloud est désormais une cible bien réelle.
Erreur humaine ou pas, toujours est-il qu’une IA, héritant des privilèges d’un ingénieur, a supprimé un environnement de production.
Une partie des commentaires sur « l’affaire Kiro » convergent en ce constat.
Amazon n’avait initialement pas communiqué à propos de l’incident, survenu mi-décembre. Il a fini par le faire la semaine dernière… après que le Financial Times l’eut révélé.
Ce qu’affirme le Financial Times
S’en référant à des employés d’Amazon, le FT déclare qu’AWS a subi, « ces derniers mois », au moins deux pannes en production dues à des erreurs impliquant ses propres outils d’IA. Il ne date pas l’une d’entre elles, qui aurait, toujours selon des employés, impliqué l’assistant Amazon Q Developer.
Celle de mi-décembre a entraîné 13 heures d’indisponibilité pour un « système utilisé par les clients ». La conséquence de modifications effectuées par l’assistant Kiro, qui avait choisi de supprimer puis de recréer un environnement.
Autre propos prêté à des employés : traités comme une « extension » des ingénieurs, les outils IA avaient les mêmes permissions. Dans l’un et l’autre cas, les personnes impliquées n’ont pas sollicité de validation des changements par un pair.
Le FT attribue certains propos directement à Amazon. D’après ce dernier, l’incident de décembre a été « extrêmement limité » : un seul service affecté, dans certaines zones de Chine continentale. Quant à l’autre incident, il n’a pas eu d’impact sur des services exposés aux clients.
Autre déclaration attribuée au groupe américain : dans les deux cas, il s’agissait d’une erreur humaine. Plus précisément un problème de contrôle d’accès : l’ingé impliqué dans l’incident de décembre avait plus de permissions qu’il n’aurait dû. Le même problème aurait pu se produire avec tout outil – doté ou non d’IA – ou toute action manuelle.
Ce que rétorque Amazon
Concernant le prétendu incident avec Amazon Q Developer, le groupe américain est catégorique : « Il est complètement faux de dire qu’un deuxième événement a impacté AWS ».
Celui de décembre a touché l’explorateur de coûts AWS (Cost Explorer), dans une de ses 39 régions cloud. Amazon juge ce périmètre « extrêmement limité » et précise n’avoir reçu aucune demande client.
L’entreprise confirme le scénario des contrôles d’accès mal configurés. C’est « une coïncidence » que des outils d’IA aient été impliqués, clame-t-elle. Et d’ajouter avoir implémenté des garde-fous « pour que cela ne se reproduise pas ». Parmi eux, une révision systématique par les pairs pour les accès en prod.
Une « directive Kiro » qui ne fait pas l’unanimité
En complément à ces éléments, un porte-parole a expliqué que l’erreur humaine n’était pas la validation de l’action par l’ingénieur, mais le fait que ce dernier n’avait pas compris quel était son niveau de privilèges. Sous-entendu : il aurait probablement agi différemment s’il avait su.
Amazon assure que par défaut, Kiro demande une validation pour chaque action qu’il souhaite effectuer. Il ne dit en revanche rien de la façon dont l’assistant a proposé de supprimer l’environnement en question. A-t-il été explicite ? Dans la négative, l’ingénieur s’est-il renseigné davantage avant de valider ?…
En toile de fond, une directive interne de novembre 2025 par laquelle Amazon pousse ses équipes à standardiser sur Kiro. Une démarche entreprise tant au nom d’une sécurité renforcée (limitation des risques de fuites de données, notamment) que d’une télémétrie unifiée.
L’initiative a suscité des remous. Plus d’un millier d’employés ont demandé de pouvoir conserver un accès à des outils, dont Claude Code. Motif : ils sont plus performants que Kiro sur des cas d’usage comme le refactoring multilangage et la gestion de certains frameworks « de niche ».
In a landmark 6–3 ruling issued on Friday, February 20, 2026, the United States Supreme Court invalidated several aggressive trade tariffs implemented by President Donald Trump. According to NBCNews, the decision is expected to trigger a significant reduction in the retail cost of consumer electronics, including smartphones, laptops, and tablets, which had seen sharp price increases due to these import duties. The Court focused on the administration’s use of the […]
EC2 gère désormais officiellement la virtualisation imbriquée.
L’option est activable dans toutes les régions commerciales AWS ; pour le moment sur trois familles d’instances en CPU Intel : les C8i, M8i et R8i. Elle donne le choix entre KVM et Hyper-V. Avec quelques limites, dont :
Pas d’hibernation des instances
Désactivation du mode VSM (Virtual Secure Mode) sur les instances Windows
Absence de gestion des instances Windows à plus de 192 CPU
La virtualisation imbriquée constitue une alternative économique au bare metal pour exécuter des micro-VM (par exemple avec la technologie Firecracker d’AWS, qui nécessite KVM). Ou des outils de développement et de test logiciel – WSL2, émulateurs, pipelines CI/CD manipulant des images de VM…
La virtualisation imbriquée, apparue sur Azure et Google Cloud en 2017
Intégrée dans Windows Server 2022, la virtualisation imbriquée avait été lancée sur Azure dès 2017. Elle ne gère officiellement qu’Hyper-V, sur les processeurs Intel avec extensions VT-x ainsi que sur les EPYC et Ryzen d’AMD. Entre autres limites, elle ne gère pas la mémoire dynamique (obligation d’éteindre la VM hôte pour ajuster sa mémoire).
Google aussi avait commencé à intégrer la virtualisation imbriquée dans son cloud public en 2017, à base de KVM. Initialement, c’était pour les VM Linux reposant sur des CPU Intel de génération Haswell et ultérieures. Elle est maintenant généralisée, mais toujours pas gérée sur les processeurs AMD ou Arm – et pas utilisable avec les VM E2 et H4D, ainsi que celles à mémoire optimisée.
Google donne une estimation de la surcharge qu’implique la virtualisation imbriquée. Il annonce une baisse potentielle de performance d’au moins 10 % pour les workloads liés au CPU. Et éventuellement davantage pour ceux orientés I/O.
AWS a potentiellement attendu que le hardware permette de minimiser ces pertes… et de garantir un niveau de sécurité conforme à ses standards.
OCI gère aussi la virtualisation imbriquée, à base de KVM.
Perplexity s’offre les services du cloud Azure de Microsoft pour déployer des modèles d’IA via le service Foundry, incluant notamment ceux développés par OpenAI, Anthropic et xAI, selon des sources citées par Bloomberg.
Son montant : 750 millions $ sur trois ans.
« Nous sommes ravis de nous associer à Microsoft pour accéder aux modèles de pointe de X, OpenAI et Anthropic », a déclaré Perplexity en précisant que ce nouveau contrat ne s’accompagne d’aucun transfert de dépenses depuis Amazon Web Services, son principal fournisseur cloud historique.
« AWS reste le fournisseur d’infrastructure cloud privilégié de Perplexity, et nous sommes impatients d’annoncer des extensions de ce partenariat dans les semaines à venir », a ajouté le porte-parole.
Cette diversification illustre une tendance forte de l’approche « multicloud » qui s’est accélérée avec l’avènement de l’IA.
Des relations complexes avec Amazon
Perplexity avait jusqu’ici construit l’essentiel de son activité sur AWS, utilisant le service Bedrock pour accéder aux modèles Anthropic qui alimentent son moteur de recherche.
Aravind Srinivas, le directeur général de Perplexity, est un habitué des conférences AWS qui présentait volontiers Perplexity comme l’un de ses clients IA de référence.
Les relations se sont toutefois tendues ces derniers mois. En novembre, Amazon a poursuivi Perplexity en justice pour tenter d’empêcher la start-up de permettre aux consommateurs d’utiliser ses outils d’IA pour faire leurs achats sur la marketplace du géant du commerce en ligne. Perplexity a riposté en qualifiant Amazon d’intimidateur, dénonçant des actions constituant « une menace pour le choix des utilisateurs ». Srinivas avait alors révélé avoir pris des « centaines de millions » d’engagements auprès d’AWS.
Microsoft muscle son offre IA
Pour Microsoft, cet accord renforce sa stratégie visant à positionner Azure comme la plateforme de référence pour développer des applications d’IA et déployer des modèles de multiples fournisseurs. Le groupe propose depuis longtemps les modèles de son partenaire OpenAI et a conclu un accord similaire avec Anthropic en novembre.
« Nos clients s’attendent à utiliser plusieurs modèles dans le cadre de n’importe quelle charge de travail », a déclaré le PDG Satya Nadella lors d’une conférence téléphonique sur les résultats cette semaine. « Et nous offrons la plus large sélection de modèles de tous les hyperscalers. »
Plus de 1 500 clients Microsoft Foundry ont déjà utilisé à la fois les modèles OpenAI et Anthropic, a précisé le PDG Satya Nadella lors d’une conférence téléphonique sur les résultats financcette semaine indiquant que le nombre de clients dépensant plus d’un million de dollars par trimestre sur Foundry a progressé de près de 80% au cours du trimestre clos en décembre.
Perplexity compte parmi les start-ups d’IA les mieux valorisées, mais fait face à une rude concurrence de Google et OpenAI dans son ambition de révolutionner la recherche d’informations en ligne. Contrairement à OpenAI et Anthropic, qui ont récemment multiplié les accords d’infrastructure, elle n’a pas levé autant de capitaux que ses concurrents.
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.
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.
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
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
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à)
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
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 endpointsdual-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…
Avec 83 % des dépenses IT des grandes entreprises captées par des fournisseurs étrangers et une part de marché européenne marginale sur la plupart des segments critiques (OS, cloud, IA générative), l’UE fait face à des risques majeurs de souveraineté et de sécurité.
Ce dossier décrypte les données chiffrées de cette dépendance, analyse la matrice des risques économiques et géopolitiques associés, et illustre concrètement ces enjeux à travers le cas du secteur de l’énergie, où la cybersécurité repose massivement sur des solutions non européennes.
>Dépendances numériques de l’UE : une matrice des risques
L’étude commandée par le Parlement européen propose une matrice d’évaluation du « risque de souveraineté », sur trois axes (contrôle juridique, autonomie technique, indépendance stratégique) comportant chacun trois dimensions
Une panne AWS en US-EAST-1 liée à la résolution de noms perturbe des services dans le monde, Amazon confirme une reprise progressive et un suivi public détaillé.
Aujourd’hui, dans Affaires Sensibles, le naufrage de l’USS Indianapolis, le 30 juillet 1945 : la pire catastrophe de l’histoire de la marine américaine
Connexion
