Editar

Partilhar via


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

Azure Firewall
Azure Application Gateway
Azure Bastion
Azure Load Balancer
Azure Traffic Manager

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 possa resistir a uma interrupção regional. A inspeção de tráfego é fornecida pelo Firewall de Aplicativo Web do Azure (WAF) e pelo Firewall do Azure.

Notas sobre arquitetura

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

Em um ambiente WAN virtual, os gateways de aplicativos não podem ser implantados no hub, portanto, seriam instalados em redes virtuais faladas.

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 para o 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 dupla inspeção pelo WAF e pelo Firewall do Azure desse tráfego da Web 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 Application Gateway oferece uma melhor integração com o Firewall do Azure para uma abordagem de proteção em camadas.

Fluxos de tráfego HTTP(S) de entrada

Diagrama mostrando o balanceamento de carga de várias regiões com o Firewall do Azure, o Gateway de Aplicativo e o Gerenciador de Tráfego para tráfego da Web.

Transfira um ficheiro do Visio desta arquitetura.

  1. O Azure Traffic Manager 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 Application Gateways 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 endpoint; O Gestor de Tráfego não vê o tráfego HTTP(S).

  2. Os Gateways de Aplicativos implantados em zonas de disponibilidade recebem tráfego HTTP(S) do navegador e os Firewalls de Aplicativos Web Premium inspecionam o tráfego para detetar ataques da Web. Os Gateways de Aplicativos enviarão tráfego para seu back-end, o balanceador de carga interno para as máquinas virtuais frontend. Para esse fluxo específico, o balanceador de carga interno na frente dos servidores Web não é estritamente necessário, uma vez que o Application Gateway pode executar esse balanceamento de carga sozinho. No entanto, ele está 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 frontend será intercetado pelo Firewall Premium do Azure por meio de Rotas Definidas pelo Usuário aplicadas na sub-rede do Gateway de Aplicativo. O Firewall Premium do Azure aplicará a inspeção TLS ao tráfego para segurança adicional. O Firewall do Azure também é redundante de zona. Se o Firewall do Azure detetar uma ameaça no tráfego, ele descartará os pacotes. Caso contrário, após a 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á distribuído pelas 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 de zona, como o balanceador de carga da camada da Web.

  7. As máquinas virtuais da camada de negócios estão espalhadas por zonas de disponibilidade e encaminharã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

Diagrama mostrando o balanceamento de carga de várias regiões com o Firewall do Azure, o Gateway de Aplicativo e o Gerenciador de Tráfego para tráfego não Web.

Transfira um ficheiro do Visio desta arquitetura.

  1. O Azure Traffic Manager 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 endpoint; O Gestor de Tráfego não vê o tráfego HTTP(S).

  2. O Firewall Premium do Azure é redundante de zona e inspecionará o tráfego de entrada em busca de segurança. Se o Firewall do Azure detetar uma ameaça no tráfego, ele descartará os pacotes. Caso contrário, após a inspeção bem-sucedida, o Firewall do Azure encaminhará o tráfego para o balanceador de carga interno da camada da Web executando a Traduçã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á distribuído pelas 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 de zona, como o balanceador de carga da camada da Web.

  6. As máquinas virtuais da camada de negócios estão espalhadas por zonas de disponibilidade e encaminharã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 irã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 aplicativos 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 baseado em nuvem e gerenciado pela Microsoft 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 as mudanças de demanda de aplicativos.
  • O Gateway de Aplicativo do Azure é um balanceador de carga de camada 7 com funcionalidade opcional do Firewall de Aplicativo Web (WAF). O SKU v2 do Application Gateway suporta redundância de zona de disponibilidade e é recomendado 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 Azure Traffic Manager é um balanceador de carga de tráfego global baseado em DNS que distribui tráfego para serviços em regiões globais do Azure enquanto fornece alta disponibilidade e capacidade de resposta. Para obter mais informações, veja a secção Configuração do Gestor de Tráfego.
  • O Azure Load Balancer é um balanceador de carga de camada 4. Um balanceador de carga redundante 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 tem recursos aprimorados para proteger contra ataques distribuídos de negação de serviço (DDoS).
  • O DNS do Azure é um serviço de alojamento para domínios DNS. Ele fornece resolução de nomes usando a infraestrutura do Microsoft Azure. Ao alojar os seus domínios no Azure, pode gerir os recursos DNS com as mesmas credenciais, APIs, ferramentas e faturação dos seus outros serviços do Azure.
  • As zonas de DNS privado do Azure são um recurso do DNS do Azure. As Zonas Privadas DNS do Azure fornecem resolução de nomes dentro de uma rede virtual e entre redes virtuais. Os registos contidos numa zona DNS privada não podem ser resolvidos a partir da Internet. A resolução de DNS em relação a uma zona DNS privada funciona apenas a partir de redes virtuais ligadas à mesma.
  • As Máquinas Virtuais do Azure são recursos de computação escalonáveis e sob demanda que oferecem a flexibilidade da virtualização, mas eliminam as demandas de manutenção do hardware físico. As opções de sistema operacional incluem Windows e Linux. Certos componentes dos aplicativos podem ser substituídos por recursos do Azure de plataforma como serviço (por exemplo, o banco de dados e a camada de frontend), mas a arquitetura não mudaria significativamente se usasse o Private Link e a Integração VNet do Serviço de Aplicativo para trazer esses serviços PaaS para a rede virtual.
  • Os Conjuntos de Dimensionamento de Máquina Virtual do Azure são dimensionamentos de máquinas virtuais 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. Neste 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 roteamento de desempenho. Ele roteia o tráfego para o ponto de extremidade que tem a menor latência para o usuário. O Gestor de Tráfego ajusta automaticamente o seu algoritmo de balanceamento de carga à medida que a latência do ponto final é alterada. 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 para 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 Application Gateways, 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 desencadearia 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 em nível regional, como:

  • Firewall de Aplicações Web (WAF)
  • Terminação do Transport Layer Security (TLS)
  • Encaminhamento baseado no caminho
  • Afinidade de sessão baseada em cookies

