Elastic Beanstalk: publicar aplicações sem gerenciar servidores

O AWS Elastic Beanstalk fica no meio-termo entre a liberdade total (e a complexidade) do EC2 e a automação total do Lambda. Ele é um serviço de orquestração que facilita a implantação e o gerenciamento de aplicações web. Você envia o código, e ele monta a infraestrutura em volta dele.

Podemos classificá-lo como uma PaaS (Plataforma como Serviço). A ideia é simples: você decide o que a aplicação faz, e o serviço decide como a máquina que roda a aplicação deve ser montada, atualizada e vigiada. Esta aula explica o que ele faz por dentro, mostra um deploy completo de uma API em Go usando a EB CLI, compara as políticas de deploy e termina com os erros que aparecem na prática.

1. O que ele faz?

O objetivo principal do Elastic Beanstalk é permitir que os desenvolvedores foquem na criação do código, enquanto a AWS cuida da infraestrutura necessária para rodar esse código.

Ao contrário do EC2, em que você precisa instalar o sistema operacional, configurar o servidor web, ajustar o balanceador de carga e configurar o auto scaling manualmente, o Elastic Beanstalk faz tudo isso automaticamente assim que você envia a sua aplicação. O custo dessa automação é perder um pouco de controle sobre detalhes que você poderia ajustar no EC2 puro. Em troca, você ganha um caminho previsível do código até o ar.

2. Como funciona na prática?

O fluxo de trabalho é simples, mas há uma distinção que confunde muita gente: o Beanstalk não roda o seu código diretamente. Ele cria um ambiente, que é o conjunto de recursos AWS, e coloca a sua versão da aplicação dentro desse ambiente.

Upload do código: você envia o seu código (Java, .NET, PHP, Node.js, Python, Ruby, Go ou Docker) para o Elastic Beanstalk.
Provisionamento automático: o serviço lê o seu código e cria e configura os recursos necessários da AWS, como:
- Instâncias EC2 para processamento.
- Elastic Load Balancing para distribuir o tráfego.
- Auto Scaling para aumentar ou diminuir a capacidade conforme a demanda.
- Monitoramento de integridade pelo CloudWatch.

Dois termos aparecem o tempo todo. Uma application version é uma versão do código guardada com um rótulo, como v42. Um environment é o conjunto de instâncias e balanceador que roda uma versão. Um mesmo aplicativo pode ter vários ambientes, como dev, staging e prod, cada um rodando uma versão diferente.

3. Vantagens principais

Rapidez de implantação: é a forma mais curta de colocar uma aplicação web no ar na AWS, porque a configuração inicial já vem pronta.
Controle total quando você precisa: embora automatize a infraestrutura, você continua com acesso às instâncias EC2 subjacentes. Se precisar fazer uma configuração avançada no sistema operacional, pode entrar por SSH com a EB CLI. Isso mantém a conveniência de um serviço gerenciado sem perder a flexibilidade de um servidor tradicional.
Gerenciamento contínuo: a AWS mantém a plataforma (o runtime e o sistema) e oferece atualizações gerenciadas, reduzindo a manutenção de servidores que você faria no EC2.

4. Custo

O próprio Elastic Beanstalk não cobra nada a mais. A página oficial de preços diz “There is no additional charge for AWS Elastic Beanstalk” (consultada em 27 de outubro de 2026). Você paga pelos recursos que ele cria para rodar a aplicação: as horas das instâncias EC2, o balanceador de carga, o armazenamento no S3 (onde ficam os pacotes das versões) e os logs do CloudWatch, se você os ativar.

Como o Beanstalk cria recursos por você, o custo pode crescer sem que você perceba. Um ambiente com balanceador e duas instâncias cobra por todos eles, mesmo que a aplicação receba pouco tráfego. Use a calculadora oficial da AWS para estimar, e apague os ambientes de teste quando terminar. Os valores unitários não foram conferidos nesta revisão.

5. Como usar de verdade

