Conectividade de zona de aterrissagem de dados de região única

A zona de aterrissagem de gerenciamento de dados, as zonas de aterrissagem de dados e todos os serviços dentro delas são configurados na mesma região em uma configuração de região única. Todas as zonas de aterrissagem estão dentro da mesma assinatura do hub de conectividade. Essa assinatura hospeda recursos de rede compartilhados, que podem incluir um dispositivo virtual de rede (como o firewall do Azure), um gateway de Rota Expressa, um gateway de rede virtual privada (VPN), uma rede virtual de hub ou uma WAN virtual (hub vWAN).

Figura 1: Conectividade de região única.

Com base nos recursos atuais dos Serviços de Rede do Azure, recomendamos que você use uma arquitetura de rede entrelaçada. Você deve configurar o emparelhamento Vnet entre:

• O Hub de Conectividade e a Zona de Gerenciamento de Dados
• O Hub de Conectividade e cada Zona de Pouso de Dados
• A Zona de Gerenciamento de Dados e cada Zona de Aterrissagem de Dados
• Cada zona de aterrissagem de dados

Este artigo descreve os prós e contras de cada opção de arquitetura de rede que consideramos para análise em escala de nuvem.

A primeira seção deste artigo se concentra em um padrão de região única, onde a Zona de Gerenciamento de Dados e todas as Zonas de Aterrissagem de Dados estão hospedadas na mesma região.

Cada padrão de desenho é avaliado utilizando os seguintes critérios:

• Custo
• Gerenciamento de acesso de usuários
• Gestão de serviços
• Largura de banda
• Latência

Analisaremos cada opção de projeto com o seguinte caso de uso da zona de aterrissagem de dados cruzados em mente:

Nota

A máquina virtual B (VM B) hospedada na zona de aterrissagem de dados B carrega um conjunto de dados da conta de armazenamento A hospedada na zona de aterrissagem de dados A. Em seguida, a VM B processa esse conjunto de dados e o armazena na Conta de Armazenamento B, que é hospedada na zona de aterrissagem de dados B.

Importante

Este artigo e outros artigos na seção de rede descrevem unidades de negócios cruzadas que compartilham dados. No entanto, esta pode não ser a sua estratégia inicial e que você precisa começar em um nível básico primeiro.

Projete sua rede para que você possa, eventualmente, implementar nossa configuração recomendada entre zonas de aterrissagem de dados. Certifique-se de ter as zonas de aterrissagem de gerenciamento de dados diretamente conectadas às zonas de pouso para governança.

Arquitetura de rede malhada (recomendado)

Recomendamos que você use uma arquitetura de malha de rede ao adotar análises em escala de nuvem. Além do design de rede de hub e spoke existente configurado em seu locatário, você precisa fazer duas coisas para implementar uma arquitetura de malha de rede:

• Adicione emparelhamentos Vnet entre todas as Vnets da zona de aterrissagem de dados.
• Adicione emparelhamentos Vnet entre sua zona de aterrissagem de gerenciamento de dados e todas as zonas de aterrissagem de dados.

Em nosso cenário de exemplo, os dados carregados da Conta de Armazenamento A transitam por uma conexão de emparelhamento Vnet (2) configurada entre as duas Vnets da zona de aterrissagem de dados. É carregado e processado pela VM B ((3) e (4)) e, em seguida, enviado através do Ponto de Extremidade Privado local (5) para ser armazenado na Conta de Armazenamento B.

Nesse cenário, os dados não passam pelo Hub de Conectividade. Ele permanece dentro da Plataforma de Dados que consiste em uma zona de aterrissagem de gerenciamento de dados e uma ou mais zonas de aterrissagem de dados.

Figura 2: Arquitetura de rede malhada.

Gerenciamento de acesso de usuários em arquitetura de rede malhada

Em um projeto de arquitetura de rede entrelaçada, as equipes de aplicativos de dados exigem apenas duas coisas para poder criar novos serviços (incluindo pontos de extremidade privados):

• Acesso de gravação ao grupo de recursos dedicado na zona de aterrissagem de dados
• Ingressar no acesso à sub-rede designada

