# 504 no CloudFront com VPC Origin: o diagnóstico errado da IA

> A IA culpou o certificado pelo 504 ao trocar o VPC Origin pelo ALB. A causa era a subnet privada sem entrada da internet. Veja como cheguei nela.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: IA, Rede
- URL: https://pages.formacaoaws.com.br/blog/504-no-cloudfront-vpc-origin-diagnostico-errado-da-ia/
- Aula de origem: "A IA Investigou Meu Problema na AWS… Mas Estava Errada (VPC Origin)" (https://www.youtube.com/watch?v=chanxNhU_as)

Ao tirar o VPC Origin do CloudFront e apontar a origin direto para o load balancer, a aplicação de um cliente passou a devolver 504 Gateway Timeout. Pedi a um agente de IA para investigar: ele culpou o certificado, e a causa era outra, na rede. Abaixo está o diagnóstico dele, o que eu conferi para descartá-lo e a correção que resolveu.

A aula foi gravada em 22 de dezembro de 2025 e o cenário é de um cliente da minha consultoria.

## O cenário: CloudFront, VPC Origin e load balancer em subnet privada

No início de 2025 eu tinha implantado o VPC Origin para um serviço desse cliente. Ele é o mecanismo que faz o CloudFront acessar o Application Load Balancer de forma privada: ao criar o VPC Origin, nasce uma interface de rede dentro da subnet onde está o load balancer, e a comunicação acontece ali dentro. Por isso o load balancer pode ficar numa subnet privada. Para ver a criação do VPC Origin do zero, veja [Load balancer sem IPv4 público](https://pages.formacaoaws.com.br/blog/load-balancer-sem-ipv4-publico/).

O desenho do cliente:

- o usuário faz a requisição ao CloudFront, que tem a origin do VPC Origin e outras, como uma que aponta para o S3;
- o VPC Origin leva até o load balancer, na subnet privada;
- o load balancer fala com uma EC2 da aplicação, que roda no Elastic Beanstalk;
- uma route table com NAT Gateway dá saída para a internet, para a EC2 se registrar no Beanstalk;
- a EC2 fala com o RDS, numa subnet privada de banco.

![Antes: o CloudFront chega ao VPC Origin, que entrega na interface de rede (ENI) do load balancer (ALB) dentro da subnet privada, onde está a EC2; a EC2 se liga à route table](https://pages.formacaoaws.com.br/blog/assets/posts/504-no-cloudfront-vpc-origin-diagnostico-errado-da-ia/antes.svg)

## O problema: o 504 ao trocar a origin pelo load balancer

O cliente precisou desativar o VPC Origin. O VPC Origin tem limitações, e uma delas, até o momento da aula, é não trabalhar com WebSocket. A aplicação do cliente ia mudar e passar a usar essa tecnologia.

Eu precisava então fazer o tráfego ir direto do CloudFront para o load balancer. Cada vez que eu trocava a origin pela do load balancer, vinha o erro: 504, Gateway Timeout.

> **Importante:** a limitação de WebSocket é a que valia na data da aula. Antes de decidir por VPC Origin, confira o que ele suporta hoje na [documentação oficial](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html).

## O que a IA diagnosticou

Tenho um agente de IA focado em DevOps nesse cliente. Dei o contexto, disse onde estava a distribuição, qual endpoint eu queria acessar e qual estava com problema, e pedi uma investigação de ponta a ponta do 504.

O diagnóstico veio com o certificado SSL como emitido e em uso, e com um "problema identificado": mismatch de domínios. Na leitura dele, o load balancer tinha certificado para o domínio do cliente, mas o CloudFront tentava acessar pelo endereço do Beanstalk. A origin estava configurada com esse endpoint, e isso não é problema: o endpoint do Beanstalk é direcionado ao load balancer.

![O diagnóstico da IA: em "problema identificado", o mismatch de domínios entre a origin do CloudFront e o certificado; os domínios do cliente estão cobertos](https://pages.formacaoaws.com.br/blog/assets/posts/504-no-cloudfront-vpc-origin-diagnostico-errado-da-ia/diagnostico.webp)

Ele propôs três caminhos:

1. usar HTTP na origin problemática, com `OriginProtocolPolicy` em `http-only` e a porta 80;
2. adicionar um certificado para o domínio do Beanstalk;
3. usar um CNAME correto, apontando para o ambiente do Beanstalk.

![As três soluções propostas pela IA: HTTP na origin, certificado para o domínio do Beanstalk e um CNAME](https://pages.formacaoaws.com.br/blog/assets/posts/504-no-cloudfront-vpc-origin-diagnostico-errado-da-ia/opcoes.webp)

Se eu tivesse mandado "resolva para mim", ela começaria a trocar essas coisas: tirar certificado de um canto, mexer em outro, e depois reverter ficaria mais complicado.

## Passo 1: peça o diagnóstico antes de deixar a IA mexer

Foi o que me salvou. Hoje, sempre que uso IA para qualquer coisa, peço que ela investigue, me dê um diagnóstico e diga o que pretende fazer. Pergunto: o que você pensa em fazer sobre essa problemática? Só depois decido o que executar.

Os três caminhos chegaram como proposta, e eu pude lê-los antes de qualquer mudança.

## Passo 2: descarte o que a IA apontou

Eu sabia que o problema não era o certificado. Verifiquei:

- o certificado do Certificate Manager estava associado ao CloudFront e ao load balancer;
- o security group do load balancer aceitava o tráfego do CloudFront, com um prefix list configurado;
- o load balancer tinha IPv4 público: eu não o tinha trocado para interno, e o mantive internet-facing para o cliente poder reverter, se quisesse.

Com isso, as três soluções da IA saíam da mesa. Trocar para HTTP porque a porta HTTPS "não está acessível" e começar a injetar recursos era só bagunçar a infraestrutura.

> **Importante:** o load balancer só ficou público porque o security group só aceitava o CloudFront, pelo prefix list. Se você deixar um load balancer público, mantenha essa regra de entrada restrita: veja [como restringir o acesso a Application Load Balancers](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html) na documentação do CloudFront.

## Passo 3: siga o caminho na rede

Sem certificado e sem security group como culpados, olhei para o desenho. O load balancer estava numa subnet privada, então olhei para a route table dela.

A saída para a internet existia, por um NAT Gateway. A entrada não: nessa route table não havia internet gateway. Um fluxo de saída, sem fluxo de entrada.

## Passo 4: mover o load balancer para a subnet pública

A correção foi simples depois de enxergar o problema: trocar o load balancer da subnet privada para a pública e tirar o apontamento do VPC Origin. Com o load balancer público, o apontamento do VPC Origin deixa de existir e a aplicação passou a funcionar.

![Depois: o CloudFront chega direto ao load balancer (ALB), que passou para a subnet pública; a EC2 segue na subnet privada](https://pages.formacaoaws.com.br/blog/assets/posts/504-no-cloudfront-vpc-origin-diagnostico-errado-da-ia/depois.svg)

O caminho depois da troca:

**Fluxo:** Usuário (pede a página) → Amazon CloudFront (origin direta no load balancer) → Load balancer (agora na subnet pública) → Amazon EC2 (aplicação no Beanstalk)

## Quem responde pela revisão

Eu quis ter clareza sobre a AWS para saber onde estava o problema e usar a IA só para ganhar velocidade em algo que domino. No re:Invent 2025, o CTO da Amazon disse que o papel de quem constrói não é mais criar código, a parte executiva, e sim revisar. No meu caso, pedi à IA que me dissesse o que faria. Quando vi que não era compatível com a solução, fui lá e fiz eu mesmo.

Quando a IA faz o trabalho por você, você continua dono da atividade e responsável pela revisão. Dizer "foi a IA que errou" não transfere a responsabilidade. Por isso eu repito: dominar a AWS vem antes de dominar a IA. Ela é mais uma ferramenta no seu arsenal, e potencializa o trabalho de quem já sabe o que está operando.

## Checklist

- Ao pedir ajuda à IA, peça primeiro o diagnóstico e o que ela pretende fazer, sem executar.
- Leia cada caminho proposto e confira se ele tem relação com o sintoma antes de aceitar.
- Confira o certificado no CloudFront e no load balancer.
- Confira se o security group do load balancer aceita o CloudFront, pelo prefix list.
- Em subnet privada, olhe a route table: saída por NAT Gateway não cria entrada da internet.
- Se o load balancer precisa receber do CloudFront sem VPC Origin, ele fica na subnet pública, com a entrada restrita ao CloudFront.
- Se for usar VPC Origin, confira as limitações atuais na documentação oficial, como o suporte a WebSocket.

Se você quer praticar esse tipo de diagnóstico em desafios de CDN, load balancer e pipeline, é o que a Formação AWS faz toda semana, com casos de mercado.