Firewall do Azure - O Firewall Premium do Azure oferece segurança de rede para aplicativos genéricos (tráfego da Web e não da 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 Premium do Firewall 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 evitar 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 aderem aos pilares do Azure Well-Architected Framework (WAF). 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, consulte Microsoft Azure Well-Architected Framework.

Fiabilidade

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 no suporte da zona de disponibilidade.

Pares de regiões - Use pares de regiões para obter mais resiliência. Certifique-se de que ambos os Pares de Região dão suporte a todos os serviços do Azure de que seu aplicativo precisa (consulte serviços por região). Aqui estão dois benefícios dos Pares de Região:

  • As atualizações planejadas do Azure são implantadas 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 seu Gateway de Aplicativo, Firewall do Azure, Balanceador de Carga do Azure e 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 do aplicativo em constante mudança.

Para obter mais informações, consulte:

Roteamento global

Método de roteamento global - Use o método de roteamento de tráfego que melhor atende às necessidades de seus clientes. O Traffic Manager suporta 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 dentro de uma região.

Para obter mais informações, consulte:

Visualização de tráfego global

Utilize a Vista de Tráfego no Gestor de Tráfego para ver padrões de tráfego e métricas de latência. A Vista de Tráfego pode ajudá-lo a planear a expansão da sua pegada para novas regiões do Azure.

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

Gateway de Aplicação

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

  • O 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 serão geradas em zonas de disponibilidade para oferecer tolerância a falhas.

  • O 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 SKU v1 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.

Azure Firewall

A camada Premium do Firewall do Azure é necessária neste design para fornecer inspeção TLS. O Firewall do Azure intercetará as sessões TLS entre o Gateway de Aplicativo e as máquinas virtuais da camada da Web que geram 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 Aplicativos.

Recomendações da sonda de saúde

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

Gestor de Tráfego

Integridade do ponto de extremidade - Crie um ponto de extremidade que informe a integridade geral do aplicativo. O Gerenciador de Tráfego usa uma sonda HTTP(S) para monitorar a disponibilidade de cada região. A sonda verifica a existência de uma resposta HTTP 200 para um caminho de URL especificado. Use o ponto de extremidade criado para a sonda de integridade. Caso contrário, a sonda pode relatar um ponto de extremidade íntegro quando partes críticas do aplicativo estiverem 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 a sonda verifica a integridade do ponto de extremidade.
  • Número tolerado de falhas: quantas falhas a sonda tolera antes de marcar o ponto final como não íntegro.
  • Tempo limite de teste: quanto tempo antes de o Traffic Manager considerar o ponto de extremidade não íntegro.
  • Time-to-live (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. O TTL predefinido é de 300 segundos (5 minutos), mas também pode configurar este valor quando cria o perfil do Gestor 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 investigação de integridade do Application Gateway e do balanceador de carga para garantir que você entenda a integridade de suas VMs. Aqui está uma breve visão geral:

  • O Application Gateway sempre usa uma sonda HTTP.

  • O Balanceador de Carga pode avaliar HTTP ou TCP. Use uma sonda HTTP se uma VM executar um servidor HTTP. Use TCP para todo o resto.

  • As sondas 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 final tem de permitir pedidos HTTP anónimos. Se uma sonda 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. O teste continua a verificar e retornará a VM para o pool de back-end se a VM ficar disponível novamente.

Para obter mais informações, consulte:

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 diretamente duas ou mais redes virtuais no Azure. As redes virtuais aparecem como uma só para fins de conectividade. O tráfego entre máquinas virtuais em redes virtuais emparelhadas usa a 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

Firewall de Aplicativo Web - A funcionalidade WAF do Gateway de Aplicativo do Azure detetará e impedirá ataques no nível HTTP, como injeção de SQL (SQLi) ou script entre sites (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 não 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 para o sistema 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. Permita o tráfego de entrada da própria sub-rede da camada de banco de dados. Esta regra permite a comunicação entre as VMs de banco de dados. A replicação e o failover do 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 menor (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 Firewall do Azure.

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

Otimização de custos

Para obter mais informações, consulte:

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áquinas virtuais estão disponíveis em todos os tamanhos de máquinas virtuais Windows e Linux. Você só é cobrado pelas máquinas virtuais implantadas e pelos recursos de infraestrutura subjacentes consumidos. Não há cobranças incrementais. 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óximos passos

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