Balanceamento de carga de várias regiões com o Gerenciador de Tráfego, o Firewall do Azure e o Gateway de Aplicativo

Firewall do Azure
Gateway de Aplicativo do Azure
Azure Bastion
Azure Load Balancer
Gerenciador de Tráfego do Azure

Essa arquitetura é para aplicativos globais voltados para a Internet que usam protocolos HTTP(S) e não-HTTP(S). Ele apresenta balanceamento de carga global baseado em DNS, duas formas de balanceamento de carga regional e emparelhamento de rede virtual global para criar uma arquitetura de alta disponibilidade que pode resistir a uma interrupção regional. A inspeção de tráfego é fornecida pelo WAF (Firewall de Aplicativo Web) do Azure e pelo Firewall do Azure.

Notas de arquitetura

A arquitetura neste documento é facilmente extensível a um design de rede virtual hub-and-spoke, em que o Firewall do Azure estaria na rede de hub e o Gateway de Aplicativo também na rede de hub ou em um raio. Se o Gateway de Aplicativo for implantado no hub, você ainda desejará vários Gateways de Aplicativo, cada um para um determinado conjunto de aplicativos, para evitar conflitos de RBAC e impedir que atinjam os limites do Gateway de Aplicativo (consulte Limites do Gateway de Aplicativo).

Em um ambiente de WAN Virtual, os Application Gateways não podem ser implantados no hub, portanto, eles seriam instalados em redes virtuais de spoke.

A arquitetura proposta opta pela inspeção dupla do conteúdo da Web por meio de um Firewall de Aplicativo Web (baseado no Gateway de Aplicativo) na frente do Firewall do Azure. Existem outras opções, conforme documentado em Firewall e Application Gateway para redes virtuais, mas essa opção é a mais flexível e completa: expõe o endereço IP do cliente no cabeçalho X-Forwarded-For HTTP do aplicativo final, fornece criptografia de ponta a ponta e impede que os clientes ignorem o WAF para acessar o aplicativo.

Se apenas aplicativos Web forem expostos (sem aplicativos não-HTTP(S)) e a inspeção dupla desse tráfego Web pelo WAF e pelo Firewall do Azure não for necessária, o Azure Front Door seria uma solução de balanceamento de carga global melhor do que o Gerenciador de Tráfego. O Front Door é um balanceador de carga de camada 7 para conteúdo HTTP(S) que também fornece cache, aceleração de tráfego, terminação SSL/TLS, gerenciamento de certificados, testes de integridade e outros recursos. No entanto, o Gateway de Aplicativo oferece melhor integração com o Firewall do Azure para uma abordagem de proteção em camadas.

Fluxos de tráfego HTTP(S) de entrada

Diagram showing multi-region load balancing with Azure Firewall, Application Gateway and Traffic Manager for web traffic.

