Instâncias de computação em nuvem decidem o custo, o desempenho e a resiliência de toda a operação digital de uma empresa. O EC2 AWS, portanto, é o serviço que mais pesa na fatura de cloud da maioria das organizações brasileiras, e escolher mal o tipo de instância pode dobrar o gasto sem entregar mais capacidade.
Resumo
- O modelo de precificação do EC2 AWS tem três camadas: On-Demand, Reserved e Spot. Cada uma serve a um perfil de carga específico, e misturá-las corretamente, assim, reduz a fatura em até 70%.
- A família de instâncias define o custo por unidade de trabalho. Escolher a família errada é o erro mais caro e mais silencioso da operação em nuvem.
- Governança de instâncias EC2 é pré-requisito para qualquer estratégia de FinOps. Sem ela, o crescimento da fatura logo supera o crescimento do negócio.
Introdução
O EC2 AWS concentra, em média, entre 40% e 60% da fatura total de cloud de empresas brasileiras de médio porte. A plataforma existe desde 2006 e permanece a base da infraestrutura de milhares de organizações, mas o volume de opções cresceu tanto que a decisão ficou complexa. São, aliás, mais de 750 tipos de instâncias disponíveis hoje.
O problema não é falta de opção. O problema é que muitos times escolhem instâncias pelo hábito, não pela carga de trabalho. O resultado aparece na fatura: recursos superdimensionados que ninguém desliga, porque ninguém sabe ao certo quem os criou.
O artigo a seguir cobre os modelos de precificação, as famílias de instâncias, os erros mais custosos e o roteiro de decisão que um CIO precisa para justificar cada escolha ao CFO e ao conselho.
O que é o EC2 AWS e por que ele ainda domina
O Amazon EC2 entrega capacidade de computação sob demanda na nuvem da AWS. O executivo aloca servidores virtuais, chamados de instâncias, em segundos, sem comprar hardware físico. A empresa paga pelo tempo de uso, não pela capacidade instalada.
A vantagem central é a elasticidade. Um varejista brasileiro pode escalar de 10 para 500 instâncias em minutos durante a Black Friday, pois a infraestrutura acompanha o pico sem investimento antecipado em hardware.
A AWS, aliás, investe pesado em novos processadores próprios. As instâncias baseadas no chip Graviton, da geração M7g e C8g, entregam até 40% mais desempenho por dólar em comparação com as gerações anteriores baseadas em Intel. Conforme a análise da Forrester sobre o AWS re:Invent 2025, a AWS acelerou o lançamento de chips próprios e deve continuar a reduzir o custo por carga de trabalho nas novas gerações.
O domínio do EC2 AWS no mercado brasileiro se explica pela presença de duas regiões locais: São Paulo e, mais recentemente, a expansão de zonas de disponibilidade. Latência menor e conformidade com a LGPD, portanto, pesam na decisão de muitas empresas reguladas.
Modelos de precificação: onde a decisão financeira acontece
A fatura do EC2 AWS depende diretamente do modelo de compra escolhido. Três opções principais, afinal, estruturam o mercado.
- On-Demand: cobrança por hora ou por segundo, sem compromisso. É, portanto, ideal para cargas imprevisíveis ou projetos de curto prazo. O preço é o mais alto por unidade de tempo.
- Reserved Instances (RI): compromisso de 1 ou 3 anos em troca de desconto de até 72% sobre o On-Demand. Serve, sobretudo, a cargas estáveis e previsíveis, como bancos de dados de produção e ERPs.
- Spot Instances: capacidade ociosa da AWS leiloada com desconto de até 90%. A AWS, contudo, pode interromper a instância com aviso de dois minutos. Serve a cargas tolerantes a falha, como processamento em lote, treinamento de modelos e renderização.
A estratégia mais comum entre empresas maduras em cloud combina os três modelos. A base estável roda em Reserved, os picos cobrem com On-Demand e as cargas batch consomem Spot. Sem essa combinação, a empresa certamente paga tarifa cheia por tudo.
Savings Plans: a alternativa flexível às Reserved Instances
Os Savings Plans funcionam como um compromisso de gasto mínimo por hora, em vez de um tipo fixo de instância. O desconto chega a 66% sobre o On-Demand, pois o executivo mantém flexibilidade para trocar de família ou de região sem perder o benefício. Para empresas que migram cargas com frequência, o modelo é superior às Reserved Instances tradicionais.
O risco, contudo, existe. Compromisso financeiro de 1 ou 3 anos, inclusive, exige previsibilidade de carga. Uma empresa que reduz operações no período paga pelo compromisso mesmo sem usar a capacidade.
Famílias de instâncias EC2: a escolha técnica que mais afeta o custo
A documentação oficial da AWS sobre instâncias de uso geral lista dezenas de famílias, cada uma otimizada para um perfil de carga. A escolha errada, principalmente, desperdiça dinheiro de duas formas: paga por recurso que a carga não usa ou sofre gargalo por falta do recurso certo.
As principais famílias seguem perfis distintos de otimização. Veja, em seguida, os grupos que mais aparecem em ambientes corporativos brasileiros:
- Uso geral (M7g, M8g): equilíbrio entre CPU, memória e rede. Serve, igualmente, a aplicações web, APIs e ambientes de desenvolvimento.
- Otimizada para computação (C8g, C7g): alta proporção de CPU por memória. Serve a processamento científico, análise em tempo real e servidores de jogos.
- Otimizada para memória (R8g, X2idn): grande quantidade de RAM por vCPU. Serve, semelhantemente, a bancos de dados in-memory, SAP HANA e caches de alta escala.
- Otimizada para armazenamento (I4i, D3): alto throughput de disco local. Serve a bancos de dados NoSQL e sistemas de arquivos distribuídos.
- Computação acelerada (P5, G6): GPUs dedicadas para IA, machine learning e renderização gráfica.
A referência técnica oficial do EC2 AWS detalha as especificações de cada família. O time de arquitetura precisa, contudo, cruzar o perfil de consumo real da carga com as métricas de CPU, memória e rede antes de escolher.
O erro do superdimensionamento silencioso
A maioria das empresas brasileiras opera instâncias com menos de 20% de utilização média de CPU. O superdimensionamento acontece porque os times provisionam para o pico histórico e nunca revisam. Uma instância m7g.4xlarge custa, certamente, cerca de quatro vezes mais do que uma m7g.xlarge. Se a carga real cabe na menor, a empresa desperdiça 75% do gasto naquela instância.
A AWS oferece o Compute Optimizer, uma ferramenta que, aliás, analisa o histórico de uso e recomenda o tipo certo de instância. O Compute Optimizer é gratuito para análise básica e reduz a fatura em 20% a 30% nas empresas que adotam as recomendações. O problema é que, todavia, poucos times implementam o ciclo de revisão mensal.
Para ver em detalhe como estruturar o controle de gastos em cloud, veja o guia sobre governança de custos em nuvem publicado neste blog.
Alta disponibilidade e resiliência com EC2 AWS
Uma instância EC2 isolada não oferece alta disponibilidade. A arquitetura correta distribui a carga entre múltiplas zonas de disponibilidade dentro da mesma região. A AWS garante, decerto, SLA de 99,99% para instâncias em múltiplas zonas, contra 99,5% para instância única.
O Auto Scaling Group automatiza a adição e a remoção de instâncias conforme a demanda. A empresa define um mínimo, um máximo e uma política de escala. O grupo adiciona instâncias quando a CPU ultrapassa 70% e remove quando cai abaixo de 30%, por exemplo. O custo segue a demanda real, não o pico estimado.
Para cargas críticas, o Elastic Load Balancer distribui o tráfego entre as instâncias do grupo. Se uma instância falha, o balanceador redireciona o tráfego para as demais em segundos. O conjunto, Auto Scaling mais balanceador, é, sobretudo, o padrão mínimo para qualquer aplicação de produção. Para uma análise mais profunda sobre arquiteturas de alta disponibilidade, veja o artigo sobre alta disponibilidade em infraestrutura de TI.
Backup e recuperação: o que o SLA não cobre
O SLA da AWS cobre a disponibilidade da infraestrutura, não a integridade dos dados da empresa. O CIO precisa, certamente, configurar snapshots automáticos dos volumes EBS e testar a restauração periodicamente. Uma empresa que nunca testou o restore, decerto, descobre o problema no pior momento possível.
O AWS Backup centraliza as políticas de retenção para EC2, RDS e outros serviços. A conformidade com a LGPD exige, inclusive, que dados pessoais em backup sigam as mesmas políticas de acesso e retenção dos dados em produção. Ignorar o backup dos volumes EBS é o erro de segurança mais comum em ambientes EC2 de empresas brasileiras.
Segurança e compliance no EC2 AWS
Segurança no EC2 AWS começa pelo Security Group, o firewall virtual que controla o tráfego de entrada e saída de cada instância. O erro mais frequente é, decerto, liberar a porta 22 (SSH) para qualquer IP do mundo. Um scanner automatizado encontra essa instância, de fato, em menos de uma hora e inicia tentativas de acesso.
As boas práticas de segurança para o EC2 AWS seguem uma ordem clara de prioridade:
- Restringir acesso SSH e RDP a IPs corporativos específicos ou usar o AWS Systems Manager Session Manager, que elimina a necessidade de abrir portas de administração.
- Aplicar IAM Roles nas instâncias, em vez de armazenar credenciais de acesso dentro da máquina. Credencial hardcoded em instância EC2 é, igualmente, vetor de comprometimento clássico.
- Ativar o AWS Inspector para varredura contínua de vulnerabilidades no sistema operacional e nas aplicações instaladas.
- Criptografar volumes EBS com AWS KMS. A criptografia em repouso é, sobretudo, requisito de conformidade para dados financeiros e de saúde sob a LGPD.
A análise da IBM sobre tipos de instância EC2 reforça que a escolha do tipo de instância também afeta a superfície de ataque: instâncias com acesso a hardware dedicado (instâncias bare metal) eliminam o risco de ataques de canal lateral entre vizinhos de hypervisor, o que importa para cargas financeiras e de saúde.
Para empresas reguladas, o AWS Artifact fornece relatórios de conformidade com PCI DSS, SOC 2 e ISO 27001. Por fim, o auditor aceita esses relatórios como evidência da segurança da infraestrutura de nuvem.
Roteiro de decisão para o CIO: do provisionamento à otimização
A decisão sobre o EC2 AWS não termina no provisionamento inicial. O ciclo de vida de uma instância, principalmente, exige revisão contínua. O roteiro abaixo organiza as etapas por ordem de impacto financeiro e operacional.
- Mapear o perfil de cada carga de trabalho antes de escolher a família de instâncias. CPU intensiva, memória intensiva, I/O intensivo ou GPU são, assim, perfis distintos com famílias distintas.
- Definir o modelo de compra conforme a previsibilidade da carga. Cargas estáveis, logo, vão para Reserved ou Savings Plans. Cargas variáveis usam On-Demand. Cargas batch usam Spot.
- Ativar o Compute Optimizer e revisar as recomendações mensalmente. O ciclo de revisão mensal é, outrossim, o que separa empresas que controlam a fatura das que apenas a pagam.
- Implementar tags obrigatórias em todas as instâncias: centro de custo, ambiente (produção, homologação, desenvolvimento) e responsável técnico. Sem tag, não há, então, visibilidade de gasto por área.
- Estabelecer políticas de desligamento automático para instâncias de desenvolvimento e homologação fora do horário comercial. O ganho típico é, de fato, de 60% a 65% do custo dessas instâncias.
Para decisões sobre parceiros que ajudam a executar esse roteiro, o artigo sobre consultoria AWS traz os critérios certos para escolher o parceiro de nuvem. Para cargas de IA que rodam sobre EC2, veja o guia sobre agentes de IA para AWS.
O Gartner Peer Insights para o Amazon EC2 mostra que as empresas mais satisfeitas com o serviço são as que combinam automação de escala com governança de tags desde o início. As menos satisfeitas são as que migraram cargas sem mapear o perfil de consumo antes.
Conclusão
O EC2 AWS entrega capacidade de computação sem igual em escala e flexibilidade. O serviço, porém, cobra caro de quem não o governa. A família de instâncias errada, o modelo de compra inadequado e a falta de revisão periódica, assim, transformam a nuvem num gasto crescente sem retorno claro.
O CIO que domina as três camadas de decisão, família, modelo de compra e ciclo de revisão, controla a fatura e justifica cada real ao CFO. O que separa uma operação EC2 eficiente de uma cara não é o tamanho da empresa: é a disciplina do processo.
A próxima etapa prática é ativar o Compute Optimizer, auditar as instâncias sem tag e definir o calendário de revisão mensal. O ganho, sem dúvida, aparece na fatura do mês seguinte.
Perguntas frequentes
Qual é a diferença entre instâncias On-Demand e Reserved no EC2 AWS?
As instâncias On-Demand cobram por hora ou por segundo sem compromisso prévio. O preço é o mais alto por unidade de tempo, pois a empresa não assume risco de longo prazo. As Reserved Instances exigem compromisso de 1 ou 3 anos e entregam, de fato, desconto de até 72% sobre o On-Demand. A escolha depende da previsibilidade da carga: cargas estáveis economizam com Reserved, cargas imprevisíveis pagam menos no On-Demand do que pagariam por capacidade ociosa em Reserved.
Como o EC2 AWS impacta a conformidade com a LGPD?
O EC2 AWS permite que a empresa armazene e processe dados em regiões específicas, como São Paulo, já que a AWS mantém os dados dentro dos limites geográficos configurados. A conformidade com a LGPD exige, ainda, criptografia dos volumes EBS com AWS KMS, políticas de acesso via IAM e retenção de logs no CloudTrail. A infraestrutura da AWS é, por certo, certificada em ISO 27001 e SOC 2, e os relatórios estão disponíveis no AWS Artifact para apresentar a auditores.
Quando vale usar instâncias Spot no EC2 AWS?
As instâncias Spot valem para cargas que toleram interrupção: processamento em lote, treinamento de modelos de machine learning, renderização de vídeo e pipelines de dados. O desconto chega a 90% sobre o On-Demand, já que a AWS pode recuperar a instância com aviso de dois minutos. A arquitetura da carga precisa, de qualquer forma, salvar o estado periodicamente e retomar do ponto de interrupção. Cargas de produção contínua, como APIs e bancos de dados, não toleram interrupção e não devem rodar exclusivamente em Spot.
Como reduzir a fatura do EC2 AWS sem migrar de serviço?
Três ações entregam resultado imediato. A primeira é ativar o Compute Optimizer e aplicar as recomendações de redimensionamento: o ganho médio, com efeito, fica entre 20% e 30%. A segunda é converter instâncias de cargas estáveis para Savings Plans ou Reserved Instances: o desconto chega a 72%. A terceira é desligar automaticamente instâncias de desenvolvimento e homologação fora do horário comercial, visto que o ganho típico é de 60% a 65% do custo dessas instâncias. As três ações juntas, sem dúvida, costumam reduzir a fatura total do EC2 AWS em 40% a 50% em empresas sem governança prévia.