Esta seção percorre um caso completo: uma API em Go, com uma rota de saúde, implantada num ambiente de teste e atualizada por uma nova versão. A ferramenta é a EB CLI, que executa comandos eb no diretório do projeto. Os nomes são exemplos.

5.1 Preparar o projeto

O Beanstalk aceita um código Go de forma simples. Se a raiz do pacote tem um arquivo application.go com o pacote main, o serviço compila com go build -o bin/application application.go e sobe o binário em seguida. Segundo a documentação do ambiente Go, a aplicação é iniciada na porta 5000.

package main

import (
	"fmt"
	"log"
	"net/http"
	"os"
)

func main() {
	port := os.Getenv("PORT")
	if port == "" {
		port = "5000"
	}

	http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
		w.WriteHeader(http.StatusOK)
		fmt.Fprintln(w, "ok")
	})

	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "olá, você chegou em %s\n", r.Host)
	})

	log.Printf("escutando na porta %s", port)
	log.Fatal(http.ListenAndServe(":"+port, nil))
}

Esse código foi testado na minha máquina: compila com go build, passa em go vet e responde ok em /health quando sobe com PORT=8081. No macOS, a porta 5000 costuma estar ocupada pelo AirTunes, e foi por isso que o teste local usou outra porta. A versão fica com o padrão 5000 para ser igual ao ambiente.

Crie o projeto com o código, e teste antes de enviar:

mkdir meu-servico && cd meu-servico
# salve o código acima como application.go
go vet application.go
PORT=8081 go run application.go

Em outra aba, curl localhost:8081/health deve responder ok. Um go.mod também é aceito pela plataforma Go, segundo a documentação. A versão de Go usada pelo ambiente não foi conferida nesta revisão, então escolha uma versão compatível com a plataforma que você selecionar.

5.2 Criar a aplicação e o ambiente com a EB CLI

A EB CLI precisa estar instalada e autenticada na conta. A instalação não foi executada nesta revisão, então siga a documentação de configuração da EB CLI para o seu sistema.

O comando eb init cria a aplicação no Beanstalk e grava as escolhas no diretório .elasticbeanstalk/, para que os próximos comandos saibam em qual aplicação e região trabalhar. A opção -p escolhe a plataforma. O nome exato da plataforma Go deve ser conferido com eb platform list, porque a documentação mostra exemplos com outros runtimes e não confirma o nome do Go nesta consulta. A opção -k associa o par de chaves, que você usará com eb ssh:

eb init meu-servico -p go -r us-east-1 -k chave-api

Em seguida, crie o ambiente. A opção --single cria uma única instância, sem balanceador, e serve para desenvolvimento e teste. Sem ela, o ambiente é balanceado e escalável, que é o que a produção costuma usar:

eb create meu-servico-dev --single

A documentação avisa que o ambiente de instância única não é pronto para produção: se a instância se tornar instável durante o deploy, a aplicação pode ficar indisponível por um período. Ele é para teste, desenvolvimento e homologação.

Quando o comando termina, consulte o estado e abra o endereço:

eb status
eb health
eb open

eb status mostra o ambiente, a versão em execução e o endereço (CNAME). eb health mostra a saúde do ambiente e das instâncias, e eb health --refresh atualiza essa visão a cada 10 segundos. eb open abre o endereço no navegador.

5.3 Enviar uma nova versão

O deploy com a EB CLI tem uma regra que pega muita gente: o eb deploy empacota o último commit, não os arquivos do disco. Segundo a documentação, quando o Git está instalado, a CLI usa git archive sobre o commit mais recente. Arquivos alterados e não commitados ficam de fora, a menos que você use .ebignore (que muda o comportamento para incluir tudo, exceto o que estiver na lista) ou a opção --staged, que envia o que está no índice do Git.

Depois de alterar o código, faça o commit e implante com um rótulo legível:

git add application.go
git commit -m "api: rota /health"
eb deploy -l v2-health -m "rota /health"

O -l define o rótulo da versão, e o -m a descrição. Ao terminar, acompanhe os eventos e os logs:

eb events
eb logs

eb events lista os eventos do ambiente, em ordem. eb logs mostra os logs da instância; sem opção, ele traz as últimas linhas. --all salva os logs completos em .elasticbeanstalk/logs, e --zip compacta esse conjunto.

Para voltar à versão anterior, implante o rótulo antigo. A opção --version aceita uma versão existente:

eb deploy --version v1-inicial

Essa é a forma de rollback que a documentação descreve: o deploy de uma versão já existente, sem reconstruir nada.

5.4 Variáveis de ambiente e configuração

A forma recomendada de mudar configuração sem mudar o código é pela variável de ambiente. Ela é lida dentro da aplicação com os.Getenv, como no exemplo. A documentação do Go confirma que as propriedades do ambiente são acessíveis dessa forma. O comando eb setenv grava a variável no ambiente; a sintaxe exata não foi conferida nesta revisão, mas o comando existe na referência da EB CLI.

Para configurações que precisam ser versionadas junto com o código, a documentação aceita arquivos de configuração no pacote, em .ebextensions/, com a sintaxe option_settings em YAML. As políticas de deploy usam essa sintaxe, e a próxima seção mostra um exemplo.

5.5 Políticas de deploy

A política de deploy decide como as instâncias trocam de versão. Ela muda o que acontece com a capacidade e com o tráfego, e é uma das decisões mais importantes da aula. Segundo a documentação, o padrão é All at once, mas um ambiente balanceado criado com a EB CLI (sem --single) usa rolling deployments.

As cinco políticas são estas: All at once (todas as instâncias de uma vez, com indisponibilidade curta), Rolling (lotes, que saem de serviço e reduzem a capacidade), Rolling with additional batch (um lote extra sobe antes, para manter a capacidade), Immutable (um grupo novo de instâncias, separado do atual) e Traffic splitting (um grupo novo recebe uma fração do tráfego por um período de avaliação, como um teste canário).

A configuração fica num arquivo do pacote. Este exemplo, copiado da documentação, usa lotes de 25% no rolling:

option_settings:
  aws:elasticbeanstalk:command:
    DeploymentPolicy: Rolling
    BatchSizeType: Percentage
    BatchSize: 25

Para o caso em que você quer que um deploy ruim nunca atinja o ambiente inteiro, a política Immutable é a mais segura, e o diagrama abaixo mostra por quê:

option_settings:
  aws:elasticbeanstalk:command:
    DeploymentPolicy: Immutable

Traffic splitting exige um Application Load Balancer, que é o que a EB CLI cria por padrão. Os valores NewVersionPercent e EvaluationTime da seção aws:elasticbeanstalk:trafficsplitting definem a fração de tráfego e o tempo de avaliação. Esses valores não foram testados nesta revisão.

figura 2 · beanstalk 02 rolling contra immutable

O desenho compara as duas políticas com o mesmo problema: a versão nova falha no meio. No rolling, o lote 1 já mudou para a versão nova quando o lote 2 falha, e o ambiente fica com v1 e v2 convivendo. No immutable, a falha acontece no grupo novo, que é descartado, e o grupo antigo nunca foi tocado. Quando uma versão ruim não pode alcançar nem parte das instâncias, a política immutable é a mais segura entre as listadas, ao custo de ter temporariamente o dobro de instâncias.

5.6 O ciclo de um deploy

Um deploy atravessa várias etapas que você pode acompanhar em eb events. O diagrama mostra a sequência, incluindo o caminho de falha:

O código sai do seu commit, vira um ZIP enviado ao bucket do Beanstalk e é registrado como uma application version. O ambiente aplica a política de deploy, um lote de cada vez. Cada lote passa pelo health check antes de o próximo começar. Se o lote não fica saudável dentro do tempo limite, o deploy falha, e o caminho vermelho leva ao rollback com eb deploy --version. O rollback não é automático por padrão: é uma decisão sua, com base no evento.

5.7 Como uma requisição chega ao código

