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

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

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

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

Compute

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

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

Stockage

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

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

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

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

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

Réseau

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

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

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

Bases de données

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

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

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

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

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

Analytics

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

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

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

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

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

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

IA/ML

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

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

Conteneurs

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

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

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

Sécurité, identité, conformité

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

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

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

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

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

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

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

Gestion, gouvernance

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

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

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

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

Illustration générée par IA

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

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

> Les dépendances numériques de l’UE chiffrées, GenAI comprise
Les grandes entreprises européennes orientent près 83 % de leurs budgets IT vers des acteurs américains.

> Dépendances numériques : l’exemple de la cyber dans le secteur de l’énergie
La dépendance de l’UE à des logiciels étrangers trouve une illustration avec les solutions cyber déployées dans le secteur de l’énergie.

The post Souveraineté numérique de l’UE : état des lieux et enjeux stratégiques appeared first on Silicon.fr.

Cyberattaque CodeRED : alertes d’urgence stoppées dans plus de dix États, fuite de mots de passe et bascule vers IPAWS....

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.

Illustration principale © Aryan – Adobe Stock

The post Fonctions durables, instances managées… AWS Lambda devient plus flexible appeared first on Silicon.fr.

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 preview depuis 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.

Illustration principale générée par IA

The post AWS re:Invent : l’AI Factory, une grammaire désormais légitime ? appeared first on Silicon.fr.

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.

De son côté, AWS a lancé (en préview) AWS Interconnect – multicloud pour proposer des connexions privées depuis AWS vers d’autres fournisseurs de cloud.​

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.​

The post AWS et Google Cloud créent un pont multicloud appeared first on Silicon.fr.

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.

Illustration générée par IA

The post AWS fait un pas vers un DNS plus résilient appeared first on Silicon.fr.

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é.

Cet article Panne AWS mondiale : reprise progressive confirmée par Amazon est apparu en premier sur Linformatique.org.

— Permalien

— Permalien