Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo ajuda você a selecionar o serviço de balanceamento de carga Azure correto para sua carga de trabalho. Ele compara Azure Load Balancer, Gateway de Aplicativo e Azure Front Door para distribuição de tráfego regional e global. Ele também explica quando combiná-los. Para uma visão mais curta, serviço por serviço, veja O que é balanceamento de carga e entrega de conteúdo?
O que este artigo aborda
A entrega de aplicativos abrange a forma como sua rede distribui o tráfego entre os recursos de back-end após ele chegar ao perímetro da rede. Este artigo aborda o balanceamento de carga de Camada 4 e Camada 7 e a aceleração global do tráfego. Ele também aborda os critérios de decisão para escolher entre os três serviços primários de balanceamento de carga Azure.
Note
Este artigo complementa a entrada da Internet: exponha seu aplicativo à Internet, que se concentra em como o tráfego chega à sua rede. Este artigo se concentra em como equilibrar e entregar esse tráfego para os back-ends do aplicativo.
Quem precisa deste artigo
Leia este artigo se você:
- Hospedar aplicativos Web ou APIs que precisam de alta disponibilidade em várias instâncias de back-end.
- Precisa de descarregamento de SSL/TLS, roteamento baseado em URL ou proteção de Firewall de Aplicações Web (WAF) para tráfego HTTP/HTTPS.
- Distribua o tráfego em várias regiões Azure para recuperação de desastre ou desempenho.
- Executar cargas de trabalho não HTTP (TCP/UDP) que exigem balanceamento de carga regional com sondas de integridade.
- Deseja entender qual balanceador de carga se ajusta ao tipo de tráfego, ao escopo geográfico e aos requisitos de segurança.
Foco em migração direta: muitos aplicativos internos realocados precisam apenas de um Load Balancer regional. Adicione serviços de entrega voltados para a Internet ao publicar um aplicativo aos clientes.
Foco em modernização: escolha a entrega por tipo de aplicativo: Azure Front Door para aplicativos Web globais e Gerenciador de Tráfego para aplicativos não Web, com pontos de extremidade regionais ativos-ativos.
Foco em nuvem cruzada: mapeie balanceadores de carga de outras nuvens para equivalentes no Azure (por exemplo, AWS ALB para Gateway de Aplicativo, NLB para Azure Load Balancer) e entregue através do spoke atrás do firewall do hub.
Azure serviços e recursos
A tabela a seguir resume os três serviços primários de balanceamento de carga Azure.
| Service | O que ele fornece | Quando usar isso | Restrições de chave |
|---|---|---|---|
| Azure Standard Load Balancer | Balanceamento de carga da camada 4 (TCP/UDP) em uma região. Sondas de integridade, redundância de zona, regras SNAT de saída e portas de alta disponibilidade para dispositivos virtuais de rede. | Conjuntos de Dimensionamento de Máquinas Virtuais, tráfego interno do AKS, cargas de trabalho regionais não HTTP/HTTPS e alta disponibilidade de NVA. | Nenhuma terminação SSL/TLS; nenhum WAF; nenhum roteamento baseado em URL; somente no escopo regional. |
| Gateway de Aplicativo do Azure | Balanceamento de carga regional da Camada 7 (HTTP/HTTPS). Terminação SSL/TLS, roteamento baseado em caminho de URL, hospedagem em vários sites, afinidade de sessão baseada em cookies e integração opcional com WAF. | Aplicativos Web regionais que precisam de descarregamento de SSL, roteamento de URL, suporte a WebSocket ou proteção de WAF. | Somente regional; requer uma sub-rede dedicada; não é adequado para cenários globais de roteamento ou CDN. |
| Azure Front Door | Balanceamento de carga anycast global e CDN. Terminação TLS na borda, WAF integrado, sondagens de integridade de origem, divisão de tráfego e cache em mais de 190 pontos de presença (PoPs) globais. | Aplicações web globais, implantações multirregionais ativo-ativo, CDN e cache, e aplicação global de WAF. | Somente HTTP/HTTPS; as origens devem ser publicamente acessíveis ou alcançáveis por meio de um Link Privado (nível Premium). |
Redundância de zona
A redundância de zona protege a camada de entrega do aplicativo contra falhas de datacenter. Cada serviço lida com zonas de disponibilidade de forma diferente:
- Standard Load Balancer (público) tem redundância de zona por padrão porque os endereços IP públicos Standard usam a configuração com redundância de zona por padrão. O tráfego continua a fluir mesmo se uma zona de disponibilidade falhar. O Load Balancer Padrão (interno) requer configuração explícita de front-end com redundância de zona: você deve selecionar várias zonas ao criar o IP do front-end.
- O Gateway de Aplicativo v2 dá suporte à redundância de zona quando você implanta instâncias em várias zonas de disponibilidade. Especifique as zonas durante a implantação. Um Gateway de Aplicativo com redundância de zona distribui instâncias pelas zonas selecionadas, mantendo a disponibilidade caso uma única zona fique offline.
- O Azure Front Door é inerentemente redundante em termos de zona como um serviço anycast global. Seus mais de 190 PoPs de borda abrangem várias regiões do mundo, portanto, nenhuma falha em uma única zona ou região impacta o roteamento de tráfego global.
Dimensionamento automático
Cada serviço manipula a escala de forma diferente:
- O Gateway de Aplicativo v2 (camadas Standard_v2 e WAF_v2) dá suporte ao dimensionamento automático com base na carga de tráfego. Você configura as contagens mínima e máxima de instâncias, e o gateway se dimensiona dentro desses limites. O preço usa unidades de capacidade: uma medida composta de novas conexões por segundo, conexões persistentes e taxa de transferência. Defina uma contagem mínima de instâncias de pelo menos duas para cargas de trabalho de produção para evitar latência de inicialização a frio durante picos de tráfego.
- Azure Front Door é dimensionado automaticamente como um serviço global gerenciado. Você não precisa de planejamento de capacidade ou dimensionamento de instância.
- Standard Load Balancer escala para milhões de fluxos TCP/UDP sem intervenção manual ou alterações de configuração. É um serviço de plataforma totalmente gerenciado sem nenhum conceito de instância.
Sondas de saúde
Todos os três serviços usam sondas de integridade para detectar back-ends com problemas e interromper o roteamento de tráfego para eles:
- Standard Load Balancer dá suporte a investigações de integridade TCP, HTTP e HTTPS. Configure intervalos de sondagem e limites de problemas para controlar a velocidade de failover. Intervalos mais curtos detectam falhas mais rapidamente, mas geram mais tráfego de investigação.
-
Gateway de Aplicativo usa sondas de integridade HTTP/HTTPS com caminhos, nomes de host e correspondência de resposta personalizáveis. Sondas personalizadas permitem validar a lógica da aplicação (por exemplo, verificar um endpoint
/healthque valida a conectividade com o banco de dados). - Front Door usa sondas de integridade HTTP/HTTPS em origens. Oferece suporte a caminhos de sondagem configuráveis, intervalos e correspondência de códigos de resposta. O Front Door sonda origens de vários PoPs, fornecendo verificação de integridade distribuída.
Como escolher
O fluxograma a seguir resume o caminho de decisão principal para selecionar um serviço de balanceamento de carga Azure.
Use as tabelas de decisão a seguir para selecionar o serviço de balanceamento de carga correto para seu cenário.
De qual balanceador de carga preciso?
| Eu preciso... | Utilização |
|---|---|
| Balanceamento de carga de tráfego TCP/UDP em uma única região | Load Balancer Padrão do Azure: distribuição de camada 4 com sondas de integridade, redundância de zona e portas de alta disponibilidade. |
| Encerrar SSL/TLS, rotear por caminho de URL ou nome do host e adicionar WAF para um aplicativo Web regional | Gateway de Aplicativo do Azure: balanceamento de carga regional de camada 7 com WAF integrado (SKU v2). |
| Roteie o tráfego HTTP/HTTPS globalmente, reduza a latência com cache de borda ou execute failover entre regiões | Azure Front Door: Anycast global com CDN, WAF e sondas de integridade de origem multirregionais. |
Comparação das principais restrições
| Service | Camada | Scope | Limitação principal |
|---|---|---|---|
| Standard Load Balancer | Camada 4 (TCP/UDP) | Regional | Sem reconhecimento de aplicativo: não é possível inspecionar cabeçalhos HTTP, URLs ou cookies. |
| Application Gateway | Camada 7 (HTTP/HTTPS) | Regional | Requer uma sub-rede dedicada (/24 recomendado); não pode rotear o tráfego globalmente. |
| Front Door | Camada 7 (HTTP/HTTPS) | Global | Origins deve ser pública ou acessível via Link Privado (apenas no nível Premium); não há suporte a TCP/UDP. |
Combinando serviços
Muitas arquiteturas de produção combinam vários serviços de balanceamento de carga em uma cadeia. Cada serviço lida com o que faz melhor:
- Front Door + Gateway de Aplicativo: use o Front Door para distribuição global de tráfego e WAF de borda e, em seguida, direcione para instâncias regionais do Gateway de Aplicativo para roteamento baseado em caminho de URL e gerenciamento de pool de back-end. O Front Door Premium pode se conectar ao Application Gateway por meio do Link Privado, mantendo o Application Gateway privado. Esse padrão atende a implantações de várias regiões em que cada região tem requisitos complexos de roteamento de URL.
- Front Door + Load Balancer: use o Front Door para distribuição global de HTTP/HTTPS, com um Load Balancer Standard interno atrás dele para distribuir o tráfego entre Conjuntos de Dimensionamento de Máquinas Virtuais ou NVAs dentro de uma região. O Front Door gerencia o roteamento e o cache globais, enquanto o Load Balancer fornece distribuição de Camada 4 para instâncias de computação.
- Application Gateway + Load Balancer: Use o Application Gateway para gerenciar o tráfego HTTP/HTTPS na camada de front-end e o Load Balancer para camadas de back-end não HTTP (bancos de dados, filas de mensagens) na mesma implantação. Esse padrão mantém a inteligência da Camada 7 na borda com distribuição leve da Camada 4 internamente.
Capacidades de encaminhamento
Entender os recursos de roteamento ajuda a restringir sua escolha:
| Capability | Standard Load Balancer | Application Gateway | Front Door |
|---|---|---|---|
| Roteamento baseado em caminho de URL | No | Sim | Sim |
| Roteamento de vários sites (cabeçalho do host) | No | Sim | Sim |
| Afinidade de sessão baseada em cookie | No | Sim | Sim |
| Divisão ponderada do tráfego | No | No | Sim |
| Roteamento geográfico | No | No | Sim |
| Descarregamento de SSL/TLS | No | Sim | Sim |
| Suporte para WebSocket | Passagem | Sim | Sim |
| Suporte do HTTP/2 | No | Sim | Sim |
Tip
O Application Gateway v2 ajusta-se automaticamente entre um número mínimo e máximo de instâncias, e você paga, no mínimo, pela capacidade mínima, mesmo quando não há tráfego. Defina a contagem mínima de instâncias para sua carga de linha de base, não seu pico e permita que o dimensionamento automático absorva picos. Superdimensionar o mínimo provisionado é uma fonte comum de custos evitáveis do Application Gateway.
Considerações sobre o design
Foco no design de entrega de aplicativos
- Use um Azure Load Balancer interno para o tráfego leste-oeste entre as camadas de um aplicativo re-hospedado, mantendo o mesmo balanceamento de carga do qual o aplicativo já dependia.
- Adicionar serviços de entrega públicos somente para aplicativos expostos à Internet; muitas cargas de trabalho internas migradas não precisam de nenhuma.
- Mantenha a arquitetura de entrega simples e em uma única região durante a re-hospedagem inicial.
- Rotear qualquer tráfego de internet de entrada pelo firewall do hub antes de atingir a carga de trabalho.
Modernizar o foco de design de entrega de aplicativos
- Escolha por tipo de aplicativo: Azure Front Door para aplicativos Web globais (terminação de borda, WAF) e Gerenciador de Tráfego do Azure para aplicativos não Web que precisam de distribuição regional baseada em DNS.
- Implante o modelo ativo-ativo entre regiões e distribua o tráfego para o ponto de extremidade público de cada região atrás do firewall central, que atua como SNAT e DNAT.
- Use o Application Gateway para roteamento regional de Camada 7 e terminação TLS, atrás da Front Door quando precisar de entrega global.
- Não implante o Front Door e o Gerenciador de Tráfego para o mesmo fluxo; escolha um com base em se o aplicativo é Web ou não web.
Foco do design de entrega de aplicações multinuvem
- Mapeie os serviços de distribuição de outras nuvens para o Azure: AWS Application Load Balancer ou Google Cloud Application Load Balancing para Gateway de Aplicativo do Azure, e balanceadores de carga de rede para Azure Load Balancer.
- Hospedar a entrega de Camada 7 (Gateway de Aplicativo, com WAF) no spoke evita a atribuição direta de IPs públicos às máquinas virtuais.
- Encaminhe a entrada pública pelo firewall do hub protegido antes de atingir cargas de trabalho migradas.
- Use o Front Door ou o Traffic Manager para entrega em várias regiões quando as cargas de trabalho estiverem em execução em mais de uma região do Azure.
Pré-requisitos
Antes de implementar os serviços de entrega de aplicativos:
- Rede virtual implantada: Você precisa de pelo menos uma rede virtual com sub-redes. Consulte a rede virtual e o design da sub-rede para obter diretrizes de planejamento de sub-rede.
- Tipo de tráfego de carga de trabalho identificado: Saiba se sua carga de trabalho usa HTTP/HTTPS (Camada 7) ou TCP/UDP (Camada 4). Esse tipo de tráfego determina sua escolha principal de balanceador de carga.
- Escopo geográfico definido: Determine se os usuários estão em uma única região ou distribuídos globalmente. Bases de usuários globais se beneficiam da aceleração anycast do Front Door.
- Capacidade de sub-rede para o Gateway de Aplicativo: O Gateway de Aplicativo requer uma sub-rede dedicada sem outros recursos. Uma sub-rede /24 suporta até 125 instâncias mais cinco endereços reservados no Azure.
Considerações de segurança
Os serviços de balanceamento de carga fazem parte do perímetro de segurança. Eles são os primeiros componentes a processar o tráfego de entrada, o que torna a configuração de segurança crítica. Siga estas práticas para proteger a camada de entrega do aplicativo.
Firewall de Aplicativo Web (WAF)
Habilite o WAF no modo de prevenção no Application Gateway ou no Front Door para todas as cargas de trabalho web de produção. O modo de detecção registra apenas ameaças sem bloqueá-las. Use isso durante o ajuste inicial para identificar falsos positivos e, em seguida, alterne para o modo de prevenção antes de o tráfego de produção começar a fluir.
O WAF protege contra explorações comuns da Web, incluindo:
- Injeção de SQL e cross-site scripting (XSS)
- Anomalias de protocolo e contrabando de requisições
- Bots e rastreadores (com regras de proteção contra bot)
- As 10 principais vulnerabilidades do OWASP por meio de conjuntos de regras gerenciados
Tanto o WAF do Application Gateway quanto o WAF do Front Door usam o mesmo mecanismo de regras, mas têm escopos diferentes. O Gateway de Aplicativo WAF protege uma implantação regional, enquanto o Front Door WAF aplica políticas na borda global antes que o tráfego chegue a qualquer origem. Para ajuste detalhado do WAF e configuração do conjunto de regras, consulte Firewall de Aplicativo Web.
proteção contra DDoS
Ative a Proteção DDoS do Azure em todos os endereços IP públicos associados aos seus serviços de balanceamento de carga. Os IPs públicos do Load Balancer Standard e os IPs públicos do Gateway de Aplicativo são alvos principais de ataques volumétricos. Esses IPs representam os pontos de entrada do aplicativo.
Azure Proteção contra DDoS fornece:
- Monitoramento de tráfego sempre ativo com ajuste adaptativo.
- Mitigação automática de ataque quando o tráfego excede um limite.
- Telemetria de ataques e alertas por meio do Azure Monitor.
- Proteção de custos (crédito de serviço) para o escalonamento de recursos acionado por ataques DDoS.
Para planejamento e configuração de proteção contra DDoS, consulte a proteção contra DDoS.
Link Privado de origem (Front Door Premium)
Azure Front Door Premium oferece suporte à conectividade do Link Privado com origens. Essa funcionalidade remove a necessidade de servidores de back-end acessíveis publicamente. O Front Door conecta-se à sua origem por meio da rede de backbone Azure em vez da Internet pública. Use origens do Link Privado quando:
- Seus back-ends são serviços internos que não devem ter endereços IP públicos.
- Você precisa restringir o acesso à origem apenas ao tráfego do Front Door.
- Os requisitos de conformidade proíbem endereços de acesso públicos em servidores de aplicação.
- Você deseja remover a superfície de ataque de uma origem exposta publicamente.
As origens do Link Privado com suporte incluem App Service, Armazenamento do Azure, Application Gateway, Balanceador de Carga Padrão interno e origens personalizadas com serviço Link Privado.
Para padrões de arquitetura do Link Privado, consulte o acesso privado aos serviços PaaS do Azure.
Importante
O nível Standard do Front Door não permite a Link Privado para origens. Somente o Front Door Premium fornece essa funcionalidade.
TLS mútuo (mTLS)
O Gateway de Aplicativo v2 dá suporte ao TLS mútuo para autenticação de back-end. Use o mTLS quando os servidores de back-end exigirem autenticação de cliente baseada em certificado do gateway. Essa autenticação adiciona uma camada de verificação de confiança. O backend pode confirmar que o tráfego vem da instância legítima do Application Gateway, e não de um agente mal-intencionado que contornou o gateway.
Artigos relacionados
- O que é balanceamento de carga e entrega de conteúdo?: Visão geral serviço a serviço do Gateway de Aplicativo do Azure, Load Balancer e Front Door.
- Entrada da Internet: exponha seu aplicativo à Internet: como o tráfego chega ao seu perímetro de rede Azure.
- Projeto de rede virtual e de sub-rede: planejamento de sub-rede, incluindo o dimensionamento da sub-rede dedicada do Gateway de Aplicativo.
- Acesso privado aos serviços PaaS do Azure: padrões de Link Privado, incluindo Front Door Premium, para a origem.
- Conectividade entre regiões: Arquiteturas multirregional com o Front Door como ponto de entrada global.
- Saída de Internet: SNAT, regras de saída e gateway NAT para tráfego de saída de back-ends com balanceamento de carga.
Saiba mais
- O que é Azure Load Balancer?
- O que é Gateway de Aplicativo do Azure?
- O que é o Azure Front Door?
- Localizações de borda do Azure Front Door por área metropolitana
- Confiabilidade no Azure Load Balancer
- Configuração de infraestrutura do Gateway de Aplicação
- Segure sua origem com Link Privado no Azure Front Door Premium
Próximas Etapas
Tip
Explorando por conta própria? Retorne ao navegador de visão geral para encontrar seu próximo artigo por funcionalidade.
Próximo passo na sua jornada de migração:
Controlar o tráfego de saída da Internet: centralize o acesso de saída por meio do firewall do hub e desative a saída padrão.
A seguir, em sua jornada de modernização:
Configure a conectividade privada aos serviços PaaS: crie sub-redes de link privado em cada VNet spoke para suas cargas de trabalho de AKS, ASE e banco de dados gerenciado.
A seguir, em sua jornada multinuvem:
Proteja seu caminho de trânsito entre nuvens: implante Firewall do Azure em seu hub virtual seguro para inspecionar todo o tráfego de nuvem cruzada e associado à Internet.