Nesse design, as equipes de aplicativos de dados podem implantar pontos de extremidade privados. Desde que tenham os direitos de acesso necessários para conectar pontos de extremidade privados a uma sub-rede em um determinado discurso, suas equipes não precisam de suporte ao configurar a conectividade necessária.

Sumário:

Gerenciamento de serviços em arquitetura de rede malhada

Em um projeto de arquitetura de rede entrelaçada, nenhum dispositivo virtual de rede atua como um único ponto de falha ou limitação. A falta de conjuntos de dados sendo enviados por meio do Hub de Conectividade reduz a sobrecarga da equipe central da plataforma Azure, desde que você não precise expandir esse dispositivo virtual.

Isso implica que a equipe central da plataforma do Azure não pode mais inspecionar e registrar todo o tráfego enviado entre zonas de aterrissagem de dados. No entanto, a análise em escala de nuvem é uma plataforma coerente que abrange várias assinaturas, o que permite escala e supera as limitações no nível da plataforma, portanto, isso não é uma desvantagem.

Com todos os recursos hospedados em uma única assinatura, sua equipe central da plataforma Azure também não inspeciona mais todos os dados no Hub de Conectividade central. Você ainda pode capturar logs de rede usando os Logs de Fluxo do Grupo de Segurança de Rede. Você pode consolidar e armazenar outros logs de aplicativo e de nível de 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 de Política do Azure para configurações de diagnóstico.

Esse design também permite que você crie uma solução de DNS nativa do Azure com base em Zonas DNS Privadas. Você pode automatizar o ciclo de vida do registro DNS A por meio de definições de Política do Azure para grupos DNS privados.

Sumário:

Custo da arquitetura de rede malhada

Nota

Ao acessar um ponto de extremidade privado em uma rede emparelhada, você só será cobrado pelo ponto de extremidade privado em si, não pelo emparelhamento de VNet. Você pode ler a declaração oficial em FAQ: Como funcionará o faturamento ao acessar um endpoint privado a partir de uma rede emparelhada?.

Neste design de rede, você paga apenas por:

• os seus Endpoints Privados (por hora)
• o tráfego de entrada e saída enviado através dos seus Pontos de Extremidade Privados para carregar o conjunto de dados bruto (1) e armazenar o conjunto de dados processado (6)

O emparelhamento Vnet não será cobrado (2), e é por isso que esta opção tem um custo mínimo.

Sumário:

Largura de banda e latência em uma arquitetura de rede malhada

Esse design não tem limitações conhecidas de largura de banda ou latência porque nenhum dispositivo virtual de rede limita a taxa de transferência para sua troca de dados entre zonas de aterrissagem de dados. O único fator limitante do projeto é o limite físico de nossos datacenters (velocidade dos cabos de fibra ótica).

Sumário:

Resumo da arquitetura de rede malhada

Se você planeja adotar análises em escala de nuvem, recomendamos que use o design de rede malhada. Uma rede de 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 na camada DNS.

Se você precisar impor outras políticas de rede dentro da plataforma de dados, use Grupos de Segurança de Rede em vez de dispositivos virtuais de rede central.

Arquitetura tradicional de hub e spoke (não recomendada)

O design da arquitetura de rede Hub and spoke é a opção mais óbvia e que muitas empresas adotaram. Nele, a transitividade da rede é configurada no Hub de Conectividade para acessar dados na Conta de Armazenamento A da VM B. Os dados atravessam dois pares Vnet ((2) e (5)) e um dispositivo virtual de rede hospedado 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 de hub e spoke.

Gerenciamento de acesso de usuários na arquitetura tradicional de hub e spoke

Em um design tradicional de hub and spoke, as equipes de aplicativos de dados exigem apenas duas coisas para que possam criar novos serviços (incluindo pontos de extremidade privados):

• Acesso de gravação ao grupo de recursos na zona de aterrissagem de dados
• Ingressar no acesso à sub-rede designada

Nesse design, as equipes de aplicativos de dados podem implantar pontos de extremidade privados. Desde que tenham os direitos de acesso necessários para conectar pontos de extremidade privados a uma sub-rede em um determinado discurso, suas equipes não precisam de suporte ao configurar a conectividade necessária.