Baixe um Arquivo Visio dessa arquitetura.

  1. O Gerenciador de Tráfego do Azure usa o roteamento baseado em DNS para balancear a carga do tráfego de entrada entre as duas regiões. O Gerenciador de Tráfego resolve consultas DNS do aplicativo para os endereços IP públicos dos pontos de extremidade do Gateway de Aplicativo do Azure. Os pontos de extremidade públicos dos Gateways de Aplicativo servem como pontos de extremidade de back-end do Gerenciador de Tráfego para tráfego HTTP(S). O Gerenciador de Tráfego resolve consultas DNS com base em uma escolha de vários métodos de roteamento. O navegador se conecta diretamente ao ponto de extremidade; O Gerenciador de Tráfego não vê o tráfego HTTP(S).

  2. Os Gateways de Aplicativo implantados em zonas de disponibilidade recebem tráfego HTTP(S) do navegador e os Firewalls de Aplicativo Web Premium inspecionam o tráfego para detectar ataques da Web. Os Gateways de Aplicativo enviarão tráfego para seu back-end, o balanceador de carga interno para as máquinas virtuais front-end. Para esse fluxo específico, o balanceador de carga interno na frente dos servidores Web não é estritamente necessário, pois o Gateway de Aplicativo pode executar esse balanceamento de carga sozinho. No entanto, ele é incluído para consistência com o fluxo para aplicativos não-HTTP(S).

  3. O tráfego entre o Gateway de Aplicativo e o balanceador de carga interno de front-end será interceptado pelo Firewall do Azure Premium por meio de Rotas Definidas pelo Usuário aplicadas na sub-rede do Gateway de Aplicativo. O Azure Firewall Premium aplicará a inspeção TLS ao tráfego para obter segurança adicional. O Firewall do Azure também é redundante por zona. Se o Firewall do Azure detectar uma ameaça no tráfego, ele descartará os pacotes. Caso contrário, após uma inspeção bem-sucedida, o Firewall do Azure encaminhará o tráfego para o balanceador de carga interno da camada da Web de destino.

  4. A camada da Web é a primeira camada do aplicativo de três camadas, contém a interface do usuário e também analisa as interações do usuário. O balanceador de carga da camada da Web está espalhado por todas as três zonas de disponibilidade e distribuirá o tráfego para cada uma das três máquinas virtuais da camada da Web.

  5. As máquinas virtuais da camada da Web estão espalhadas pelas três zonas de disponibilidade e se comunicarão com a camada de negócios por meio de um balanceador de carga interno dedicado.

  6. A camada de negócios processa as interações do usuário e determina as próximas etapas, e fica entre as camadas da Web e de dados. O balanceador de carga interno da camada de negócios distribui o tráfego para as máquinas virtuais da camada de negócios nas três zonas de disponibilidade. O balanceador de carga da camada de negócios é redundante por zona, como o balanceador de carga da camada da Web.

  7. As máquinas virtuais da camada de negócios estão espalhadas pelas zonas de disponibilidade e rotearão o tráfego para o ouvinte do grupo de disponibilidade dos bancos de dados.

  8. A camada de dados armazena os dados do aplicativo, normalmente em um banco de dados, armazenamento de objetos ou compartilhamento de arquivos. Essa arquitetura tem o SQL Server em máquinas virtuais distribuídas em três zonas de disponibilidade. Eles estão em um grupo de disponibilidade e usam um nome de rede distribuído (DNN) para rotear o tráfego para o ouvinte do grupo de disponibilidade para balanceamento de carga.

Fluxos de tráfego não-HTTP(S) de entrada

Diagram showing multi-region load balancing with Azure Firewall, Application Gateway and Traffic Manager for non-web traffic.

Baixe um Arquivo Visio dessa arquitetura.

  1. O Gerenciador de Tráfego do Azure usa o roteamento baseado em DNS para balancear a carga do tráfego de entrada entre as duas regiões. O Gerenciador de Tráfego resolve consultas DNS do aplicativo para os endereços IP públicos dos pontos de extremidade do Azure. Os pontos de extremidade públicos do Application Firewall servem como pontos de extremidade de back-end do Gerenciador de Tráfego para tráfego não-HTTP(S). O Gerenciador de Tráfego resolve consultas DNS com base em uma escolha de vários métodos de roteamento. O navegador se conecta diretamente ao ponto de extremidade; O Gerenciador de Tráfego não vê o tráfego HTTP(S).

  2. O Firewall do Azure Premium é redundante de zona e inspecionará o tráfego de entrada para segurança. Se o Firewall do Azure detectar uma ameaça no tráfego, ele descartará os pacotes. Caso contrário, após uma inspeção bem-sucedida, o Firewall do Azure encaminhará o tráfego para o balanceador de carga interno da camada da Web que executa a Conversão de Endereço de Rede de Destino (DNAT) nos pacotes de entrada.

  3. A camada da Web é a primeira camada do aplicativo de três camadas, contém a interface do usuário e também analisa as interações do usuário. O balanceador de carga da camada da Web está espalhado por todas as três zonas de disponibilidade e distribuirá o tráfego para cada uma das três máquinas virtuais da camada da Web.

  4. As máquinas virtuais da camada da Web estão espalhadas pelas três zonas de disponibilidade e se comunicarão com a camada de negócios por meio de um balanceador de carga interno dedicado.

  5. A camada de negócios processa as interações do usuário e determina as próximas etapas, e fica entre as camadas da Web e de dados. O balanceador de carga interno da camada de negócios distribui o tráfego para as máquinas virtuais da camada de negócios nas três zonas de disponibilidade. O balanceador de carga da camada de negócios é redundante por zona, como o balanceador de carga da camada da Web.

  6. As máquinas virtuais da camada de negócios estão espalhadas pelas zonas de disponibilidade e rotearão o tráfego para o ouvinte do grupo de disponibilidade dos bancos de dados.

  7. A camada de dados armazena os dados do aplicativo, normalmente em um banco de dados, armazenamento de objetos ou compartilhamento de arquivos. Essa arquitetura tem o SQL Server em máquinas virtuais distribuídas em três zonas de disponibilidade. Eles estão em um grupo de disponibilidade e usam um nome de rede distribuído (DNN) para rotear o tráfego para o ouvinte do grupo de disponibilidade para balanceamento de carga.

Fluxos de tráfego de saída (todos os protocolos)

Os fluxos de tráfego de saída para atualizações de patch de máquina virtual ou outra conectividade com a Internet passarão das máquinas virtuais de carga de trabalho para o Firewall do Azure por meio de Rotas Definidas pelo Usuário. O Firewall do Azure imporá regras de conectividade usando categorias da Web, bem como regras de rede e de aplicativo para impedir que cargas de trabalho acessem conteúdo inadequado ou cenários de exfiltração de dados.

Componentes

  • O Firewall do Azure é um firewall de próxima geração gerenciado pela Microsoft baseado em nuvem que fornece inspeção profunda de pacotes para fluxos de tráfego Norte/Sul e Leste/Oeste. Ele pode ser espalhado por zonas de disponibilidade e oferece dimensionamento automático automático para lidar com alterações de demanda de aplicativos.
  • O Gateway de Aplicativo do Azure é um balanceador de carga de camada 7 com funcionalidade opcional de WAF (Web Application Firewall). A SKU v2 do Application Gateway oferece suporte à redundância de zona de disponibilidade e é recomendada para a maioria dos cenários. O Application Gateway inclui dimensionamento automático horizontal configurável para que possa reagir automaticamente às alterações de demanda do aplicativo.
  • O Gerenciador de Tráfego do Azure é um balanceador de carga de tráfego global baseado em DNS que distribui o tráfego para serviços entre regiões globais do Azure e, ao mesmo tempo, fornece alta disponibilidade e capacidade de resposta. Para obter mais informações, consulte a Configuração do Gerenciador de Tráfego.
  • O Azure Load Balancer é um balanceador de carga de camada 4. Um balanceador de carga com redundância de zona ainda distribuirá o tráfego com uma falha de zona de disponibilidade para as zonas restantes.
  • A Proteção contra DDoS do Azure aprimorou os recursos para proteger contra ataques distribuídos de negação de serviço (DDoS).
  • O DNS do Azure é um serviço de hospedagem para domínios DNS. Ele fornece resolução de nomes usando a infraestrutura do Microsoft Azure. Ao hospedar seus domínios no Azure, você pode gerenciar seus registros DNS usando as mesmas credenciais, APIs, ferramentas e cobrança que seus outros serviços do Azure.
  • As zonas DNS Privadas do Azure são um recurso do DNS do Azure. As Zonas Privadas DNS do Azure fornecem resolução de nomes em uma rede virtual e entre redes virtuais. Os registros contidos em uma zona DNS privada não são resolvidos pela Internet. A resolução DNS em uma zona DNS privada funciona somente a partir de redes virtuais vinculadas a ela.
  • As Máquinas Virtuais do Azure são recursos de computação escalonáveis sob demanda que oferecem a flexibilidade da virtualização, mas eliminam as demandas de manutenção do hardware físico. As opções do sistema operacional incluem Windows e Linux. Determinados componentes dos aplicativos podem ser substituídos por recursos de plataforma como serviço do Azure (por exemplo, o banco de dados e a camada de front-end), mas a arquitetura não mudaria significativamente se usasse o Link Privado e a Integração de Rede Virtual do Serviço de Aplicativo para trazer esses serviços de PaaS para a rede virtual.
  • Os Conjuntos de Dimensionamento de Máquina Virtual do Azure são dimensionamentos de máquina virtual automatizados e com balanceamento de carga que simplificam o gerenciamento de seus aplicativos e aumentam a disponibilidade.
  • O SQL Server em VMs permite que você use versões completas do SQL Server na nuvem sem precisar gerenciar nenhum hardware local.
  • A Rede Virtual do Azure é uma rede privada segura na nuvem. Ele conecta máquinas virtuais entre si, à Internet e a redes entre locais.
  • As Rotas Definidas pelo Usuário são um mecanismo para substituir o roteamento padrão em redes virtuais. Nesse cenário, eles são usados para forçar os fluxos de tráfego de entrada e saída a atravessar o Firewall do Azure.

Detalhes da solução

