# Troubleshooting no Elastic Beanstalk: ache o erro no log da EC2 > Deploy no Elastic Beanstalk que falha ou fica parado sem resposta: conecte na EC2 pelo SSM, leia o eb-engine.log e descubra a causa. - Autor: Henrylle Maia, consultor AWS - Publicado em: 2026-10-15 - Assuntos: Containers - URL: https://pages.formacaoaws.com.br/blog/elastic-beanstalk-troubleshooting/ - Aula de origem: "Troubleshooting na prática no Elastic Beanstalk" (https://www.youtube.com/watch?v=AbS2v4KSK3E) Deploy no Elastic Beanstalk que falha ou fica rodando sem terminar, e o console não diz o porquê? Entre na instância EC2 pelo SSM e leia o log do próprio Elastic Beanstalk. Mostro isso em dois casos que reproduzi: um zip montado errado e uma máquina pequena demais. A origem foi um desafio que passei na Formação AWS, em que muita gente travava num deploy de aplicação Docker. A aula é de dezembro de 2023, e telas e instâncias do console mudam. O que vale é o método. O local dos logs está na [documentação oficial](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.logging.html). ## Por que olhar o log da EC2 Dá para mandar os logs do Elastic Beanstalk para o CloudWatch. Só que, quando o deploy não termina, você não sabe se o log não chegou ao CloudWatch ou se a aplicação deu problema. No caso dos meus alunos, o build da imagem Docker acontecia na própria EC2 e não finalizava. Por isso o caminho é o arquivo onde o Elastic Beanstalk escreve na instância: `/var/log/eb-engine.log`. É a fonte do que aparece no console e do que vai para o CloudWatch. Ver esse arquivo acontecendo, no olho, tira a dúvida. **Fluxo:** Ambiente (single instance com Docker) → Sessão SSM (CloudShell dentro da EC2) → eb-engine.log (tail -f durante o deploy) → Causa (erro explícito ou parada no build) → Correção (zip na raiz ou instância maior) Se você ainda não fez um primeiro deploy, comece pelo post [Elastic Beanstalk com Docker](https://pages.formacaoaws.com.br/blog/elastic-beanstalk-com-docker). Aqui parto do ambiente criado e vou direto ao diagnóstico. ## Passo 1: criar o ambiente e conectar na instância Criei uma aplicação `BIA-YT` e um ambiente `BIA-YT-ENV` com a plataforma Docker, a aplicação de exemplo do Elastic Beanstalk e **Single Instance**. As escolhas que importam: - **Instance profile:** uma role com as permissões do Elastic Beanstalk e também uma policy para SSM, que é como entro na EC2 sem chave SSH. - **Rede:** IP público e as três zonas de disponibilidade. - **Security group:** basta um que libere a porta 80 para o mundo. - **Instância:** `t3.micro`, monitoramento no padrão (aprimorado). O ambiente leva uns 3 minutos para subir. Nesse tempo, abra o **CloudShell** da AWS: é um terminal que usa a sua sessão do console, sem credenciais na sua máquina (veja o post sobre o [CloudShell](https://pages.formacaoaws.com.br/blog/aws-cloudshell-terminal-seguro)). Clone o projeto da BIA, que tem um script de conexão por SSM: ```bash git clone https://github.com/henrylle/bia cd bia/scripts ./start-session-bash.sh ``` O script recebe o ID da instância e abre a sessão. O ID está na EC2 que o Elastic Beanstalk lançou para o ambiente. Dentro da sessão: ```bash sudo su cat /var/log/eb-engine.log ``` Com o ambiente saudável, o fim do arquivo mostra o `CommandService Response` com `"status":"SUCCESS"` e a linha `Platform Engine finished execution on command: app-deploy`. Esse é o deploy que terminou bem. ## Passo 2: acompanhar um novo deploy com tail Antes de fazer o deploy, deixe o log correndo na sessão: ```bash tail -f /var/log/eb-engine.log ``` Em outra aba, no Elastic Beanstalk, clique em **Upload and deploy**, escolha o zip e confirme. O zip vai para o S3, o Elastic Beanstalk o recebe na instância e o log começa a andar: extração do pacote, hooks e o build do Docker. ## Passo 3: erro explícito, o zip com pasta Montei dois zips, um com problema e um certo. No com problema, os arquivos do projeto estavam **dentro de uma pasta** no zip. É um erro comum: o Elastic Beanstalk procura o `Dockerfile` ou o `Dockerrun.aws.json` na **raiz** do zip. No log, a falha apareceu na hora: ``` [ERROR] An error occurred during execution of command [app-deploy] - [Docker Specific Build Application]. Stop running the command. Error: Dockerfile and Dockerrun.aws.json are both missing, abort deployment ``` O mesmo texto aparece na aba **Events** do ambiente: "Both 'Dockerfile' and 'Dockerrun.aws.json' are missing in your source bundle". Aqui o console já bastava, e a correção é refazer o zip com o conteúdo na raiz. ![A aba Events do Elastic Beanstalk com o erro do deploy: Dockerfile e Dockerrun.aws.json ausentes no pacote (o ID da instância foi coberto)](https://pages.formacaoaws.com.br/blog/assets/posts/elastic-beanstalk-troubleshooting/eventos-erro-deploy.webp) ## Passo 4: o deploy que não avança Com o zip certo, o log passou da etapa inicial. Ele encontrou o `Dockerfile`, viu a imagem `node:18-slim`, não precisou baixar nenhuma imagem e começou o `docker compose build`. E parou aí. A última linha do log é esta: ``` [INFO] Running command /bin/sh -c docker compose pull --ignore-buildable [INFO] server Skipped - No image to be pulled [INFO] successfully execute command: docker compose pull --ignore-buildable [INFO] Running command /bin/sh -c docker compose build ``` Era o que acontecia com os alunos: o deploy ficava rodando, sem saída, e o Elastic Beanstalk não dava mais feedback. Depois de um tempo, o ambiente ficou em estado **Degraded**. A aba Events só registra o deploy em andamento, sem instância enviando dados. ![A aba Events: deploy em andamento há 3 minutos, 0 de 1 instância concluída e nenhuma enviando dados](https://pages.formacaoaws.com.br/blog/assets/posts/elastic-beanstalk-troubleshooting/eventos-degradado.webp) Só o console deixa você perdido: nada diz que o build parou. O log da EC2 mostra a última linha executada, o `docker compose build`, que não anda. Nesse caso a causa era a máquina: o `t3.micro` não tinha poder computacional para concluir o build. Olhar a CPU e outras métricas da instância confirmaria o mesmo. Para entender que o comando parou ali, é preciso um pouco de Docker. ## Passo 5: ambiente com instância maior e comparação O ambiente travado não se resolve esperando. Criei outro, `BIA-YT-ENV-MAIOR`, igual ao primeiro (Docker, aplicação de exemplo, mesma instance profile, as três zonas, mesmo security group), só que com **`t3.medium`**, dois níveis acima. Conectei na nova instância com o mesmo script, abri o `tail -f` e, com o ambiente pronto, fiz o deploy do zip certo. Com os dois terminais lado a lado, a diferença ficou clara. O log do ambiente pequeno estava parado no `docker compose build`. O do ambiente maior chegou à mesma linha e, em cerca de um minuto e meio, avançou e concluiu o deploy. O build deve soltar o log e avançar em cerca de 2 minutos, e essa instância tem 4 GB de memória. Ao abrir a URL do ambiente maior, a aplicação da BIA respondeu. ## Checklist - Instance profile do ambiente com policy de SSM para entrar na EC2 sem chave SSH. - CloudShell aberto, projeto clonado e conexão feita pelo script com o ID da instância. - `tail -f /var/log/eb-engine.log` rodando antes de iniciar o deploy. - Zip com `Dockerfile` ou `Dockerrun.aws.json` na raiz, não dentro de uma pasta. - Erro explícito conferido tanto no log quanto na aba Events. - Deploy parado no `docker compose build` tratado como falta de recurso: confirmar a última linha do log e as métricas da instância. - Novo ambiente com instância maior para comparar os dois logs. Troubleshooting é isso: ir ao local onde o erro nasce e ler. Na Formação AWS eu aprofundo esses assuntos na prática.