Sumário:

Gerenciamento de serviços em arquitetura tradicional de hub e spoke

Este design de rede é bem conhecido e consistente com a configuração de rede existente da maioria das organizações. Isso torna o design fácil de explicar e implementar. Você também pode usar uma solução de DNS nativa do Azure centralizada com Zonas DNS Privadas para fornecer resolução FQDN dentro do seu locatário do Azure. A utilização de Zonas DNS Privadas permite-lhe automatizar o ciclo de vida do registo DNS A através das Políticas do Azure.

Outro benefício desse design é que o tráfego é roteado por meio de um dispositivo virtual de rede central, para que o tráfego de rede enviado de um Spoke para outro possa ser registrado e inspecionado.

Uma desvantagem desse design é que sua equipe central da Plataforma Azure precisa gerenciar manualmente as Tabelas de Rotas. Isso é necessário para garantir a transitividade entre os raios, o que permite o compartilhamento de ativos de dados em várias zonas de aterrissagem de dados. A gestão de rotas pode tornar-se complexa e propensa a erros ao longo do tempo e deve ser considerada antecipadamente.

Outra desvantagem dessa configuração de rede é a maneira como o dispositivo virtual de rede central é configurado. O dispositivo virtual de rede funciona como um único ponto de falha e pode causar sérios períodos de inatividade dentro da plataforma de dados se ocorrer uma falha. Além disso, à medida que os tamanhos dos conjuntos de dados aumentam dentro de uma plataforma de dados e o número de casos de uso da zona de aterrissagem entre dados aumenta, mais tráfego é enviado por meio do dispositivo virtual de rede central.

Com o tempo, isso pode resultar em gigabytes ou até terabytes de dados sendo enviados através da instância central. Como a largura de banda dos dispositivos virtuais de rede existentes geralmente é limitada a apenas uma taxa de transferência de gigabytes de um ou dois dígitos, o dispositivo virtual de rede central pode se tornar um gargalo que limita criticamente o fluxo de tráfego entre zonas de aterrissagem de dados e limita a capacidade de compartilhamento de ativos de dados.

A única maneira de evitar esse problema é expandir seu dispositivo virtual de rede central em várias instâncias, o que tem grandes implicações de custo para esse design.

Sumário:

Custo da arquitetura tradicional de hub e spoke

Nota

Ao acessar um ponto de extremidade privado em uma rede emparelhada, você só será cobrado pelo ponto de extremidade privado em si e não pelo emparelhamento de VNet. Você pode ler a declaração oficial em FAQ: Como funcionará o faturamento ao acessar um endpoint privado a partir de uma rede emparelhada?.

Para essa rede, você é cobrado por hora pelos pontos de extremidade privados de suas contas de armazenamento. Você também é cobrado pelo tráfego de entrada e saída enviado através dos Pontos de Extremidade Privados para carregar um conjunto de dados bruto (1) e armazenar o conjunto de dados processado (8).

Seu cliente é cobrado pela entrada e saída de um peering Vnet (5). Como mencionado anteriormente, o primeiro peering Vnet não é cobrado (2).

Você acabará com um alto custo de dispositivo virtual de rede central se usar esse design de rede ((3) e (4)). Você precisa comprar licenças extras e dimensionar o dispositivo virtual de rede central com base na demanda ou pagar a cobrança processada por gigabyte, como é feito com o Firewall do Azure.

Sumário:

Largura de banda e latência na arquitetura tradicional de hub e spoke

Este design de rede tem sérias limitações de largura de banda. O dispositivo virtual de rede central torna-se um gargalo crítico à medida que sua plataforma cresce, o que limita os casos de uso da zona de aterrissagem entre dados e o compartilhamento de conjuntos de dados. Também provavelmente cria várias cópias de conjuntos de dados ao longo do tempo.

Esse design também afeta fortemente a latência, que se torna especialmente crítica em cenários de análise em tempo real.

Sumário:

Resumo da arquitetura tradicional de hub e spoke

Este design de rede hub and 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ços e largura de banda e latência, não podemos recomendar esse design de rede para casos de uso de zona de aterrissagem entre dados.

Arquitetura de projeção de ponto final privado (não recomendado)

