Connectivité à une seule région pour la zone d’atterrissage des données

La zone d’atterrissage de gestion des données, les zones d’atterrissage des données, et tous les services qu’elles contiennent, sont configurés dans la même région dans une configuration à une seule région. Toutes les zones d’atterrissage se trouvent dans le même abonnement hub de connectivité. Cet abonnement héberge des ressources réseau partagées, qui peuvent inclure une appliance réseau virtuelle (comme le pare-feu Azure), une passerelle ExpressRoute, une passerelle de réseau privé virtuel (VPN), un réseau virtuel hub ou un hub Virtual WAN (hub vWAN).

Figure 1 : Connectivité à une seule région.

Sur la base des fonctionnalités actuelles d’Azure Networking Services, nous vous recommandons d’utiliser une architecture réseau en maillage. Vous devriez configurer le peering VNet entre :

• Le hub de connectivité et la zone de gestion des données
• Le hub de connectivité et chaque zone d’atterrissage des données
• La zone de gestion des données et chaque zone d’atterrissage des données
• Chaque zone d’atterrissage des données

Cet article décrit les avantages et les inconvénients de chacune des options d’architecture réseau que nous avons considérées pour l’analyse à l’échelle du cloud.

La première section de cet article porte sur un modèle à une seule région, où la zone de gestion des données et toutes les zones d’atterrissage de données sont hébergées dans la même région.

Chaque modèle de conception est évalué à l’aide des critères suivants :

• Coût
• Gestion de l'accès utilisateur
• Gestion du service
• Bande passante
• Latence

Nous allons analyser chaque option de conception avec le cas d’utilisation de la zone d’atterrissage inter-données suivant à l’esprit :

Remarque

La machine virtuelle B (MV B) hébergée dans la zone d’atterrissage de données B charge un jeu de données à partir du compte de stockage A, qui est hébergé dans la zone d’atterrissage A. Ensuite, la machine virtuelle B traite le jeu de données et le stocke dans le compte de stockage B, qui est hébergé dans la zone d’atterrissage de données B.

Important

Cet article et d’autres articles de la section Mise en réseau décrivent les unités commerciales qui partagent les données. Toutefois, il ne doit pas s’agir de votre stratégie initiale et vous devez commencer au niveau de base.

Concevez votre réseau de manière que vous puissiez éventuellement implémenter notre configuration recommandée entre les zones d’atterrissage des données. Assurez-vous que les zones d’atterrissage de gestion des données sont directement connectées aux zones d’atterrissage de gouvernance.

Architecture réseau en maillage (recommandée)

Nous vous recommandons d’utiliser une architecture de maillage réseau lors de l’adoption de l’analyse à l’échelle du cloud. Outre la conception de réseau hub-and-spoke existante configurée au sein de votre locataire, vous devez effectuer deux opérations pour implémenter une architecture réseau de maillage :

• Ajoutez des peerings de réseaux virtuels entre tous les réseaux virtuels de zone d’atterrissage de données.
• Ajoutez des jumelages de réseaux virtuels entre votre zone d’atterrissage de gestion des données et toutes les zones d’atterrissage de données.

Dans notre exemple de scénario, les données chargées à partir du compte de stockage A transitent vers une connexion de peering de réseaux virtuels (2) configurée entre les deux réseaux virtuels de zone d’atterrissage de données. Elles sont chargées et traitées par la machine virtuelle B ((3) et (4)), puis envoyées via le point de terminaison privé local (5) pour être stockées dans le compte de stockage B.

Dans ce scénario, les données ne passent pas par le hub de connectivité. Elles restent dans la plateforme de données qui se compose d’une zone d’atterrissage de gestion des données et d’une ou plusieurs zones d’atterrissage de données.

Figure 2 : Architecture réseau en maillage.

Gestion des accès utilisateur dans une architecture réseau en maillage

Dans une conception d’architecture réseau en maillage, les équipes d’applications de données nécessitent uniquement deux éléments pour pouvoir créer de nouveaux services (y compris des points de terminaison privés) :