Gerenciador de Tráfego - Configuramos o Gerenciador de Tráfego para usar o roteamento de desempenho. Ele roteia o tráfego para o ponto de extremidade que tem a latência mais baixa para o usuário. O Gerenciador de Tráfego ajusta automaticamente seu algoritmo de balanceamento de carga à medida que a latência do ponto de extremidade muda. O gerenciador de tráfego fornece failover automático se houver uma interrupção regional. Ele usa roteamento prioritário e verificações de integridade regulares para determinar onde rotear o tráfego.

Zonas de disponibilidade - A arquitetura usa três zonas de disponibilidade. As zonas criam uma arquitetura de alta disponibilidade para os Gateways de Aplicativos, balanceadores de carga internos e máquinas virtuais em cada região. Se houver uma interrupção de zona, as zonas de disponibilidade restantes nessa região assumirão a carga, o que não acionaria um failover regional.

Gateway de Aplicativo - Enquanto o Gerenciador de Tráfego fornece balanceamento de carga regional baseado em DNS, o Gateway de Aplicativo oferece muitos dos mesmos recursos que o Azure Front Door, mas no nível regional, como:

  • Firewall do aplicativo Web (WAF)
  • Terminação TLS (Transport Layer Security)
  • Roteamento baseado em caminho
  • Afinidade de sessão baseada em cookie

Firewall do Azure - O Firewall Premium do Azure oferece segurança de rede para aplicativos genéricos (tráfego Web e não Web), inspecionando três tipos de fluxos nessa arquitetura:

  • Os fluxos HTTP(S) de entrada do Gateway de Aplicativo são protegidos com a inspeção TLS do Firewall Premium do Azure.
  • Os fluxos de entrada não HTTP(S) da Internet pública são inspecionados com o restante dos recursos do Firewall Premium do Azure.
  • Os fluxos de saída das Máquinas Virtuais do Azure são inspecionados pelo Firewall do Azure para impedir a exfiltração de dados e o acesso a sites e aplicativos proibidos.

Emparelhamento de rede virtual - Chamamos o emparelhamento entre regiões de "emparelhamento de rede virtual global". O emparelhamento de rede virtual global fornece replicação de dados de baixa latência e alta largura de banda entre regiões. Você pode transferir dados entre assinaturas do Azure, locatários do Microsoft Entra e modelos de implantação com esse emparelhamento global. No ambiente hub-spoke, existiriam emparelhamentos de rede virtual entre redes hub e spoke.

Recomendações

As recomendações a seguir seguem os pilares do WAF (Azure Well-Architected Framework). Os pilares do WAF são princípios orientadores que ajudam a garantir a qualidade das cargas de trabalho na nuvem. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Confiabilidade

Regiões - Use pelo menos duas regiões do Azure para alta disponibilidade. Você pode implantar seu aplicativo em várias regiões do Azure em configurações ativas/passivas ou ativas/ativas. Várias regiões também ajudam a evitar o tempo de inatividade do aplicativo se um subsistema do aplicativo falhar.

  • O Gerenciador de Tráfego fará failover automaticamente para a região secundária se a região primária falhar.
  • A escolha das melhores regiões para suas necessidades deve ser baseada em considerações técnicas, regulatórias e suporte de zona de disponibilidade.

Pares de regiões - Use pares de regiões para obter a maior resiliência. Certifique-se de que ambos os Pares de Região suportam todos os serviços do Azure de que a sua aplicação necessita (consulte serviços por região). Aqui estão dois benefícios dos Pares de Regiões:

  • As atualizações planejadas do Azure são lançadas em regiões emparelhadas, uma de cada vez, para minimizar o tempo de inatividade e o risco de interrupção do aplicativo.
  • Os dados continuam a residir na mesma geografia que seu par (exceto para o Sul do Brasil) para fins fiscais e legais.

Zonas de disponibilidade - Use várias zonas de disponibilidade para dar suporte ao Gateway de Aplicativo, ao Firewall do Azure, ao Balanceador de Carga do Azure e às camadas de aplicativo, quando disponíveis.

Dimensionamento automático e instâncias do gateway de aplicativo - Configure o gateway de aplicativo com um mínimo de duas instâncias para evitar tempo de inatividade e dimensionamento automático para fornecer adaptação dinâmica às demandas de capacidade de aplicativos em mudança.

Para saber mais, veja:

Roteamento global

