Recursos do Gateway de Aplicativo do Azure
O Gateway de Aplicativo do Azure é um balanceador de carga do tráfego da Web que permite que você gerencie o tráfego para seus aplicativos Web.
Observação
Para cargas de trabalho da Web, é altamente recomendável utilizar a proteção contra DDoS do Azure e um firewall de aplicativo Web para proteger contra ataques de 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 de DDoS no nível da rede. Para obter mais informações, confira linha de base de segurança dos serviços do Azure.
O Gateway de Aplicativo inclui os seguintes recursos:
Terminação do protocolo SSL/TLS (Secure Sockets Layer)
O gateway de aplicativo dá suporte a terminação SSL/TLS no gateway, pelo qual o tráfego flui geralmente descriptografado até os servidores de back-end. Esse recurso permite que os servidores Web fiquem livres da sobrecarga da criptografia e descriptografia dispendiosa. Mas, às vezes, a comunicação não criptografada com os servidores não é uma opção aceitável. Isso pode ocorrer devido a requisitos de segurança, de conformidade ou o aplicativo pode aceitar apenas uma conexão segura. Para tais aplicativos, o Gateway de Aplicativo dá suporte à criptografia SSL/TLS de ponta a ponta.
Para saber mais, confira Visão geral da terminação de SSL e SSL de ponta a ponta com um Gateway de Aplicativo
Dimensionamento automático
Dimensionamento automático do Gateway de Aplicativo Standard_v2 que pode ser expandido ou reduzido com base na mudança dos padrões de carga de tráfego. O escalonamento automático também remove o requisito de escolher um tamanho de implantação ou contagem de instâncias durante o provisionamento.
Para saber mais sobre os recursos Standard_v2 do Gateway de Aplicativo, confira O que é o Gateway de Aplicativo do Azure v2.
Redundância de zona
Um Gateway de Aplicativo Standard_v2 pode abranger várias Zonas de Disponibilidade, que oferecem uma melhor resiliência a falhas e eliminam a necessidade de provisionar Gateways de Aplicativo separados em cada zona.
VIP estático
O gateway de aplicativo Standard_v2 é compatível exclusivamente com 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 do Aplicativo Web
O WAF (Firewall do Aplicativo Web) é um serviço que fornece proteção centralizada para seus aplicativos Web contra vulnerabilidades e explorações comuns. O WAF é baseado em regras dos conjuntos de regras de núcleo do OWASP (Open Web Application Security Project) 3.1 (somente WAF_v2), 3.0 e 2.2.9.
Os aplicativos Web cada vez mais são alvos de ataques mal-intencionados que exploram vulnerabilidades conhecidas comuns. Os ataques de injeção de SQL, os ataques de scripts entre sites, entre outros, são comuns entre essas explorações. Pode ser difícil impedir esses ataques no código do aplicativo e isso pode exigir manutenção, aplicação de patches e monitoramento rigorosos em muitas camadas da topologia do aplicativo. Um firewall de aplicativo Web centralizado ajuda a simplificar bastante o gerenciamento de segurança e oferece mais garantia ao administrador do aplicativo contra ameaças ou invasões. Uma solução WAF também pode reagir a uma ameaça de segurança mais rapidamente ao aplicar um patch contra uma vulnerabilidade conhecida em um local central do que a proteção de cada um dos aplicativos Web individuais. Os gateways de aplicativos existentes podem ser facilmente convertidos em um gateway de aplicativo com firewall de aplicativo Web.
Veja Proteção contra DDoS do aplicativo para obter diretrizes sobre como usar o WAF do Azure com o Gateway de Aplicativo para proteção contra DDoS. Para obter mais informações, confira O que é o Firewall de Aplicativo Web do Azure.
Controlador de entrada para AKS
O Controlador de entrada do Gateway de Aplicativo (AGIC) permite usar o gateway de aplicativo como entrada para um cluster do Serviço do Kubernetes do Azure (AKS).
O controlador de entrada é executado como um pod no cluster do AKS e consome Recursos de Entrada do Kubernetes e os converte em uma configuração do Gateway de Aplicativo que permite ao gateway balancear o tráfego para os pods do Kubernetes. O controlador de entrada só é compatível com o Gateway de Aplicativo Standard_v2 e os SKUs WAF_v2.
Para saber mais, consulte Controlador de entrada do Gateway de Aplicativo (AGIC).
Roteamento baseado em URL
O roteamento baseado em caminho de URL permite rotear o tráfego para pools de servidores back-end de acordo com os caminhos de URL da solicitação. Um dos cenários possíveis é encaminhar as solicitações de diferentes tipos de conteúdo para diferentes pools.
Por exemplo, as solicitações de http://contoso.com/video/* são encaminhadas para VideoServerPool, e as de http://contoso.com/images/* são encaminhadas para ImageServerPool. O DefaultServerPool será selecionado se nenhum dos padrões de caminho forem compatíveis.
Para obter mais informações, consulte visão geral de Roteamento Baseado em Caminho de URL.
Hospedagem de vários sites
Com o Gateway de Aplicativo, você pode configurar o roteamento com base no nome do host ou no nome de domínio para mais de um aplicativo Web no mesmo gateway de aplicativo. Permite que você configure a topologia mais eficiente para suas implantações adicionando até mais de 100 sites a um gateway de aplicativo. Cada site pode ser direcionado para seu próprio pool 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 aplicativo. Você criaria três ouvintes com vários sites e configuraria cada ouvinte para as respectivas configurações de porta e protocolo.
As solicitações de http://contoso.com são encaminhadas para ContosoServerPool, e as de http://fabrikam.com são encaminhadas para FabrikamServerPool.
Da mesma forma, dois subdomínios do mesmo domínio pai podem ser hospedados na mesma implantação de gateway de aplicativo. Exemplos de uso de subdomínios podem incluir http://blog.contoso.com e http://app.contoso.com hospedados em uma implantação de gateway de aplicativo único. Para obter mais informações, consulte hospedagem de vários sites com o Gateway de Aplicativo.
Você também pode definir nomes do host curinga em um ouvinte com vários sites e até cinco nomes do host por ouvinte. Para saber mais, confira nomes do host curinga em ouvinte.
Redirecionamento
Um cenário comum para muitos aplicativos Web é dar suporte ao redirecionamento automático de HTTP para HTTPS para garantir que toda a comunicação entre o aplicativo e seus usuários ocorra em um caminho criptografado.
No passado, talvez você tenha usado técnicas como a criação de um pool dedicado cujo único propósito é redirecionar as solicitações recebidas em HTTP para HTTPS. O gateway de aplicativo dá suporte à capacidade de redirecionar o tráfego no Gateway de Aplicativo. Isso simplifica a configuração do aplicativo, otimiza o uso de recursos e dá suporte a novos cenários de redirecionamento, incluindo redirecionamento global e baseado no caminho. O suporte ao redirecionamento do Gateway de Aplicativo não está limitado apenas ao redirecionamento de HTTP para HTTPS. Esse é um mecanismo de redirecionamento genérico; portanto, você pode redirecionar bidirecionalmente em qualquer porta definida usando regras. Ele também dá suporte a redirecionamento para um site externo.
O suporte a redirecionamento do Gateway de Aplicativo oferece os seguintes recursos:
- Redirecionamento global de uma porta para outra porta no Gateway. Isso habilita o redirecionamento de HTTP para HTTPS em um site.
- Redirecionamento baseado em caminho. Esse tipo de redirecionamento permite o redirecionamento de HTTP para HTTPS apenas em uma área específica do site, por exemplo, uma área de carrinho de compras indicada por
/cart/*. - Redirecionamento para um site externo.
Confira mais informações em Visão geral de redirecionamento do Gateway de Aplicativo.
Afinidade de sessão
O recurso de afinidade de sessão baseada em cookies é útil quando você deseja manter uma sessão de usuário no mesmo servidor. Usando cookies gerenciados pelo gateway, o Gateway de Aplicativo pode direcionar o tráfego seguinte de uma sessão de usuário para o mesmo servidor visando o processamento. Isso é importante em casos em que o estado de sessão é salvo localmente no servidor para uma sessão de usuário.
Para obter mais informações, consulte Como funciona o gateway de aplicativo.
Tráfego do WebSocket e HTTP/2
O Gateway de Aplicativo fornece suporte nativo para os protocolos WebSocket e HTTP/2. Não há nenhuma configuração configurável pelo usuário para habilitar ou desabilitar seletivamente o suporte ao WebSocket.
Os protocolos WebSocket e HTTP/2 permitem uma comunicação full duplex entre um servidor e um cliente em uma conexão TCP de execução longa. Isso permite uma comunicação mais interativa entre o servidor Web e o cliente, que pode ser bidirecional, sem a necessidade de sondagem, necessária nas implementações baseadas 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 mais eficiente de recursos. Esses protocolos foram projetados para funcionar em portas HTTP tradicionais de 80 e 443.
Para obter mais informações, consulte suporte ao WebSocket e suporte ao HTTP/2.
Descarregamento de conexão
O esvaziamento de conexões ajuda você a fazer a remoção normal de 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. Com a configuração habilitada, o gateway de aplicativo garante que todas as instâncias cujos registros foram cancelados de um pool de back-end não receberão nenhuma nova solicitação, permitindo que as solicitações existentes sejam concluídas dentro de um limite de tempo configurado. Isso se aplica aos 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
- relatadas como não íntegras pelas investigações de integridade ou
- removidas durante uma operação de redução horizontal
A única exceção é quando as solicitações continuam a ser intermediadas para as instâncias de cancelamento de registro, devido à afinidade de sessão gerenciada por gateway.
O esvaziamento de conexões também é respeitado para conexões WebSocket. O esvaziamento de conexões é invocado para cada atualização para o gateway. Para evitar a perda de conexão com os membros existentes do pool de back-end, habilite o esvaziamento de conexões.
Para obter informações sobre limites de tempo, confira Definição das configurações de back-end.
Páginas de erro personalizadas
O Gateway de Aplicativo permite que você crie páginas de erro personalizadas em vez de exibir páginas de erro padrão. Você pode usar sua própria identidade visual e layout em uma página de erro personalizada.
Para obter mais informações, confira Erros Personalizados.
Reescrever 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. A reescrita desses cabeçalhos HTTP ajuda você a realizar vários cenários importantes, como:
- Adição de 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 Gateway de Aplicativo e o SKU v2 do WAF dão suporte à capacidade de adicionar, remover ou atualizar solicitações HTTP e cabeçalhos de resposta, enquanto os pacotes de solicitação e resposta são transferidos entre os pools de cliente e de back-end. Você também pode reescrever URLs, parâmetros de cadeia de caracteres de consulta e o nome do host. Com a reescrita de URL e o roteamento baseado em caminho de URL, você pode optar por rotear as solicitações para um dos pools de back-end baseados no caminho original ou no caminho reescrito usando a opção de reavaliação de mapa de caminho.
Ele também fornece a capacidade de adicionar condições para garantir que os cabeçalhos ou URLs especificados sejam reescritos somente quando determinadas condições forem atendidas. Essas condições se baseiam nas informações de solicitação e resposta.
Para saber mais, confira Reescrever cabeçalhos HTTP e URL.
Dimensionamento
O SKU Standard_v2 do Gateway de Aplicativo pode ser configurado para dimensionamento automático ou para implantações de tamanho fixas. A SKU v2 não oferece tamanhos de instância diferentes. Para obter mais informações sobre o desempenho e os preços do v2, confira Dimensionamento automático do SKU V2 e Noções básicas de preços.
O Gateway de Aplicativo Standard (v1) é oferecido em três tamanhos: Pequeno, Médio e Grande. Os tamanhos de instância pequenos são destinados a cenários de desenvolvimento e teste.
Para obter uma lista completa de limites do gateway de aplicativo, consulte Limites de serviço do Gateway de Aplicativo.
A tabela a seguir mostra uma produtividade de desempenho médio para cada instância do Gateway de Aplicativo v1 com o descarregamento SSL habilitado:
| Tamanho médio da resposta da página de back-end | Small | Médio | grande |
|---|---|---|---|
| 6 KB | 7,5 Mbps | 13 Mbps | 50 Mbps |
| 100 KB | 35 Mbps | 100 Mbps | 200 Mbps |
Observação
Esses valores são valores aproximados para uma produtividade do Gateway de Aplicativo. A produtividade real depende de vários detalhes de ambiente, como o tamanho médio da página, a localização das instâncias de back-end e o tempo de processamento para fornecer uma página. Para obter números de desempenho exatos, você deve executar seus próprios testes. Esses valores são fornecidos apenas para a orientação do planejamento de capacidade.
Comparação de recursos de versão
Para uma comparação de recursos do Gateway de Aplicativo v1-v2, consulte O que é o Gateway de Aplicativo do Azure v2.