• Accès en écriture à leur groupe de ressources dédié dans la zone d’atterrissage des données
• Accès avec jonction à leur sous-réseau désigné

Dans cette conception, les équipes d’applications de données peuvent déployer eux-mêmes des points de terminaison privés. Tant qu’elles disposent des droits d’accès nécessaires pour connecter des points de terminaison privés à un sous-réseau dans un réseau spoke donné, vos équipes n’ont pas besoin de support lors de la configuration de la connectivité nécessaire.

Résumé :

Management des services dans une architecture réseau en maillage

Dans une conception d’architecture réseau en maillage, aucune appliance réseau virtuelle n’agit comme un point de défaillance ou de limitation unique. Le manque de jeux de données envoyés via le hub de connectivité réduit la surcharge de votre équipe de plateforme Azure centrale, à condition que vous n’ayez pas besoin de mettre à l’échelle cette appliance virtuelle.

Cela a pour conséquence que l’équipe de la plateforme Azure centrale ne peut plus journaliser ni inspecter tout le trafic envoyé entre les zones d’atterrissage des données. Toutefois, l’analyse à l’échelle du cloud est une plateforme cohérente couvrant plusieurs abonnements, qui permet de mettre à l’échelle et de surmonter les limitations au niveau de la plateforme. Elle ne constitue donc pas un inconvénient.

Avec toutes les ressources hébergées dans un seul abonnement, votre équipe de plateforme Azure centrale n’inspecte plus toutes les données dans le hub de connectivité central. Vous pouvez toujours capturer les journaux réseau à l’aide des journaux de flux du groupe de sécurité réseau. Vous pouvez consolider et stocker d’autres journaux de niveau application et service à l’aide des paramètres de diagnostic spécifiques au service.

Vous pouvez capturer tous ces journaux à grande échelle à l’aide des définitions Azure Policy pour les paramètres de diagnostic.

Cette conception vous permet également de créer une solution DNS Azure native basée sur des zones DNS privées. Vous pouvez automatiser le cycle de vie des enregistrements DNS A via des définitions Azure Policy pour les groupes DNS privés.

Résumé :

Coût de l’architecture réseau en maillage

Remarque

Lorsque vous accédez à un point de terminaison privé à partir d’un réseau appairé, vous n’êtes facturé que pour le point de terminaison privé lui-même, et non pour le peering VNet. Vous pouvez lire l’explication officielle dans Forum aux questions : Comment est facturé l’accès à un point de terminaison privé à partir d’un réseau appairé ?.

Dans cette conception réseau, vous payez uniquement pour :

• vos points de terminaison privés (par heure)
• le trafic d’entrée et de sortie envoyé par le biais de vos points de terminaison privés pour charger votre jeu de données brut (1) et stocker votre jeu de données traité (6)

Le peering de réseaux virtuels n’est pas facturé (2). C’est pourquoi cette option a un coût minimal.

Résumé :

Bande passante et latence dans une architecture réseau en maillage

Cette conception ne présente aucune limitation connue au niveau de la bande passante ou de la latence, car aucune appliance réseau virtuelle ne limite le débit pour le partage de données entre les zones d’atterrissage inter-données. Le seul facteur de limitation de la conception est la limite physique de nos centres de données (vitesse des câbles à fibre optique).

Résumé :

Résumé sur l’architecture réseau en maillage

Si vous envisagez d’adopter l’analyse à l’échelle du cloud, nous vous recommandons d’utiliser la conception de réseau en maillage. Un réseau en maillage offre une bande passante maximale et une faible latence à un coût minimal, mais ne fait aucun compromis concernant la gestion des accès utilisateur ou sur la couche DNS.

Si vous devez appliquer des stratégies réseau supplémentaires au sein de la plateforme de données, utilisez des groupes de sécurité réseau au lieu d’appliances réseau virtuelles centrales.

Architecture hub-and-spoke traditionnelle (non recommandée)

