Conectividade de zona de destino de dados em uma única região
A zona de destino de gerenciamento de dados, as zonas de destino de dados e todos os serviços dentro delas são instalados na mesma região usando uma configuração de uma única região. Todas as zonas de destino estão dentro da mesma assinatura do hub de conectividade. Essa assinatura hospeda recursos de rede compartilhada, que podem incluir uma solução de virtualização de rede (como o firewall do Azure), um gateway de ExpressRoute, um gateway de VPN (rede virtual privada), uma rede virtual do hub ou um hub vWAN (WAN virtual).
Figura 1: conectividade em uma única região.
Com base nos recursos atuais dos Serviços de Rede do Azure, é recomendável usar uma arquitetura de rede em malha. Você deve configurar o emparelhamento de VNet entre:
- O Hub de Conectividade e a Zona de Gerenciamento de Dados
- O Hub de Conectividade e cada Zona de Destino de Dados
- A Zona de Gerenciamento de Dados e cada Zona de Destino de Dados
- Cada Zona de Destino de Dados
Este artigo descreve os prós e os contras de cada opção de arquitetura de rede considerada para análise em escala de nuvem.
A primeira seção deste artigo se concentra em um padrão de uma única região, em que a Zona de Gerenciamento de Dados e todas as Zonas de Destino de Dados estão hospedadas na mesma região.
Cada padrão de design é avaliado usando os seguintes critérios:
- Custo
- Gerenciamento de acesso do usuário
- Gerenciamento de serviços
- Largura de banda
- Latency
Analisaremos cada opção de design pensando no seguinte caso de uso da zona de destino entre dados:
Observação
A máquina virtual B (VM B) hospedada na zona de destino de dados B carrega um conjunto de dados da conta de armazenamento A hospedada na zona de destino de dados A. Em seguida, a VM B processa esse conjunto de dados e o armazena na Conta de Armazenamento B, que está hospedada na zona de destino de dados B.
Importante
Este artigo e outros artigos na seção de rede descrevem as unidades entre empresas que compartilham dados. No entanto, essa pode não ser sua estratégia inicial e você precisa começar em um nível base primeiro.
Crie a rede de modo que você possa implementar eventualmente nossa configuração recomendada entre zonas de destino de dados. Verifique se você as zonas de destino de gerenciamento de dados estão conectadas diretamente às zonas de destino para governança.
Arquitetura de rede em malha (recomendado)
É recomendável usar uma arquitetura de malha de rede, ao adotar a análise em escala de nuvem. Além do design de rede hub e spoke existente configurado no locatário, você precisa fazer duas coisas para implementar uma arquitetura de malha de rede:
- Adicione emparelhamentos de VNet entre todas as VNets da zona de destino de dados.
- Adicione os emparelhamentos de VNet entre a zona de destino de gerenciamento de dados e todas as zonas de destino de dados.
Em nosso cenário de exemplo, os dados carregados na Conta de Armazenamento A transitam por uma conexão de emparelhamento de VNet (2) configurada entre as duas VNets da zona de destino de dados. Eles são carregados e processados pela VM B ((3) e (4)) e, em seguida, enviados pelo Ponto de Extremidade Privado local (5) para serem armazenados na Conta de Armazenamento B.
Nesse cenário, os dados não passam pelo Hub de Conectividade. Eles permanecem na Plataforma de Dados, que consiste em uma zona de destino de gerenciamento de dados e uma ou mais zonas de destino de dados.
Figura 2: arquitetura de rede em malha.
Gerenciamento de acesso do usuário na arquitetura de rede em malha
Em um design de arquitetura de rede em malha, as equipes de aplicativos de dados têm apenas dois requisitos para criar novos serviços (incluindo Pontos de Extremidade Privados):
- Gravar o acesso ao grupo de recursos dedicado na zona de destino de dados
- Ingressar no acesso à sub-rede designada
Nesse design, as equipes de aplicativos de dados podem implantar pontos de extremidade privados por conta própria. Contanto que tenham os direitos de acesso necessários para conectar pontos de extremidade privados a uma sub-rede em determinado spoke, as equipes não precisam de suporte ao configurar a conectividade necessária.
Resumo: 
Gerenciamento de serviços na arquitetura de rede em malha
Em um design de arquitetura de rede de malha, nenhuma solução de virtualização de rede atua como ponto único de falha ou limitação. A falta de conjuntos de dados enviados por meio do Hub de Conectividade reduz a sobrecarga da equipe central da plataforma do Azure, contanto que você não precise escalar horizontalmente essa solução de virtualização.
Isso implica que a equipe central da plataforma Azure não pode mais inspecionar e registrar todo o tráfego enviado entre as zonas de destino de dados. No entanto, a análise em escala de nuvem é uma plataforma coerente que abrange várias assinaturas, o que permite a escala e supera as limitações no nível da plataforma, de modo que isso não é uma desvantagem.
Com todos os recursos hospedados em assinatura única, a equipe de plataforma central do Azure também deixa de inspecionar todos os dados no Hub de Conectividade central. Você ainda pode capturar os logs de rede usando os Logs de Fluxo do Grupo de Segurança de Rede. Você pode consolidar e armazenar outros logs de nível de aplicativo e serviço, usando as Configurações de Diagnóstico específicas do serviço.
Você pode capturar todos esses logs em escala, usando as definições do Azure Policy para configurações de diagnóstico.
Esse design também permite criar uma solução DNS nativa do Azure com base nas Zonas de DNS Privadas. Você pode automatizar o ciclo de vida do registro A do DNS por meio das definições do Azure Policy para grupos de DNS privados.
Resumo:
Custo da arquitetura de rede em malha
Observação
Ao acessar um ponto de extremidade privado em uma rede emparelhada, você só será cobrado pelo próprio ponto de extremidade privado e não pelo emparelhamento de VNet. Você pode ler a instrução oficial em Perguntas frequentes: como a cobrança funcionará ao acessar um ponto de extremidade privado em uma rede emparelhada?.
Neste design de rede, você paga apenas pelo seguinte:
- Seus pontos de extremidade privados (por hora)
- O tráfego de entrada e saída enviado por meio de seus pontos de extremidade privados para carregar seu conjunto de dados bruto (1) e armazenar seu conjunto de dados processado (6)
O emparelhamento de VNet não será cobrado (2), por isso essa opção tem custo mínimo.
Resumo:
Largura de banda e latência em uma arquitetura de rede em malha
Esse design não tem limitações conhecidas de largura de banda ou latência, pois nenhuma solução de virtualização de rede limita a taxa de transferência para troca de dados da zona de destino entre dados. O único fator limitante do design é o limite físico de nossos datacenters (velocidade dos cabos de fibra óptica).
Resumo:
Resumo da arquitetura de rede em malha
Se você planeja adotar a análise em escala de nuvem, é recomendável usar o design de rede em malha. Uma rede em malha oferece largura de banda máxima e baixa latência a um custo mínimo, mas não compromete o gerenciamento de acesso do usuário ou a camada DNS.
Se você precisar impor outras políticas de rede na plataforma de dados, use Grupos de Segurança de Rede, em vez de soluções de virtualização de rede centrais.
Arquitetura hub e spoke convencional (não recomendada)
O design de arquitetura de rede hub e spoke é a opção mais óbvia e a que muitas empresas adotaram. Nele, a transitividade de rede é configurada no Hub de Conectividade para acessar os dados da Conta de Armazenamento A na VM B. Os dados atravessam dois emparelhamentos de VNet ((2) e (5)) e uma solução de virtualização de rede hospedada dentro do Hub de Conectividade ((3) e (4)). Em seguida, os dados são carregados pela máquina virtual (6) e armazenados novamente na Conta de Armazenamento B (8).
Figura 3: arquitetura hub e spoke.
Gerenciamento de acesso do usuário na arquitetura hub e spoke convencional
Em um design hub e spoke convencional, as equipes de aplicativos de dados têm apenas dois requisitos para criar novos serviços (incluindo Pontos de Extremidade Privados):
- Gravar o acesso ao grupo de recursos na zona de destino de dados
- Ingressar no acesso à sub-rede designada
Nesse design, as equipes de aplicativos de dados podem implantar pontos de extremidade privados por conta própria. Contanto que tenham os direitos de acesso necessários para conectar pontos de extremidade privados a uma sub-rede em determinado spoke, as equipes não precisam de suporte ao configurar a conectividade necessária.
Resumo:
Gerenciamento de Serviços na arquitetura hub e spoke convencional
Esse design de rede é bem conhecido e consistente com a configuração de rede existente da maioria das organizações. Ele torna o design fácil de explicar e implementar. Você também pode usar uma solução DNS nativa do Azure centralizada com Zonas DNS Privadas para fornecer a resolução de FQDN dentro do locatário do Azure. O uso das Zonas de DNS Privadas permite automatizar o ciclo de vida do registro A do DNS por meio das Políticas do Azure.
Outro benefício desse design é que o tráfego é encaminhado por meio de uma solução de virtualização de rede central. Portanto, o tráfego de rede enviado de um Spoke para outro também pode ser registrado e inspecionado.
Uma desvantagem desse design é que a equipe central da Plataforma do Azure precisa gerenciar manualmente as Tabelas de Rotas. Isso é necessário para garantir a transitividade entre Spokes, o que permite o compartilhamento de ativos de dados em várias zonas de destino de dados. O gerenciamento de rotas pode se tornar complexo e propenso a erros ao longo do tempo e deve ser considerado antecipadamente.
Outra desvantagem dessa configuração de rede é a forma como a solução de virtualização de rede central é configurada. A solução de virtualização de rede atua como ponto único de falha e pode causar um tempo de inatividade importante dentro da plataforma de dados em caso de falha. Além disso, à medida que aumenta o tamanho dos conjuntos de dados em uma plataforma de dados e o número de casos de uso de zona de destino entre dados, mais tráfego é enviado por meio da solução de virtualização de rede central.
Com o tempo, isso pode resultar em gigabytes ou até mesmo terabytes de dados enviados por meio da instância central. Como a largura de banda das soluções de virtualização de rede existentes geralmente é limitada a apenas uma taxa de transferência de gigabyte de um ou dois dígitos, a solução de virtualização de rede central pode se tornar um gargalo que limita criticamente o fluxo de tráfego entre zonas de destino de dados e limita a capacidade de compartilhamento de ativos de dados.
A única maneira de evitar esse problema é escalar horizontalmente a solução de virtualização de rede central em várias instâncias, o que tem grandes implicações de custo para esse design.
Resumo: 
Custo da arquitetura hub e spoke convencional
Observação
Ao acessar um ponto de extremidade privado em uma rede emparelhada, você só será cobrado pelo próprio ponto de extremidade privado e não pelo emparelhamento VNet. Você pode ler a instrução oficial em Perguntas frequentes: como a cobrança funcionará ao acessar um ponto de extremidade privado em uma rede emparelhada?.
Para essa rede, você é cobrado por hora pelos Pontos de Extremidade Privados das contas de armazenamento. Você também é cobrado pelo tráfego de entrada e saída enviado pelos Pontos de Extremidade Privados para carregar um conjunto de dados bruto (1) e armazenar o conjunto de dados processado (8).
O cliente é cobrado pela entrada e saída de um emparelhamento de VNet (5). Conforme mencionado anteriormente, o primeiro emparelhamento de Vnet não é cobrado (2).
Você acabará com um alto custo de solução de virtualização de rede central, se estiver usando esse design de rede ((3) e (4)). Você precisa comprar licenças adicionais e escalar a solução de virtualização de rede central de acordo com a demanda ou pagar o encargo processado por gigabyte, como é feito com o Firewall do Azure.
Resumo:
Largura de banda e latência na arquitetura hub e spoke convencional
Esse design de rede tem limitações de largura de banda importantes. A solução de virtualização de rede central se torna um gargalo crítico, à medida que a plataforma cresce, o que limita os casos de uso da zona de destino entre dados e o compartilhamento de conjuntos de dados. Ela também provavelmente cria várias cópias de conjuntos de dados ao longo do tempo.
Esse design também afeta muito a latência, o que se torna especialmente crítico em cenários de análise em tempo real.
Resumo:
Resumo da arquitetura hub e spoke convencional
Esse design de rede hub e spoke tem gerenciamento de acesso e alguns benefícios de gerenciamento de serviços, mas devido a limitações críticas de gerenciamento de serviço e largura de banda e latência, não podemos recomendar esse design de rede para casos de uso de zona de destino entre dados.
Arquitetura de projeção de Ponto de Extremidade Privado (não recomendada)
Outra opção de design é a projeção de Pontos de Extremidade Privados em cada zona de destino. Nesse design, um Ponto de Extremidade Privado para a conta de armazenamento A é criado em cada zona de destino. Isso leva a um primeiro Ponto de Extremidade Privado na zona de destino de dados A conectada à VNet na zona de destino de dados A, um segundo Ponto de Extremidade Privado para a VNet na zona de destino de dados B e assim por diante.
O mesmo se aplica à Conta de Armazenamento B e, possivelmente, a outros serviços dentro das zonas de destino de dados. Se definirmos o número de zonas de destino de dados como n, acabaremos com n Pontos de Extremidade Privados para pelo menos todas as contas de armazenamento e, possivelmente, também outros serviços nas zonas de destino de dados. Isso leva a um aumento exponencial no número de Pontos de Extremidade Privados.
Figura 4: arquitetura de projeção de ponto de extremidade privado.
Como todos os Pontos de Extremidade Privados de um serviço específico (por exemplo, a Conta de Armazenamento A) têm o mesmo FQDN (por exemplo, storageaccounta.privatelink.blob.core.windows.net), essa solução cria desafios na camada DNS que não podem ser resolvidos usando as Zonas DNS Privadas. Em vez disso, você precisa de uma solução DNS personalizada que possa resolver nomes DNS com base na origem/endereço IP do solicitante. Isso permite que você faça com que a VMA se conecte aos pontos de extremidade privados conectados à Vnet na zona de destino de dados A e faça com que a VM B se conecte aos pontos de extremidade privados conectados à Vnet na zona de destino de dados B. Você pode fazer isso com uma configuração baseada no Windows Server, enquanto pode automatizar o ciclo de vida dos registros A do DNS por meio de uma combinação do Log de Atividades e do Azure Functions.
Nessa configuração, você pode carregar o conjunto de dados bruto na Conta de Armazenamento A na VM B, acessando o conjunto de dados por meio do Ponto de Extremidade Privado local (1). Depois de carregar e processar o conjunto de dados ((2) e (3)), você pode armazená-lo na Conta de Armazenamento B, acessando diretamente o Ponto de Extremidade Privado local (4). Nesse cenário, os dados não devem atravessar os emparelhamentos de VNet.
Gerenciamento de acesso do usuário na arquitetura de projeção de ponto de extremidade privado
A abordagem desse design para o gerenciamento de acesso do usuário é semelhante à da arquitetura de rede em malha. No entanto, nesse design, você pode exigir direitos de acesso para outras zonas de destino de dados, para criar Pontos de Extremidade Privados não apenas em uma zona de destino de dados designada e na VNet, mas também em outras zonas de destino de dados e nas respectivas VNets.
Por isso, as equipes de aplicativos de dados têm três requisitos, e não dois, para criar novos serviços por conta própria:
- Acesso de gravação a um grupo de recursos em uma zona de destino de dados designada
- Ingressar no acesso à sub-rede designada
- Acesso a um grupo de recursos e sub-rede dentro de todas as outras zonas de destino de dados para criar seus respectivos pontos de extremidade privados locais
Esse design de rede aumenta a complexidade na camada de gerenciamento de acesso, pois as equipes de aplicativo de dados precisam de permissões em todas as zonas de destino de dados. O design também pode ser confuso e levar a um RBAC inconsistente ao longo do tempo.
Se as equipes de zona de destino de dados e as equipes de aplicativos de dados não receberem os direitos de acesso necessários, ocorrerão os problemas descritos em Arquitetura hub e spoke convencional (não recomendada).
Resumo:
Gerenciamento de serviços na arquitetura de projeção de ponto de extremidade privado
Embora novamente semelhante ao design da arquitetura de rede em malha, esse design de rede tem o benefício de que nenhuma solução de virtualização de rede atua como ponto único de falha ou limitação da taxa de transferência. Isso também reduz a sobrecarga de gerenciamento para a equipe central da plataforma do Azure, ao deixar de enviar os conjuntos de dados por meio do Hub de Conectividade, pois não há necessidade de escalar verticalmente a solução de virtualização. Isso implica que a equipe central da plataforma Azure não pode mais inspecionar e registrar todo o tráfego enviado entre as zonas de destino de dados. No entanto, a análise em escala de nuvem é uma plataforma coerente que abrange várias assinaturas, o que permite a escala e supera as limitações no nível da plataforma, de modo que isso não é uma desvantagem.
Com todos os recursos hospedados em uma assinatura única, o tráfego não é inspecionado no Hub de Conectividade central. Você ainda pode capturar os logs de rede usando logs de Fluxo de Grupo de Segurança de Rede, bem como consolidar e armazenar outros logs de nível de serviço e aplicativo usando as Configurações de Diagnóstico específicas do serviço. Você pode capturar todos esses logs em escala usando as Políticas do Azure. Por outro lado, o espaço de endereço de rede exigido pela plataforma de dados cresce devido ao aumento exponencial dos Pontos de Extremidade Privados necessários, o que não é ideal.
As principais preocupações em relação a essa arquitetura de rede são os desafios de DNS mencionados anteriormente. Você não pode usar uma solução nativa do Azure na forma de Zonas DNS Privadas. Portanto, essa arquitetura exige uma solução de terceiros que possa resolver o FQDNS com base na origem/endereço IP do solicitante. Você também precisa desenvolver e manter ferramentas e fluxos de trabalho para automatizar os registros A do DNS Privado, o que aumenta consideravelmente a sobrecarga de gerenciamento, em comparação à solução orientada pelo Azure Policy proposta.
Você pode criar uma infraestrutura DNS distribuída usando zonas DNS Privadas, mas isso cria ilhas de DNS, que, em última análise, causam problemas quando você tenta acessar os serviços de link privado hospedados em outras zonas de destino no locatário. Portanto, esse design não é uma opção viável.
Resumo:
Custo da arquitetura de projeção de ponto de extremidade privado
Observação
Ao acessar um ponto de extremidade privado em uma rede emparelhada, você só será cobrado pelo próprio ponto de extremidade privado e não pelo emparelhamento VNet. Você pode ler a instrução oficial em Perguntas frequentes: como a cobrança funcionará ao acessar um ponto de extremidade privado em uma rede emparelhada?.
Nesse design de rede, você só é cobrado pelos Pontos de Extremidade Privados (por hora) e pelo tráfego de entrada e saída enviado por esses Pontos de Extremidade Privados para carregar conjuntos de dados brutos (1) e armazenar conjuntos de dados processados (4). No entanto, deve-se esperar custos adicionais em virtude do aumento exponencial no número de Pontos de Extremidade Privados da plataforma de dados. Como você é cobrado por hora, o custo adicional depende muito de quantos Pontos de Extremidade Privados são criados.
Resumo:
Largura de banda e latência na arquitetura de projeção de ponto de extremidade privado
Esse design não tem limitações conhecidas de largura de banda e latência, pois não tem soluções de virtualização de rede que limitem a taxa de transferência para troca de dados da zona de destino entre dados. O único fator limitante do design é o limite físico de nossos datacenters (velocidade dos cabos de fibra óptica).
Resumo:
Resumo da arquitetura de projeção de Ponto de Extremidade Privado
O aumento exponencial de Pontos de Extremidade Privados nessa arquitetura de rede pode fazer com que você perca a noção de quais Pontos de Extremidade Privados são usados para qual finalidade em qual local. Você também fica limitado por problemas de gerenciamento de acesso e complexidades da camada DNS. Devido a esses problemas, não é possível recomendar esse design de rede para casos de uso de zona de destino entre dados.
Arquitetura de Pontos de Extremidade Privados no Hub de Conectividade (não recomendada)
Outra opção de rede é hospedar os Pontos de Extremidade Privados no Hub de Conectividade e conectá-los à VNet do Hub. Nessa solução, você hospeda um único Ponto de Extremidade Privado para cada serviço na Vnet corporativa. Devido à arquitetura de rede hub e spoke existente na maioria das corporações e ao fato de que o Hub de Conectividade hospeda os Pontos de Extremidade Privados nessa solução, a transitividade não é necessária. O emparelhamento de VNet entre o Hub de Conectividade e as zonas de destino de dados permite acesso direto.
Os dados atravessam um único emparelhamento de Vnet entre o Hub de Conectividade e a zona de destino de dados para carregar um conjunto de dados armazenado na Conta de Armazenamento A na VM B. Depois que esse conjunto de dados é carregado e processado ((3) e (4)), ele atravessa o mesmo emparelhamento de Vnet uma segunda vez (5), antes de finalmente ser armazenado na Conta de Armazenamento B por meio do Ponto de Extremidade Privado conectado à Vnet do Hub (6).
Figura 5: arquitetura de Pontos de Extremidade Privados no Hub de Conectividade.
Gerenciamento de acesso do usuário na arquitetura de Hub de Conectividade
Neste design de rede, as equipes de zona de destino de dados e equipes de aplicativos de dados têm dois requisitos para conectar os Pontos de Extremidade Privados à VNet do Hub:
- Permissões de gravação em um grupo de recursos em sua assinatura do Hub de Conectividade
- Permissões de ingresso na Vnet do Hub
O Hub de Conectividade é designado para a equipe de plataforma do Azure da sua organização e é dedicado a hospedar a infraestrutura de rede necessária e compartilhada da sua organização (incluindo firewalls, gateways e ferramentas de gerenciamento de rede). Essa opção de rede torna esse design inconsistente, pois não segue os princípios de gerenciamento de acesso nos princípios básicos da Zona de Destino em Escala Corporativa. Portanto, a maioria das equipes de plataforma do Azure não aprovará essa opção de design.
Resumo:
Gerenciamento de serviços na arquitetura de Hub de Conectividade
Embora semelhante ao design da arquitetura de rede em malha, esse design não tem soluções de virtualização de rede que atuam como ponto único de falha ou limitação da taxa de transferência. Isso também reduz a sobrecarga de gerenciamento para a equipe central da plataforma do Azure, ao deixar de enviar os conjuntos de dados por meio do Hub de Conectividade, pois não há necessidade de escalar verticalmente a solução de virtualização. Isso implica que a equipe central da plataforma Azure não pode mais inspecionar e registrar todo o tráfego enviado entre as zonas de destino de dados. No entanto, a análise em escala de nuvem é uma plataforma coerente que abrange várias assinaturas, o que permite a escala e supera as limitações no nível da plataforma, de modo que isso não é uma desvantagem.
Com todos os recursos hospedados em uma assinatura única, o tráfego não é inspecionado no Hub de Conectividade central. Você ainda pode capturar os logs de rede usando logs de Fluxo de Grupo de Segurança de Rede, bem como consolidar e armazenar outros logs de nível de serviço e aplicativo usando as Configurações de Diagnóstico específicas do serviço. Você pode capturar todos esses logs em escala usando as Políticas do Azure.
Esse design também permite que você crie uma solução DNS nativa do Azure com base nas Zonas de DNS Privadas e automatize o ciclo de vida de registro A do DNS por meio das Políticas do Azure.
Resumo:
Custo da arquitetura de Hub de Conectividade
Observação
Ao acessar um ponto de extremidade privado em uma rede emparelhada, você só será cobrado pelo próprio ponto de extremidade privado e não pelo emparelhamento VNet. Você pode ler a instrução oficial em Perguntas frequentes: como a cobrança funcionará ao acessar um ponto de extremidade privado em uma rede emparelhada?.
Nesse design de rede, você só é cobrado pelos Pontos de Extremidade Privados (por hora) e pelo tráfego de entrada e saída enviado por esses Pontos de Extremidade Privados para carregar conjuntos de dados brutos (1) e armazenar conjuntos de dados processados (6).
Resumo:
Largura de banda e latência na arquitetura de Hub de Conectividade
Esse design não tem limitações conhecidas de largura de banda e latência, pois não tem soluções de virtualização de rede que limitem a taxa de transferência para troca de dados da zona de destino entre dados. O único fator limitante do design é o limite físico de nossos datacenters (velocidade dos cabos de fibra óptica).
Resumo:
Resumo da arquitetura de Pontos de Extremidade Privados no Hub de Conectividade
Embora esse design de arquitetura de rede tenha vários benefícios, as inconsistências de gerenciamento de acesso mencionadas anteriormente o tornam inadequado. Portanto, não podemos recomendar essa abordagem de design.
Conclusão sobre a conectividade de zona de destino de dados em uma única região
Dentre todas as opções de arquitetura de rede examinadas e seus prós e contras, a arquitetura de rede em malha é a vencedora evidente. Ela tem grandes benefícios para a taxa de transferência e para custo e gerenciamento, e é por isso que recomendamos usá-la ao implantar a análise em escala de nuvem. O emparelhamento de redes virtuais spoke não era comum anteriormente e isso levou a problemas no compartilhamento de conjuntos de dados entre domínios e unidades de negócios.
Você pode ver a análise em escala de nuvem como solução coerente que abrange várias assinaturas. Em uma configuração de assinatura única, o fluxo de tráfego de rede é igual ao fluxo na arquitetura de rede em malha. Em uma configuração de assinatura única, provavelmente os usuários atingirão os limites e cotas de nível de assinatura da plataforma, o que a análise de escala de nuvem visa evitar.