Dentro da instância, o Beanstalk coloca um proxy na frente do seu binário, para servir arquivos estáticos e repassar as requisições. O diagrama mostra o caminho de uma requisição e o caso em que o processo não está escutando.

O cliente fala com o balanceador. O balanceador repassa a requisição ao proxy na instância, e o proxy repassa ao binário, que responde. A parte vermelha do desenho é a que mais aparece em suporte: o binário não sobe, ou sobe em outra porta, e o proxy não tem para onde mandar a requisição. Quando isso acontece, o health check falha e o Beanstalk marca a instância como não saudável. A documentação do Go confirma a porta 5000 para o binário, mas como o proxy descobre essa porta no Amazon Linux 2023 não foi confirmado nesta revisão. O código acima aceita a variável PORT por segurança.

Se o processo termina sozinho, o Beanstalk o reinicia. A documentação diz que os processos listados em um Procfile são monitorados e reiniciados quando terminam, e que a aplicação principal precisa se chamar web e aparecer primeiro. Tarefas curtas, que devem rodar e terminar, pertencem ao Buildfile e não ao Procfile.

6. Java no Beanstalk

A plataforma Java SE existe, e a busca indicou que o Corretto está disponível no Amazon Linux 2023 para versões como 21 e 25. Porém, o formato exato do bundle (se o JAR fica na raiz e como o Beanstalk o inicia) e a porta da aplicação não foram confirmados na documentação oficial nesta revisão. Confira a página da plataforma Java SE antes de publicar uma aplicação Java.

7. Erros comuns e como resolver

O deploy não traz a mudança. O eb deploy empacota o último commit. Faça git commit antes, ou use --staged se quiser enviar o índice.
O deploy falha no health check. O processo não subiu ou não escuta na porta esperada. Leia eb events para o motivo e eb logs --all para o log completo do processo.
A versão nova derruba o ambiente inteiro. A política está em All at once, que é o padrão de um ambiente de instância única. Use um ambiente balanceado com Rolling ou Immutable quando precisar de disponibilidade.
Um ambiente único fica indisponível durante o deploy. Isso é esperado pela própria documentação do --single. Ele não serve para produção.
A EB CLI criou o ambiente, mas o eb ssh não conecta. O par de chaves precisa existir na região e estar associado ao ambiente, na opção -k do eb init ou do eb create.
O custo cresce sem uso. O Beanstalk não cobra pelo serviço, mas cobra pelas instâncias, pelo balanceador e pelos logs. Apague os ambientes de teste com eb terminate, que remove o ambiente e os recursos que ele criou.

Resumo: quando usar o Elastic Beanstalk?

Use-o quando você tem uma aplicação web (como um site WordPress, uma API em Node.js ou um app em Python ou Go) e quer a robustez de servidores EC2 com escalabilidade, mas não quer perder tempo configurando redes, instalando servidores web e gerenciando o sistema operacional manualmente.

Ele é menos adequado quando você precisa de controle fino sobre cada recurso da rede ou quando a infraestrutura já é gerenciada por outra ferramenta, como Terraform. Nesse caso, o Beanstalk pode duplicar o que a sua ferramenta já faz.

Não verificado nesta revisão

Preço do balanceador, das instâncias e do armazenamento de logs: não consultado. Use a calculadora oficial.
Nome exato da plataforma Go para eb init -p: confira com eb platform list.
Versão de Go usada pela plataforma e a forma como o proxy encontra a porta no Amazon Linux 2023.
Instalação da EB CLI e saída dos comandos: não executados nesta revisão. O eb não estava instalado na máquina usada para testar.
Sintaxe de eb setenv, eb ssh e eb terminate: os comandos existem na referência, mas a sintaxe completa não foi conferida página por página.
Valores de NewVersionPercent e EvaluationTime: documentados, não testados.
O comportamento de rollback automático, que a documentação descreve como exigência de decisão do operador após falha: não confirmado em ambiente real.
Java: layout do bundle e porta, como indicado na seção 6.

Fontes

Consultadas em 27 de outubro de 2026.

Neste texto