Método de roteamento global - Use o método de roteamento de tráfego que melhor atenda às necessidades de seus clientes. O Gerenciador de Tráfego oferece suporte a vários métodos de roteamento de tráfego para rotear deterministicamente o tráfego para os vários pontos de extremidade de serviço.

Configuração aninhada - Use o Gerenciador de Tráfego em uma configuração aninhada se precisar de um controle mais granular para escolher um failover preferencial em uma região.

Para saber mais, veja:

Visão de tráfego global

Use a Exibição de Tráfego no Gerenciador de Tráfego para ver padrões de tráfego e métricas de latência. O Modo de Exibição de Tráfego pode ajudá-lo a planejar sua expansão para novas regiões do Azure.

Consulte Exibição de tráfego do Gerenciador de Tráfego para obter detalhes.

Gateway de Aplicativo

Use a SKU do Application Gateway v2 para resiliência automatizada pronta para uso.

  • A SKU do Application Gateway v2 garante automaticamente que novas instâncias sejam geradas em domínios de falha e domínios de atualização. Se você escolher redundância de zona, as instâncias mais recentes também surgirão em zonas de disponibilidade para oferecer tolerância a falhas.

  • A SKU do Application Gateway v1 oferece suporte a cenários de alta disponibilidade quando você implanta duas ou mais instâncias. O Azure distribui essas instâncias entre domínios de atualização e falha para garantir que as instâncias não falhem ao mesmo tempo. O v1 SKU suporta escalabilidade adicionando várias instâncias do mesmo gateway para compartilhar a carga.

O Gateway de Aplicativo precisa confiar no certificado de CA do Firewall do Azure.

Firewall do Azure

A camada Premium do Firewall do Azure é necessária neste design para fornecer inspeção TLS. O Firewall do Azure interceptará as sessões TLS entre o Gateway de Aplicativo e as máquinas virtuais da camada da Web gerando seus próprios certificados, bem como inspecionará os fluxos de tráfego de saída das redes virtuais para a Internet pública. Você pode encontrar mais informações sobre esse design em Rede de confiança zero para aplicativos Web com o Firewall do Azure e o Gateway de Aplicativo.

Recomendações de sonda de saúde

Aqui estão algumas recomendações para testes de integridade no Gerenciador de Tráfego, no Gateway de Aplicativo e no Balanceador de Carga.

Gerenciador de Tráfego

Integridade do ponto de extremidade - Crie um ponto de extremidade que relate a integridade geral do aplicativo. O Gerenciador de Tráfego usa um teste HTTP(S) para monitorar a disponibilidade de cada região. A investigação verifica uma resposta HTTP 200 para um caminho de URL especificado. Use o ponto de extremidade criado para o teste de integridade. Caso contrário, o teste pode relatar um ponto de extremidade íntegro quando partes críticas do aplicativo estão falhando.

Para obter mais informações, consulte Padrão de monitoramento de ponto de extremidade de integridade.

Atraso de failover - O Gerenciador de Tráfego tem um atraso de failover. Os seguintes fatores determinam a duração do atraso:

  • Intervalos de sondagem: com que frequência o teste verifica a integridade do ponto de extremidade.
  • Número tolerado de falhas: quantas falhas o teste tolera antes de marcar o ponto de extremidade como não íntegro.
  • Tempo limite de teste: quanto tempo antes o Gerenciador de Tráfego considera o ponto de extremidade não íntegro.
  • Tempo de vida (TTL): os servidores DNS devem atualizar os registros DNS armazenados em cache para o endereço IP. O tempo necessário depende do TTL do DNS. A TTL padrão é 300 segundos (5 minutos), mas você pode configurar esse valor ao criar o perfil do Gerenciador de Tráfego.

Para obter mais informações, consulte Monitoramento do Gerenciador de Tráfego.

Gateway de aplicativo e balanceador de carga

Familiarize-se com as políticas de teste de integridade do Application Gateway e do balanceador de carga para garantir que você compreenda a integridade de suas VMs. Aqui está uma breve visão geral:

  • O Gateway de Aplicativo sempre usa uma investigação HTTP.

  • O Load Balancer pode avaliar HTTP ou TCP. Use um teste HTTP se uma VM executar um servidor HTTP. Use TCP para todo o resto.

  • As investigações HTTP enviam uma solicitação HTTP GET para um caminho especificado e escutam uma resposta HTTP 200. Esse caminho pode ser o caminho raiz ("/") ou um ponto de extremidade de monitoramento de integridade que implementa lógica personalizada para verificar a integridade do aplicativo.

  • O ponto de extremidade deve permitir solicitações HTTP anônimas. Se um teste não conseguir alcançar uma instância dentro do período de tempo limite, o Application Gateway ou o Load Balancer interromperá o envio de tráfego para essa VM. A investigação continua a verificar e retornará a VM para o pool de back-end se a VM ficar disponível novamente.

Para saber mais, veja:

Excelência operacional

Grupos de recursos - Use grupos de recursos para gerenciar recursos do Azure por tempo de vida, proprietário e outras características.

Emparelhamento de rede virtual - Use o emparelhamento de rede virtual para conectar perfeitamente duas ou mais redes virtuais no Azure. As redes virtuais aparecerão como uma só para fins de conectividade. O tráfego entre máquinas virtuais em uma rede virtual emparelhada usa infraestrutura de backbone da Microsoft. Certifique-se de que o espaço de endereço das redes virtuais não se sobrepõe.

Rede virtual e sub-redes - Crie uma sub-rede separada para cada camada da sua sub-rede . Você deve implantar VMs e recursos, como Application Gateway e Load Balancer, em uma rede virtual com sub-redes.

Segurança

Web Application Firewall - A funcionalidade WAF do Gateway de Aplicativo do Azure detectará e impedirá ataques no nível HTTP, como SQL injection (SQLi) ou cross-site scripting (CSS).

Firewall de Próxima Geração - O Firewall Premium do Azure fornece uma camada adicional de defesa inspecionando o conteúdo em busca de ataques que não sejam da Web, como arquivos mal-intencionados carregados via HTTP(S) ou qualquer outro protocolo.

Criptografia de ponta a ponta - O tráfego é criptografado o tempo todo ao atravessar a rede do Azure. O Gateway de Aplicativo e o Firewall do Azure criptografam o tráfego antes de enviá-lo ao sistema de back-end correspondente.

Negação de Serviço Distribuída (DDoS) - Use a Proteção de Rede DDoS do Azure para obter maior proteção contra DDoS do que a proteção básica que o Azure fornece.

Grupos de segurança de rede (NSGs) - Use NSGs para restringir o tráfego de rede dentro da rede virtual. Por exemplo, na arquitetura de três camadas mostrada aqui, a camada de dados aceita tráfego somente da camada de negócios, não do front-end da Web. Somente a camada de negócios pode se comunicar diretamente com a camada de banco de dados. Para impor essa regra, a camada de banco de dados deve bloquear todo o tráfego de entrada, exceto a sub-rede da camada de negócios.

  1. Permitir tráfego de entrada da sub-rede da camada de negócios.
  2. Permitir tráfego de entrada da própria sub-rede da camada de banco de dados. Essa regra permite a comunicação entre as VMs do banco de dados. A replicação e o failover de banco de dados precisam dessa regra.
  3. Negar todo o tráfego de entrada da rede virtual, usando a VirtualNetwork tag na regra) para substituir a instrução de permissão incluída nas regras NSG padrão.

Crie a regra 3 com prioridade mais baixa (número maior) do que as primeiras regras.

Você pode usar marcas de serviço para definir controles de acesso à rede em Grupos de Segurança de Rede ou no Firewall do Azure.

Para obter mais informações, consulte Configuração da infraestrutura do gateway de aplicativo.

Otimização de custo

Para saber mais, veja:

Eficiência de desempenho

Conjuntos de dimensionamento de máquina virtual - Use conjuntos de dimensionamento de máquina virtual para automatizar a escalabilidade de suas máquinas virtuais. Os conjuntos de dimensionamento de máquina virtual estão disponíveis em todos os tamanhos de máquina virtual Windows e Linux. Você só é cobrado pelas máquinas virtuais implantadas e pelos recursos de infraestrutura subjacente consumidos. Não há cobranças adicionais. Os benefícios dos Conjuntos de Dimensionamento de Máquina Virtual são:

  • Crie e gerencie várias máquinas virtuais facilmente
  • Alta disponibilidade e resiliência de aplicativos
  • Dimensionamento automatizado à medida que a demanda de recursos muda

Para obter mais informações, consulte Conjuntos de dimensionamento de máquina virtual.

Próximas etapas

Para obter mais arquiteturas de referência usando as mesmas tecnologias, consulte: