Par Aurélie, M2M Network.

En bref : une interconnexion cloud privée relie un réseau d’entreprise à un cloud public (AWS, Microsoft Azure, Google Cloud, OVHcloud, Oracle Cloud) par un circuit qui ne passe pas par l’Internet public. Les fournisseurs d’interconnexion, que le marché appelle aussi Network as a Service (NaaS) ou échanges cloud (cloud exchange), vendent ce raccordement à la demande : un port physique dans un datacenter, puis une connexion virtuelle vers l’entrée privée de chaque cloud. Un opérateur de cartes SIM raccordé à l’un d’eux peut ainsi relivrer le trafic de son APN privé (réseau mobile) directement dans le réseau privé que son client exploite chez le cloud, sans adresse publique ni transit par Internet.

Ce guide s’adresse aux DSI, architectes cloud, responsables réseau et intégrateurs IoT qui envoient les données d’un parc d’objets connectés vers AWS, Azure ou un cloud français et cherchent un raccordement privé au cloud pour ce parc IoT.

Qu’est-ce qu’une interconnexion cloud privée ?

Chaque grand cloud propose une porte d’entrée réseau distincte de l’Internet public. AWS présente AWS Direct Connect comme une connexion réseau dédiée vers AWS et précise que le trafic reste, pendant son transit, sur le réseau mondial d’AWS sans jamais toucher l’Internet public. Microsoft décrit Azure ExpressRoute comme le moyen d’étendre ses réseaux locaux au cloud Microsoft « au moyen d’une connexion privée avec l’aide d’un fournisseur de connectivité ». Google Cloud indique pour Cloud Interconnect que le trafic entre les réseaux du client et les siens ne traverse pas l’Internet public. OVHcloud résume l’effet recherché avec OVHcloud Connect : « Vos données ne sont plus exposées au réseau public ».

Deux manières d’atteindre ces entrées coexistent. La première est une connexion physique directe : le client installe un équipement dans un emplacement de raccordement du cloud et commande une connexion croisée (cross-connect) jusqu’à ses routeurs ; AWS vend ainsi des ports dédiés de 1, 10 ou 100 Gbit/s, et Microsoft propose ExpressRoute Direct en 10, 100 ou 400 Gbit/s. La seconde passe par un partenaire déjà raccordé, qui découpe sa liaison en connexions plus petites : chez AWS, ces connexions hébergées vont de 50 Mbit/s à 25 Gbit/s, sur un lien partagé par plusieurs clients. C’est ce second modèle qu’exploitent les fournisseurs d’interconnexion.

Ces emplacements de raccordement sont distincts des régions où tournent les serveurs : Microsoft précise qu’un emplacement ExpressRoute, site de colocation où sont installés ses routeurs, n’a pas besoin de correspondre à la région Azure utilisée. En France, Microsoft en liste trois (Paris, Paris2, Marseille) et AWS trois pour sa région de Paris.

Les entrées privées des clouds : nom et ce qu’elles relient

CloudEntrée privéeCe qu’elle relieDébits publiés
AWSAWS Direct ConnectLe réseau du client à AWS, par des interfaces virtuelles (VIF) privées, publiques ou de transitConnexion dédiée : 1, 10 ou 100 Gbit/s ; connexion hébergée par un partenaire : 50 Mbit/s à 25 Gbit/s
MicrosoftAzure ExpressRouteLes réseaux locaux aux services cloud Microsoft (Azure, Microsoft 365), avec un routage dynamique BGPCircuit : 50 Mbit/s à 10 Gbit/s ; ExpressRoute Direct : 10, 100 ou 400 Gbit/s
Google CloudCloud Interconnect (Dedicated, Partner, Cross-Cloud)Le réseau sur site, ou un réseau situé dans un autre cloud, aux réseaux VPC de Google CloudPartner Interconnect : rattachements de 50 Mbit/s à 50 Gbit/s
OVHcloudOVHcloud ConnectLe réseau sur site au vRack, le réseau privé qui relie les ressources OVHcloud entre ses centres de donnéesDe 50 Mbit/s garantis à 100 Gbit/s garantis
OracleOCI FastConnectLe centre de données du client à Oracle Cloud Infrastructure : réseau virtuel (VCN) en peering privé, services publics en peering publicPar un partenaire Oracle : ports de 1, 10 ou 100 Gbit/s ; par un fournisseur tiers ou en colocation : jusqu’à 400 Gbit/s

Le principe reste le même partout : un circuit privé, une session de routage avec le cloud, un débit choisi par paliers. Quatre de ces clouds publient un premier palier à 50 Mbit/s pour les raccordements par partenaire, sans achat d’un port complet.

À quoi sert un fournisseur d’interconnexion (Network as a Service)

Un fournisseur d’interconnexion exploite un réseau privé présent dans de nombreux datacenters et déjà raccordé aux entrées privées des clouds. Ses clients achètent un accès à ce réseau plutôt que des liaisons vers chaque cloud. Le MEF, association internationale de fournisseurs de réseau, de cloud et de sécurité, a publié en octobre 2023 une définition du Network as a Service : de la connectivité à la demande, de la garantie de performance applicative, de la cybersécurité et des services multicloud, fournis dans un écosystème automatisé et normalisé. Microsoft parle, lui, d’échange cloud : dans un datacenter qui en dispose, on peut demander des connexions croisées virtuelles vers son cloud, de niveau 2 ou de niveau 3 managées.

Les quatre briques d’une offre NaaS

  • Le port : une interface Ethernet à haut débit, dans un datacenter où le fournisseur est présent, qui relie l’équipement du client (ou de son opérateur) au réseau du fournisseur. C’est la seule partie physique de l’ensemble.
  • La connexion virtuelle : un circuit logique entre deux points du réseau du fournisseur, par exemple entre le port et l’entrée privée d’un cloud. Plusieurs connexions virtuelles partagent le même port, chacune avec son propre débit, d’un mégabit par seconde à plusieurs gigabits selon le fournisseur et le datacenter.
  • Le routeur cloud virtuel : un service de routage de niveau 3, sans matériel à installer, qui réunit dans un même domaine de routage des connexions vers plusieurs clouds. Il sert à relier deux clouds entre eux, ou plusieurs régions d’un même cloud, sans repasser par les locaux du client.
  • La mise en service à la demande : les connexions se créent et se modifient depuis un portail ou une API ; un fournisseur annonce moins d’une minute par connexion, un autre quelques minutes pour déployer un routeur virtuel. Côté cloud, il reste à accepter la connexion : AWS n’active une connexion hébergée qu’après cette acceptation.

L’intérêt tient en une phrase : un seul port donne accès à tous les clouds présents sur le réseau du fournisseur, et relier le parc à un deuxième cloud revient à ajouter une connexion virtuelle. Google Cloud propose aussi, de son côté, Cross-Cloud Interconnect, une connexion physique directe entre un réseau situé dans un autre cloud et ses réseaux VPC.

Qui sont les fournisseurs d’interconnexion

Le plus fiable est de lire les listes publiées par les clouds eux-mêmes. Pour sa région de Paris, AWS cite parmi ses partenaires Direct Connect, entre autres, Colt, Console Connect, Equinix, InterCloud, Megaport et Orange Business Services, sur trois emplacements : Telehouse Voltaire, Equinix PA3 et Digital Realty PAR7. Microsoft liste pour ExpressRoute à Paris (Digital Realty PAR5) des fournisseurs comme Colt, Console Connect, Equinix, InterCloud, Megaport et Orange, dont la plupart se retrouvent à Paris2 (Equinix), et à Marseille (Digital Realty MRS3) Colt, DE-CIX, Interxion (Digital Realty) et Jaguar Network. OVHcloud nomme Digital Realty, Colt Technology Services, Console Connect et Megaport comme partenaires d’OVHcloud Connect. Chaque offre porte un nom commercial (Equinix Fabric, par exemple), mais toutes reposent sur les briques décrites plus haut.

Comment un opérateur de cartes SIM relivre le trafic dans le cloud

Côté réseau mobile, tout commence à l’APN, le nom du point d’accès sur lequel la carte SIM ouvre sa session de données. En 4G, la passerelle P-GW de l’opérateur termine cette session et fait sortir le trafic par le point de référence SGi, que la norme 3GPP TS 29.061 définit comme l’interface entre le réseau mobile et le réseau de données externe. En 5G, ce rôle revient à l’UPF et au point de référence N6 (3GPP TS 23.501), et l’APN devient le DNN, que la norme déclare équivalent.

La suite n’est pas imposée par la norme. Pour l’accès à l’intranet d’une entreprise, la 3GPP TS 29.061 donne au terminal une adresse de l’espace d’adressage de l’entreprise, puis admet que la liaison entre le réseau mobile et l’intranet emprunte n’importe quel réseau, même Internet, auquel cas un protocole de sécurité peut être convenu entre l’opérateur et le client. Ce chemin est donc un choix d’architecture : tunnel IPsec sur Internet, VPN MPLS, liaison de niveau 2 ou interconnexion cloud privée.

Pour relivrer le trafic dans un cloud, l’opérateur raccorde son cœur de réseau, là où sort le trafic de ses APN, à un port chez un fournisseur d’interconnexion. La chaîne se décrit alors en cinq étapes :

  1. les cartes SIM du parc se rattachent à un APN privé dédié au client, qui leur attribue des adresses de son plan d’adressage ;
  2. en sortie de passerelle, le trafic de ce client est isolé dans une table de routage qui lui est propre, ce que la RFC 4364 (VPN IP sur BGP et MPLS) appelle une VRF ;
  3. il traverse un filtrage qui n’autorise que les flux attendus entre les objets et les services cloud ;
  4. il emprunte une connexion virtuelle, sur le port de l’opérateur, jusqu’à l’entrée privée du cloud choisi ;
  5. une session BGP échange les routes, comme le documentent Microsoft pour ExpressRoute et OVHcloud pour OVHcloud Connect : le réseau privé du client chez le cloud apprend la plage d’adresses de l’APN, et inversement.

À aucune étape le trafic ne prend d’adresse publique ni ne transite par l’Internet public : il passe du réseau de l’opérateur à celui du fournisseur d’interconnexion, puis à celui du cloud, où les serveurs voient les objets avec leurs adresses privées.

Ce qu’il faut pour relier un parc de cartes SIM à un cloud

  1. Un APN privé dédié au parc, ou un DNN dédié en 5G, qui attribue aux cartes SIM des adresses de votre plan d’adressage. La norme 3GPP TS 23.501 range ce montage parmi les réseaux non publics fournis par un opérateur, par exemple au moyen de DNN dédiés.
  2. Un plan d’adressage sans chevauchement entre la plage de l’APN et les réseaux privés du cloud (réseaux VPC chez Google Cloud, réseau virtuel chez Azure, vRack chez OVHcloud, VCN chez Oracle), sans quoi les routes échangées entrent en conflit.
  3. Un compte cloud et le choix de l’entrée privée (AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect, OVHcloud Connect ou OCI FastConnect), dans un emplacement de raccordement où l’opérateur et le cloud sont tous deux présents.
  4. Une connexion virtuelle dimensionnée sur le trafic cumulé du parc, et non sur celui d’un objet, en partant des paliers publiés par le cloud.
  5. L’acceptation de la connexion côté cloud : chez AWS, une connexion hébergée n’est active qu’après acceptation par le client, et elle ne porte qu’une seule interface virtuelle (privée, publique ou de transit).
  6. Un filtrage des flux entre les objets et le cloud, en liste blanche : seuls les destinations et les ports utiles passent. Le principe est détaillé dans notre page sur le pare-feu des flux de cartes SIM.
  7. De la redondance : Microsoft compose chaque circuit ExpressRoute de deux connexions vers deux routeurs, et recommande pour une résilience maximale deux circuits dans deux emplacements de peering.
  8. Un chiffrement adapté aux données : une liaison privée isole le trafic de l’Internet public, le chiffrement est une autre question. L’ANSSI recommande de protéger les flux sensibles entre un système connecté et les réseaux externes en confidentialité et en intégrité par des moyens cryptographiques à l’état de l’art (R23 du guide ANSSI-PA-087).

Interconnexion cloud privée ou VPN IPsec : comment choisir

Microsoft range ExpressRoute et sa passerelle VPN dans une même catégorie, la connectivité hybride. Un tunnel IPsec entre l’opérateur, ou le routeur 4G du site, et une passerelle VPN du cloud chiffre le trafic mais le fait passer par Internet ; notre guide du VPN 4G pour site distant détaille ce montage côté routeur.

