Elastic Beanstalk em 2026: primeiro deploy na prática e quando trocar por ECS ou App Runner

Subi uma aplicação PHP de exemplo do zero no Elastic Beanstalk, entrei na instância sem key pair e escalei o ambiente para dois a quatro servidores. No fim, o raciocínio de quando esse serviço ainda vale a pena perto de ECS e App Runner.

Nota da redação: a seção final sobre limpeza do ambiente afirma que apagar o ambiente pelo console desfaz automaticamente a stack do CloudFormation e remove os recursos provisionados. Não encontramos confirmação dessa afirmação na documentação oficial disponível (o trecho da seção 'Clean up' da fonte usada foi cortado antes desse conteúdo). O restante do artigo foi verificado e confere com a documentação da AWS; trate apenas essa afirmação específica sobre o comportamento de exclusão com cautela e confirme no Cost Explorer antes de assumir que nada ficou provisionado.

Subi uma aplicação PHP de exemplo do zero no Elastic Beanstalk, entrei na instância sem key pair e escalei o ambiente para dois a quatro servidores. No fim, o raciocínio de quando esse serviço ainda vale a pena perto de ECS e App Runner.

Abri o console do Elastic Beanstalk pela enésima vez para este tutorial e a sensação é a mesma de sempre: é o jeito mais rápido de colocar uma aplicação no ar sem desenhar VPC, ASG e load balancer na mão. Mas rápido não é sinônimo de certo para todo workload. Fiz o deploy completo de uma aplicação PHP de exemplo, atualizei a versão e escalei o ambiente, e vou mostrar onde cada passo pode travar.

O que o Elastic Beanstalk realmente entrega

Elastic Beanstalk não é uma camada de abstração mágica: é orquestração de recursos que você mesmo configuraria. Quando você cria um ambiente, ele provisiona uma instância EC2, um security group liberando a porta 80, um bucket S3 para guardar o código-fonte, dois alarmes do CloudWatch para escalar por carga e uma stack inteira do CloudFormation por trás de tudo isso. Você pode abrir essa stack no console do CloudFormation e ver exatamente o que foi criado.

Isso importa porque, no dia em que algo quebrar, você não vai debugar "o Beanstalk": vai debugar a instância EC2, o Auto Scaling group ou o load balancer que ele gerou. Entender essa pilha de recursos desde o primeiro deploy evita surpresa depois.

Antes de abrir o console: as duas IAM roles que todo mundo pula

Todo ambiente do Beanstalk Standard (a variante que roda em EC2, que é a que segui aqui) precisa de duas roles, e a AWS não assume nenhuma delas por padrão:

• Service role: permite ao Elastic Beanstalk monitorar suas instâncias e aplicar atualizações de plataforma. Precisa das policies AWSElasticBeanstalkEnhancedHealth e AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy.
• EC2 instance profile: é o que a própria instância usa para escrever logs e falar com outros serviços. Precisa de AWSElasticBeanstalkWebTier, AWSElasticBeanstalkWorkerTier e AWSElasticBeanstalkMulticontainerDocker.

O console cria as duas na hora, pelo wizard de criação de aplicação, mas se você já tem roles de um projeto anterior, pode reaproveitar. Pule o EC2 key pair: não vai precisar dele, porque a conexão com a instância vai ser via Session Manager.

Passo a passo: do wizard ao ambiente no ar

1. No console do Elastic Beanstalk, escolhi Create application e dei o nome getting-started-app.
2. No nome do ambiente, usei gs-app-web-env e selecionei a plataforma PHP.
3. Em Application code e Presets, deixei os padrões: Sample application e Single instance.
4. Criei a service role e o instance profile como descrito acima.
5. Pulei direto para Skip to Review (networking, banco de dados e parâmetros de escala ficam para depois) e cliquei em Submit.

O deploy inicial leva até cinco minutos. Atualizações depois disso são mais rápidas, porque só o que mudou é reenviado. Quando a saúde do ambiente vira Ok, a aplicação já responde em um domínio no formato subdominio.regiao.elasticbeanstalk.com, via HTTP (sem TLS por padrão, então o navegador pode reclamar).

Entrando na instância sem key pair

O jeito certo de debugar em 2026 não é mais criar um par de chaves e abrir a porta 22: é Session Manager. Antes de conseguir conectar, precisei adicionar ao instance profile (a role aws-elasticbeanstalk-ec2-role) a policy gerenciada que começa com AmazonSSMManagedEC2Instance. Sem isso, o botão Connect no console do EC2 simplesmente não funciona, e foi exatamente onde travei na primeira tentativa.