Outra opção de design é a projeção de pontos finais privados em cada zona de pouso. Neste design, um ponto de extremidade privado para a conta de armazenamento A é criado em cada zona de aterrissagem. Isso leva a um primeiro Ponto Final Privado na zona de aterrissagem de dados A conectado à Vnet na zona de aterrissagem de dados A, um segundo Ponto Final Privado conectado à Vnet na zona de aterrissagem de dados B e assim por diante.

O mesmo se aplica à Conta de Armazenamento B e, potencialmente, a outros serviços dentro das zonas de aterrissagem de dados. Se definirmos o número de zonas de aterrissagem de dados como n, acabaremos com n pontos de extremidade privados para pelo menos todas as contas de armazenamento e potencialmente outros serviços dentro das zonas de aterrissagem de dados também. Isso leva a um aumento exponencial no número de Endpoints Privados.

Figura 4: Arquitetura de projeção de ponto final privado.

Como todos os pontos de extremidade privados de um determinado serviço (por exemplo, Conta de armazenamento A) têm o mesmo FQDN (como storageaccounta.privatelink.blob.core.windows.net), essa solução cria desafios na camada DNS que não podem ser resolvidos usando zonas DNS privadas. Em vez disso, você precisa de uma solução DNS personalizada capaz de resolver nomes DNS com base na origem/endereço IP do solicitante. Isso permite que você faça com que o VMA se conecte aos Pontos de Extremidade Privados conectados à Vnet na zona de aterrissagem de dados A e faça com que a VM B se conecte aos Pontos de Extremidade Privados conectados à Vnet na zona de aterrissagem de dados B. Você pode fazer isso com uma configuração baseada no Windows Server, enquanto pode automatizar o ciclo de vida dos registros DNS A por meio de uma combinação de Log de Atividades e Funções do Azure.

Nesta configuração, você pode carregar o conjunto de dados brutos 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 nenhum peering Vnet.

Gerenciamento de acesso de usuário na arquitetura de projeção de ponto final privado

A abordagem deste design para o gerenciamento de acesso do usuário é semelhante à da arquitetura de rede malhada. No entanto, neste design, você pode exigir direitos de acesso para outras zonas de aterrissagem de dados, para criar pontos de extremidade privados não apenas dentro de uma zona de aterrissagem de dados designada e Vnet, mas também em outras zonas de aterrissagem de dados e suas respetivas Vnets.

Por isso, suas equipes de aplicativos de dados precisam de três coisas, e não duas, para poder criar novos serviços por conta própria:

• acesso de gravação a um grupo de recursos em uma zona de aterrissagem 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 aterrissagem de dados para criar seus respetivos pontos de extremidade privados locais

Esse design de rede aumenta a complexidade em sua camada de gerenciamento de acesso, uma vez que suas equipes de aplicativos de dados exigem permissões em cada zona de aterrissagem de dados. O design também pode ser confuso e levar a RBAC inconsistente ao longo do tempo.

Se as equipes da zona de aterrissagem de dados e as equipes de aplicativos de dados não receberem os direitos de acesso necessários, ocorrerão problemas descritos na arquitetura tradicional de hub e spoke (não recomendada).

Sumário:

Gerenciamento de serviços em arquitetura de projeção de ponto final privado

Embora novamente semelhante ao design da arquitetura de rede malhada, esse design de rede tem o benefício de nenhum dispositivo virtual de rede atuando como um único ponto de falha ou taxa de transferência de limitação. Ele também reduz a sobrecarga de gerenciamento para sua equipe central da plataforma Azure ao não enviar conjuntos de dados por meio do Hub de Conectividade, porque não há necessidade de dimensionar o dispositivo virtual. Isso implica que a equipe central da plataforma do Azure não pode mais inspecionar e registrar todo o tráfego enviado entre zonas de aterrissagem de dados. No entanto, a análise em escala de nuvem é uma plataforma coerente que abrange várias assinaturas, o que permite escala e supera as limitações no nível da plataforma, portanto, isso não é uma desvantagem.

