Vue lecture

AWS et Google Cloud créent un pont multicloud

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.

  •  

AWS fait un pas vers un DNS plus résilient

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.

  •  

Panne AWS mondiale : reprise progressive confirmée par Amazon

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.

  •  
❌