Load balancer sem IPv4 público: VPC Origin no CloudFront

Um Application Load Balancer público tem um IPv4 público em cada zona de disponibilidade, e a AWS cobra por cada um. Com o VPC origin do CloudFront, o load balancer fica só com IP privado: abaixo está o que trocar na rede e no security group, com a conta de um cliente meu que tem 27 load balancers.

A aula é só o desenho no quadro, sem console da AWS. O que não sai do que eu falei no vídeo está marcado como "o que a aula não mostra".

O problema: um IPv4 público por zona, em cada load balancer

Desde que a AWS passou a cobrar o IPv4 público, eu fui eliminando o máximo que dava, no meu billing e no dos meus clientes. O que era complicado de tirar era o do load balancer. Para os outros, veja o texto sobre IP público cobrado na AWS.

O load balancer tem uma interface de rede (ENI) em cada zona em que está: três zonas, três ENIs. Quando ele é público, cada ENI tem um IPv4 público e um privado.

A conta do cliente:

• 27 load balancers × 3 zonas (se eu não me engano, como falei na aula) = 81 interfaces de rede, ou seja, 81 IPv4 públicos.
• 81 × 4 (o valor que usei, cerca de 4 dólares por IPv4 por mês) = 324 dólares por mês.
• 324 × 12 = 3.888 dólares por ano, que arredondei para 4 mil ("$4K / ANO" no desenho).

Por que o load balancer precisava ser público

O caminho típico: o usuário chega pelo Route 53 ao CloudFront. No CloudFront, o behavior manda o tráfego para uma origin, a origin aponta para o load balancer e o load balancer para a frota de instâncias (ECS, EKS, Beanstalk ou EC2 direto).

O CloudFront fica na rede da AWS, fora da sua VPC. Para ele enxergar o load balancer, o load balancer precisava estar acessível de fora: interface pública e, com IPv4, IPv4 público. Daí os 81 endereços.

1Ter CloudFront na frente da aplicação

O recurso que resolve isso está atrelado ao CloudFront. Se a sua aplicação não tem CDN na frente, comece por aí.

Eu recomendaria o CloudFront de qualquer jeito: ele reduz o custo de transferência de saída, dá cache e traz uma série de outros benefícios.

2Criar o VPC origin apontando para o load balancer

Em 20 de novembro de 2024, entre as novidades do re:Invent, a AWS lançou um tipo de origin que aponta direto para dentro da sua VPC. Na área do CloudFront você cria um VPC origin para um recurso específico, como o seu load balancer.

Na prática, é como se a AWS puxasse um cabo de rede até a sua VPC e criasse ali uma interface de rede dela, com IPv4 privado. O que você precisa garantir é a comunicação entre a interface do load balancer e essa interface criada pelo CloudFront.

Com isso, o load balancer não precisa mais de IPv4 público. As interfaces dele ficam só com IPv4 privado, e ele pode ir para subnet privada.

O que a aula não mostra: a tela de criar o VPC origin, a troca da origin no behavior e a mudança do load balancer para subnet privada. Na aula eu só digo que dá para criar uma origin para o load balancer e mostro o desenho. O passo a passo no console, os requisitos e as regiões com suporte estão na documentação oficial: Restrict access with VPC origins.

3Garantir um internet gateway na VPC

É o único requisito que eu citei: a VPC precisa ter um internet gateway. Ele não precisa estar atrelado à sua subnet; basta existir na VPC, porque quem usa é o VPC origin.

4Trocar a regra de entrada do load balancer

Quem já usa CloudFront deve ter, no security group do load balancer, uma liberação para o prefix list do CDN. Eu espero que esteja assim. Se não estiver, é provável que a porta 443 esteja aberta para todo mundo (0.0.0.0/0).

Com o VPC origin, o CloudFront também cria um security group na sua VPC, associado à interface de rede dele. Na regra de entrada do load balancer, troque o prefix list pela porta 443 vinda desse security group.

Dá também para fazer todo o tráfego do CloudFront ao load balancer em HTTPS, desde que você configure o listener e tenha o certificado nele.

Além do custo, você ganha segurança: a regra de entrada do load balancer passa a apontar para o security group da interface do CloudFront.

O caminho depois da troca:

Checklist

• Conte os load balancers públicos da conta e as zonas de cada um: cada interface pública é um IPv4 cobrado.
• Confirme que a aplicação tem CloudFront na frente, com a origin apontando para o load balancer.
• Crie o VPC origin no CloudFront apontando para o load balancer.
• Garanta que a VPC tem um internet gateway (não precisa estar atrelado à subnet).
• No security group do load balancer, troque o prefix list do CDN (ou a 443 aberta) pela porta 443 vinda do security group criado pelo CloudFront.
• Se puder, faça o tráfego do CloudFront ao load balancer em HTTPS, com o certificado no listener.
• Confira o preço atual do IPv4 público na página de preços da Amazon VPC.

No cliente dos 27 load balancers, são cerca de 4 mil dólares por ano, mais o ganho de segurança. Aplique no seu ambiente e veja quanto some do billing.