Devinette du soir : Qu’est-ce qui est pire qu'un secret que vous avez oublié de cacher ?
Réponse : Des dizaines, des millions de secrets qui traînent sur GitHub parce que quelqu'un a eu la flemme de configurer un vrai gestionnaire de variables d'environnement !
Hé oui, les amis ! On a tous fait cette boulette au moins une fois (ou alors vous mentez, ou vous êtes un robot). On crée un petit fichier .env, on oublie de le rajouter au .gitignore, et paf, vos clés AWS se retrouvent à poil. Selon GitHub, c'est plus de 39 millions de secrets qui ont été détectés en fuite sur leurs dépôts en 2024. C'est du délire !
Envmap - Le gestionnaire de variables d'environnement qui tue les fichiers .env (
Source
)
Du coup, au lieu de continuer à se farcir du bricolage avec des fichiers qui traînent en clair sur le disque, je vous propose de jeter un œil à Envmap.
C'est un outil écrit en Go dont l'objectif est de réduire au maximum l'écriture de vos secrets sur le disque dur. En mode normal, il va les pomper directement chez les grands manitous du stockage sécurisé comme AWS Secrets Manager, HashiCorp Vault, 1Password ou encore Doppler (même si pour l'instant, certains de ces providers sont encore en cours d'intégration).
Comme ça, au lieu de faire un vieux source .env qui laisse traîner un fichier sensible, vous lancez votre application avec envmap run -- node app.js. L'outil récupère les variables en RAM et les injecte dans le process. C'est propre, c'est net, et ça évite surtout de pousser par erreur votre config sur un repo public.
Pour ceux qui se demandent s'il faut quand même envoyer ses fichiers .env sur GitHub (spoiler : non, jamais !), Envmap propose une commande import pour ingérer vos vieux secrets. Et pour ceux qui ont besoin d'un stockage local, sachez qu'Envmap peut aussi chiffrer vos variables en AES-256-GCM, ce qui est quand même plus sérieux qu'un fichier texte lisible par n'importe qui. Notez aussi qu'il existe une commande sync si vous avez vraiment besoin de générer un fichier .env temporaire.
Perso, ce que je trouve vraiment cool, c'est l'intégration avec direnv. On rajoute une ligne dans son .envrc, et hop, les secrets sont chargés automatiquement quand on entre dans le dossier du projet. C'est magique et ça évite les crises cardiaques au moment du push.
D'ailleurs, si vous voulez aller plus loin dans la sécurisation de vos outils, je vous recommande de lire mon article sur
SOPS
ou encore ma réflexion sur
l'usage de GitLab
pour vos projets sensibles.
Bref, c'est open source (sous licence Apache 2.0), et avec ça, vous dormirez sur vos deux oreilles !
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
Vous passez vos journées à faire des aws iam list-users | jq '.Users[]' et autres trucs interminables pour juste trouver une info ?? Laissez tomber, j'ai le truc qui va vous changer la vie !
Ça s'appelle Sisu et c'est un petit outil en Go qui monte vos ressources AWS comme un système de fichiers local. Du coup, au lieu de taper des commandes AWS complexes, vous utilisez juste grep, cat, diff, vim... c'est à dire les outils Unix que vous connaissez déjà par cœur.
Vous lancez la commande sisu et hop, vos ressources AWS se retrouvent montées dans ~/.sisu/mnt/ ! Vos buckets S3, vos paramètres SSM, vos roles IAM, vos lambdas, vos instances EC2...etc. Tout ça organisé en dossiers par profil AWS et par région.
Ainsi, pour chercher tous vos utilisateurs IAM qui ont un accès admin, c'est aussi simple que :
Et pour lire un secret ? Un simple cat default/us-east-1/secrets/myapp/database/value.
C'est bête comme Jordan mais ça change tout pour la maintenance au quotidien !
Et côté services supportés, Sisu gère pas mal de trucs tels que le S3 et SSM Parameter Store en lecture/écriture/suppression, et IAM, VPC, Lambda, EC2, Secrets Manager, Route 53 et CloudWatch Logs en lecture seule. Y'a même un truc sympa pour EC2 c'est que vous pouvez vous connecter à une instance via SSM Session Manager sans avoir besoin de clés SSH. Suffit d'exécuter le fichier connect qui se trouve dans le dossier de l'instance (à condition d'avoir l'agent SSM configuré sur l'instance et le plugin Session Manager côté client, évidemment).
Pour les logs CloudWatch, c'est bien aussi puisqu'ils sont streamés à la demande par batches de 100, donc vous pouvez faire un grep dessus sans tout charger en mémoire d'un coup.
Côté installation, c'est du Go classique :
go install github.com/semonte/sisu@latest
Faudra juste penser à installer FUSE avant sur votre système (apt install fuse sous Ubuntu/Debian, yum install fuse sous RHEL/CentOS) et c'est tout, y'a rien d'autre à configurer si vous avez déjà vos credentials AWS en place.
Après, l'outil cache les résultats pendant 5 minutes pour éviter de spammer l'API AWS à chaque ls, ce qui est plutôt indispensable pour limiter les appels et le temps de réponse.
Bref, si vous en avez marre de jongler avec jq pour parser du JSON AWS, Sisu va vous aider ! C'est open source sous licence MIT,
et c'est par ici !
Des checkpoints, du replay… et ça donne des fonctions Lambda « durables ».
AWS a mis cette option en lumière lors de sa conférence re:Invent 2025. La promesse : des exécutions qui peuvent durer jusqu’à 1 an, avec une reprise fiable après interruption ou mise en pause.
Un SDK à intégrer dans le code des fonctions permet d’implémenter les primitives qui gèrent ce mécanisme. Les mises en pause peuvent se faire pour une durée déterminée. On peut aussi conditionner la reprise à un événement donné.
La facturation se fait sur trois plans :
Opérations « durables » (étapes, pauses, callbacks) : 8 $ le million
Données écrites : 0,25 $/Go
Données conservées : 0,15 $/Go/mois
Lambda en un peu moins serverless
Autre option mise en avant : les instances Lambda managées. Il s’agit ici de choisir les configurations EC2 sur lesquelles exécuter les fonctions.
On crée pour cela des « fournisseurs de capacités ». Ces fournisseurs s’exécutent dans le compte AWS, au sein d’un VPC (et au moins d’un sous-réseau). On peut en paramétrer certains aspects :
Architecture CPU
Types d’instances autorisées (liste blanche, liste noire ou sans restriction)
Nombre maximal d’instances
Mode de mise à l’échelle (manuelle ou automatique)
Clé de chiffrement EBS (éventuellement personnalisée)
Un autre modèle de concurrence…
Lorsqu’on publie une version d’une fonction associée à un fournisseur de capacité, Lambda lance des instances managées (3 par défaut, pour la résilience). Ou bien il en utilise des existantes si les ressources sont suffisantes pour accueillir l’environnement d’exécution.
De même, un environnement d’exécution peut gérer plusieurs invocations en parallèle (64 maximum). Le modèle de concurrence est donc différent de celui de Lambda « standard » (une invocation = un environnement).
… de sécurité…
Ce système suppose que la sûreté des threads, la gestion d’état et l’isolation du contexte doivent être gérés différemment en fonction du contexte.
Les fournisseurs de sécurité constituent en fait la limite de confiance. Avec les instances Lambda managées, les fonctions s’exécutent effectivement dans des conteneurs, lesquels ne fournissent pas le même niveau de sécurité que la techno de micro-VM Firecracker utilisée en standard.
… de scaling…
Avec les instances Lambda managées, pas de démarrage à froid. La mise à l’échelle est asynchrone, sur la base de signaux de consommation CPU. Dans cet esprit, l’option est donc à réserver aux workloads dont le trafic est prévisible. AWS ne garantit d’ailleurs pas la stabilité si la charge fait plus que doubler dans un intervalle de 5 minutes.
Quatre paramètres influent sur la mise à l’échelle :
Quantités de mémoire et de vCPU allouées à une fonction
Concurrence maximale par environnement
Cible d’utilisation de ressources
Types d’instances autorisés
… et de tarification
Les instances Lambda managées sont facturées au prix d’EC2 à la demande… avec 15 % de frais supplémentaires. L’option permet néanmoins d’exploiter d’éventuelles remises (savings plans, instances réservées…). Il faut ajouter des frais de 0,20 $ par million de requêtes.
Plus besoin de shards ni de requêtes fédérées : vous pouvez consolider vos données vectorielles en un seul index.
AWS en fait l’un des arguments de S3 Vectors, lancé en disponibilité générale lors de la re:Invent.
Avec S3 Vectors, la promesse d’un index unique
Le service était en previewdepuis juillet. Il apporte une gestion native des vecteurs dans S3, avec un type de bucket spécifique. Sur le papier, c’est une alternative moins onéreuse à Aurora Serverless et OpenSearch Serverless, en contrepartie de temps de réponse allongés (« sous la seconde », affirme AWS).
La préversion permettait de stocker jusqu’à 50 millions de vecteurs par index (et 10 000 index par bucket). Avec la version commerciale, on passe à 2 milliards, d’où l’argument de la consolidation. Autre seuil relevé : le nombre maximal de résultats par requête (100 désormais, contre 30 en preview). Quant à la latence, elle est maintenant « fréquemment sous les 100 ms ».
S3 Vectors a une intégration avec Bedrock Knowledge Bases (RAG) et avec Amazon OpenSearch (utilisation comme moteur sur les clusters managés ou injection d’un snapshot dans la version serverless).
L’accélération GPU activée sur OpenSearch
En parallèle, une option d’accélération GPU fait son entrée sur l’OpenSearch d’AWS. Promesse : construire des bases vectorielles « jusqu’à 10 fois plus vite » pour un quart du prix traditionnel, grâce à un usage optimisé de l’infra. En complément, il devient possible de régler les niveaux de rappel et de latence souhaités.
Une mémoire épisodique pour les agents Bedrock
À l’occasion de la re:Invent, il y a aussi du nouveau dans Bedrock AgentCore. Cette offre, lancée à l’été 2025, est dans la lignée de Bedrock Agents. Elle en a étendu les capacités (gestion native de MCP et contrôle plus fin de la mémoire, par exemple) et en a désagrégé la plupart en modules indépendants, par ailleurs « détachés » de Bedrock de sorte qu’ils prennent en charge des technologies non disponibles sur la plate-forme.
Voilà Bedrock AgentCore doté d’une forme de mémoire épisodique. Avec cette stratégie, les agents capturent des « épisodes structurants » (contexte, processus de raisonnement, actions, résultats). Ils sont censés pouvoir ainsi agir de façon plus cohérente lorsqu’ils rencontrent des situations similaires.
AWS dote aussi AgentCore de la diffusion audio bidirectionnelle. Lors des interactions vocales, l’agent peut être interrompu et s’adapter au nouveau contexte sans avoir à terminer son action au préalable.
Un service managé de supervision est également ajouté, mais pour le moment en preview. On peut y intégrer des évaluations personnalisées en plus de celles livrées pour analyser des indicateurs tels que la précision, l’utilité, la concision et la sûreté. Les résultats sont délivrés dans CloudWatch.
Autre preview : celle de la fonctionnalité Policy in AgentCore. Elle permet d’intercepter les appels d’outils sur la passerelle et de leur appliquer des stratégies définies en langage naturel ou avec Cedar.
Les derniers modèles Mistral et Gemma ajoutés sur Bedrock
AWS a aussi profité de la re:Invent pour rappeler les derniers ajouts de modèles ouverts sur Bedrock. Parmi eux :
Mistral Large 3, Ministral 3 (3B, 8B, 14B), Magistral Small 1.2, Voxtral Mini 1.0, Voxtral Small 1.0
Gemma 3 (4B, 12B, 27B)
Kimi K2 Thinking (de Moonshot AI)
MiniMax M2 (de MiniMax AI)
Nemotron Nano 2 9B et une version « vision » 12B (de NVIDIA)
GPT-OSS-safeguard 20B et 120B (modèles de modération de contenu)
Qwen3-Next-80B-A3B et Qwen3-VL-235B-A22B
Nova Sonic : une deuxième génération plus polyglotte
Amazon enrichit aussi sa propre famille de modèles Nova. Avec notamment Nova 2 Sonic.
La première génération de ce modèle de reconnaissance et de synthèse vocales avait été lancée en avril. La deuxième gère mieux les entrées alphanumériques, les énoncés courts, les accents, le bruit de fond et l’audio qualité téléphonie (8 kHz). Avec elle arrivent les « voix polyglottes » (capacité à changer de langue au milieu d’une conversation), les appels d’outils asynchrones et un réglage de sensibilité pour la détection de voix (ce qui laisse plus ou moins de temps à l’utilisateur pour finir sa phrase).
AWS lance Nova dans le bain de l’automatisation web
Sous la marque Nova Forge, AWS permet de continuer l’entraînement de ses propres modèles à partir de divers checkpoints, en utilisant des jeux de données spécialisés « sur étagère » ou en en important. L’ensemble repose sur l’outillage SageMaker AI et permet d’effectuer éventuellement de l’apprentissage par renforcement.
On trouve aussi un modèle Amazon (Nova 2 Lite) à la base de Nova Act, service d’automatisation agentique pour les navigateurs web. Il est intégré avec le framework d’ochestration Strands Agents.
Les données synthétiques sous l’angle privacy
Les serveurs de tracking MLflow qu’on peut greffer depuis l’an dernier à SageMaker pour superviser les expérimentations ML disposent désormais d’une option serverless. Avec la possibilité de partager des instances entre domaines et comptes AWS.
Le service Clean Rooms (salles blanches de données) permet quant à lui maintenant de créer des jeux de données synthétiques (tabulaires, destinées à entraîner des modèles de régression et de classification ; pas des LLM). Le système utilise un modèle qui reproduit les patterns statistiques du dataset d’origine tout en éliminant les données identifiantes. En ce sens, il est présenté comme une alternative aux techniques d’anonymisation.
AI Factories : AWS s’approprie aussi la notion
AWS s’approprie le concept des AI Factories en lançant une offre sous ce nom. On n’en sait pas grand-chose à l’heure actuelle, sinon qu’elle doit permettre de déployer des clusters IA managés (puces Trainium et NVIDIA + services AWS) dans les datacenters des clients, « comme une région AWS privée ». Premier client référent : l’entreprise saoudienne HUMAIN, qui va installer sur place une « zone IA » avec jusqu’à 150 000 GPU.
Des fonctions Lambda « durables »
Les fonctions Lambda durables ne sont pas spécifiques aux workloads IA, mais elles sont susceptibles de faciliter leur exécution.
Par « durables », il faut entendre « dont la durée de vie peut atteindre 1 an ». Elle peuvent effectivement être mises en pause jusqu’à ce que des conditions spécifiques soient remplies (typiquement, des événements externes). Seul le temps de calcul actif est facturé.
Un SDK s’intègre au code des fonctions pour pouvoir implémenter ces pauses. Ainsi que des « étapes » permettant de ne pas reprendre l’exécution depuis le début en cas d’échec.
Les grandes entreprises combinent plusieurs clouds pour répartir les workloads, optimiser les coûts, rapprocher les données des utilisateurs et limiter les risques de dépendance à un seul fournisseur. Jusqu’ici, relier ces environnements impliquait soit l’usage d’Internet public sans garanties de bande passante, soit des montages de connectivité privée complexes, longs à déployer et coûteux à exploiter.
L’alliance entre AWS et Google Cloud combine le nouveau service AWS Interconnect- multicloud et Google Cloud Cross-Cloud Interconnect pour proposer une connectivité privée et automatisée entre les deux environnements. Elle fournit une connectivité entre VPC AWS et VPC/VPC‑SC Google Cloud, intégrée de manière native aux consoles et APIs des deux fournisseurs.
Google Cloud avait déjà positionné Cross-Cloud Interconnect comme brique clé de son architecture “Cross-Cloud Network”, permettant de relier Google Cloud à AWS, Azure, Oracle Cloud Infrastructure et d’autres MSP via des liens privés à haut débit.
Les deux acteurs mettent en avant une automatisation poussée : les clients peuvent réserver de la capacité dédiée à la demande et établir la connectivité en quelques minutes, sans gérer directement le câblage, les circuits ni l’infrastructure physique sous‑jacente.
L’annonce inclut une spécification ouverte pour l’interopérabilité réseau entre clouds décrite comme un standard commun de connectivité privée qui vise à réduire la complexité de l’adressage, du routage et de la gestion des politiques réseau entre environnements AWS et Google Cloud.
L’objectif est de permettre à d’autres fournisseurs de cloud d’implémenter le même modèle, afin d’étendre ce socle d’interopérabilité au‑delà du seul duo AWS–Google Cloud. Cette ouverture pourrait favoriser l’émergence d’un écosystème où les clouds majeurs s’alignent sur des standards communs de connectivité privée, à l’image de ce qui existe déjà pour certains protocoles réseau et interfaces de peering.
Caractéristiques techniques mises en avant
Sur le plan technique, Cross-Cloud Interconnect fournit des liaisons privées avec des capacités de 10 ou 100 Gbit/s dans de nombreux sites mondiaux, gérées par Google côté physique, avec des métriques de performance détaillées (latence, pertes de paquets, temps de trajet aller‑retour).
Les documents techniques de Google décrivent un modèle de double attachement (primaire et redondant) et l’utilisation de BGP pour l’échange de routes entre Google Cloud et AWS, avec des exigences de haute disponibilité.
AWS Interconnect-multicloud, en préview, est présenté comme un service managé offrant des connexions privées simples, résilientes et à haut débit vers d’autres clouds, intégrées avec les outils réseau et d’observabilité AWS.
L’intégration avec Cross-Cloud Interconnect vise à abstraire la gestion des ports, des circuits et des délais de provisioning, en exposant une expérience de type “cloud‑native” dans les deux consoles.
Cas d’usage et bénéfices clients
L’alliance cible des scénarios où les données ou applications sont réparties entre AWS et Google Cloud, par exemple pour des plateformes analytiques, des charges IA/ML, ou l’intégration de SaaS opérant sur plusieurs clouds.
Un exemple cité concerne l’intégration de Salesforce Data 360, qui nécessite des ponts privés robustes entre différents environnements pour alimenter des cas d’usage d’IA et d’analytique sur des données réparties.
Pour les clients, les bénéfices mis en avant sont la réduction du temps de mise en service des liaisons, la simplification opérationnelle (moins de gestion d’infrastructure physique) et de meilleures garanties de performance que l’Internet public. L’approche standardisée doit aussi faciliter la gouvernance réseau et la sécurité dans des environnements multicloud complexes, où les architectures doivent concilier segmentation, conformité et performance de bout en bout.
Sous le feu des critiques des associations professionnelles et scrutés par les régulateurs, les deux grands CSP américains engagent un mouvement vers un modèle où la connectivité inter‑cloud devient un service managé de première classe, au même titre que le compute ou le stockage, plutôt qu’un assemblage de liens télécoms et de configurations spécifiques.
Reste à observer dans quelle mesure les autres fournisseurs adopteront la spécification proposée et comment les intégrateurs réseau et opérateurs télécoms adapteront leurs offres face à cette montée en puissance de la connectivité multicloud native.
Le plan de contrôle de Route 53 n’est plus tout à fait monorégion.
AWS l’a effectivement répliqué en partie. Et ainsi réduit la dépendance à la région cloud us-east-1.
En toile de fond, l’incident d’octobre. Il a pris racine dans cette région cloud, (re)mettant en lumière le point faible qu’elle constitue. Entre autres, donc, parce que quantité de services y ont leur plan de contrôle.
Une récupération « accélérée »…
La réplication partielle de celui de Route 53 se traduit par une option de « récupération accélérée ». On peut l’activer pour chaque zone hébergée publique (conteneur d’enregistrements définissant l’acheminement du trafic d’un domaine spécifique sur le réseau Internet). Une copie de la zone est alors conservée dans la région us-west-1.
… avec un RTO de 60 minutes
En cas d’indisponibilité prolongée dans la région us-east-1, une bascule est censée s’effectuer… dans un délai de 60 minutes. On n’a alors pas accès à l’ensemble des méthodes API. Mais les principales sont disponibles : listage des zones, des enregistrements et des ensembles de délégation, soumission et suivi de changements, etc.
En période de bascule, il n’est pas possible de créer de zones, ni d’en supprimer. On ne peut pas non plus (dés)activer la signature DNSSEC. Et les connexions AWS PrivateLink ne fonctionnent pas. Par après, pour supprimer une zone, il faut d’abord désactiver l’option de « récupération accélérée ». Laquelle, pour préciser, ne concerne pas le volet DNS privé de Route 53.
La Commission européenne lance trois enquêtes de marché sur les offres d’AWS et Microsoft Azure dans le cadre du Digital Markets Act (DMA) dont l’objectif est de limiter le pouvoir des grandes entreprises technologiques, désignées comme « contrôleurs d’accès » , et de garantir des conditions de concurrence équitables pour les rivaux plus petits.
Les investigations se décomposent en trois volets distincts :
Désignation en tant que « contrôleurs d’accès ». A travers deux enquêtes, la Commission va évaluer si Amazon Web Services (AWS) et Microsoft Azure doivent être désignés comme « contrôleurs d’accès » pour leurs services cloud.Si cette désignation est confirmée, ces services cloud seraient ajoutés à la liste des services de plateforme essentiels pour lesquels Amazon et Microsoft sont déjà considérés comme contrôleurs d’accès.
Efficacité du DMA dans le cloud. Cette troisième enquête vise à évaluer l’efficacité des obligations actuelles du DMA pour lutter contre les pratiques déloyales ou anticoncurrentielles dans le secteur du Cloud. L’examen porte notamment sur les obstacles à l’interopérabilité, l’accès limité aux données pour les entreprises utilisatrices, les services de vente liée et de groupage, ainsi que les clauses contractuelles potentiellement déséquilibrées.
Les critères de la DMA
Le DMA, entré en vigueur en 2023, définit un « contrôleur d’accès » comme une entreprise proposant un service de plateforme essentiel, avec plus de 45 millions d’utilisateurs actifs mensuels et une capitalisation boursière d’au moins 75 milliards € (86,87 milliards $). AWS est le plus grand fournisseur de cloud au niveau mondial, avec 30 %de parts de marché, suivi par Microsoft Azure (20%) et Google Cloud (13 %).
Les entreprises désignées comme « contrôleurs d’accès » sont tenues de rendre leurs services interopérables avec ceux de leurs concurrents et ne peuvent pas favoriser leurs propres services au détriment de ceux de leurs rivaux. En cas de violation du DMA, les entreprises encourent des amendes pouvant atteindre 10 % de leur chiffre d’affaires annuel mondial.
La cheffe de l’antitrust de l’UE, Teresa Ribera, a déclaré que la Commission cherchera également à déterminer si « les règles existantes du règlement sur les marchés numériques doivent être mises à jour afin que l’Europe puisse suivre le rythme de l’évolution rapide des pratiques dans le secteur de l’informatique en nuage ».
Un porte-parole de Microsoft a indiqué que l’entreprise était prête à contribuer à l’enquête.
Du côté d’AWS, on estime que « désigner les fournisseurs de cloud comme contrôleurs d’accès ne vaut pas le risque d’étouffer l’invention ou d’augmenter les coûts pour les entreprises européennes ».
La Commission veut conclure les deux enquêtes sur la désignation d’AWS et Azure dans un délai de 12 mois. L’enquête sur l’application du DMA aux marchés du cloud donnera lieu à la publication d’un rapport final dans un délai de 18 mois.
Signal repose en partie sur AWS… et cela en a surpris beaucoup.
Meredith Whittaker le constate et s’en étonne. La présidente de la Fondation Signal s’en inquiète même : et si la concentration du pouvoir dans les mains de quelques hyperscalers était moins perçue qu’elle ne le pensait ?
Que la panne AWS soit « une leçon »
« Pourquoi Signal utilise-t-il AWS ? » n’est pas la question, poursuit l’intéressée. Il faut mesurer ce que toute plate-forme globale de communication en temps réel exige en matière d’infrastructure. La voix et la vidéo, en particulier, requièrent une architecture complexe pour gérer gigue et perte de paquets. Ces choses-là, AWS, Azure et GCP les fournissent à grande échelle. Pas les autres, tout du moins dans un contexte occidental.
Une telle infrastructure coûte des milliards à provisionner et à maintenir, en plus d’être largement amortissable, fait remarquer Meredith Whittaker. C’est pourquoi « presque tous ceux qui gèrent un service temps réel » (elle mentionne Mastodon, X et Palantir) s’appuient au moins en partie sur ces sociétés.
« Même si on avait les milliards pour, ce n’est pas qu’une question d’argent« , ajoute-t-elle. L’expertise est rare. Et très concentrée. D’ailleurs, l’outillage, les playbooks et le langage même du SRE moderne émanent des hyperscalers.
Dans la pratique, 3 ou 4 acteurs ont la main sur l’entièreté de la stack, résume M. Whittaker. Dans ces conditions, Signal « fait au possible » pour garantir une intégrité dans l’écosystème où il se trouve, grâce à du chiffrement de bout en bout.
La panne AWS, sera espère-t-elle, une leçon ; une mise en lumière des risques que suppose la « concentration du système nerveux de notre monde dans les mains de quelques acteurs ».
Signal sur AWS : une publicité limitée
Jusque-là, Signal n’avait pas fait grande publicité de son utilisation d’AWS.
On en trouve quelques traces sur son GitHub. Entre autres dans un ticket ouvert début 2021.
Dans une période d’exode marqué vers Signal, un utilisateur qui cherchait à migrer depuis WhatsApp s’était plaint d’un bug avec les liens servant à rejoindre un groupe.
« N’est-ce pas possible de monter en charge ?« , avait demandé un autre utilisateur, croyant savoir que Signal utilisait AWS. Un des contributeurs au projet le lui avait confirmé.
CloudFront, utilisé pendant un temps pour contourner la censure
AWS est aussi apparu à quelques reprises sur le blog de Signal. Notamment en 2018, dans le cadre d’une mise au point sur le domain fronting.
Cette technique, fonctionnant au niveau de la couche application, est traditionnellement utilisée pour contourner la censure. Elle permet de se connecter par HTTPS à un service interdit, tout en paraissant communiquer avec un site différent.
Pour la mettre en œuvre, Signal s’est, pendant un temps, appuyé sur Google App Engine, profitant du fait que couche de terminaison TLS était séparée de celle traitant les requêtes. Il l’a appliqué en Égypte, à Oman, au Qatar et aux Émirats arabes unis. Pour continuer à bloquer Signal, ces pays auraient dû bloquer google.com. Un pas qu’ils n’ont pas franchi.
La situation fut différente pour l’Iran. En application des sanctions américaines, Google n’autorisait pas le traitement, dans App Engine, de requêtes issues de ce pays. Mis sous pression pour lever cette interdiction, il avait, au contraire, fermé la porte au domain fronting au niveau mondial.
Signal s’était alors rabattu sur CloudFront, qui hébergeait quelques-uns des domaines les plus populaires (top 100 Alexa) dans les régions en question. Le projet étant open source, Amazon avait fini par avoir vent de la bascule… et avait rapidement fermé lui aussi les vannes du domain fronting.
Un an après l’annonce de son lancement, Amazon Web Services (AWS) a annoncé la mis en service de Rainier, son cluster de calcul haute performance, dont l’infrastructure est répartie sur plusieurs centres de données aux États-Unis.
Le projet s’appuie sur les puces Trainium2, développées en interne par Amazon pour l’apprentissage automatique. Environ 500 000 unités sont intégrées dans la première phase du cluster, interconnectées via un réseau à très faible latence destiné à optimiser les échanges entre nœuds de calcul.
AWS met en avant la scalabilité et la résilience multi-site de l’ensemble. Le cœur du dispositif se situe dans l’État de l’Indiana, où Amazon investit plus de 11 milliards $ dans un centre de données de nouvelle génération. D’autres installations complémentaires sont prévues sur plusieurs sites américains afin d’assurer la continuité de service et la répartition de la charge.
Anthropic, premier utilisateur du cluster
Le principal client identifié est Anthropic, concepteur du LLM Claude, qui exploitera Rainier pour l’entraînement de ses modèles de grande taille, avec un objectif d’utilisation de plus d’un million de puces Trainium2 d’ici fin 2025.
Avec Rainier, Amazon renforce son positionnement dans le cloud haute performance et les infrastructures d’IA. Le groupe entend se placer comme un fournisseur clé d’environnement d’entraînement à grande échelle, aux côtés des autres hyperscalers qui développent également leurs propres architectures dédiées.
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
