Comparaison des offres de connectivité privée de Google Cloud, Microsoft Azure et AWS

Nous expliquons ici les différences en matière de connectivité privée entre ces hyperscalers majeurs.

Du fait de l’adoption en forte croissance des stratégies multicloud, comprendre les modèles de connectivité privée proposés par ces hyperscalers devient de plus en plus primordial. La connectivité privée peut, dans de nombreux cas, permettre d’augmenter le débit de bande passante, de réduire les coûts globaux liés au réseau et d’offrir une expérience réseau plus prévisible et stable que les connexions Internet. Que vous souhaitiez passer au niveau supérieur en bénéficiant de la connectivité privée avec un nouveau fournisseur de services cloud (CSP) ou vous débarrasser de votre bon vieux VPN Internet, cet article vous aide à comprendre les différents modèles de connectivité existants, la terminologie spécifique mais aussi les composants des offres de connectivité privée de Google Cloud Platform (GCP), Microsoft Azure et Amazon Web Services (AWS).

Ces fournisseurs de services cloud utilisent une terminologie qui n’est pas toujours identique. Commençons par expliciter certains termes employés par ces trois CSP.

Maintenant que nous connaissons mieux la terminologie utilisée par les CSP, entrons dans le vif du sujet. Nous allons d’abord nous pencher sur AWS Direct Connect.

AWS Direct Connect

Les principaux composants d’AWS Direct Connect sont les interfaces virtuelles (VIF), le circuit physique/Direct Connect et les passerelles – qui sont de trois types : les passerelles privées virtuelles (VGW), les passerelles Direct Connect (DGW/DXGW) et les passerelles de transit (TGW).

AWS Direct Connect propose divers modèles de connectivité : connexions dédiées, connexions hébergées et VIF hébergées. Afin de choisir la solution la plus adaptée à votre entreprise et à votre cas d’utilisation, il convient de bien comprendre chacun des trois modèles.

Connexion dédiée : il s’agit d’une connexion physique demandée via la console AWS et associée à un seul utilisateur. Vous obtenez votre Lettre d’autorisation-Affectation d’installation de connexion (LOA-CFA) et travaillez avec votre opérateur de centre de données ou partenaire AWS pour établir une connexion transversale entre votre équipement et AWS. Les vitesses de port disponibles sont 1 Gbit/s et 10 Gbits/s.

Connexion hébergée : il s’agit d’une connexion physique qu’un partenaire AWS Direct Connect provisionne pour le compte d’un client. Les clients font une demande de connexion hébergée en contactant le partenaire AWS qui provisionne la connexion. Les vitesses disponibles sont 50 Mbits/s, 100 Mbits/s, 200 Mbits/s, 300 Mbits/s, 400 Mbits/s, 500 Mbits/s, 1 Gbit/s, 2 Gbits/s, 5 Gbits/s et 10 Gbits/s.

VIF hébergée : il s’agit d’une interface virtuelle provisionnée pour un client par le compte qui possède un circuit physique Direct Connect. La bande passante est partagée par toutes les VIF sur la connexion parent.

Contrairement aux autres CSP, AWS propose différents types de passerelles pouvant être utilisés avec Direct Connect : les passerelles privées virtuelles, les passerelles Direct Connect et les passerelles de transit.

Passerelle privée virtuelle (VGW) : il s’agit d’une fonction de routage de périphérie logique, entièrement redondante et distribuée qui est liée à un VPC afin de permettre un routage privé du trafic depuis et vers le VPC.

Passerelle Direct Connect (DGW) : une passerelle Direct Connect est une ressource disponible dans le monde entier qui peut être utilisée pour relier plusieurs VPC à un seul ou plusieurs circuits Direct Connect. Toutefois, cette passerelle ne fournit pas de connectivité entre les VPC.

Passerelle de transit (TGW) : une passerelle de transit connecte vos VPC à des réseaux sur site via un hub central. Cela simplifie votre réseau et met fin aux relations de peering complexes.

Le type de passerelle que vous utilisez et le type de ressources publiques ou privées auxquelles vous voulez accéder à terme détermineront le type de VIF à utiliser.

Explorons les trois différents types de VIF : VIF privée, publique et de transit.

VIF privée – Interface virtuelle privée : elle est utilisée pour accéder à un VPC Amazon en utilisant des adresses IP privées. Vous pouvez annoncer jusqu’à 100 préfixes à AWS.

Remarque : vous pouvez relier une VIF privée à une passerelle privée virtuelle (VGW) ou à une passerelle Direct Connect (DGW).

VIF publique – Interface virtuelle publique : une interface virtuelle publique peut accéder à tous les services publics AWS en utilisant des adresses IP publiques (S3, DynamoDB). Vous pouvez annoncer jusqu’à 1 000 préfixes à AWS.

Remarque : les VIF publiques ne sont pas associées ou liées à un type de passerelle en particulier.

• Connectez-vous à toutes les adresses IP publiques AWS à l’échelle mondiale (adresse IP publique requise pour le peering BGP).
• Accédez aux services Amazon routables publiquement dans toutes les régions AWS (à l’exception de la région AWS Chine).

VIF de transit – Interface virtuelle de transit : une interface virtuelle de transit est utilisée pour accéder à un ou plusieurs VPC Amazon via une passerelle de transit qui est associée à une passerelle Direct Connect. Vous pouvez utiliser des interfaces virtuelles de transit avec des connexions Direct Connect AWS de 1/2/5/10 Gbits/s et vous pouvez annoncer jusqu’à 100 préfixes à AWS.

Azure ExpressRoute

Que vous utilisiez ExpressRoute Direct ou le modèle de partenaire, les composants principaux restent les mêmes : les peerings (privés ou Microsoft), les passerelles VNet et le circuit ExpressRoute physique***.*** Contrairement aux autres CSP, chaque Azure ExpressRoute comprend deux circuits pour la haute disponibilité/la redondance et à des fins de SLA.

Tout comme les modèles AWS dédiés et hébergés, Azure a ses propres offres similaires d’ExpressRoute Direct et de partenaire ExpressRoute.

Avec ** ** Azure ExpressRoute Direct, le client est propriétaire du port ExpressRoute et la LOA-CFA est fournie par Azure. Les connexions transversales par fibre sont commandées par le client dans son centre de données. Les débits de port pris en charge sont des interfaces de 10 Gbits/s ou 100 Gbits/s.

Avec le modèle de partenaire ExpressRoute**, le fournisseur de services se connecte au port ExpressRoute. La LOA-CFA est fournie par Azure au fournisseur de services ou au partenaire. Les connexions transversales par fibre sont provisionnées par le partenaire. Le client travaille avec le partenaire pour provisionner les circuits ExpressRoute en utilisant les connexions que le partenaire a déjà configurées ; le fournisseur de services est propriétaire des connexions physiques à Microsoft. Les clients peuvent créer des ExpressRoutes avec la bande passante suivante : 50 Mbits/s, 100 Mbits/s, 200 Mbits/s, 500 Mbits/s, 1 Gbit/s, 2 Gbits/s, 5 Gbits/s ou 10 Gbits/s.**

Azure propose également un modèle de connectivité unique appelé ExpressRoute Local. Faisant figure d’exception comparé aux autres modèles de connectivité des CSP, ExpressRoute Local permet aux clients Azure de se connecter à un emplacement de pair Azure spécifique. La connexion à une ou deux régions locales associées au pair offre l’avantage supplémentaire d’une utilisation illimitée des données. Pour obtenir plus de détails sur ExpressRoute Local, lisez notre article de blog récent : Éviter le choc provoqué par la facture cloud avec Azure ExpressRoute Local et Megaport.

