EC2 é o serviço de máquinas virtuais da AWS. Você aluga capacidade de computação — CPU, memória, rede — sob demanda, paga por hora ou por segundo, e descarta quando não precisa mais. É a base sobre a qual grande parte da AWS é construída.
A ideia por trás do EC2
Imagine que você precisa de um servidor para rodar uma aplicação. Antes da nuvem, você comprava o hardware, esperava semanas pela entrega, instalava o sistema operacional e só então começava a trabalhar. Com o EC2, esse processo leva minutos: você escolhe o perfil de hardware que precisa, seleciona uma imagem de sistema operacional (AMI) e a instância está pronta.
EC2 significa Elastic Compute Cloud — o “elástico” é literal. Você pode subir 1 instância ou 500 em questão de minutos, e desligar tudo depois de um processamento em lote sem pagar pelo tempo ocioso.
Tipos de instâncias: escolha certa para cada workload
A AWS organiza as instâncias em famílias, cada uma otimizada para um perfil de uso diferente. Entender isso evita pagar caro por recursos que você não usa — ou travar a aplicação por falta do recurso certo.
| Família | Perfil | Exemplos de uso |
|---|---|---|
| General Purpose (M, T) | CPU e memória equilibrados | Aplicações web, servidores de aplicação, ambientes de desenvolvimento |
| Compute Optimized (C) | CPU de alta performance por memória | Processamento em lote, encoders de vídeo, servidores de jogos |
| Memory Optimized (R, X) | Grande quantidade de RAM | Bancos de dados em memória (Redis, SAP HANA), analytics em tempo real |
| Storage Optimized (I, D) | Alta throughput e IOPS de disco | Bancos de dados NoSQL, data warehouses, sistemas de arquivos distribuídos |
| GPU (G, P, Inf) | Processamento gráfico e ML | Treinamento de modelos, renderização, inferência de IA |
A instância t3.medium (2 vCPUs, 4 GB RAM) é o ponto de entrada mais comum para quem está começando. A família T usa créditos de CPU — funciona bem para cargas com picos curtos, mas pode throttle em uso contínuo. Para workloads constantes, prefira a família M.
Modelos de preço: onde a economia acontece
Esse é o ponto onde a maioria das empresas erra. Rodar tudo em on-demand é cômodo, mas é o modelo mais caro.
On-Demand: você paga por hora (ou por segundo para Linux). Sem compromisso. Ideal para desenvolvimento, testes e cargas imprevisíveis. É o modelo base, mas não deve ser o modelo principal em produção.
Reserved Instances: você se compromete com uma instância por 1 ou 3 anos e recebe desconto de até 72% comparado ao on-demand. Existem três variantes: All Upfront (paga tudo na frente, maior desconto), Partial Upfront e No Upfront (paga mensalmente, menor desconto).
Savings Plans: similar às Reserved Instances, mas o compromisso é por gasto horário mínimo, não por tipo de instância. Isso dá mais flexibilidade para mudar de família ou região e ainda manter o desconto.
Spot Instances: você usa capacidade ociosa da AWS com descontos de até 90%. O risco: a AWS pode retomar a instância com 2 minutos de aviso quando precisar da capacidade. Ideal para processamento em lote, renderização e workloads tolerantes a interrupção.
EC2 vs VMs em cloud privada
A comparação é direta: tanto EC2 quanto VMs em cloud privada são máquinas virtuais. A diferença está no modelo operacional e no perfil de custo.
No EC2, você não gerencia o hypervisor. A AWS cuida de tudo abaixo do sistema operacional. Você tem controle total do SO para cima, mas nenhum abaixo.
Em uma cloud privada como a Adentro, o modelo é similar — você recebe uma VM com recursos garantidos — mas a fatura é em BRL, sem variação cambial, e o dimensionamento é feito com base no seu perfil de uso real, não no catálogo fixo da AWS.
O ponto de atenção no EC2 é o custo de egresso: dados que saem da instância para a internet são cobrados por GB. Isso não é overhead pequeno em aplicações que servem muitos dados para os clientes.
O que considerar ao escolher o tipo de instância
- Perfil de CPU: sua aplicação é CPU-bound (processamento intenso) ou I/O-bound (aguarda rede/disco)? CPU-bound pede família C; I/O-bound tolera instâncias mais balanceadas.
- Memória necessária: bancos de dados em memória precisam de instâncias R. Subestimar memória causa swap e degrada a performance.
- Tipo de armazenamento: EC2 usa EBS (storage de bloco) por padrão. Para I/O muito alto, instâncias com NVMe local (família I) podem ser necessárias — mas atenção: NVMe local não persiste ao parar a instância.
- Rede: instâncias maiores têm mais largura de banda de rede. Para aplicações que movem muito dado entre instâncias, isso importa.
- Custo: sempre compare com a Calculadora AWS antes de fechar a arquitetura. Um tipo de instância errado pode custar 2x sem entregar 2x de performance.
Quer entender qual perfil de VM faz sentido para o seu workload em cloud privada? Fale com um arquiteto Adentro.