Como colocar um Application Load Balancer na frente das suas instâncias EC2

Quem desenha a VPC da empresa chega num ponto em que uma instância sozinha não basta: é preciso distribuir tráfego entre réplicas em zonas de disponibilidade diferentes, sem derrubar nada quando uma delas cai. É exatamente o problema que o Application Load Balancer (ALB) resolve, e é o roteiro que eu seguiria num projeto típico, baseado na documentação oficial do Elastic Load Balancing.

A ideia aqui não é só clicar em "criar" no console. É entender o que cada peça faz: o load balancer recebe a requisição, o listener decide para onde ela vai, e o target group é quem sabe quais instâncias estão de pé para receber tráfego.

Pré-requisitos antes de abrir o console

Antes de criar qualquer coisa, alinhe a rede. O Elastic Load Balancing exige que a VPC do load balancer tenha subnets em pelo menos duas Availability Zones, e você precisa de ao menos um target saudável registrado em cada AZ habilitada para o balanceador funcionar.

• Subnets: selecione subnets em pelo menos duas AZs (ou uma subnet de Local Zone, ou uma subnet de Outpost, dependendo do caso).
• Security group das instâncias: precisa liberar tráfego na porta do listener vindo dos nós do load balancer (se os targets forem especificados por IP) ou dos IPs dos clientes (se forem por ID de instância).
• Security group das instâncias para health check: precisa liberar tráfego do load balancer na porta e no protocolo usados pelo health check, que pode ser diferente da porta de aplicação.
• Instâncias já no ar: suba ao menos uma instância EC2 em cada AZ que você vai habilitar, com a aplicação respondendo na porta que o target group vai checar.

Aqui mora o primeiro trade-off de Confiabilidade: se você colocar todas as instâncias numa única AZ, o ALB até cria normalmente, mas você perde a garantia de que uma falha de zona não derruba o serviço inteiro.

Criando o target group e registrando os alvos

Eu prefiro criar o target group antes do balanceador, porque o listener já nasce apontando para algo existente. Com o AWS CLI configurado para a região sa-east-1, o primeiro passo é criar o grupo:

aws elbv2 create-target-group \
 --name meu-target-group \
 --protocol HTTP \
 --port 80 \
 --vpc-id vpc-0123456789abcdef0 \
 --health-check-protocol HTTP \
 --health-check-path /

O comando devolve um TargetGroupArn, que você vai usar em seguida para registrar as instâncias:

aws elbv2 register-targets \
 --target-group-arn arn:aws:elasticloadbalancing:sa-east-1:123456789012:targetgroup/meu-target-group/abc123 \
 --targets Id=i-0a1b2c3d4e5f6g7h8 Id=i-0h8g7f6e5d4c3b2a1

Se as instâncias estiverem em AZs diferentes, o health check do target group vai refletir isso no próximo passo, o de verificação.

Criando o Application Load Balancer

Com o target group pronto, crio o balanceador propriamente dito. Pelo console, o caminho é EC2 → Load Balancers → Create load balancer → Application Load Balancer, onde você escolhe nome (até 32 caracteres, sem começar ou terminar com hífen), o scheme (Internet-facing ou Internal) e o tipo de endereço IP (IPv4, Dualstack ou Dualstack without public IPv4).

Pelo CLI, o mesmo resultado sai num único comando:

aws elbv2 create-load-balancer \
 --name meu-load-balancer \
 --type application \
 --subnets subnet-1234567890abcdef0 subnet-0abcdef1234567890 \
 --security-groups sg-1111222233334444

Para um balanceador interno, que só roteia tráfego dentro da VPC usando IPs privados, basta acrescentar --scheme internal. Para suportar tráfego IPv6 além de IPv4, adiciono --ip-address-type dualstack, mas aí as subnets escolhidas precisam ter blocos CIDR IPv4 e IPv6, não só um deles.