L’interconnexion cloud privée prend l’avantage quand le parc alimente plusieurs clouds, quand une politique interne interdit le transit par Internet, ou quand la latence doit rester stable : Microsoft avance pour ExpressRoute « une plus grande fiabilité, des vitesses plus rapides, des latences cohérentes et une sécurité plus élevée que les connexions classiques sur Internet ». En contrepartie, elle se commande par paliers de débit et engage trois réseaux : l’opérateur, le fournisseur d’interconnexion et le cloud. Les deux approches se combinent : un tunnel chiffré peut circuler dans une interconnexion privée.

Ce que propose M2M Network

M2M Network propose un réseau privé de cartes SIM : les cartes de chaque client sont séparées dans des APN dédiés, leurs flux passent par des pare-feu que le client administre lui-même, puis restent dans des VPN, des MPLS ou des VPLS jusqu’à ses sites, ou sont relivrés par une interconnexion cloud privée directement dans ses environnements AWS, Azure, OVHcloud et d’autres clouds, sans passer par Internet. L’APN privé classique reste proposé pour les besoins plus simples. Pour héberger les serveurs en France, le groupe MUONA dispose aussi de Guardis, infrastructure certifiée ISO 27001 et HDS que l’APN privé peut joindre sans passer par l’Internet public. Chaque raccordement s’étudie au cas par cas : contactez-nous pour décrire votre parc et votre cloud cible.

Cette offre de réseau privé de cartes SIM, du pare-feu jusqu’au cloud, s’appelle M2M Cloud Connect.

À lire aussi

Questions fréquentes

Qu’est-ce que le Network as a Service (NaaS) ?

Le Network as a Service désigne un réseau consommé comme un service : on achète un accès au réseau d’un fournisseur plutôt que ses propres liaisons, et on y crée des connexions à la demande. Le MEF, association professionnelle du secteur, l’a défini en octobre 2023 comme un ensemble de connectivité à la demande, de garantie applicative, de cybersécurité et de services multicloud dans un écosystème automatisé. Dans l’interconnexion cloud, il prend la forme d’un port dans un datacenter et de connexions virtuelles vers chaque cloud.

Quelle différence entre une interconnexion cloud privée et un VPN IPsec vers le cloud ?

Le VPN IPsec chiffre le trafic mais le fait passer par Internet. L’interconnexion cloud privée emprunte des réseaux privés de bout en bout (opérateur, fournisseur d’interconnexion, cloud) sans transit par l’Internet public. Les deux se combinent : un tunnel chiffré peut circuler dans une interconnexion privée quand les données sont sensibles.

Quel débit minimal pour relier des objets connectés à un cloud en privé ?

AWS (connexion hébergée), Microsoft (circuit ExpressRoute), Google Cloud (Partner Interconnect) et OVHcloud (OVHcloud Connect) publient tous un premier palier à 50 Mbit/s pour les raccordements par partenaire. Oracle annonce des ports de 1, 10 ou 100 Gbit/s pour FastConnect via ses partenaires. Le débit se dimensionne sur le trafic cumulé du parc, pas sur celui d’un objet.

Faut-il installer un équipement dans un datacenter ?

Il faut un port physique dans un datacenter où le fournisseur d’interconnexion est présent, mais ce port peut être celui de l’opérateur de cartes SIM. Dans ce cas, le client n’installe rien : il dispose d’un compte cloud, accepte la connexion proposée (AWS l’exige pour une connexion hébergée) et configure son réseau privé chez le cloud.

Peut-on relier un même parc de cartes SIM à deux clouds ?

Oui : soit une connexion virtuelle par cloud sur le même port, soit un routeur cloud virtuel qui réunit les connexions vers plusieurs clouds dans un même domaine de routage. Il faut alors un plan d’adressage cohérent entre l’APN et les réseaux privés de chaque cloud, sans plages qui se chevauchent.

Une interconnexion cloud privée chiffre-t-elle les données ?

Les clouds présentent leurs entrées privées comme des connexions qui évitent l’Internet public ; AWS cite à part plusieurs options de chiffrement pour Direct Connect. Pour les données sensibles, l’ANSSI recommande une protection cryptographique des flux entre un système connecté et les réseaux externes (R23 du guide ANSSI-PA-087), par exemple un chiffrement dans l’application ou un tunnel IPsec dans la liaison privée.

Sources