La conception de l’architecture réseau hub-and-spoke est l’option la plus évidente et celle que de nombreuses entreprises ont adoptée. Dans cette conception, la transitivité réseau est configurée dans le hub de connectivité pour accéder aux données dans le compte de stockage A à partir de la machine virtuelle B. Les données traversent deux peerings de réseaux virtuels ((2) et (5)) et une appliance réseau virtuelle hébergée à l’intérieur du hub de connectivité ((3) et (4)). Ensuite, les données sont chargées par la machine virtuelle (6) et stockées dans le compte de stockage B (8).

Figure 3 : Architecture Hub-and-Spoke.

Gestion des accès utilisateur dans une architecture hub-and-spoke traditionnelle

Dans une conception d’architecture hub-and-spoke traditionnelle, les équipes d’applications de données nécessitent uniquement deux éléments pour pouvoir créer de nouveaux services (y compris des points de terminaison privés) :

• Accès en écriture à leur groupe de ressources dans la zone d’atterrissage des données
• Accès avec jonction à leur sous-réseau désigné

Dans cette conception, les équipes d’applications de données peuvent déployer eux-mêmes des points de terminaison privés. Tant qu’elles disposent des droits d’accès nécessaires pour connecter des points de terminaison privés à un sous-réseau dans un réseau spoke donné, vos équipes n’ont pas besoin de support lors de la configuration de la connectivité nécessaire.

Résumé :

Management des services dans une architecture hub-and-spoke traditionnelle

Cette conception de réseau est bien connue et cohérente avec la configuration réseau existante de la plupart des organisations. Cette conception est donc facile à expliquer et à implémenter. Vous pouvez également utiliser une solution DNS Azure native centralisée avec des zones DNS privées pour fournir une résolution FQDN au sein de votre locataire Azure. L’utilisation de zones DNS privées vous permet d’automatiser le cycle de vie des enregistrements DNS A par le biais de stratégies Azure Policy.

Un autre avantage de cette conception est que le trafic est routé via une appliance réseau virtuelle centrale. Ainsi, le trafic réseau envoyé d’un réseau spoke à un autre peut aussi être journalisé et inspecté.

L’un des inconvénients de cette conception est que votre équipe de plateforme Azure centrale doit gérer manuellement les tables de routage. Cela est nécessaire pour garantir la transitivité entre les réseaux spoke, qui permet le partage des ressources de données entre plusieurs zones d’atterrissage de données. La gestion des routes peut devenir complexe et sujette aux erreurs au fil du temps et doit être prise en considération en amont.

Un autre inconvénient de cette configuration réseau est la façon dont votre appliance réseau virtuelle centrale est configurée. Premièrement, l’appliance réseau virtuelle agit comme un point de défaillance unique et peut provoquer de longs temps d’arrêt au sein de la plateforme de données en cas de défaillance. Deuxièmement, à mesure que les jeux de données deviennent de plus en plus volumineux dans la plateforme de données et que le nombre de cas d’usage entre plusieurs zones d’atterrissage inter-données augmente, on observe une hausse du trafic envoyé par le biais de l’appliance réseau virtuelle centrale.

À la longue, cela peut aboutir à l’envoi de plusieurs gigaoctets ou téraoctets de données via l’instance centrale. Étant donné que la bande passante des appliances réseau virtuelles existantes est souvent limitée à un débit de gigaoctets à un ou deux chiffres, l’appliance réseau virtuelle centrale peut devenir un goulot d’étranglement qui limite de façon critique le flux de trafic entre les zones d’atterrissage de données et limite le partage des ressources de données.

La seule façon d’éviter ce problème consiste à effectuer un scale-out de votre appliance réseau virtuelle centrale sur plusieurs instances, ce qui a des implications majeures sur les coûts de cette conception.

Résumé :

Coût de l’architecture hub-and-spoke traditionnelle

Remarque

Lorsque vous accédez à un point de terminaison privé à partir d’un réseau appairé, vous n’êtes facturé que pour le point de terminaison privé lui-même, et non pour le peering VNet. Vous pouvez lire l’explication officielle dans Forum aux questions : Comment est facturé l’accès à un point de terminaison privé à partir d’un réseau appairé ?.