Se a equipe já trabalha com infraestrutura como código, o mesmo recurso em CloudFormation fica assim:

Resources:
 meuLoadBalancer:
 Type: 'AWS::ElasticLoadBalancingV2::LoadBalancer'
 Properties:
 Name: meu-alb
 Type: application
 Scheme: internal
 IpAddressType: dualstack
 Subnets:
 - !Ref subnetAZ1
 - !Ref subnetAZ2
 SecurityGroups:
 - !Ref meuSecurityGroup

Aqui entra o trade-off de Excelência Operacional: o console é mais rápido para um teste pontual, mas CloudFormation (ou Terraform/CDK) é o que garante que esse ALB nasce, muda e some do mesmo jeito em todo ambiente, sem depender de alguém lembrar quais flags usou.

Adicionando o listener

Sem listener, o load balancer não sabe o que fazer com a requisição que chega. Crio um listener HTTP na porta 80 apontando para o target group criado antes:

aws elbv2 create-listener \
 --load-balancer-arn arn:aws:elasticloadbalancing:sa-east-1:123456789012:loadbalancer/app/meu-load-balancer/abc123 \
 --protocol HTTP \
 --port 80 \
 --default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:sa-east-1:123456789012:targetgroup/meu-target-group/abc123

Se o projeto exige HTTPS, é aqui que entra o segundo listener, com certificado emitido pelo AWS Certificate Manager e uma security policy compatível com o TLS mínimo que a aplicação aceita. Decidir entre HTTP simples e HTTPS obrigatório é um trade-off direto de Segurança: menos fricção para subir um protótipo contra tráfego criptografado de ponta a ponta até o load balancer.

Verificando se o load balancer está funcionando

O load balancer só está pronto para atender clientes quando existe pelo menos um target saudável em cada AZ habilitada. Eu confiro isso com:

aws elbv2 describe-target-health \
 --target-group-arn arn:aws:elasticloadbalancing:sa-east-1:123456789012:targetgroup/meu-target-group/abc123

Se o status aparecer como initial, geralmente é porque a instância ainda está no processo de registro, ou ainda não passou pelo número mínimo de health checks consecutivos para virar healthy. Dou uma esperada e rodo o comando de novo antes de desconfiar de configuração.

Com pelo menos um target healthy, pego o DNS name do balanceador (algo como meu-load-balancer-1234567890abcdef.elb.sa-east-1.amazonaws.com) e colo direto no navegador. Se tudo estiver certo, a página default da aplicação aparece. Para um balanceador interno, o mesmo teste só funciona de uma máquina com conectividade privada à VPC, como uma instância bastion ou uma VPN já configurada.

O que costuma quebrar

Na prática, os dois erros mais comuns não são no load balancer em si, são na rede ao redor dele:

• Security group da instância sem a porta do health check liberada para o próprio load balancer: o target fica preso em unhealthy mesmo com a aplicação rodando normal, porque o ALB não consegue nem checar.
• Subnets de uma única AZ: o console cria o balanceador sem reclamar, mas ele nunca vai oferecer a resiliência que o Well-Architected espera do pilar de Confiabilidade, porque uma única zona indisponível tira o serviço do ar inteiro.

Quando a página não carrega mesmo com target healthy, o problema costuma estar em DNS (propagação do CNAME apontando para o DNS name do ALB) ou em regras de listener mal configuradas, não no balanceador propriamente dito.

Próximos passos

Depois que o balanceador básico está no ar, os ajustes que valem a pena vir em seguida são regras de listener mais finas (roteamento por path ou por host), atributos do load balancer (como idle_timeout e logs de acesso), atributos do target group (deregistration delay, health check interval) e, se o listener for HTTPS, a lista de certificados adicionais para múltiplos domínios no mesmo listener via SNI. Cada um desses ajustes é outro trade-off: mais granularidade de roteamento custa mais regras para manter sincronizadas entre ambientes.

Fonte: Documentação do Elastic Load Balancing — ALB