# Load balancer sem IPv4 público: VPC Origin no CloudFront > Como tirar o IPv4 público do Application Load Balancer com o VPC Origin do CloudFront: o que muda na rede, no security group e na conta. - Autor: Henrylle Maia, consultor AWS - Publicado em: 2026-10-15 - Assuntos: Rede, Custos - URL: https://pages.formacaoaws.com.br/blog/load-balancer-sem-ipv4-publico/ - Aula de origem: "Pare de usar IPV4 Público com seu Load Balancer na AWS" (https://www.youtube.com/watch?v=tS1MX24mTcs) 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](https://pages.formacaoaws.com.br/blog/ip-publico-ipv4-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). ![Load balancer público: cada uma das 3 zonas tem uma ENI com IPv4 público e privado; 27 load balancers dão 81 ENIs, 81 IPv4 públicos e 81 privados](https://pages.formacaoaws.com.br/blog/assets/posts/load-balancer-sem-ipv4-publico/alb-antes-ipv4-publico.svg) > **Importante:** o 4 é um valor aproximado, de dezembro de 2024, só para dar a ordem de grandeza. Na fala eu digo "multiplica por 4"; que é dólar por mês fecha com o total anual em dólar. Antes de fazer a sua conta, confira o preço atual na seção *Public IPv4 Address* da [página de preços da Amazon VPC](https://aws.amazon.com/vpc/pricing/) e conte os IPs da sua conta. ## 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. ## Passo 1: ter 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. ## Passo 2: criar 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. ![Com o VPC origin, o CloudFront cria uma ENI na VPC e as ENIs do load balancer ficam só com IPv4 privado, com os IPv4 públicos riscados; a VPC tem um internet gateway](https://pages.formacaoaws.com.br/blog/assets/posts/load-balancer-sem-ipv4-publico/vpc-origin-alb-privado.svg) > **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](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html). ## Passo 3: garantir 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. ## Passo 4: trocar 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. ![CloudFront, behavior e origin apontando para o ALB em subnet privada; nas regras de entrada, o prefix list do CDN riscado e a 443 liberada para o security group do CloudFront](https://pages.formacaoaws.com.br/blog/assets/posts/load-balancer-sem-ipv4-publico/desenho-final-sem-ipv4.svg) 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. > **Importante:** tirar o IPv4 público do load balancer não zera os IPv4 públicos da conta. Praticamente tudo passa a funcionar de forma privada, mas o NAT Gateway provavelmente você continua usando. O que sobra está no texto sobre [IP público cobrado na AWS](https://pages.formacaoaws.com.br/blog/ip-publico-ipv4-cobrado-na-aws/). O caminho depois da troca: **Fluxo:** Amazon CloudFront (behavior e origin) → VPC origin (interface de rede dentro da sua VPC) → Application Load Balancer (só IPv4 privado) → Instâncias (a frota da aplicação) ## 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.