Resumo
Os preços do AWS EC2 parecem simples na tabela. Na prática, custos auxiliares como transferência de dados, armazenamento EBS e cobranças de IPv4 público podem somar 40–50% sobre as horas de computação. Este guia detalha os preços on-demand, reserved, spot e de Savings Plans com números reais, quantifica os itens ocultos que os times de FinOps costumam deixar de fora do orçamento e apresenta as estratégias de otimização que transformam o gasto imprevisível com EC2 em um número gerenciável e defensável.
A maioria dos times de FinOps sabe qual é a tarifa on-demand do EC2. Bem poucos conseguem dizer qual é, de fato, o custo total do EC2 quando entram na conta a transferência de dados, o armazenamento, os load balancers e a cobrança de IPv4 público que passou a valer em 2024. Essa diferença entre a tabela de preços e a fatura real é o que gera as surpresas orçamentárias que colocam programas de FinOps na berlinda.
O preço do EC2 não é complicado por falta de transparência nas tarifas individuais. A AWS publica todos os números. A complexidade vem do fato de que essas tarifas se desdobram em dezenas de dimensões, e a maioria dos modelos de custo subestima as cobranças auxiliares que se acumulam em torno de cada instância. Este guia traz para os profissionais de FinOps o contexto de preços, a matemática dos custos ocultos e os frameworks de otimização necessários para montar orçamentos de EC2 precisos e defendê-los.
O que é o AWS EC2?
O Amazon Elastic Compute Cloud (AWS EC2) oferece servidores virtuais redimensionáveis, chamados de instâncias, na nuvem da AWS. Os times provisionam capacidade de computação sob demanda, sem precisar comprar nem manter hardware físico.
Para quem atua em FinOps, o enquadramento mais relevante é outro: o EC2 costuma ser o maior item da fatura da AWS. O Gartner projeta gastos globais com nuvem pública de US$ 723 bilhões em 2025 (Gartner), e a computação puxa esse gasto. A AWS cobra o EC2 por segundo (com mínimo de um minuto) para instâncias Linux e por hora para Windows. As tarifas variam por família de instância, tamanho, região, sistema operacional e tenancy.
Uma m7i.large de uso geral em US East (N. Virginia) sai a US$ 0,1008/hora on-demand. Uma c7i.large otimizada para computação, na mesma região, custa US$ 0,08925/hora. Diferenças pequenas por hora viram valores expressivos em escala: 100 instâncias m7i.large rodando continuamente custam cerca de US$ 73.584/ano on-demand, antes de qualquer cobrança auxiliar.
Preços vigentes em maio de 2026. Consulte a página de preços On-Demand do AWS EC2 para tarifas atualizadas.
Como os tipos de instância do EC2 influenciam as decisões de preço?
Cada família de instância do EC2 é otimizada para uma proporção diferente de recursos, e essa proporção impacta diretamente o trade-off entre custo e desempenho que os times de FinOps precisam avaliar.
As instâncias de uso geral (família m) equilibram CPU, memória e rede. Cobrem o maior leque de workloads e são o ponto de partida padrão para a maioria das aplicações. Já as instâncias otimizadas para computação (família c) entregam mais vCPUs por dólar de memória, ficando 10–15% mais baratas por vCPU-hora em workloads CPU-bound, como processamento em batch e codificação de mídia. As instâncias otimizadas para memória (famílias r e x) invertem essa proporção e alocam mais RAM por vCPU para bancos de dados em memória e analytics.
O impacto no preço é uma questão de encaixe. Rodar um workload CPU-bound em uma instância otimizada para memória significa pagar por RAM ociosa. Rodar um banco de dados memory-heavy em uma instância otimizada para computação significa superdimensionar vCPUs só para ter RAM suficiente, o que infla a quantidade e o custo. O grupo de trabalho de autoscaling do EC2 da FinOps Foundation recomenda mirar 40–70% de utilização média de CPU e sinalizar para downsizing tudo o que ficar consistentemente abaixo de 20–30% (FinOps Foundation).
As gerações mais novas também pesam no preço. Em 2025, a AWS lançou as famílias m8i e c8i de 8ª geração, com até 15% mais preço-desempenho que a 7ª geração. Os times de FinOps devem comparar as instâncias da nova geração com as reservas atuais antes de renovar commitments.
Como a AWS calcula e cobra os preços do EC2?
A cobrança do EC2 começa pela tarifa hora-instância, mas não termina aí. Esta seção cobre os três modelos de preço, os custos auxiliares que inflam o valor real e as métricas de right-sizing que ajudam a trazer esse número para baixo.
Qual modelo de preço do EC2 combina com o seu workload?
A AWS oferece três modelos principais de preço para o EC2. Cada um traz um trade-off diferente entre flexibilidade e profundidade do desconto.
On-demand cobra a tarifa horária publicada, sem compromisso. Dá flexibilidade total, mas é a opção mais cara. Funciona bem para workloads imprevisíveis, projetos de curto prazo e qualquer capacidade que ainda não tenha estabilizado o suficiente para entrar em previsão.
Reserved Instances (RIs) e Savings Plans trocam compromisso por desconto. Uma RI Standard de 1 ano gira em torno de 40% de desconto sobre o on-demand. Uma RI Standard de 3 anos, cerca de 60%. Os Compute Savings Plans oferecem descontos parecidos (até 66%) com mais flexibilidade, sendo aplicados automaticamente entre famílias de instância, regiões e até Fargate e Lambda. A FinOps Foundation calcula o ponto de equilíbrio de uma RI de 1 ano em cerca de 7–8 meses, com utilização plena e desconto de 40% (FinOps Foundation).
O lado complicado: commitments não podem ser cancelados no meio do prazo. Os padrões de workload mudam, e reservas não utilizadas viram custo afundado. É esse risco que torna os erros comuns em commitments na AWS um dos problemas mais caros de FinOps.
Spot Instances aproveitam capacidade ociosa do EC2 com descontos de 60–90% sobre o on-demand. A AWS define os preços de Spot com base na oferta e demanda de longo prazo (e não em leilões) e dá um aviso de interrupção de 2 minutos quando a capacidade é retomada. Para workloads tolerantes a falhas, como processamento em batch, pipelines de CI/CD e microsserviços stateless, o Spot entrega o desconto mais profundo disponível.
Preços vigentes em maio de 2026. Consulte a página de preços de Reserved Instances da AWS e a página de preços do Spot para tarifas atualizadas.
| Modelo | Desconto vs. On-Demand | Compromisso | Flexibilidade | Garantia de capacidade |
|---|---|---|---|---|
| On-Demand | Nenhum | Nenhum | Total | Sim |
| RI Standard de 1 ano | ~40% | 1 ano | Baixa (presa à família/região) | Apenas no escopo da AZ |
| RI Standard de 3 anos | ~60% | 3 anos | Baixa | Apenas no escopo da AZ |
| Compute Savings Plan | Até 66% | 1 ou 3 anos | Alta (cross-family, cross-region) | Não |
| Spot | 60–90% | Nenhum | Total (pode perder capacidade) | Não |
A tabela reflete as faixas de desconto publicadas pela AWS em maio de 2026. Os descontos reais variam por tipo de instância, região e opção de pagamento.
Quais custos ocultos se somam além do preço da instância?
A tarifa da instância raramente conta a história inteira. Armazenamento EBS, transferência de dados, load balancers e cobranças de IPv4 público podem somar 40–50% sobre as horas de computação em um workload típico voltado para a internet.
Armazenamento EBS (o block storage padrão do EC2) começa em US$ 0,08/GB-mês para volumes gp3. Um volume raiz modesto, de 100 GB por instância, acrescenta US$ 8/mês por instância, ou US$ 960/ano em uma frota de 10 instâncias. Snapshots custam mais US$ 0,05/GB-mês em cima disso.
Transferência de dados pega os times de FinOps de surpresa mais do que qualquer outro item da fatura. O egress de internet a partir de US East custa US$ 0,09/GB depois dos 100 GB/mês gratuitos. Um workload puxando 5 TB/mês de egress paga cerca de US$ 450/mês só em taxas de transferência. O tráfego inter-AZ custa US$ 0,01/GB em cada direção (US$ 0,02/GB ida e volta), uma surpresa comum em deployments multi-AZ com Kubernetes, onde o tráfego do service mesh cruza zonas de disponibilidade o tempo todo.
Endereços IPv4 públicos agora custam US$ 0,005/hora (~US$ 3,60/mês cada um) desde a mudança de preço de fevereiro de 2024. A cobrança vale para todo IPv4 público em uso em instâncias EC2, load balancers, NAT gateways e endpoints RDS.
NAT Gateways agravam o problema da transferência de dados: US$ 0,045/hora por AZ (~US$ 32,40/mês), mais US$ 0,045/GB processado, em cima das taxas padrão de egress para tráfego destinado à internet.
Considere um cenário realista: 10 instâncias m7i.large com 100 GB de gp3 cada, um ALB, 12 endereços IPv4 públicos, 5 TB de egress mensal e 500 GB de tráfego inter-AZ. Esse ambiente custa cerca de US$ 1.380/mês. As horas de instância respondem por US$ 736 desse total. Os custos auxiliares representam 47% da fatura.
Preços vigentes em maio de 2026. Consulte a página de preços do AWS EBS e a página de preços de transferência de dados do EC2 para tarifas atualizadas.
Como fazer right-sizing das instâncias com base na utilização?
Right-sizing é casar a capacidade da instância com a demanda real do workload. Continua sendo o caminho mais rápido para cortar gastos com EC2 sem precisar de commitments nem mudanças arquiteturais.
O próprio whitepaper de right-sizing da AWS define um limiar claro: qualquer instância com utilização máxima de CPU e memória abaixo de 40% ao longo de quatro semanas é candidata a downsizing (AWS). Reduzir pela metade uma instância superdimensionada economiza cerca de 50% nessa instância, sem impacto de desempenho, desde que a utilização caiba na nova capacidade.
O AWS Compute Optimizer automatiza essa análise com machine learning, mirando CPU P99.5 em 80% de utilização sustentada. O motor de rightsizing do Cost Explorer marca como ociosas as instâncias com utilização máxima de CPU igual ou abaixo de 1% e recomenda a terminação.
Configurações de segurança também podem mexer nos custos. Criptografar volumes EBS com AWS KMS adiciona uma pequena cobrança por requisição, e rodar instâncias com dedicated tenancy (às vezes exigidas por compliance) custa bem mais do que tenancy compartilhada. Os times de FinOps devem incluir esses impactos de preço ligados a compliance nos cálculos de right-sizing, em vez de tratar o gasto com segurança como overhead fixo.
Para estratégias contínuas de otimização, o right-sizing precisa ser contínuo, não trimestral. Os padrões de workload mudam conforme as aplicações evoluem, e uma instância bem dimensionada hoje pode estar superprovisionada em poucas semanas.
Quais estratégias de otimização de custos do EC2 os times de FinOps devem priorizar?
A McKinsey constatou que práticas eficazes de FinOps reduzem custos de nuvem em 20–30%, com base na análise de US$ 3 bilhões em faturas reais de nuvem (McKinsey). Essa economia não vem de uma única alavanca. Exige uma abordagem de portfólio que combine descontos baseados em commitment, adoção de Spot e right-sizing contínuo.
Como avaliar estratégias de compra de reserved instances?
A FinOps Foundation recomenda avaliar compras de commitment pela Effective Savings Rate (ESR), e não pelo percentual de desconto de vitrine. A ESR mede a economia realizada menos o custo dos commitments não utilizados, dividida pelo gasto equivalente em on-demand. A ESR média de AWS Compute fica em torno de 26%, bem abaixo dos máximos teóricos de 66–72%, porque a maioria das organizações carrega algum estoque de commitment ocioso (FinOps Foundation).
Um portfólio defensável começa cobrindo o baseline previsível — o menor vale de utilização ao longo do mês — com EC2 Instance Savings Plans ou RIs Standard, que oferecem os descontos mais profundos. Em cima disso, acrescente Compute Savings Plans para workloads variáveis em estado estável, já que se aplicam entre famílias, regiões e computação serverless. Deixe workloads burstos ou incertos no on-demand até que a utilização estabilize o suficiente para entrar em previsão.
As ferramentas certas de otimização de custos de nuvem automatizam a análise de cobertura e avisam quando a utilização de commitments cai abaixo dos limites-alvo.
Quando usar Spot instances em workloads sensíveis a custo?
O Spot funciona para qualquer workload que tolere interrupção. Jobs em batch, pipelines de CI/CD, processamento de dados, servidores de API stateless atrás de auto-scaling groups e microsserviços em contêineres com graceful shutdown se encaixam bem.
A chave para usar Spot com confiabilidade: diversificar entre tipos de instância e zonas de disponibilidade. Use seleção de instâncias baseada em atributos para que o EC2 escolha dentro do maior pool de capacidade possível. O Spot Instance Advisor da AWS mostra a frequência de interrupção por tipo de instância, com a maioria das famílias de uso geral e otimizadas para computação em US East rodando abaixo de 5% de taxa de interrupção.
Combinar Spot com fallback em on-demand ou Savings Plan dentro de um auto-scaling group cria uma tarifa híbrida. Uma frota rodando 70% Spot e 30% on-demand pode chegar a 45–60% de economia efetiva em relação a 100% on-demand.
Como tornar os preços do AWS EC2 previsíveis e defensáveis?
O relatório State of FinOps 2025 da FinOps Foundation, que cobre US$ 69 bilhões em gasto com nuvem entre 861 respondentes, identificou que redução de desperdício e otimização de workloads seguem como prioridade número 1 para 50% dos profissionais (FinOps Foundation). Nessa escala, mesmo melhorias marginais na gestão de custos do EC2 viram valores significativos.
Otimização manual não escala. Revisões trimestrais de right-sizing, controle de RIs em planilhas e adoção reativa de Spot deixam economia na mesa entre um ciclo de revisão e outro. A análise da McKinsey sobre US$ 3 bilhões em faturas de nuvem encontrou 10–20% de economia adicional inexplorada na maioria das organizações, inclusive nas que já tinham programas de FinOps estabelecidos (McKinsey).
O FlexSave for Compute da DoiT automatiza os descontos baseados em commitment, analisando continuamente os padrões de uso do EC2 e aplicando o mix ideal de Savings Plans e capacidade reservada sem intervenção manual. A plataforma de Procurement da DoiT consolida o billing entre contas AWS e entrega a visibilidade de custo de que as ferramentas de AWS FinOps precisam para tornar o gasto com EC2 previsível, em vez de reativo.
Perguntas frequentes sobre preços do AWS EC2
Quanto custa uma instância EC2 por mês?
O custo mensal depende do tipo de instância, da região e do modelo de preço. Uma m7i.large de uso geral em US East custa cerca de US$ 73,58/mês on-demand (730 horas × US$ 0,1008/hora). Reserved Instances e Savings Plans reduzem esse valor em 40–72%, dependendo do prazo e da opção de pagamento. Some armazenamento EBS, transferência de dados e outras cobranças auxiliares para ter o quadro completo.
Quais modelos de preço a AWS oferece para o EC2?
A AWS oferece quatro opções principais de preço para o EC2: On-Demand (sem compromisso, flexibilidade total), Reserved Instances (compromisso de 1 ou 3 anos, até 72% de desconto), Savings Plans (compromisso de 1 ou 3 anos, até 66% com mais flexibilidade entre famílias e regiões) e Spot Instances (sem compromisso, 60–90% de desconto, com possibilidade de interrupção).
Por que a minha fatura do EC2 fica acima do preço da instância?
As faturas do EC2 incluem muito mais do que horas de instância. Armazenamento EBS, transferência de dados (em especial o egress de internet a US$ 0,09/GB), Elastic Load Balancers, endereços IPv4 públicos (US$ 0,005/hora desde fevereiro de 2024), NAT Gateways e snapshots acrescentam linhas à fatura. Em workloads voltados à internet, esses custos auxiliares podem representar 40–50% do gasto total relacionado ao EC2.
Qual Effective Savings Rate os times de FinOps devem mirar?
A ESR média de AWS Compute gira em torno de 26%. Práticas maduras de FinOps miram 30–40% ou mais, mantendo alta utilização de commitments, cobrindo a carga de baseline com os instrumentos de maior desconto e medindo a economia contra o gasto equivalente em on-demand, e não pelo percentual de desconto de vitrine.
Descubra como o FlexSave for Compute pode ajudar a otimizar seus custos com AWS EC2 com ferramentas práticas e confiáveis, feitas para times de nuvem modernos. Fale com a gente e veja como a DoiT pode tornar o seu gasto com EC2 previsível.