Pour ce réseau, vous êtes facturé par heure pour les points de terminaison privés de vos comptes de stockage. Vous êtes également facturé pour le trafic d’entrée et de sortie envoyé via les points de terminaison privés pour charger un jeu de données brut (1) et stocker le jeu de données traité (8).

Votre client est facturé pour l’entrée et la sortie d’un seul peering de réseaux virtuels (5). Comme mentionné précédemment, le premier peering de réseaux virtuels n’est pas facturé (2).

Vous obtiendrez un coût élevé d’appliance réseau virtuelle centrale si vous utilisez cette conception réseau ((3) et (4)). Vous devez acheter des licences supplémentaires et mettre à l’échelle l’appliance réseau virtuelle centrale en fonction de la demande ou payer les frais traités par gigaoctets, comme c’est le cas avec le Pare-feu Azure.

Résumé :

Bande passante et latence dans une architecture hub-and-spoke traditionnelle

Cette conception de réseau présente des limitations de bande passante importantes. L’appliance réseau virtuelle centrale devient un goulot d’étranglement critique à mesure que votre plateforme augmente, ce qui limite les cas d’utilisation des zones d’atterrissage inter-données et le partage de jeux de données. Cela crée aussi probablement plusieurs copies de jeux de données au fil du temps.

Cette conception affecte également fortement la latence, ce qui devient particulièrement critique dans les scénarios d’analyse en temps réel.

Résumé :

Résumé sur l’architecture hub-and-spoke traditionnelle

Cette conception de réseau hub-and-spoke présente des avantages en matière de gestion des accès et de management des services, mais en raison des limitations critiques de la gestion des services, de la bande passante et de la latence, nous ne pouvons pas recommander cette conception réseau pour les cas d’utilisation de zones d’atterrissage inter-données.

Architecture de projection de points de terminaison privés (non recommandée)

Une autre option de conception est la projection de points de terminaison privés sur chaque zone d’atterrissage. Dans cette conception, un point de terminaison privé pour le compte de stockage A est créé dans chaque zone d’atterrissage. Cela conduit à un premier point de terminaison privé dans la zone d’atterrissage de données A connecté au réseau virtuel dans la zone d’atterrissage de données A, à un deuxième point de terminaison privé connecté au réseau virtuel dans la zone d’atterrissage de données B, et ainsi de suite.

Il en va de même pour le compte de stockage B et potentiellement les autres services au sein des zones d’atterrissage des données. Si nous définissons le nombre de zones d’atterrissage de données sur n, nous obtenons n points de terminaison privés pour au moins tous les comptes de stockage et potentiellement d’autres services au sein des zones d’atterrissage de données. Cela entraîne une augmentation exponentielle du nombre de points de terminaison privés.

Figure 4 : Architecture de projection de points de terminaison privés.

Étant donné que tous les points de terminaison privés d’un service spécifique (par exemple, le compte de stockage A) ont le même nom de domaine complet (par exemple, storageaccounta.privatelink.blob.core.windows.net), cette solution crée des problèmes sur la couche DNS qui ne peuvent pas être résolus à l’aide de zones DNS privées. Vous avez plutôt besoin d’une solution DNS personnalisée capable de résoudre les noms DNS en fonction de l’origine/l’adresse IP du demandeur. Cela vous permet de connecter VMA aux points de terminaison privés connectés au réseau virtuel dans la zone d’atterrissage de données A et de connecter la machine virtuelle B aux points de terminaison privés connectés au réseau virtuel dans la zone d’atterrissage de données B. Vous pouvez effectuer cette opération avec une configuration basée sur Windows Server, alors que vous pouvez automatiser le cycle de vie des enregistrements DNS A via une combinaison de journal d’activité et d’Azure Functions.

Dans cette configuration, vous pouvez charger le jeu de données brut contenu dans le compte de stockage A sur la machine virtuelle B en y accédant par le biais du point de terminaison privé local (1). Après avoir chargé et traité le jeu de données ((2) et (3)), vous pouvez le stocker sur le compte de stockage B en accédant directement au point de terminaison privé local (4). Dans ce scénario, les données ne doivent pas transiter par des peerings VNet.