Azure propose deux types de peering que nous pouvons comparer aux modèles semblables de VIF privée et de VIF publique d’AWS.

Peering privé — Le peering privé prend en charge les connexions depuis un centre de données privé/sur site d’un client afin d’accéder à ses réseaux virtuels Azure (VNets).

• Accédez aux services Azure Compute, principalement aux machines virtuelles (IaaS) et aux services cloud (PaaS), qui sont déployés au sein d’un réseau virtuel (VNet).
• Adresses IP privées utilisées pour le pair (RFC-1918). Les clients auront besoin d’un CIDR /28 divisé en deux CIDR /30 : un pour le pair primaire et un pour le pair secondaire.
• Le peering privé est pris en charge via des connexions logiques. Le BGP est établi entre les appareils sur site du client et les routeurs Microsoft Enterprise Edge (MSEE).

Remarque : L’emplacement des MSEE auxquels vous allez vous appairer est déterminé par l’emplacement de peering qui a été sélectionné lors du provisionnement de l’ExpressRoute.

• En fonction de la référence SKU ExpressRoute sélectionnée, un seul pair privé peut prendre en charge plus de dix VNets dans plusieurs régions géographiques.
• Le nombre maximal de préfixes pris en charge par peering est de 4 000 par défaut ; ce nombre peut atteindre 10 000 pour la SKU premium.

Peering Microsoft — Le peering Microsoft est utilisé pour la connexion aux ressources publiques Azure telles que le stockage Blob. La connectivité aux services en ligne Microsoft (services PaaS Azure et Office 365) a lieu via le peering Microsoft.

• Office 365 a été créé pour être accessible en toute sécurité et fiabilité via Internet. L’approbation de Microsoft est requise pour recevoir des routes O-365 via ExpressRoute.
• Des filtres de route doivent être créés avant que les clients ne reçoivent des routes via le peering Microsoft. Les communautés BGP sont utilisées avec des filtres de route afin de recevoir des routes pour les services client.

Avec Azure ExpressRoute, il n’y a qu’un seul type de passerelle : la passerelle VNet.

Passerelle VNet : une passerelle VNet est une fonction de routage logique similaire à VGW d’AWS. La passerelle VNet ExpressRoute est utilisée pour envoyer du trafic réseau sur une connexion privée en utilisant la passerelle de type « ExpressRoute ». Elle est également appelée « passerelle ExpressRoute ».

Avec une Azure ExpressRoute standard, plusieurs VNets peuvent être liés nativement à un seul circuit ExpressRoute dans un modèle en étoile, ce qui permet d’accéder à des ressources sur plusieurs VNets via un seul circuit. De ce fait, l’offre Azure ExpressRoute standard est considérée comme étant comparable au modèle de passerelle AWS Direct Connect.

Google Cloud Interconnect

Pour finir, la dernière option de connectivité privée de CSP que nous allons présenter est l’interconnexion GCP. Heureusement pour nous, la connectivité et les composants de GCP en font probablement la solution la plus simple des trois CSP.

Tout comme AWS et Azure, GCP propose à la fois des modèles d’interconnexion partenaire et d’interconnexion dédiée.

Interconnexion dédiée : l’interconnexion dédiée GCP fournit une connexion physique directe entre votre réseau sur site et le réseau de Google. Comme pour les autres CSP, vous obtenez la LOA-CFA de GCP et collaborez avec votre fournisseur de colocations/opérateur de centre de données pour configurer la connexion transversale.

• Une interface de 10 Gbits/s ou 100 Gbits/s dédiée à l’adressage lien-local IPv4 de client (les adresses de peering doivent être sélectionnées dans la plage 169.254.0.0/16)
• LACP, même si vous utilisez un circuit unique EBGP-4 avec des VLAN 802.1Q à sauts multiples

Interconnexion partenaire : tout comme l’interconnexion dédiée, l’interconnexion partenaire fournit la connectivité entre votre réseau sur site et votre réseau VPC via un fournisseur ou un partenaire. Une interconnexion partenaire est idéale si votre centre de données se trouve dans un autre établissement que la colocation d’interconnexion dédiée, ou si vos besoins de données ne justifient pas une connexion 10 Gbits/s entière.

La seule option de passerelle pour l’interconnexion GCP est le Google Cloud Router.

Google Cloud Router : un Cloud Router échange de manière dynamique des routes entre votre réseau VPC et votre réseau sur site en utilisant le Border Gateway Protocol (BGP).

Un GCP Cloud Router est non seulement restreint à un seul VPC, mais également à une seule région de ce VPC. Considérez cela comme une relation ou un mappage un à un. Au Google Cloud Router s’ajoutent les configurations de peering, que GCP appelle « rattachements VLAN ».

Rattachements VLAN : également connu sous le nom de rattachement d’interconnexion, un rattachement VLAN est une connexion logique entre votre réseau sur site et une seule région au sein de votre réseau VPC. Contrairement à Azure et AWS, GCP propose uniquement une option de peering privé via son interconnexion. Pour accéder aux services publics et aux API de GCP, vous pouvez configurer l’accès privé à Google via votre interconnexion afin de répondre aux besoins de vos hôtes sur site. Toutefois, l’accès privé à Google n’active pas la connectivité G Suite. Pour accéder à G Suite, vous devrez configurer une connexion/un peering vers cette solution via un échange Internet (IX) ou accéder à ces services via Internet.

Points-clés

Venons-en à la conclusion en revenant sur les points essentiels. Nous espérons que vous comprenez maintenant en détail les différentes options de connectivité privée proposées par ces CSP.

AWS Direct Connect comprend plusieurs types de passerelle et modèles de connectivité qui peuvent être utilisés pour accéder à des ressources publiques et privées depuis votre infrastructure sur site. En fonction de votre cas particulier et de vos perspectives, l’accès se fera sous forme d’une passerelle de transit associée à une passerelle Direct Connect ou d’un mappage un à un depuis une VIF privée vers une VGW.

Avec Azure ExpressRoute, vous pouvez configurer à la fois un peering Microsoft (pour accéder aux ressources publiques) et un peering privé via la connexion logique unique de couche 2. Chaque ExpressRoute est fournie avec deux circuits configurables. Avec l’ExpressRoute standard, vous pouvez connecter plusieurs VNets situés dans la même région géographique vers un seul circuit ExpressRoute et configurer une SKU premium (portée mondiale) pour assurer la connectivité depuis n’importe quel VNet dans le monde vers le même circuit ExpressRoute.

GCP propose un modèle de connectivité facile à comprendre. L’interconnexion GCP permet uniquement d’accéder nativement à des ressources privées. Si la connectivité à des ressources publiques GCP (telles que le stockage cloud) est requise, vous pouvez configurer un accès privé à Google pour vos ressources sur site. Cela n’inclut pas G Suite, l’offre SaaS de GCP. Pour accéder à G Suite, vous pouvez toujours naviguer sur l’Internet public ou configurer un peering vers la solution via une IX. Comme le GCP Cloud Router présente un mappage 1:1 avec un seul VPC et une seule région, les peerings (ou plutôt les attachements VLAN) sont créés en plus du Cloud Router. Cette fonctionnalité et ce modèle sont similaires à AWS Direct Connect et à la création directe d’une VIF sur une VGW.

Puisque vous avez lu cet article jusqu’ici, je finirai en précisant que Megaport peut non seulement vous connecter à ces trois CSP (et à bien d’autres), mais que nous pouvons également garantir une connectivité cloud à cloud entre les fournisseurs sans avoir besoin de réaliser un backhaul de ce trafic vers votre infrastructure sur site.

Ainsi, n’hésitez pas à nous contacter. Nous serions ravis de connaître votre parcours cloud et les défis que vous rencontrez afin de savoir comment nous pouvons vous aider.