# Docker na AWS: EC2 ou Elastic Beanstalk? Veja a diferença na prática

> Rodei a mesma aplicação com Docker numa EC2 e no Elastic Beanstalk e matei a instância para ver o que acontece. Veja o que cada caminho entrega.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Containers
- URL: https://pages.formacaoaws.com.br/blog/ec2-ou-elastic-beanstalk-docker/
- Aula de origem: "Docker na AWS: EC2 ou Elastic Beanstalk? O que é melhor?" (https://www.youtube.com/watch?v=TJSK9MRPZs4)

Dá para rodar um container direto numa EC2, e funciona. A diferença aparece quando a máquina morre ou quando você precisa entregar uma versão nova. Rodei a mesma aplicação com Docker nos dois caminhos, EC2 e Elastic Beanstalk, e terminei a instância para mostrar o que cada um faz por você.

A aula é de abril de 2024 e o console muda com o tempo: confira a plataforma Docker atual na [documentação do Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/create_deploy_docker.html).

## A mesma aplicação nos dois caminhos

Usei a aplicação da BIA, em Node com React, que já vem com `Dockerfile` e `docker-compose.yml`. Tirei o banco do compose para ficar só com a aplicação web. Localmente ela sobe na porta 3001, mapeada para a 8080 do container.

O desenho abaixo mostra a diferença: na EC2 solta, o `docker build` acontece na máquina que você montou. No Elastic Beanstalk, você entrega um zip e ele cuida do resto.

![Dois jeitos de rodar o docker build: na EC2 solta, riscada, ele acontece na própria máquina; no Elastic Beanstalk, o zip vira uma Application Version (AV) que chega à EC2 do ambiente](https://pages.formacaoaws.com.br/blog/assets/posts/ec2-ou-elastic-beanstalk-docker/desenho.svg)

**Fluxo:** Zip (docker-compose.yml na raiz) → Application Version (versão guardada, com rollback) → Elastic Beanstalk (cria a EC2, o security group e o IP elástico) → EC2 (build e container no ar) → Instância terminada (nova EC2 com o mesmo IP e a mesma versão)

## Caminho 1: Docker direto na EC2

Na EC2, o trabalho é seu do começo ao fim:

1. **Role IAM** com a policy `AmazonSSMManagedInstanceCore`, para eu entrar na máquina pelo Session Manager (SSM) sem par de chaves.
2. **Instância** Amazon Linux de 64 bits, `t3.micro`, VPC padrão, subnet com IP público e 10 GB de disco.
3. **Security group** com regra de entrada HTTP, porta 80, liberada para o mundo.
4. **User data** com o script do projeto, que instala Git, Docker e Node e ajusta as permissões.
5. **Conectar, clonar e ajustar:** entrei pelo SSM, dei `git clone` e editei o `docker-compose.yml` com o `nano`, trocando a porta para `80:8080`.
6. **Subir:** `docker compose up -d`. O build na máquina levou 78 segundos no total.

A aplicação respondeu na porta 80 pelo IP da instância. Para uma aplicação simples, isso atende, e dá até para configurar o Docker para reiniciar o container sempre que ele cair.

Os problemas estão em volta. Se essa máquina morrer, a aplicação sai do ar junto, e se a zona de disponibilidade em que ela está cair, também. E o projeto precisa ser baixado dentro da máquina para o build acontecer lá.

## Caminho 2: o mesmo projeto no Elastic Beanstalk

O Elastic Beanstalk é um serviço gerenciado da AWS para rodar aplicações. Você cria a **aplicação** (`bia`) e, dentro dela, os **ambientes**. Criei um só, o `bia-aula-yt`.

Na criação do ambiente, o que ele já resolve:

- **Endpoint.** Ele entrega um endereço `elasticbeanstalk.com` para a aplicação.
- **Plataforma.** Em vez de preparar a máquina com user data para rodar Docker, você escolhe a plataforma Docker sobre Amazon Linux, e ele aplica patches de segurança e atualizações.
- **Single instance**, que é o que eu precisava para este caso.
- **Service role.** A permissão que o Elastic Beanstalk usa em seu nome para mexer em Auto Scaling, Load Balancer, EC2 e S3. O console lista cada permissão que ela envolve.
- **Instance profile.** A role da EC2, com as permissões para log, X-Ray e S3, de onde a instância baixa o pacote.. Criei a minha no IAM.
- **Security group.** O Elastic Beanstalk trabalha por convenção: se você não escolhe nenhum, ele cria um com a porta 80 liberada, e não dá para desabilitar o que ele cria. Para ter controle maior, crie o seu e escolha-o.

Depois do Submit, o log de eventos mostra o que ele montou sem você pedir: um bucket no S3 para guardar as versões, o security group e um **IP elástico** para a instância.

![Eventos da criação do ambiente: o Elastic Beanstalk cria sozinho o IP elástico (EIP) e o security group, com os valores borrados](https://pages.formacaoaws.com.br/blog/assets/posts/ec2-ou-elastic-beanstalk-docker/eventos.webp)

## Entregar a aplicação: um zip, sem entrar na máquina

Na EC2, entregar foi conectar, clonar e rodar o build. No Elastic Beanstalk você sobe um pacote zip.

Ajustei o `docker-compose.yml` como antes (porta `80:8080`) e, dentro da pasta do projeto, gerei o zip pela linha de comando (funciona em Linux e Mac; no Windows dá para zipar a pasta pelo explorador, desde que tudo fique na raiz):

```bash
zip -r bia.zip *
```

Os arquivos precisam ficar **na raiz** do zip, sem pasta por fora. Para conferir, extraí o zip numa pasta separada (`out`) com o `unzip` e vi que os arquivos ficaram soltos ali.

Em **Upload and deploy**, escolhi o `bia.zip`, e o Elastic Beanstalk deu o nome de versão `bia.version1`. O pacote vai para a área **Application Versions**, e de lá o serviço faz o deploy na EC2. Como cada versão fica guardada, subir outra e voltar para a anterior vira um deploy, e o rollback é só escolher a versão antiga.

Fiz a entrega no modo mais simples; dá para ligar o deploy a um pipeline com o CodePipeline, usar o `eb deploy` ou acionar por script.

## O teste: terminar a instância

Com o deploy concluído, o `docker ps` na instância mostrou o container da BIA rodando. Então terminei a instância.

O Elastic Beanstalk percebeu que o ambiente estava sem instância e lançou outra, refez o vínculo com o **IP elástico** e mandou o Application Version fazer o deploy na máquina nova. O endereço continuou o mesmo.

Levou cerca de 3 minutos até o container subir de novo, e eu não fiz nada.

![A lista de instâncias depois do teste: a bia-aula-yt original terminada, outra t3.medium em execução e a bia-web, a t3.micro da EC2 solta, também encerrada](https://pages.formacaoaws.com.br/blog/assets/posts/ec2-ou-elastic-beanstalk-docker/instancias.webp)

O Elastic Beanstalk em si não cobra a mais: você paga pelos recursos que ele usa, como o S3 com as versões, o IP elástico e a EC2. Valores e Free Tier mudam, então confira na página de preços da AWS.

## A parte que pesa: o build exige uma instância maior

No Elastic Beanstalk roda bem mais coisa na instância do que numa EC2 solta. Para fazer o `docker build` ali, a `t3.micro` não dá conta e trava. Por isso escolhi a **`t3.medium`** no ambiente, como mostra a lista de instâncias acima.

Dá para usar uma `t3.micro` e reduzir esse custo. A saída é não fazer o build na instância: gere a imagem fora e publique no ECR, deixe no zip só o `docker-compose.yml` apontando para essa imagem e faça o deploy. A instância passa a só baixar a imagem (um `docker pull`) e rodar, e a carga cai bastante. O mesmo caminho cabe num pipeline: o CodePipeline faz o build, entrega a imagem ao ECR e produz o artefato com o compose para o Elastic Beanstalk.

## Como escolher

A EC2 sozinha serve quando você quer o container no ar e aceita cuidar da máquina: o role, o security group, a conexão, o build e o que acontecer se ela cair. O Elastic Beanstalk entrega, para a mesma aplicação:

- o endereço e o IP elástico prontos;
- a plataforma Docker já preparada e com patches aplicados;
- a entrega por zip, com versões guardadas e rollback;
- a instância substituída sozinha, com a versão e o IP de volta;
- o caminho aberto para pipeline.

Para quem está começando projetos na AWS, vale a pena usar o Elastic Beanstalk, mesmo numa aplicação simples e sem load balancer. O preço é a instância maior, a menos que você mova o build para o ECR.

Ao terminar, encerre o ambiente: ele desliga a máquina e libera os recursos, e você evita cobrança de uma instância fora do Free Tier.

## Checklist

- Mesma aplicação testada na EC2 (role SSM, security group na porta 80, clone, `docker compose up -d`).
- Aplicação e ambiente criados no Elastic Beanstalk com plataforma Docker e single instance.
- Service role e instance profile criados, e security group escolhido por você ou deixado por convenção.
- Zip com os arquivos na raiz, conferido com `unzip`.
- Deploy pelo Upload and deploy e versão guardada em Application Versions.
- Instância terminada de propósito para ver a recuperação, com o mesmo IP.
- Instância `t3.medium` para o build na instância, ou imagem no ECR para rodar em `t3.micro`.
- Ambiente encerrado ao final do teste.

Esse mesmo projeto, com pipeline, deploy por script e alta disponibilidade, é a base dos desafios da Formação AWS para Elastic Beanstalk.