Gestion de l’accès utilisateur dans l’architecture de projection de points de terminaison privés

Cette approche de conception de la gestion de l’accès utilisateur est similaire à celle de l’architecture réseau en maillage. Toutefois, dans cette conception, vous pouvez demander des droits d’accès pour d’autres zones d’atterrissage de données, afin de créer des points de terminaison privés non seulement dans une zone d’atterrissage de données désignée et un réseau virtuel, mais également dans d’autres zones d’atterrissage de données et leurs réseaux virtuels respectifs.

C’est pourquoi vos équipes d’application de données nécessitent trois éléments, et non deux, pour pouvoir créer eux-mêmes de nouveaux services :

• accès en écriture à un groupe de ressources dans une zone d’atterrissage de données désignée
• accès avec jonction à leur sous-réseau désigné
• accès à un groupe de ressources et à un sous-réseau à l’intérieur de toutes les autres zones d’atterrissage de données pour créer leurs points de terminaison privés locaux respectifs

Cette conception réseau augmente la complexité de votre couche de gestion des accès, car vos équipes d’applications de données nécessitent des autorisations dans chaque zone d’atterrissage des données. La conception peut également prêter à confusion et entraîner des contrôles d’accès en fonction du rôle incohérents au fil du temps.

Si les équipes de zone d’atterrissage de données et les équipes d’application de données ne reçoivent pas les droits d’accès nécessaires, les problèmes décrits dans la section Architecture hub-and-spoke traditionnelle (non recommandée) se produiront.

Résumé :

Management des services dans l’architecture de projection de points de terminaison privés

Bien que similaire à la conception de l’architecture de réseau en maillage, cette conception de réseau présente l’avantage de ne pas avoir d’appliance réseau virtuelle qui agit comme un point de défaillance unique ou un facteur de limitation du débit. Elle réduit également la surcharge de gestion pour votre équipe de plateforme Azure centrale en n’envoyant pas de jeux de données via le hub de connectivité, car il n’est pas nécessaire de mettre à l’échelle l’appliance virtuelle. Cela a pour conséquence que l’équipe de la plateforme Azure centrale ne peut plus journaliser ni inspecter tout le trafic envoyé entre les zones d’atterrissage des données. Toutefois, l’analyse à l’échelle du cloud est une plateforme cohérente couvrant plusieurs abonnements, qui permet de mettre à l’échelle et de surmonter les limitations au niveau de la plateforme. Elle ne constitue donc pas un inconvénient.

Avec toutes les ressources hébergées dans un seul abonnement, le trafic n’est pas inspecté dans le hub de connectivité central. Vous pouvez toujours capturer des journaux réseau en utilisant des journaux de flux de groupes de sécurité réseau, et vous pouvez consolider et stocker des journaux de niveau de service et d’application supplémentaires en définissant des paramètres de diagnostic propres au service. Vous pouvez capturer tous ces journaux à grande échelle à l’aide de stratégies Azure. En revanche, l’espace d’adressage réseau requis par votre plateforme de données augmente en raison de l’augmentation exponentielle des points de terminaison privés requis, ce qui n’est pas optimal.

Les principales préoccupations liées à cette architecture réseau sont ses défis DNS mentionnés précédemment. Vous ne pouvez pas utiliser une solution native Azure sous la forme de zones DNS privées. Par conséquent, cette architecture nécessite une solution tierce capable de résoudre les noms de domaine complets basés sur l’origine/l’adresse IP du demandeur. Vous devez également développer et gérer des outils et des flux de travail pour automatiser les enregistrements DNS A privés, ce qui augmente considérablement la surcharge de gestion par rapport à la solution Azure Policy proposée.

Vous pouvez créer une infrastructure DNS distribuée à l’aide de zones DNS privées, mais cela crée des îles DNS, entraînant à terme des problèmes lorsque vous essayez d’accéder aux services de liaison privée hébergés dans d’autres zones d’atterrissage au sein de votre locataire. Par conséquent, cette conception n’est pas une option viable.

Résumé :

