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.

O Application Gateway inclui os seguintes recursos:

Terminação de Secure Sockets Layer (SSL/TLS)

O gateway de aplicação suporta a terminação SSL/TLS no gateway, após o qual o tráfego normalmente flui sem criptografia para os servidores backend. 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 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. Dentre esses exploits, são frequentes os ataques de injeção de SQL e os ataques de cross-site scripting, entre outros. 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 Aplicações 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 os SKUs Standard_v2 e WAF_v2 do Application Gateway.

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. Se nenhum dos padrões de caminho coincidir, é selecionado o DefaultServerPool.

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 website 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. Você criaria três escutadores multi-site e configuraria cada um para a respetiva 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 coringa num ouvinte multi-site e até cinco nomes de anfitrião por ouvinte. Para saber mais, consulte Nomes de host coringa no escutador.

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 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 de WebSocket e Suporte de HTTP/2.

Drenagem de ligação

O esvaziamento de conexão ajuda a remover de forma suave os membros do pool do back-end durante atualizações de serviço planeadas ou problemas com o estado de saúde do back-end. Essa configuração é habilitada por meio da Configuração de back-end e é aplicada a todos os membros do pool de servidores 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. Ele se aplica a casos em que as instâncias de back-end são explicitamente removidas do pool de back-end após uma alteração de configuração por um usuário.

A drenagem de conexões também é respeitada para conexões WebSocket. O esvaziamento da conexão é invocado para cada atualização do gateway. Para evitar a perda de conexão dos membros existentes do pool de back-end, certifique-se de ativar a drenagem de conexão.

Para obter mais detalhes, 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 usar a sua própria marca e layout 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ção de porta dos 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 encaminhamento baseado em caminho de URL, pode-se optar por encaminhar pedidos para um dos grupos de servidores de back-end com base no caminho original ou no caminho reescrito, usando a opção de reavaliar o mapa de caminhos.

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, consulte Limites do Serviço Gateway de Aplicação.

A tabela abaixo mostra uma taxa média de transferência para cada instância v1 do gateway de aplicações com SSL offload ativado.

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.

Próximos passos

• Saiba como funciona um gateway de aplicativo
• Revisão Perguntas frequentes sobre o Azure Application Gateway