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

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á que vários Gateways de Aplicativo, cada um para um determinado conjunto de aplicativos, controlem o escopo do RBAC (controle de acesso baseado em função) do Azure e evitem atingir limites internos do Gateway de Aplicativo. Para obter mais informações, 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 (sem aplicativos não HTTP(S) e a inspeção dupla por WAF e o 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.

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 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).

2. 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 enviam tráfego para seu back-end, o balanceador de carga interno para as VMs (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 poderia executar esse balanceamento de carga em si. Mas isso é incluído para garantir consistência com o fluxo de aplicativos não HTTP(S).

3. O tráfego entre o Gateway de Aplicativo e o balanceador de carga interno de front-end é 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 aplica 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 removerá os pacotes. Caso contrário, após a inspeção bem-sucedida, o Firewall do Azure encaminha 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. Ele 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 em todas as três zonas de disponibilidade e distribui 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 são distribuídas entre as três zonas de disponibilidade e se comunicam 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, 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.

7. As máquinas virtuais de nível empresarial são distribuídas entre zonas de disponibilidade e roteiam o tráfego para o listener 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 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.

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 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).

2. O Firewall do Azure Premium é com redundância de zona e inspeciona o tráfego de entrada em busca de segurança. Se o Firewall do Azure detectar uma ameaça no tráfego, ele removerá os pacotes. Caso contrário, após a inspeção bem-sucedida, o Firewall do Azure encaminha o tráfego para o balanceador de carga interno da camada 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 é distribuído em todas as três zonas de disponibilidade e distribui 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 são distribuídas entre todas as três zonas de disponibilidade e se comunicam 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, 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.

6. As máquinas virtuais de camada de negócios são distribuídas entre zonas de disponibilidade e roteiam 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 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 vão das máquinas virtuais de carga de trabalho para o Firewall do Azure por meio de UDRs (rotas definidas pelo usuário). O Firewall do Azure impõe regras de conectividade usando categorias da Web, bem como regras de rede e aplicativo para impedir que cargas de trabalho acessem cenários inadequados de exfiltração de dados ou conteúdo.

Componentes

• O Firewall do Azure é um firewall de última geração gerenciado pela Microsoft baseado em nuvem que fornece uma inspeção profunda de pacotes para fluxos de tráfego norte-sul e leste-oeste. Nessa arquitetura, o Firewall do Azure fornece segurança de rede para tráfego web e não web. Ele usa a inspeção TLS para inspecionar fluxos HTTP(S) de entrada do Gateway de Aplicativo, manipula fluxos não HTTP(S) de entrada da Internet pública e inspeciona fluxos de saída de VMs para evitar a exfiltração de dados.

• O Gateway de Aplicativo é um balanceador de carga de camada 7 que fornece funcionalidade de WAF (firewall de aplicativo Web). Nessa arquitetura, o Gateway de Aplicativo fornece balanceamento de carga regional para tráfego HTTP(S), ajuda a detectar e prevenir ataques da Web e fornece terminação TLS e roteamento baseado em caminho. Ele serve como o ponto de extremidade de back-end para o Gerenciador de Tráfego.

• O Gerenciador de Tráfego é um balanceador de carga de tráfego global baseado em DNS que distribui o tráfego para serviços em regiões globais do Azure, fornecendo alta disponibilidade e capacidade de resposta. Nessa arquitetura, o Gerenciador de Tráfego fornece balanceamento de carga global resolvendo consultas DNS para direcionar o tráfego para os pontos de extremidade regionais apropriados. Ele faz failover automaticamente para regiões secundárias durante interrupções.

• O Azure Load Balancer é um balanceador de carga de camada 4 que distribui o tráfego de rede de entrada entre os recursos de back-end. Nessa arquitetura, o Load Balancer fornece balanceamento de carga interno entre as camadas de aplicativo e mantém alta disponibilidade entre zonas de disponibilidade em cada região.

• A Proteção contra DDoS do Azure é um serviço que ajuda a proteger contra ataques de DDoS (negação de serviço distribuído). Nessa arquitetura, a Proteção contra DDoS fornece proteção para endereços IP públicos e ajuda a garantir a disponibilidade durante cenários de ataque.

• 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. Nessa arquitetura, o DNS do Azure gerencia registros DNS e trabalha com o Gerenciador de Tráfego para fornecer recursos globais de failover e balanceamento de carga baseados em DNS.

• As zonas privadas DNS 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. Nessa arquitetura, as zonas privadas DNS do Azure permitem a resolução de nomes internos para recursos dentro da infraestrutura de rede virtual.

• As Máquinas Virtuais do Azure são um serviço que fornece recursos de computação sob demanda e escalonáveis que oferecem a flexibilidade da virtualização, mas eliminam as demandas de manutenção do hardware físico. Nessa arquitetura, as Máquinas Virtuais hospedam as camadas de aplicativo e as distribuem entre zonas de disponibilidade em várias regiões para alta disponibilidade.

  Você pode substituir componentes específicos, como o banco de dados e a camada de front-end, dos aplicativos pelos recursos de PaaS (plataforma como serviço) do Azure. No entanto, a arquitetura não mudará significativamente se você usar o Link Privado do Azure e a integração de rede virtual do Serviço de Aplicativo do Azure para trazer esses serviços de PaaS para a rede virtual.

• Os Conjuntos de Dimensionamento de Máquinas Virtuais do Azure são um serviço que fornece dimensionamento automatizado e de máquinas virtuais com balanceamento de carga para simplificar o gerenciamento de aplicativos e aumentar a disponibilidade. Nessa arquitetura, os Conjuntos de Dimensionamento de Máquinas Virtuais permitem o dimensionamento automático de camadas de aplicativo com base na demanda, mantendo a alta disponibilidade entre zonas de disponibilidade.

• O SQL Server em VMs é um serviço que fornece versões completas do SQL Server na nuvem sem precisar gerenciar nenhum hardware local. Nessa arquitetura, o SQL Server em VMs forma a camada de dados que tem grupos de disponibilidade distribuídos entre zonas de disponibilidade e usa DNN para balanceamento de carga.

• A Rede Virtual do Azure é uma rede privada segura na nuvem. Ele conecta VMs umas às outras, à Internet e a redes entre locais. Nessa arquitetura, a Rede Virtual fornece isolamento de rede e conectividade para todos os componentes. O emparelhamento de rede virtual global permite a comunicação de baixa latência entre regiões.

• UDRs são um mecanismo para substituir o roteamento padrão em redes virtuais. Nessa arquitetura, eles forçam os fluxos de tráfego de entrada e saída a atravessar o Firewall do Azure para inspeção de segurança e imposição de políticas.

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 dispararia 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.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Confiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você faz aos seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design parade 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 realiza o failover automaticamente para a região secundária se a região primária falhar.

Escolha as melhores regiões para suas necessidades com base em todos esses fatores:

• Seus requisitos técnicos, incluindo distância geográfica e latência entre regiões
• Necessidades de residência de dados
• Considerações regulatórias
• Suporte à zona de disponibilidade
• Disponibilidade do serviço em cada região
• Custo

Muitas regiões do Azure são emparelhadas. Se sua região tiver um par, poderá haver alguns benefícios em usar a região emparelhada como sua região secundária. No entanto, você deve verificar se o par de região atende a todos os seus requisitos primeiro.

Para obter mais informações sobre como selecionar regiões do Azure, consulte Selecionar regiões do Azure no Cloud Adoption Framework.

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
• Pares de regiões do Azure e regiões não emparelhadas

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.

Para obter mais informações, consulte o Modo de Exibição de Tráfego do Gerenciador de Tráfego.

Application Gateway

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 intercepta as sessões TLS entre o Gateway de Aplicativo e as máquinas virtuais da camada Web que geram seus próprios certificados, bem como inspeciona 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 sonda continua a verificar e, se a VM ficar disponível novamente, ela a retorna para o pool de back-end.

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

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design parade segurança.

Firewall do Aplicativo Web – A funcionalidade waf do Gateway de Aplicativo do Azure detecta e impede ataques no nível HTTP, como SQLi (injeção de SQL) ou CSS (script entre sites).

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.

1. Permita o tráfego de entrada da sub-rede de camada de negócios.
2. 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.
3. Negue todo o tráfego de entrada da rede virtual, usando a marca VirtualNetwork 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 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 custos

A Otimização de Custos trata-se de procurar maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design parade Otimização de Custos.

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

Excelência Operacional

A Excelência Operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução em produção. Para obter mais informações, consulte Lista de verificação de revisão de design parade 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.

Eficiência de desempenho

A Eficiência de Desempenho é a capacidade da carga de trabalho de atender às demandas colocadas nele pelos usuários de maneira eficiente. Para obter mais informações, consulte Lista de verificação de design parade 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:

• Linha de base do AKS para clusters de várias regiões