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
Gateway de Aplicação do Azure
Azure Bastion
Balanceador de Carga do Azure
Gestor 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 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 Gateway de Aplicações estiver implementado no hub, ainda é necessário ter múltiplos Gateways de Aplicações, cada um para um conjunto específico de aplicações, para controlar o âmbito de acesso baseado em funções do Azure (Azure RBAC) e evitar atingir os limites internos do Gateway de Aplicações. Para mais informações, consulte Limites do Gateway de Aplicação.

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 as aplicações web estiverem expostas (sem aplicações não-HTTP(S)), e a dupla inspeção por parte do WAF e do Azure Firewall deste tráfego web não for necessária, o Azure Front Door seria uma solução global de balanceamento de carga melhor do que o Traffic Manager. 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 Aplicação enviam tráfego para o seu backend, o balanceador de carga interno das máquinas virtuais (VMs) frontend. Para este fluxo específico, o balanceador de carga interno em frente aos servidores web não é estritamente obrigatório, uma vez que o Application Gateway poderia realizar este balanceamento de carga sozinho. Mas está incluído para manter a coerência do fluxo em aplicações não HTTP(S).

  3. O tráfego entre o Application Gateway e o balanceador de carga interno frontend é interceptado pelo Azure Firewall Premium através de rotas definidas pelo utilizador aplicadas na sub-rede do Application Gateway. O Azure Firewall Premium aplica a inspeção TLS ao tráfego para maior segurança. O Firewall do Azure também é redundante de zona. Se o Azure Firewall detetar uma ameaça no tráfego, elimina os pacotes. Caso contrário, após uma inspeção bem-sucedida, o Azure Firewall encaminha o tráfego para o balanceador de carga interno do nível web de destino.

  4. A camada web é a primeira camada da aplicação de três níveis. Contém a interface do utilizador e também analisa as interações do utilizador. O balanceador de carga da camada web está distribuído por todas as três zonas de disponibilidade e distribui o tráfego para cada uma das três máquinas virtuais da camada web.

  5. As máquinas virtuais do nível web estão distribuídas por todas as três zonas de disponibilidade e comunicam com o nível de negócio através 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 de nível empresarial estão distribuídas por zonas de disponibilidade e encaminham o tráfego para o ouvinte do grupo de disponibilidade das bases 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 Azure Firewall Premium é redundante por zona e inspeciona o tráfego de entrada para segurança. Se o Azure Firewall detetar uma ameaça no tráfego, elimina os pacotes. Caso contrário, após uma inspeção bem-sucedida, o Azure Firewall encaminha o tráfego para o balanceador de carga interno da linha web que realiza a Tradução de Endereços 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 web está distribuído por todas as três zonas de disponibilidade e distribui o tráfego para cada uma das três máquinas virtuais da camada web.

  4. As máquinas virtuais da camada web estão distribuídas por todas as três zonas de disponibilidade e comunicam com a camada de negócio através 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 de nível empresarial estão distribuídas por zonas de disponibilidade e encaminham o tráfego para o ouvinte do grupo de disponibilidade das bases 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 patches de máquinas virtuais ou outra conectividade à Internet vão das máquinas virtuais da carga de trabalho para o Azure Firewall através de rotas definidas pelo utilizador (UDRs). O Azure Firewall aplica regras de conectividade usando categorias web, bem como regras de rede e aplicação para evitar que cargas de trabalho acedam a cenários inadequados de conteúdo ou 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. Nessa arquitetura, o Firewall do Azure fornece segurança de rede para tráfego da Web e não da Web. Ele usa a inspeção TLS para inspecionar fluxos HTTP(S) de entrada do Application Gateway, lida com 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 Application Gateway é um balanceador de carga de camada 7 que fornece funcionalidade de firewall de aplicativo da Web (WAF). Nessa arquitetura, o Application Gateway fornece balanceamento de carga regional para tráfego HTTP(S), ajuda a detetar 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 Gestor 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, ao mesmo tempo que fornece 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 recursos back-end. Nessa arquitetura, o Load Balancer fornece balanceamento de carga interno entre camadas de aplicativos e mantém alta disponibilidade em zonas de disponibilidade dentro de cada região.

  • A Proteção contra DDoS do Azure é um serviço que ajuda a proteger contra ataques distribuídos de negação de serviço (DDoS). 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 alojamento 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 balanceamento de carga e failover baseados em DNS.

  • As zonas privadas do DNS do Azure são um recurso do DNS do Azure. As zonas privadas do DNS do Azure fornecem resolução de nomes dentro de uma rede virtual e entre redes virtuais. Nessa arquitetura, as zonas privadas do DNS do Azure habilitam a resolução interna de nomes 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 escaláveis sob demanda 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 aplicativos 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 front-end, dos aplicativos por recursos do Azure de plataforma como serviço (PaaS). No entanto, a arquitetura não mudará significativamente se você usar o Azure Private Link e a integração de rede virtual do Serviço de Aplicativo do Azure para trazer esses serviços PaaS para a rede virtual.

  • Os Conjuntos de Dimensionamento de Máquina Virtual do Azure são um serviço que fornece dimensionamento de máquina virtual automatizado e com balanceamento de carga para simplificar o gerenciamento de aplicativos e aumentar a disponibilidade. Nessa arquitetura, os Conjuntos de Dimensionamento de Máquina Virtual permitem o dimensionamento automático de camadas de aplicativos com base na demanda, mantendo a alta disponibilidade nas 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 entre si, à 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 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 falha na zona, as restantes zonas de disponibilidade nessa região assumiriam 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.

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, consulte Microsoft Azure Well-Architected Framework.

Fiabilidade

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

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

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

Muitas regiões do Azure são emparelhadas. Se a sua região tiver um par, pode 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ões 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 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.

Para mais informações, consulte a Vista de Tráfego do Gestor de Tráfego.

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 Azure Firewall interceta as sessões TLS entre o Application Gateway e as máquinas virtuais de nível web que geram os seus próprios certificados, bem como inspeciona 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. A sonda continua a verificar e devolve a VM ao pool de back-end se a VM voltar a estar disponível.

Para obter mais informações, consulte:

Segurança

A segurança oferece 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 de Aplicações Web - A funcionalidade WAF do Azure Application Gateway deteta e previne ataques ao nível HTTP, como injeção SQL (SQLi) ou scripting cross-site (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 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 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

A Otimização de Custos consiste em procurar formas 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 projeto para Otimização de custos.

Para obter mais informações, consulte:

Excelência Operacional

A Excelência Operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de projeto para o Operational Excellence.

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.

Eficiência de desempenho

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