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

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.

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.

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.

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.

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.

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.

1Peç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.

2Descarte 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.

3Siga 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.

4Mover 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.

O caminho depois da troca:

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.