AWS EC2: o que está por trás da instância

Abrir o console da AWS e clicar em “Launch instance” dá a impressão de que você ganhou um servidor. O SSH funciona, o Nginx sobe, o disco existe. A metáfora é boa o bastante para esconder o que mudou: você não comprou uma caixa. Alugou capacidade, com um contrato de falha diferente do ferro da sala.

EC2 (Elastic Compute Cloud) é o serviço de computação em máquina virtual da AWS. Entender isso antes de decorar tipos t3 e m5 evita dois erros: tratar a instância como pet intocável e tratar a nuvem como datacenter com cartão de crédito.

Instância é VM, com API em volta

Por baixo, uma instância é uma máquina virtual: vCPU, memória, rede, armazenamento que você escolhe (em geral EBS, um disco de rede). A imagem (AMI) é o molde do sistema. O par de chaves abre o SSH. O security group é firewall de estado: porta 22 da sua IP, 80 e 443 para o mundo, nada mais até você pedir.

A diferença para o Vagrant da sua máquina não é o Linux. É o ciclo de vida. A instância nasce em uma zona de disponibilidade, ganha IP público efêmero a menos que você reserve, e pode ser destruída sem cerimônia. Disco raiz some com ela se você pediu assim. Snapshot e AMI são o jeito de não depender do animal de estimação.

Famílias existem porque a carga não é uma só. Burstable (t) empresta CPU e cobra quando o crédito acaba — barato para laboratório, traiçoeiro para produção constante. Compute, memory, storage optimized não são marketing: são eixos. Escolher t2.micro porque é “grátis no free tier” e depois reclamar de CPU throttle é misturar estudo com carga real.

Rede e região não são detalhe. Security group, subnet, IP elástico e load balancer vivem numa região. Copiar o grupo de segurança de us-east-1 com a cabeça em sa-east-1 não cola. Latência até o usuário brasileiro também não é a mesma em Oregon e em São Paulo. A instância “igual” em outro lugar não é a mesma decisão.

O que a AWS faz e o que continua seu

Responsabilidade compartilhada, em uma parágrafo, é isto: a AWS garante o hipervisor, o datacenter, a rede física e a disponibilidade do serviço EC2 enquanto serviço; você garante o sistema operacional, os patches, as chaves, as regras de firewall, os dados no disco, a aplicação e o backup que realmente restaura. A nuvem não aplica apt upgrade no seu lugar. Não escolhe senha boa. Não impede 0.0.0.0/0 na porta 22. O modelo “eles cuidam da nuvem, eu cuido do que coloco na nuvem” parece óbvio até o primeiro incidente em que ninguém patchou o OpenSSH.

Isso não diminui o valor do EC2. Diminui a fantasia de que migrar é terceirizar operação inteira. Você terceirizou espera de hardware e parte da rede. O restante ainda é ofício.

flowchart TD
  A[Carga nova] --> B{Precisa de VM?}
  B -->|Não, é arquivo| C[S3]
  B -->|Não, é SQL gerenciado| D[RDS]
  B -->|Não, é função curta| E[Lambda]
  B -->|Sim, processo longo| F[EC2]
  F --> G[AMI + SG + disco]
  G --> H{Uma instância basta?}
  H -->|Não| I[Várias + LB]
  H -->|Sim, estudo ou lote| J[Instância só]
  classDef ouro fill:#FBF5E4,stroke:#C9A227,color:#0B1F18,stroke-width:1.4px
  classDef verde fill:#F3FAF7,stroke:#1E7A57,color:#0B1F18,stroke-width:1.4px
  classDef fim fill:#14513B,stroke:#0F3328,color:#FBFAF6,stroke-width:1.4px
  class A,B ouro
  class F,G,H verde
  class C,D,E,I,J fim

Quando não começar pelo EC2

EC2 é o caminho de menor surpresa para quem já pensa em servidor. Por isso é também o caminho que mais reproduz o datacenter antigo na nuvem: uma VM, um deploy manual, um IP na planilha.

Não comece por EC2 se a carga é arquivo estático — objeto em S3 e CDN resolvem sem processo. Não comece se a carga é banco: RDS ou equivalente cuida de backup, patch do motor e failover de um jeito que a instância “com Postgres instalado à mão” não cuida. Não comece se a carga é um job curto e esporádico: função sob demanda evita VM ociosa 24 h.

Também não comece por uma instância só de produção web se você já sabe que precisa de disponibilidade. Uma EC2 é um ponto de falha com IP. Imagem, load balancer e grupo de auto scaling existem precisamente porque instância some. Treinar o clique de “criar instância” é útil. Parar no clique é copiar o servidor da sala para um aluguel mais visível.

Há um caso honesto para uma EC2 solitária: laboratório, lote, bastion, aquele worker que processa fila e pode cair sem drama. Produção com usuário na ponta pede o conjunto, não a caixa.

Necessidade	Começar com EC2?	Alternativa típica
Site estático / asset	Não	S3 + CDN
Banco relacional	Em geral não	RDS
API com processo longo, lib nativa	Sim	EC2 ou container no ECS
Job de poucos minutos, raro	Raramente	Lambda / lote
SSH de emergência	Sim, pequena	Bastion ou Session Manager

O que vale aprender no primeiro contato

Não decore a lista de instâncias. Decore o ciclo: AMI, tipo, storage, security group, chave, zona. Suba, conecte, instale algo, tire uma AMI, destrua, suba de novo a partir da imagem. O exercício ensina o que o clique esconde: a máquina não é o ativo. A imagem e o disco snapshotado são.

Depois, o IP. Público efêmero muda no stop/start. Elástico permanece e custa quando não está associado do jeito que você imagina. DNS no Elastic IP ou, melhor, no load balancer, evita gravar endereço na aplicação.

Por fim, o dinheiro. Instância parada com EBS ligado continua na fatura do disco. Elastic IP solto cobra. Data transfer sai. O modelo “US$ 3 por hora” só é barato se você liga, usa e desliga — ou se a elasticidade está automatizada. EC2 sem desligar é servidor com extração bancária mensal.

EC2 é ferramenta certa para muita carga. Só não é a porta de entrada obrigatória da nuvem. Quando a primeira decisão é “qual VM?”, a conversa já saiu do estilo de nuvem e entrou no shopping de servidor. O próximo passo é tratar capacidade como algo que sobe e desce, não como um pet com nome.

Antes de escolher instância, vale saber o que o processo da aplicação realmente faz. A Programming One começa por aí: o código, o sistema operacional e só então a conta na nuvem.

Leia também: Nuvem não é compra de servidor e Load balancer, Nginx e vários servidores.