Com todos os recursos hospedados em uma única assinatura, o tráfego não é inspecionado no Hub de Conectividade central. Você ainda pode capturar logs de rede usando logs de Fluxo de Grupo de Segurança de Rede e pode consolidar e armazenar outros logs de nível de serviço e aplicativo usando 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çamento de rede exigido pela sua plataforma de dados aumenta devido ao aumento exponencial dos Pontos de Extremidade Privados necessários, o que não é o ideal.

As principais preocupações em relação a esta 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 requer uma solução de terceiros capaz de resolver FQDNS com base na origem/endereço IP do solicitante. Você também precisa desenvolver e manter ferramentas e fluxos de trabalho para automatizar registros A de DNS Privado, o que aumenta drasticamente a sobrecarga de gerenciamento em comparação com a solução orientada pela Política do Azure proposta.

Você pode criar uma infraestrutura DNS distribuída usando zonas DNS privadas, mas isso cria ilhas DNS, que acabam causando problemas quando você tenta acessar serviços de link privado hospedados em outras zonas de destino dentro do seu locatário. Portanto, este design não é uma opção viável.

Sumário:

Custo da arquitetura de projeção de ponto final privado

Nota

Ao acessar um ponto de extremidade privado em uma rede emparelhada, você só será cobrado pelo ponto de extremidade privado em si e não pelo emparelhamento VNet. Você pode ler a declaração oficial em FAQ: Como funcionará o faturamento ao acessar um endpoint privado a partir de uma rede emparelhada?.

Neste design de rede, você é cobrado apenas pelos Pontos de Extremidade Privados (por hora) e pelo tráfego de entrada e saída enviado através desses Pontos de Extremidade Privados para carregar conjuntos de dados brutos (1) e armazenar conjuntos de dados processados (4). No entanto, custos adicionais devem ser esperados devido ao aumento exponencial no número de terminais privados da sua plataforma de dados. Como você é cobrado por hora, o valor do custo extra depende muito de quantos pontos de extremidade privados são criados.

Sumário:

Largura de banda e latência na arquitetura de projeção de ponto final privado

Esse design não tem limitações conhecidas de largura de banda e latência porque não tem dispositivos virtuais de rede limitando a taxa de transferência para a troca de dados entre zonas de aterrissagem de dados. O único fator limitante do projeto é o limite físico de nossos datacenters (velocidade dos cabos de fibra ótica).

Sumário:

Resumo da arquitetura de projeção do Private Endpoint

O crescimento exponencial de pontos de extremidade privados nessa arquitetura de rede pode fazer com que você perca o controle de quais pontos de extremidade privados são usados para qual finalidade em qual local. Você também está limitado por problemas de gerenciamento de acesso e complexidades da camada DNS. Devido a esses problemas, não podemos recomendar esse design de rede para casos de uso de zona de aterrissagem entre dados.

Pontos de extremidade privados na arquitetura do Hub de Conectividade (não recomendado)

Outra opção de rede é hospedar pontos de extremidade privados em seu Hub de Conectividade e conectá-los à Vnet do Hub. Nesta solução, você hospeda um único ponto de extremidade privado para cada serviço em sua Vnet corporativa. Devido à arquitetura de rede hub e spoke existente na maioria das corporações e ao fato de que seu Hub de Conectividade hospeda seus pontos de extremidade privados nesta solução, a transitividade não é necessária. O emparelhamento Vnet entre seu Hub de Conectividade e as zonas de aterrissagem de dados permite acesso direto.

Os dados atravessam um único emparelhamento Vnet entre o Hub de Conectividade e a zona de aterrissagem de dados para carregar um conjunto de dados armazenado na Conta de Armazenamento A na VM B. Uma vez que esse conjunto de dados é carregado e processado ((3) e (4)), ele percorre o mesmo emparelhamento Vnet uma segunda vez (5) antes de finalmente ser armazenado na Conta de Armazenamento B através do Ponto Final Privado conectado à Vnet do Hub (6).

Figura 5: Pontos de extremidade privados na arquitetura do Hub de Conectividade.

Gerenciamento de acesso de usuários na arquitetura do Hub de Conectividade

Neste design de rede, suas equipes de zona de aterrissagem de dados e equipes de aplicativos de dados precisam de duas coisas para poder conectar pontos de extremidade privados ao Hub Vnet:

• permissões de gravação para um grupo de recursos em sua assinatura do Hub de Conectividade
• permissões de associação para o Hub Vnet

Seu Hub de Conectividade é designado para a equipe da plataforma Azure da sua organização e é dedicado para 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, porque não segue os princípios de gerenciamento de acesso dos princípios básicos da zona de aterrissagem em escala empresarial. Portanto, a maioria das equipes da plataforma Azure não aprovará essa opção de design.

Sumário:

Gerenciamento de serviços na arquitetura do Hub de Conectividade

Embora semelhante ao design da arquitetura de rede entrelaçada , esse design não tem nenhum dispositivo virtual de rede atuando como um único ponto de falha ou taxa de transferência de limitação. Ele também reduz a sobrecarga de gerenciamento para sua equipe central da plataforma Azure ao não enviar conjuntos de dados por meio do Hub de Conectividade, porque não há necessidade de dimensionar o dispositivo virtual. Isso implica que a equipe central da plataforma do Azure não pode mais inspecionar e registrar todo o tráfego enviado entre zonas de aterrissagem de dados. No entanto, a análise em escala de nuvem é uma plataforma coerente que abrange várias assinaturas, o que permite escala e supera as limitações no nível da plataforma, portanto, isso não é uma desvantagem.

Com todos os recursos hospedados em uma única assinatura, o tráfego não é inspecionado no Hub de Conectividade central. Você ainda pode capturar logs de rede usando logs de Fluxo de Grupo de Segurança de Rede e pode consolidar e armazenar outros logs de nível de serviço e aplicativo usando 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 criar uma solução de DNS nativa do Azure com base em Zonas DNS Privadas e permite automatizar o ciclo de vida do registro DNS A por meio das Políticas do Azure.

Sumário:

Custo da arquitetura do Hub de Conectividade

Nota

Ao acessar um ponto de extremidade privado em uma rede emparelhada, você só será cobrado pelo ponto de extremidade privado em si e não pelo emparelhamento de VNet. Você pode ler a declaração oficial em FAQ: Como funcionará o faturamento ao acessar um endpoint privado a partir de uma rede emparelhada?.

Neste design de rede, você é cobrado apenas pelos seus Pontos de Extremidade Privados (por hora) e pelo tráfego de entrada e saída enviado através desses Pontos de Extremidade Privados para carregar um conjunto de dados bruto (1) e armazenar o conjunto de dados processado (6).

Sumário:

Largura de banda e latência na arquitetura do Hub de Conectividade

Esse design não tem limitações conhecidas de largura de banda e latência porque não tem dispositivos virtuais de rede limitando a taxa de transferência para a troca de dados entre zonas de aterrissagem de dados. O único fator limitante do projeto é o limite físico de nossos datacenters (velocidade dos cabos de fibra ótica).

Sumário:

Resumo da arquitetura dos pontos de extremidade privados no Hub de Conectividade

Embora esse projeto de arquitetura de rede tenha vários benefícios, suas inconsistências de gerenciamento de acesso mencionadas anteriormente o tornam inferior. Portanto, não podemos recomendar essa abordagem de design.

Conclusão da conectividade da zona de aterrissagem de dados de região única

De todas as opções de arquitetura de rede analisadas e seus prós e contras, a arquitetura de rede malhada é a vencedora clara. Ele tem enormes benefícios para a taxa de transferência e para o custo e gerenciamento, e é por isso que recomendamos que você o use ao implantar análises em escala de nuvem. O emparelhamento de redes virtuais não era comum anteriormente, e isso levou a problemas com o compartilhamento de conjuntos de dados entre domínios e unidades de negócios.

Você pode ver a análise em escala de nuvem como uma solução coerente que abrange várias assinaturas. Em uma única configuração de assinatura, o fluxo de tráfego de rede é igual ao fluxo na arquitetura de rede malhada. Dentro de uma única configuração de assinatura, os usuários provavelmente atingirão os limites e cotas de nível de assinatura da plataforma, o que a análise em escala de nuvem visa evitar.

Próximos passos

• Zona de aterrissagem de dados entre regiões Conectividade