Essa arquitetura é para aplicativos globais voltados para a Internet que usam protocolos HTTP(S) e não HTTP(S). Ela 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 suportar uma interrupção regional. A inspeção de tráfego é fornecida pelo WAF (Firewall de Aplicativo Web do Azure) e pelo Firewall do Azure.
Observações sobre a 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 do hub e o Gateway de Aplicativo também estaria na rede do hub ou em um spoke. 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 evitar atingir os limites do Gateway de Aplicativo (consulte Limites do Gateway de Aplicativo).
Em um ambiente de WAN Virtual, os Gateways de Aplicativo não podem ser implantados no hub, portanto, eles seriam instalados em redes virtuais spoke.
A arquitetura proposta opta pela inspeção dupla do conteúdo da Web por meio de um Firewall de Aplicativo Web (com base no Gateway de Aplicativo) na frente do Firewall do Azure. Existem outras opções, conforme documentado em Firewall e Gateway de Aplicativo para redes virtuais, mas essa opção é a mais flexível e completa: ela expõe o endereço IP do cliente no cabeçalho HTTP X-Forwarded-For 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 (nenhum aplicativo não HTTP(S)) e a inspeção dupla pelo WAF e pelo Firewall do Azure desse tráfego da Web não for necessária, o Azure Front Door será 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, investigações 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
Baixe um Arquivo Visio dessa arquitetura.
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 os 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 na escolha de vários métodos de roteiros. O navegador se conecta diretamente ao ponto de extremidade; O Gerenciador de Tráfego não vê o tráfego HTTP(S).
Os Gateways de Aplicativo implantados em zonas de disponibilidade recebem tráfego HTTP(S) do navegador e os Firewalls do Aplicativo Web Premium inspecionam o tráfego para detectar ataques na Web. Os Gateways de Aplicativo enviarão tráfego para seu back-end, o balanceador de carga interno para as máquinas virtuais de 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 por conta própria. No entanto, ele é incluído para consistência com o fluxo para aplicativos não HTTP(S).
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 Firewall do Azure Premium aplicará a inspeção TLS ao tráfego para segurança adicional. O Firewall do Azure também tem redundância de zona. Se o Firewall do Azure detectar 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.
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 é distribuído 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.
As máquinas virtuais da camada da Web estão espalhadas por todas as três zonas de disponibilidade e se comunicarão com a camada de negócios por meio de um balanceador de carga interno dedicado.
A camada de negócios processa as interações do usuário e determina as próximas etapas, além de ficar 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 entre as três zonas de disponibilidade. O balanceador de carga de camada empresarial tem redundância de zona, como o balanceador de carga de camada da Web.
As máquinas virtuais da camada de negócios são distribuídas entre zonas de disponibilidade e rotearão o tráfego para o ouvinte do grupo de disponibilidade dos bancos de dados.
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 DNN (nome de rede distribuída) 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
Baixe um Arquivo Visio dessa arquitetura.
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 Firewall de Aplicativo servem como os pontos de extremidade de back-end do Gerenciador de Tráfego para tráfego que não é HTTP(S). O Gerenciador de Tráfego resolve consultas DNS com base na escolha de vários métodos de roteiros. O navegador se conecta diretamente ao ponto de extremidade; O Gerenciador de Tráfego não vê o tráfego HTTP(S).
O Firewall do Azure Premium tem redundância de zona e inspecionará o tráfego de entrada quanto à segurança. Se o Firewall do Azure detectar 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 que executa a DNAT (Conversão de Endereços de Rede de Destino) nos pacotes de entrada.
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 é distribuído 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.
As máquinas virtuais da camada da Web estão espalhadas por todas as três zonas de disponibilidade e se comunicarão com a camada de negócios por meio de um balanceador de carga interno dedicado.
A camada de negócios processa as interações do usuário e determina as próximas etapas, além de ficar 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 entre as três zonas de disponibilidade. O balanceador de carga de camada empresarial tem redundância de zona, como o balanceador de carga de camada da Web.
As máquinas virtuais da camada de negócios são distribuídas entre zonas de disponibilidade e rotearão o tráfego para o ouvinte do grupo de disponibilidade dos bancos de dados.
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 DNN (nome de rede distribuída) 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 aplicará regras de conectividade usando categorias da Web, bem como regras de rede e 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 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 distribuído entre zonas de disponibilidade e oferece dimensionamento automático para lidar com as alterações na demanda do aplicativo.
- O Gateway de Aplicativo do Azure é um balanceador de carga de camada 7 com funcionalidade opcional do WAF (Firewall do Aplicativo Web). O SKU v2 do Gateway de Aplicativo dá suporte à redundância da zona de disponibilidade e é recomendado para a maioria dos cenários. O Gateway de Aplicativo inclui dimensionamento automático horizontal configurável para que ele possa reagir automaticamente às alterações na 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 em todas as regiões globais do Azure, fornecendo 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 como proteção contra ataques de DDoS (negação distribuída de serviço).
- 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 de DNS do Azure. As zonas privadas de DNS do Azure fornecem resolução de nomes em uma rede virtual, bem como entre redes virtuais. Os registros contidos em uma zona DNS privada não são resolvidos pela Internet. A resolução DNS em relação a uma zona DNS privada funciona apenas de redes virtuais que estão vinculadas a ela.
- 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 do sistema operacional incluem Windows e Linux. Determinados 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 front-end), mas a arquitetura não seria alterada significativamente se usasse o Link Privado e a Integração VNET do Serviço de Aplicativo para levar esses serviços de PaaS para a rede virtual.
- Os Conjuntos de Dimensionamento de Máquinas Virtuais do Azure são um dimensionamento de máquina virtual automatizado e com balanceamento de carga que simplifica o gerenciamento dos seus aplicativos e aumenta a disponibilidade.
- O SQL Server nas 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 umas às outras, à Internet e a redes entre locais.
- As Rotas Definidas pelo Usuário são um mecanismo para substituir os roteiros 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 percorrer o Firewall do Azure.
Detalhes da solução
Gerenciador de Tráfego – Configuramos o Gerenciador de Tráfego para usar os roteiros de desempenho. Ele roteia o tráfego para o ponto de extremidade com a menor latência 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 é alterada. O Gerenciador de Tráfego fornece failover automático em caso de interrupção regional. Ele usa roteiros prioritários e verificações regulares de integridade 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 Gateways de Aplicativo, 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 disparará um failover regional.
Gateway de Aplicativo – Embora o Gerenciador de Tráfego forneça 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 do Azure Premium 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 do Firewall do Azure Premium.
- Os fluxos não HTTP(S) de entrada da Internet pública são inspecionados com o restante dos recursos do Firewall do Azure Premium.
- 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 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 automático para a região secundária se a região primária ficar indisponível.
- A escolha das melhores regiões para suas necessidades deve ser baseada em considerações técnicas e normativas e suporte à zona de disponibilidade.
Pares de regiões – Use pares de regiões para obter mais resiliência. Verifique se ambos os pares de regiões dão suporte a todos os serviços do Azure exigidos pelo seu aplicativo (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 distribuídas para regiões emparelhadas uma por vez, de modo a minimizar o tempo de inatividade e o risco de interrupção dos aplicativos.
- Os dados continuam residindo na mesma geografia que seu par (com exceção do Sul do Brasil) para fins legais e tributários.
Zonas de disponibilidade – Use várias zonas de disponibilidade para dar suporte ao Gateway de Aplicativo, ao Firewall do Azure, ao Azure Load Balancer 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 do aplicativo em constante mudança.
Para saber mais, veja:
- Regiões e zonas de disponibilidade no Azure
- BCDR (continuidade dos negócios e recuperação de desastres): Regiões Emparelhadas do Azure
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 dá suporte a vários métodos de roteamento de tráfego para encaminhar o tráfego de forma precisa para vários pontos de extremidade de serviço.
Configuração aninhada – Use o Gerenciador de Tráfego em uma configuração aninhada caso precise obter um controle mais granular para escolher um failover preferencial em uma região.
Para saber mais, veja:
- Configurar o método de roteamento de tráfego de desempenho
- Métodos de roteamento do Gerenciador de Tráfego
Exibiçã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. A Exibição de Tráfego pode ajudar você a planejar uma 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 o SKU v2 do Gateway de Aplicativo para resiliência automatizada de uso imediato.
O SKU v2 do Gateway de Aplicativo garante automaticamente que as novas instâncias se espalhem entre 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 fornecer tolerância a falhas.
O SKU v1 do Gateway de Aplicativo permite cenários de alta disponibilidade quando você tem duas ou mais instâncias implantadas. O Azure distribui essas instâncias entre domínios de atualização e de falha para garantir que todas 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 autoridade de certificação 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 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. Encontre 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 investigação de integridade
Confira algumas recomendações de investigações de integridade no Gerenciador de Tráfego, no Gateway de Aplicativo e no Load Balancer.
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 uma investigação 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 que você criou para a investigação de integridade. Caso contrário, a investigação pode relatar um ponto de extremidade íntegro quando partes essenciais do aplicativo estão apresentando falha.
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 investigação: com que frequência a investigação verifica a integridade do ponto de extremidade.
- Número tolerado de falhas: quantas falhas a investigação tolera antes de marcar o ponto de extremidade como não íntegro.
- Tempo-limite de investigação: tempo antes de o Gerenciador de Tráfego considerar o ponto de extremidade como não íntegro.
- Vida útil (TTL): os servidores DNS devem atualizar os registros DNS armazenados em cache para o endereço IP. O tempo que leva 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 Load Balancer
Familiarize-se com as políticas de investigação de integridade do Gateway de Aplicativo e do Load Balancer para garantir que você entenda a integridade de suas VMs. Confira uma breve visão geral:
O Gateway de Aplicativo sempre usa uma investigação HTTP.
O Load Balancer pode avaliar o HTTP ou TCP. Use uma investigação HTTP se uma VM executar um servidor HTTP. Use TCP para o restante.
As investigações HTTP enviam uma solicitação HTTP GET para um caminho especificado e escutam uma resposta HTTP 200. Esse caminho pode ser a 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 uma investigação não puder acessar uma instância dentro do tempo-limite, o Gateway de Aplicativo ou o Load Balancer deixará de enviar 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:
- Investigações de integridade do Load Balancer
- Visão geral do monitoramento de integridade do Gateway de Aplicativo
- Padrão de monitoramento do ponto de extremidade de integridade
Excelência operacional
Grupos de recursos – Use grupos de recursos para gerenciar recursos do Azure por vida útil 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. Verifique se 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 sub-rede. Você deve implantar VMs e recursos, como Gateway de Aplicativo 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 detectará e impedirá ataques no nível HTTP, como injeção de SQL (SQLi) ou CSS (cross-site scripting).
Firewall de Próxima Geração – O Firewall do Azure Premium 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 percorrer a rede do Azure. O Gateway de Aplicativo e o Firewall do Azure criptografam o tráfego antes de enviá-lo para o sistema de back-end correspondente.
DDoS (Negação Distribuída de Serviço) – Use a Proteção de Rede contra 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 na rede virtual. Por exemplo, na arquitetura de três camadas mostrada aqui, a camada de dados aceita apenas o tráfego da camada comercial e 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 da sub-rede de camada de negócios.
- Permita o tráfego de entrada da sub-rede de camada de negócios.
- Permita o tráfego de entrada da própria sub-rede de camada de banco de dados. Essa regra permite a comunicação entre as VMs do banco de dados. A replicação e o failover do banco de dados precisam dessa regra.
- Negue todo o tráfego de entrada da rede virtual usando a marcação
VirtualNetworkna regra) para substituir a instrução permit incluída nas regras padrão do NSG.
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 os controles de acesso à rede em grupos de segurança de rede ou no Firewall do Azure.
Confira mais informações em Configuração da infraestrutura do Gateway de Aplicativo.
Otimização de custo
Para saber mais, veja:
- Preços de balanceamento de carga
- Preços de redes virtuais
- Preços do Gateway de Aplicativo
- Escolhendo o SKU de Firewall do Azure certo para atender às suas necessidades
- Perfil de Gerenciador de Tráfego
- Calculadora de preço
Eficiência de desempenho
Conjuntos de Dimensionamento de Máquinas Virtuais – Use Conjuntos de Dimensionamento de Máquinas Virtuais 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 do Linux e do Windows. Você é cobrado apenas pelas máquinas virtuais implantadas e pelos recursos de infraestrutura subjacentes consumidos. Não há encargos incrementais. Os benefícios dos Conjuntos de Dimensionamento de Máquinas Virtuais são:
- Criar e gerenciar várias máquinas virtuais facilmente
- Alta disponibilidade e resiliência do aplicativo
- Dimensionamento automatizado à medida que a demanda de recursos muda
Para obter mais informações, confira Conjuntos de Dimensionamento de Máquinas Virtuais do Microsoft Azure.
Próximas etapas
Para obter mais arquiteturas de referência usando as mesmas tecnologias, consulte: