Topologies réseau Azure et estimation des coûts de transfert de données pour les architectes

 

 

Le choix d’une topologie de réseau peut être délicat. C’est encore plus vrai si l’on intègre le modèle de coût à l’équation : dans un modèle de paiement à la consommation basé sur la capacité (bande passante allouée par heure) et sur le trafic généré (en Go), la conception choisie peut avoir des conséquences significatives sur la facture.

 

Cet article se basera sur une topologie de réseau mondial créée à partir de plusieurs architectures de référence bien connues utilisant un ensemble de services réseau Azure. À partir de ce scénario, nous allons estimer le coût du trafic sur les différentes sections de la topologie. 

 

Topologies réseau Azure et scénarii d’estimation des coûts

 

Dans cette étude de cas, il y a deux centres de données situés l’un dans la région LATAM et l’autre dans la région EMEA. Ces centres de données sont connectés à plusieurs VNET dans Azure, via deux hubs déployés dans les régions Azure USA Est et Europe Ouest. Ce modèle s’appuie sur deux schémas de référence pour la connectivité des centres de données :

 

 

• Le schéma « cloud hybride», qui permet une connexion privée entre les centres de données et Azure via un tunnel VNP ou un circuit Azure ExpressRoute
• Le schéma « hub-and-spoke» qui permet une connexion privée entre des centaines de réseaux virtuels (VNET) dans le cloud et le centre de données, via des hubs centraux

 

Estimons à présent le coût de transfert des données dans chacun de ces chemins réseau, numérotés de 1 à 5. Les estimations de coût sont réalisées avec la Calculatrice de prix Azure, sur la base des tarifs publics d’août 2019. L’objectif est ici de démontrer l’impact des modèles de réseau sur les coûts de transfert des données. Noter que nous nous intéressons uniquement aux coûts de transfert des données. Le cas d’usage se base sur le transfert de données entre la VM 1 et 2 et réciproquement (4 To de la VM 1 à la VM 2 et 8 To de la VM 2 à la VM 1)

Cas n°1 – Homologation (ou « peering ») entre deux VNET Azure

 

 

Le VNET Peering est une fonction qui permet d’établir une connexion privée entre deux ou plusieurs réseaux virtuels (jusqu’à 500 au moment de la rédaction de cet article). Cette fonction est hautement disponible, évolutive, facile à configurer, et aucun service réseau supplémentaire n’est requis pour la configurer et la gérer. Il faut toutefois savoir que « le trafic entrant et sortant est facturé à chaque terminaison des réseaux appairés ». Pour être plus précis, le paiement du trafic s’applique aux instances de VM qui transmettent et reçoivent du trafic à travers le peering.

 

• Le TOTAL FACTURÉ pour le transfert des données porte sur 24 To (2 x 12 To à chaque terminaison), soit environ 246 $/mois

 

Astuce : dans une topologie hub-and-spoke, vous pouvez identifier facilement la VM du VNET spoke qui a généré le trafic vers et depuis une appliance virtuelle de réseau (NVA) située dans le VNET hub (via VNET Peering). Ce point est particulièrement intéressant pour la refacturation interne.

 

Cas n°2 – Azure VNET vers un emplacement local, via un VPN de transit/une passerelle ER

 

 

Ce modèle offre un coût intéressant grâce au cumul de deux facteurs :

1. Microsoft ne fait pas payer le transfert de données entrantes vers Azure

 

• Le TOTAL FACTURÉ pour le transfert des données porte sur 20To, soit environ 835 $/mois (avec VPN sur Internet) ou 328 $/mois (avec Azure ExpressRoute)

Cas n°3 – VNET Azure en topologie spoke-to-spoke via une Appliance virtuelle de réseau

Cette configuration est décrite dans le centre Azure Reference Architectures sous le titre « Déployer une topologie de réseau hub-and-spoke dans Azure » – Dans cette topologie, vous utilisez le VNET hub pour l’accès sur site (connectivité nord-sud) mais également pour les liaisons spoke-to-spoke (connectivité est/ouest), l’appliance NVA se chargeant du routage et éventuellement du filtrage, de l’inspection des paquets, etc. Cette topologie présente un coût deux fois plus élevé que dans le cas n°1, où les deux VNET spoke sont directement appairés.

 

