Neste post, que acompanha o vídeo do canal, vamos configurar um AWS Application Load Balancer (ALB) com dois target groups. O primeiro distribui o tráfego de uma aplicação web entre duas instâncias EC2. O segundo recebe só as requisições de uma API, usando uma regra baseada no caminho da URL (path).
Aqui você encontra o cenário, os conceitos e o checklist de configuração para consultar depois de assistir.
O que é o Application Load Balancer
O Application Load Balancer é o balanceador de carga da AWS que trabalha na camada 7 (HTTP e HTTPS). Isso significa que ele entende a requisição e consegue decidir o destino por path, host, cabeçalho, método ou query string. É diferente do Network Load Balancer, que trabalha na camada 4 (TCP/UDP) e olha só para IP e porta.
Na prática, o ALB resolve três problemas de uma vez:
- Alta disponibilidade: se uma instância ou uma zona de disponibilidade cair, o tráfego segue para as instâncias saudáveis.
- Roteamento inteligente: uma mesma URL pública atende a aplicação web e a API, cada uma no seu grupo de servidores.
- Menos exposição: as instâncias ficam sem IP público, e só o ALB recebe tráfego da internet.
O cenário do laboratório
O fluxo que montamos no vídeo é este:
- O usuário acessa a URL do ALB.
- O ALB tem um Security Group próprio, que libera HTTP na porta 80.
- Requisições para
/vão para o target group da aplicação web, com duas instâncias EC2 (server 1 e server 2). - Requisições para o path da API vão para o target group da API, com uma terceira instância EC2.
As duas instâncias web estão em subnets diferentes da mesma VPC, cada uma em uma zona de disponibilidade. Se uma zona tiver problema, a outra instância continua respondendo e a aplicação segue no ar.
Nenhuma das instâncias tem IP público. O Security Group delas só aceita tráfego vindo do Security Group do ALB.
Recursos AWS utilizados
| Recurso | Papel no laboratório |
|---|---|
| Amazon VPC e subnets | Rede com subnets em duas zonas de disponibilidade |
| Amazon EC2 | Duas instâncias da aplicação web e uma da API |
| Security Groups | Um para o ALB (HTTP da internet) e outro para as instâncias (HTTP só do ALB) |
| Target groups | web com as duas instâncias web e api com a instância da API |
| Application Load Balancer | Recebe as requisições e aplica as regras do listener |
Passo a passo resumido
1. Security Groups
- SG do ALB: entrada HTTP (80) de qualquer origem. Em produção, use HTTPS (443) com certificado do AWS Certificate Manager.
- SG das instâncias: entrada HTTP (80) apenas com origem no SG do ALB. Referenciar o Security Group em vez de um bloco de IP é o que garante que ninguém acesse as instâncias diretamente.
2. Target group da aplicação web
- Tipo de destino: instâncias. Protocolo HTTP, porta 80, versão HTTP1.
- Health check no path
/. É por ele que o ALB decide se a instância está saudável para receber tráfego. - Registre as duas instâncias web. Até existir um load balancer usando o grupo, o status aparece como unused, e isso é normal.
3. O Application Load Balancer
- Esquema internet-facing, na mesma VPC, com pelo menos duas subnets em zonas diferentes.
- Associe o SG do ALB.
- Listener HTTP:80 com ação padrão de forward para o target group web.
Com isso, ao acessar a URL do ALB e atualizar a página, você vê as respostas alternando entre server 1 e server 2.
4. Target group da API
Repita o processo do target group web, registrando a instância da API. Também libere, no Security Group dessa instância, o HTTP vindo do SG do ALB. É um passo fácil de esquecer, e sem ele o health check falha.
5. Regra por path no listener
Em Listeners and rules, adicione uma regra ao listener HTTP:80:
- Condição: path igual ao caminho da API.
- Ação: forward para o target group
api. - Prioridade: 1. Regras de menor número são avaliadas primeiro, e a regra padrão fica sempre por último.
Além de forward, o ALB oferece outras duas ações que valem conhecer: redirect (por exemplo, de HTTP para HTTPS) e fixed response, que devolve uma resposta fixa sem chegar a nenhum servidor.
Boas práticas para levar para produção
- HTTPS no listener, com certificado gratuito do ACM e redirect de HTTP para HTTPS.
- AWS WAF na frente do ALB para filtrar SQL injection, XSS e acesso por país. Mostro isso no próximo post: Como configurar o AWS WAF.
- Instâncias em subnets privadas, com saída pela NAT Gateway quando precisarem de internet. Explico a montagem da rede neste post: Aprenda a criar VPC, Peering e Transit Gateway na AWS.
- Auto Scaling group como destino do target group, para escalar sem registrar instâncias manualmente.
- Logs de acesso do ALB no S3 para investigação de incidentes.
- Custo: o ALB cobra por hora e por LCU, mesmo sem tráfego. Ao final do laboratório, apague o load balancer, os target groups e as instâncias.
Material de apoio
- Vídeo completo no canal: Como configurar AWS Application Load Balancer com 2 target groups
- Documentação oficial: Guia do usuário do ELB (AWS)
Ficou alguma dúvida sobre a configuração? Deixe nos comentários.
Atualmente atua como Architecture Manager pela Atos Brasil, entusiasta Microsoft, FreeBSD e Debian, com mais de 20 anos de experiência em infraestrutura de T.I com ambientes heterogêneos, possuí o título de Microsoft Certified Trainer, AWS Community Builder, FinOps Member Foundation, Membro do comitê público do IDCIBER e especialista em segurança de perímetro, tendo atuado com soluções como Isa Server, iptables, IPFW, Cisco ASA, SonicWall, Fortigate, pfSense e soluções de Web Application Firewall.
