Recursos do Azure Application Gateway
O Gateway de Aplicação do Azure é um balanceador de carga do tráfego da Web que lhe permite gerir o tráfego das suas aplicações Web.
Nota
Para cargas de trabalho da Web, é altamente recomendável utilizar a proteção contra DDoS do Azure e um firewall de aplicativo Web para se proteger contra ataques DDoS emergentes. Outra opção é empregar o Azure Front Door junto com um firewall de aplicativo Web. O Azure Front Door oferece proteção no nível da plataforma contra ataques DDoS no nível da rede. Para obter mais informações, consulte Linha de base de segurança para serviços do Azure.
O Application Gateway inclui os seguintes recursos:
Terminação SSL / TLS (Secure Sockets Layer)
O gateway de aplicativo suporta terminação SSL/TLS no gateway, após o qual o tráfego normalmente flui sem criptografia para os servidores de back-end. Esta funcionalidade permite que os servidores Web estejam livres de sobrecarga de encriptação e desencriptação dispendiosa. Mas, às vezes, a comunicação não criptografada com os servidores não é uma opção aceitável. Isso pode ser devido a requisitos de segurança, requisitos de conformidade ou o aplicativo só pode aceitar uma conexão segura. Para esses aplicativos, o gateway de aplicativos suporta criptografia SSL/TLS de ponta a ponta.
Para obter mais informações, consulte Visão geral da terminação SSL e SSL de ponta a ponta com o Application Gateway
Dimensionamento automático
O Application Gateway Standard_v2 oferece suporte ao dimensionamento automático e pode ser dimensionado para cima ou para baixo com base na alteração dos padrões de carga de tráfego. O dimensionamento automático também elimina o requisito de escolher um tamanho de implementação ou uma contagem de instâncias ou durante o aprovisionamento.
Para obter mais informações sobre os recursos de Standard_v2 do Gateway de Aplicativo, consulte O que é o Gateway de Aplicativo do Azure v2.
Redundância entre zonas
Um Standard_v2 Application Gateway pode abranger várias zonas de disponibilidade, oferecendo melhor resiliência a falhas e eliminando a necessidade de provisionar gateways de aplicativos separados em cada zona.
VIP estático
O gateway de aplicativo Standard_v2 SKU suporta exclusivamente o tipo VIP estático. Isso garante que o VIP associado ao gateway de aplicativo não seja alterado mesmo durante o tempo de vida do gateway de aplicativo.
Firewall de Aplicações Web
O Web Application Firewall (WAF) é um serviço que fornece proteção centralizada de seus aplicativos Web contra exploits e vulnerabilidades comuns. O WAF é baseado em regras dos conjuntos de regras principais OWASP (Open Web Application Security Project) 3.1 (somente WAF_v2), 3.0 e 2.2.9.
Cada vez mais, as aplicações Web são alvo de ataques maliciosos que exploram vulnerabilidades conhecidas comuns. Destas vulnerabilidades, são frequentes os ataques de injeção de SQL, scripting entre sites, entre muitas outras. Impedir este tipo de ataques ao código das aplicações constitui um desafio e exige uma manutenção, correção e monitorização rigorosas em muitas camadas da topologia da aplicação. Uma firewall de aplicações Web centralizada ajuda a simplificar em muito a gestão da segurança e confere aos administradores de aplicações uma maior garantia de proteção contra as ameaças ou intrusões. Uma solução WAF também pode reagir mais rapidamente a uma ameaça de segurança ao corrigir uma vulnerabilidade conhecida numa localização central, em vez de proteger cada uma das aplicações Web individualmente. Os gateways de aplicativos existentes podem ser facilmente convertidos em um gateway de aplicativo habilitado para Web Application Firewall.
Consulte Proteção contra DDoS de aplicativo para obter orientação sobre como usar o WAF do Azure com o Application Gateway para proteger contra ataques DDoS. Para obter mais informações, consulte O que é o Firewall de Aplicativo Web do Azure.
Controlador de Entrada para AKS
O Application Gateway Ingress Controller (AGIC) permite que você use o Application Gateway como a entrada para um cluster do Serviço Kubernetes do Azure (AKS).
O controlador de entrada é executado como um pod dentro do cluster AKS e consome recursos de entrada do Kubernetes e os converte em uma configuração do Application Gateway, o que permite que o gateway balanceie a carga do tráfego para os pods do Kubernetes. O controlador de entrada suporta apenas Standard_v2 do Application Gateway e WAF_v2 SKUs.
Para obter mais informações, consulte Application Gateway Ingress Controller (AGIC).
Encaminhamento com base no URL
O Roteamento Baseado em Caminho de URL permite rotear o tráfego para pools de servidores de back-end com base nos Caminhos de URL da solicitação. Um dos cenários consiste em encaminhar pedidos de diferentes tipos de conteúdo para diferentes agrupamentos.
Por exemplo, os pedidos de http://contoso.com/video/* são encaminhados para VideoServerPool e os pedidos de http://contoso.com/images/* são encaminhados para ImageServerPool. É selecionado o DefaultServerPool se nenhum dos padrões de caminho corresponder.
Para obter mais informações, consulte Visão geral do roteamento baseado em caminho de URL.
Alojamento de vários sites
Com o Application Gateway, você pode configurar o roteamento com base no nome do host ou nome de domínio para mais de um aplicativo Web no mesmo gateway de aplicativo. Permite-lhe configurar uma topologia mais eficiente para as implementações ao adicionar até 100 sites a um gateway de aplicação. Cada site pode ser direcionado para o seu próprio agrupamento de back-end. Por exemplo, três domínios, contoso.com, fabrikam.com e adatum.com, apontam para o endereço IP do gateway de aplicação. Teria de criar três serviços de escuta com vários sites e configurar cada serviço de escuta para a respetiva definição de porta e protocolo.
As solicitações para http://contoso.com são roteadas para ContosoServerPool, http://fabrikam.com são roteadas para FabrikamServerPool e assim por diante.
Da mesma forma, dois subdomínios do mesmo domínio principal podem ser alojados na mesma implementação do gateway de aplicação. Exemplos de como utilizar subdomínios podem incluir http://blog.contoso.com e http://app.contoso.com alojados numa única implementação do gateway de aplicação. Para obter mais informações, consulte Hospedagem de vários sites do Application Gateway.
Além disso, pode definir nomes de anfitrião de caráter universal num serviço de escuta com vários sites e até cinco nomes de anfitrião por serviço de escuta. Para saber mais, consulte Nomes de host curinga no ouvinte.
Redirecionamento
Um cenário comum para muitas aplicações Web consiste em suportar o redirecionamento automático de HTTP para HTTPS para garantir que toda a comunicações entre uma aplicação e os seus utilizadores ocorre através de um caminho encriptado.
No passado, você pode ter usado técnicas como a criação de pool dedicado cujo único objetivo é redirecionar solicitações recebidas em HTTP para HTTPS. O gateway de aplicação suporta a capacidade de redirecionar o tráfego no Gateway de Aplicação. Isto simplifica a configuração da aplicação, otimiza a utilização de recursos e suporta novos cenários de redirecionamento, incluindo o redirecionamento global e com base no caminho. O suporte ao redirecionamento do Application Gateway não está limitado apenas ao redirecionamento HTTP para HTTPS. Trata-se de um mecanismo de redirecionamento genérico, para que possa redirecionar de e para qualquer porta que define através de regras. Também suporta o redirecionamento para um site externo.
O suporte de redirecionamento do Gateway de Aplicação oferece as seguintes capacidades:
- Redirecionamento global de uma porta para outra porta no Gateway. Isto permite o redirecionamento de HTTP para HTTPS num site.
- Redirecionamento com base no caminho. Este tipo de redirecionamento permite o redirecionamento de HTTP para HTTPS apenas numa área específica de um site, por exemplo, uma área de carrinho de compras indicada por
/cart/*. - Redirecionar para um site externo.
Para obter mais informações, consulte Visão geral do redirecionamento do Application Gateway.
Afinidade de sessão
A funcionalidade de afinidade de sessão com base em cookies é útil quando pretende manter uma sessão de utilizador no mesmo servidor. Usando cookies gerenciados por gateway, o Application Gateway pode direcionar o tráfego subsequente de uma sessão de usuário para o mesmo servidor para processamento. Isto é importante nos casos em que o estado da sessão é guardado localmente no servidor para uma sessão de utilizador.
Para obter mais informações, consulte Como funciona um gateway de aplicativo.
Tráfego de Websocket e HTTP/2
O Gateway de Aplicação fornece suporte nativo para os protocolos WebSocket e HTTP/2. Não existe qualquer definição configurável pelo utilizador para ativar ou desativar seletivamente o suporte de WebSocket.
Os protocolos WebSocket e HTTP/2 ativam a comunicação duplex completa entre um servidor e um cliente através de uma ligação TCP de execução longa. Isto permite uma comunicação mais interativa entre o servidor Web e o cliente, que pode ser bidirecional sem necessidade de consulta, que é necessária em implementações com base em HTTP. Esses protocolos têm baixa sobrecarga, ao contrário do HTTP, e podem reutilizar a mesma conexão TCP para várias solicitações/respostas, resultando em uma utilização de recursos mais eficiente. Estes protocolos foram concebidos para funcionar através das portas HTTP tradicionais 80 e 443.
Para obter mais informações, consulte Suporte a WebSocket e suporte a HTTP/2.
Drenagem de ligação
A drenagem da conexão ajuda você a obter a remoção normal dos membros do pool de back-end durante atualizações de serviço planejadas ou problemas com a integridade do back-end. Essa configuração é habilitada por meio da Configuração de back-end e é aplicada a todos os membros do pool de back-end durante a criação da regra. Uma vez habilitado, o gateway de aplicativo garante que todas as instâncias de cancelamento de registro de um pool de back-end não recebam novas solicitações, permitindo que as solicitações existentes sejam concluídas dentro de um limite de tempo configurado. Aplica-se a casos em que as instâncias de back-end são:
- explicitamente removido do pool de back-end após uma alteração de configuração por um usuário
- notificadas como insalubres pelas sondas de saúde, ou
- removido durante uma operação de scale-in
A única exceção é quando as solicitações continuam a ser intermediadas por proxy para as instâncias de cancelamento de registro devido à afinidade de sessão gerenciada pelo gateway.
A drenagem de conexões também é honrada para conexões WebSocket. A drenagem da conexão é invocada para cada atualização do gateway. Para evitar a perda de conexão para membros existentes do pool de back-end, certifique-se de habilitar a drenagem de conexão.
Para obter informações sobre limites de tempo, consulte Configuração de configurações de back-end.
Páginas de erros personalizadas
O Gateway de Aplicação permite-lhe criar páginas de erro personalizadas, em vez de apresentar as páginas de erro predefinidas. Pode utilizar a sua própria imagem e esquema corporativos através de uma página de erro personalizada.
Para obter mais informações, consulte Erros personalizados.
Rescrever cabeçalhos HTTP e URL
Os cabeçalhos HTTP permitem que o cliente e o servidor passem informações adicionais com a solicitação ou a resposta. Reescrever esses cabeçalhos HTTP ajuda você a realizar vários cenários importantes, como:
- Adicionar campos de cabeçalho relacionados à segurança, como HSTS/ X-XSS-Protection.
- Remoção de campos de cabeçalho de resposta que podem revelar informações confidenciais.
- Remoção de informações de porta de cabeçalhos X-Forwarded-For.
O Application Gateway e o WAF v2 SKU suportam a capacidade de adicionar, remover ou atualizar cabeçalhos de solicitação e resposta HTTP, enquanto os pacotes de solicitação e resposta se movem entre os pools de cliente e back-end. Também pode reescrever os URLs, os parâmetros de cadeia de consulta e o nome do anfitrião. Com a reconfiguração de URL e o roteamento baseado em caminho de URL, você pode optar por rotear solicitações para um dos pools de back-end com base no caminho original ou no caminho reescrito, usando a opção de mapa de caminho reavaliar.
Além disso, permite-lhe adicionar condições para garantir que os cabeçalhos ou URLs especificados são reescritos apenas quando forem cumpridas determinadas condições. Estas condições baseiam-se nas informações do pedido e da resposta.
Para obter mais informações, consulte Reescrever cabeçalhos HTTP e URL.
Dimensionamento
O Application Gateway Standard_v2 pode ser configurado para dimensionamento automático ou implantações de tamanho fixo. O SKU v2 não oferece tamanhos de instância diferentes. Para obter mais informações sobre desempenho e preços da v2, consulte Autoscaling V2 e Noções básicas sobre preços.
O Application Gateway Standard (v1) é oferecido em três tamanhos: Pequeno, Médio e Grande. Os tamanhos de instâncias pequenas destinam-se a cenários de testes e desenvolvimento.
Para obter uma lista completa dos limites do gateway de aplicação, veja limites do serviço Gateway de Aplicação.
A tabela a seguir mostra uma taxa de transferência de desempenho média para cada instância v1 do gateway de aplicativo com descarregamento SSL habilitado:
| Tamanho médio da resposta da página de back-end | Pequena | Médio | Grande |
|---|---|---|---|
| 6 KB | 7.5 Mbps | 13 Mbps | 50 Mbps |
| 100 KB | 35 Mbps | 100 Mbps | 200 Mbps |
Nota
Estes valores são valores aproximados para um débito de gateway de aplicação. A taxa de transferência real depende de vários detalhes do ambiente, como o tamanho médio da página, a localização das instâncias de back-end e o tempo de processamento para servir uma página. Para números de desempenho exatos, deve executar o seus próprios testes. Estes valores são fornecidos apenas para a capacidade orientação de planeamento.
Comparação de recursos de versão
Para obter uma comparação de recursos do Application Gateway v1-v2, consulte O que é o Azure Application Gateway v2.