• Le TOTAL FACTURÉ pour le transfert des données porte sur 48 To (2 x 12 To à chaque terminaison + 24 To pour le trafic en transit géré par la NVA), soit environ 492 $/mois

 

Astuce :  cette topologie n’a pas besoin de NVA pour fonctionner : vous pouvez remplacer la NVA utilisée comme « saut » suivant du VNET spoke par l’IP privée de votre passerelle VPN, et le trafic sera acheminé d’un spoke à l’autre. Toutefois, cette gestion du trafic est-ouest ne correspond pas à l’utilisation principale d’une passerelle VPN,  vous risquez d’atteindre rapidement la limite de bande passante de cette passerelle (par exemple, 1 Gbps), ce qui risque de dégrader la connectivité au niveau local.

Cas n°4a – Topologie Azure spoke-to-spoke via transit multi-saut sur VNET Peering (entre zones géographiques)

 

 

Pour le moment, le peering transitif n’est pas pris en charge : il n’est pas possible de transférer du trafic d’un VNET à un autre puis à un autre (on parle de topologie en chaîne) avec VNET Peering.

Cas n°4b – Topologie Azure spoke-to-spoke via transit multi-saut sur un VPN site-à-site (entre zones géographiques)

 

 

Modifier légèrement la topologie précédente et remplacer le VNET Peering mondial par une passerelle VPN site-à-site. Dans ce cas, le transfert de données entre les deux passerelles VPN est facturé au coût de transfert de données inter-VNET (et non au coût de transfert de données sortantes Internet, puisque nous ne ciblons pas un point de terminaison local/« hors Azure »).

 

• Le TOTAL FACTURÉ pour le transfert des données porte sur 36 To (2 x 12 To pour le VNET Peering à chaque terminaison + 12 To pour le transfert inter-VNET), soit environ 676 $/mois

Cas n°4c – Topologie Azure spoke-to-spoke via transit multi-saut sur un circuit Azure ExpressRoute Premium (entre zones géographiques)

 

Ici, remplacer le VPN S2S par un circuit Azure ExpressRoute (référence Premium, puisque le trafic passe d’une région Azure à une autre). Pour ce qui concerne les coûts de transfert des données, cette topologie est avantageuse puisque seul est facturé le trafic sortant vers le centre de données au niveau du point de peering Azure ExpressRoute. Vous n’avez pas à payer pour le transfert de données qui ne sortent pas des limites d’Azure ExpressRoute.

 

• Le TOTAL FACTURÉ pour le transfert des données porte sur 24 To (2 x 12 To pour le VNET Peering à chaque terminaison), soit environ 256 $/mois.

Cas n°5 – Centre de données local vers centre de données local via ER Global Reach (entre zones géographiques)

 

 

Jusqu’ici, nous nous sommes intéressés au transfert de données vers/depuis Azure. Ceci est le dernier cas dans lequel le trafic entre vos centres de données transite par le backbone Azure. Le module complémentaire Azure ExpressRoute Global Reach offre une alternative intéressante pour votre topologie : vous n’avez pas à déployer une NVA dans Azure pour acheminer le trafic entre le centre de données sur site n°1 et Azure, puis entre Azure et le centre de données sur site n°2. Le routage se fait au niveau des emplacements de peering Azure ExpressRoute et non dans votre région Azure, ce qui permet d’obtenir des latences plus faibles. Vous pouvez également définir la bande passante allouée à ce « pont » (elle ne sera pas nécessairement la même que pour les circuits ER).

 

Pour ce qui est du coût, Global Reach facture le transfert de données entrantes et sortantes. Comme les VM 1 et 2 partagent des données dans les deux sens, les frais s’appliquent également aux deux extrémités du circuit Global Reach (par exemple, 2 x 4 To + 2 x 8 To = 24 To au total).

 

• Le TOTAL FACTURÉ pour le transfert des données porte sur 36 To (12 TB pour le transfert de données sortantes ER + 24 To pour le trafic qui transite par Global Reach), soit environ 1 268 $/mois

 

Astuce : cette topologie est très proche de la connectivité « branch-to-branch », entre filiales. ER Global Reach reste toutefois une option plus intéressante si l’on souhaite connecter deux centres de données (en particulier si les circuits ER sont déjà en place, puisque Global Reach est juste un module complémentaire). En revanche, la solution Azure Virtual WAN peut être plus adaptée aux filiales (sites de moindre importance ou plus nombreux, typiquement plusieurs dizaines)