Coût d’une architecture de projection de points de terminaison privés

Remarque

Lorsque vous accédez à un point de terminaison privé à partir d’un réseau appairé, vous n’êtes facturé que pour le point de terminaison privé lui-même, et non pour le peering VNet. Vous pouvez lire l’explication officielle dans Forum aux questions : Comment est facturé l’accès à un point de terminaison privé à partir d’un réseau appairé ?.

Dans cette conception réseau, vous êtes facturé uniquement pour les points de terminaison privés (par heure) et le trafic d’entrée et de sortie envoyé via ces points de terminaison privés pour charger des jeux de données bruts (1) et stocker des jeux de données traités (4). Toutefois, des coûts supplémentaires sont à prévoir en raison de l’augmentation exponentielle du nombre de points de terminaison privés de votre plateforme de données. Étant donné que vous êtes facturé par heure, le montant du coût supplémentaire dépend fortement du nombre de points de terminaison privés créés.

Résumé :

Bande passante et latence dans l’architecture de projection de points de terminaison privés

Cette conception ne présente aucune limitation connue au niveau de la bande passante et de la latence, car aucune appliance réseau virtuelle ne limite le débit pour le partage de données entre les zones d’atterrissage inter-données. Le seul facteur de limitation de la conception est la limite physique de nos centres de données (vitesse des câbles à fibre optique).

Résumé :

Résumé sur l’architecture de projection de points de terminaison privés

La croissance exponentielle des points de terminaison privés dans cette architecture réseau peut vous amener à perdre le suivi des points de terminaison privés utilisés, à quelles fins et à quels emplacements. Vous êtes également limité par les problèmes de gestion des accès et les complexités de la couche DNS. En raison de ces problèmes, nous ne pouvons pas recommander cette conception réseau pour les cas d’utilisation de zones d’atterrissage inter-données.

Points de terminaison privés dans l’architecture du hub de connectivité (non recommandée)

Une autre option réseau consiste à héberger des points de terminaison privés dans votre hub de connectivité et à les connecter au réseau virtuel hub. Dans cette solution, vous hébergez un point de terminaison privé unique pour chaque service sur votre réseau virtuel d’entreprise. En raison de l’architecture réseau hub-and-spoke existante chez la plupart des entreprises et du fait que votre hub de connectivité héberge vos points de terminaison privés dans cette solution, la transitivité n’est pas nécessaire. Le peering de réseaux virtuels entre votre hub de connectivité et les zones d’atterrissage de données permettent un accès direct.

Les données transitent sur un peering de réseaux virtuels unique entre le hub de connectivité et la zone d’atterrissage des données afin de charger un jeu de données stocké dans le compte de stockage A sur la machine virtuelle B. Une fois ce jeu de données chargé et traité ((3) et (4)),il traverse le même peering de réseaux virtuels une deuxième fois (5) avant d’être finalement stocké dans le compte de stockage B via le point de terminaison privé connecté au réseau virtuel hub (6).

Figure 5 : Points de terminaison privés dans l’architecture du hub de connectivité.

Gestion de l’accès utilisateur dans l’architecture du hub de connectivité

Dans cette conception réseau, vos équipes de zone d’atterrissage de données et vos équipes d’application de données ont besoin de deux éléments pour pouvoir connecter des points de terminaison privés au réseau virtuel hub :

• autorisations d’écriture sur un groupe de ressources dans votre abonnement au hub de connectivité
• autorisations avec jonction au réseau virtuel hub

Votre hub de connectivité est désigné pour l’équipe de plateforme Azure de votre organisation. Il est dédié à l’hébergement de l’infrastructure réseau nécessaire et partagée de votre organisation (y compris les pare-feu, les passerelles et les outils de gestion réseau). Cette option réseau rend la conception incohérente, car elle n’est pas conforme aux principes de gestion des accès contenus dans les principes de base des zones d’atterrissage à l’échelle de l’entreprise. Par conséquent, la plupart des équipes de plateforme Azure n’approuvent pas cette option de conception.

Résumé :

Management des services dans l’architecture du hub de connectivité