Com a policy anexada, abri o console do EC2, selecionei a instância do ambiente gs-app-web-env, escolhi Connect e depois Session Manager. De lá, rodei:

bash
cd /var/log/nginx
tail -f access.log

Dar refresh na URL da aplicação em outra aba e ver a linha nova aparecer no terminal é a confirmação de que o túnel do Session Manager está funcionando e de que o nginx (o reverse proxy que a maioria das plataformas gerenciadas do Beanstalk usa na frente da aplicação, sendo o Apache a alternativa em outras plataformas) está roteando o tráfego corretamente.

Atualizando a aplicação sem recriar o ambiente

Para simular uma atualização, baixei o pacote de exemplo php-v2.zip, fui em Upload and deploy na página do ambiente e subi o arquivo. O console preenche sozinho um Version label incremental. Durante o deploy, o status de saúde fica cinza; quando o health check volta a responder, ele fica verde de novo e a página passa a mostrar a v2.

Se for editar o código-fonte você mesmo, lembre de recompactar sem atributos extras de arquivo (importa em macOS):

zip -X -r ../php-v2.zip .

Cada versão enviada é adicionada à tabela de Application versions, visível no menu lateral da aplicação.

Saindo do modo instância única

O ambiente padrão sobe com uma única instância, sem load balancer. Para um cenário mais realista de produção, fui em Configuration → Instance traffic and scaling configuration e troquei o Environment type de Single instance para Load balanced, com Min em 2 e Max em 4 instâncias no Auto Scaling group.

A AWS avisa que essa mudança substitui todas as instâncias atuais, então é uma operação com downtime potencial, não uma atualização incremental. O evento Successfully deployed new configuration no painel de Events é o sinal de que o ASG e o load balancer já estão de pé e associados ao ambiente.

Beanstalk Standard e Beanstalk Cluster são arquiteturas diferentes

Vale um aviso para quem só conhece o Beanstalk de alguns anos atrás: a documentação atual descreve duas variantes sob o mesmo nome. O Beanstalk Standard, que segui neste tutorial, roda em instâncias EC2 com as roles de serviço e instance profile tradicionais. O Beanstalk Cluster roda sua aplicação como contêineres num cluster EKS, usa roles de IAM orientadas a EKS em vez de instance profile de EC2, escala por número de réplicas de pod (podendo haver mais de uma réplica por instância) em vez de por número de instâncias, e os logs saem pelo backend de observabilidade configurado, não por conexão direta via Session Manager.

São dois produtos com filosofias de escala diferentes dentro do mesmo console. Se sua equipe já pensa em termos de pods e réplicas, o Cluster evita que você reaprenda o modelo de instância única do Standard.

Quando eu trocaria por ECS ou por App Runner

Isso é leitura minha, não está nos manuais da AWS, mas é o raciocínio que eu seguiria num projeto real. O Elastic Beanstalk compensa quando a aplicação é um monólito único, o time já pensa em termos de instância e Auto Scaling group, e não há apetite para desenhar task definitions ou configurar um cluster do zero. É o caminho mais curto do código local ao ar.

Eu trocaria por ECS com Fargate ou EC2 no momento em que a arquitetura vira multisserviço: vários contêineres com ciclos de deploy independentes, cada um com sua própria task definition, rede e política de scaling. ECS dá controle fino sobre placement, uso de Spot e instâncias Graviton por serviço, algo que o Beanstalk não expõe com a mesma granularidade.

Já o App Runner entra quando o objetivo é o oposto de controle: um único contêiner HTTP, sem querer administrar Auto Scaling group, security group ou instância nenhuma, com scale-to-zero quando não há tráfego. Para quem só quer publicar uma imagem de contêiner e esquecer a infraestrutura embaixo, App Runner tira até o ASG do caminho que o Beanstalk ainda obriga você a configurar.

Limpando o que ficou no ar

Depois de testar as cinco etapas, a expectativa é que apagar o ambiente pelo console desfaça a stack do CloudFormation que vimos lá no início, levando junto os recursos que ela provisionou. A própria AWS estima que o custo total do tutorial fica abaixo de um dólar, desde que você não deixe o ambiente escalado em Load balanced rodando por dias. Vale checar o Cost Explorer no dia seguinte para confirmar que não sobrou nada cobrando.

Fonte: Documentação do AWS Elastic Beanstalk — Getting started