Bien que similaire à la conception de l’architecture de réseau en maillage, cette conception ne dispose pas d’appliance réseau virtuelle agissant comme un point de défaillance unique ou un facteur de limitation du débit. Elle réduit également la surcharge de gestion pour votre équipe de plateforme Azure centrale en n’envoyant pas de jeux de données via le hub de connectivité, car il n’est pas nécessaire de mettre à l’échelle l’appliance virtuelle. Cela a pour conséquence que l’équipe de la plateforme Azure centrale ne peut plus journaliser ni inspecter tout le trafic envoyé entre les zones d’atterrissage des données. Toutefois, l’analyse à l’échelle du cloud est une plateforme cohérente couvrant plusieurs abonnements, qui permet de mettre à l’échelle et de surmonter les limitations au niveau de la plateforme. Elle ne constitue donc pas un inconvénient.

Avec toutes les ressources hébergées dans un seul abonnement, le trafic n’est pas inspecté dans le hub de connectivité central. Vous pouvez toujours capturer des journaux réseau en utilisant des journaux de flux de groupes de sécurité réseau, et vous pouvez consolider et stocker des journaux de niveau de service et d’application supplémentaires en définissant des paramètres de diagnostic propres au service. Vous pouvez capturer tous ces journaux à grande échelle à l’aide de stratégies Azure.

Cette conception vous permet également de créer une solution DNS Azure native basée sur des zones DNS privées et vous permet d’automatiser le cycle de vie des enregistrements DNS A via des stratégies Azure Policy.

Résumé :

Coût de l’architecture du hub de connectivité

Remarque

Lorsque vous accédez à un point de terminaison privé à partir d’un réseau appairé, vous n’êtes facturé que pour le point de terminaison privé lui-même, et non pour le peering VNet. Vous pouvez lire l’explication officielle dans Forum aux questions : Comment est facturé l’accès à un point de terminaison privé à partir d’un réseau appairé ?.

Dans cette conception réseau, vous êtes facturé uniquement pour vos points de terminaison privés (par heure) et le trafic d’entrée et de sortie envoyé via ces points de terminaison privés pour charger un jeu de données brut (1) et stocker le jeu de données traité (6).

Résumé :

Bande passante et latence dans l’architecture du hub de connectivité

Cette conception ne présente aucune limitation connue au niveau de la bande passante et de la latence, car aucune appliance réseau virtuelle ne limite le débit pour le partage de données entre les zones d’atterrissage inter-données. Le seul facteur de limitation de la conception est la limite physique de nos centres de données (vitesse des câbles à fibre optique).

Résumé :

Résumé sur les points de terminaison privés dans l’architecture du hub de connectivité

Bien que cette conception d’architecture réseau présente plusieurs avantages, ses incohérences en matière de gestion des accès mentionnées précédemment la rendent inadéquate. Par conséquent, nous ne pouvons pas recommander cette approche de conception.

Conclusion concernant la connectivité à une seule région pour la zone d’atterrissage des données

Après avoir examiné toutes les options d’architecture réseau, ainsi que leurs avantages et inconvénients, l’architecture réseau en maillage ressort gagnante. Elle offre des avantages considérables en ce qui concerne le débit, les coûts et la gestion. C’est pourquoi nous vous recommandons de l’utiliser lors du déploiement d’analyses à l’échelle du cloud. Le peering de réseaux virtuels spoke n’a pas été très utilisé dans le passé, mais cela a entraîné divers problèmes lors du partage de jeux de données entre les domaines et les unités commerciales.

Vous pouvez afficher l’analyse à l’échelle du cloud comme une solution cohérente qui s’étend sur plusieurs abonnements. Dans une configuration d’abonnement unique, le flux de trafic réseau est égal au flux dans l’architecture réseau en maillage. Au sein d’une configuration d’abonnement unique, les utilisateurs atteignent généralement les limites et quotas du niveau d’abonnement de la plateforme, un problème que l’analyse à l’échelle du cloud vise à éviter.

Étapes suivantes

• Connectivité de la zone d’atterrissage des données sur plusieurs régions