Duas instâncias idênticas, mesmo tipo, mesma AZ, mesmo sistema operacional, podem custar valores completamente diferentes por hora. A diferença não está na máquina, está em como você se compromete a usá-la. Tipo de instância responde "qual é o meu gargalo". Forma de pagamento responde uma pergunta diferente: quão previsível é a minha carga, e quanto risco eu aceito correr em troca de desconto?
O mapa geral
| Opção | Desconto vs. On-Demand | Compromisso | Garante capacidade? | Pode ser interrompida? |
|---|---|---|---|---|
| On-Demand | Nenhum | Nenhum | Não | Não |
| Reserved Instances | Até ~72% | 1 ou 3 anos | Sim, se regional/zonal | Não |
| Savings Plans | Até ~72% | 1 ou 3 anos | Não | Não |
| Spot | Até ~90% | Nenhum | Não | Sim, com 2 min de aviso |
| Dedicated Host | Nenhum (custo extra) | Opcional | Sim | Não |
| Dedicated Instance | Nenhum (custo extra) | Nenhum | Não | Não |
| Capacity Reservation | Nenhum | Nenhum | Sim | Não |
Repare no padrão: desconto e garantia de capacidade não vêm da mesma coisa. Um vem de compromisso de tempo (RI, Savings Plans) ou de aceitar interrupção (Spot). O outro vem de reservar o hardware, o que por si só não é mais barato. Confundir os dois é o erro mais comum ao montar a estratégia de custo.
On-Demand: o preço de não decidir nada
Você paga por segundo, sem compromisso, no valor de tabela publicado pela AWS. É a base de comparação de tudo o mais nesta lista.
Quando usar:
- Carga nova, ainda sem histórico de uso medido
- Workload de curtíssimo prazo, tipo prova de conceito ou ambiente de teste esporádico
- Picos que você não consegue prever com antecedência suficiente para reservar
Quando não usar:
- Carga estável rodando 24/7 há meses. Nesse ponto, pagar On-Demand é literalmente deixar desconto na mesa, porque o histórico já existe para embasar um compromisso.
Reserved Instances: comprometer a máquina
RI é um desconto atrelado a um tipo de instância específico (ou família, dependendo do escopo escolhido) por 1 ou 3 anos. O pagamento pode ser All Upfront (desconto maior), Partial Upfront ou No Upfront (desconto menor, mas sem capital adiantado).
Existem dois sabores:
- Standard RI: o maior desconto da lista, mas rígida. Não dá para trocar de família de instância no meio do contrato. Se a carga migrar de
m6iparac6i, essa reserva sobra sem uso. - Convertible RI: desconto menor que a Standard, mas permite trocar tipo de instância, sistema operacional e tenancy durante o período, desde que o novo valor seja igual ou maior.
Escopo importa: uma RI zonal garante capacidade reservada naquela AZ específica, além do desconto. Uma RI regional perde a garantia de capacidade, mas ganha flexibilidade entre AZs da região e aplica o desconto automaticamente às instâncias correspondentes que já estão rodando.
Quando usar:
- Base de carga estável e previsível por 1 a 3 anos, como o piso mínimo de tráfego que a aplicação nunca fica abaixo
- Quando garantir capacidade numa AZ específica importa (RI zonal)
Quando não usar:
- Carga que muda de tipo de instância com frequência, ou que você não tem certeza que vai existir da mesma forma daqui a um ano
Savings Plans: comprometer o gasto, não a máquina
Savings Plans resolve a rigidez da RI Standard trocando o compromisso: em vez de reservar um tipo de instância, você se compromete com um valor fixo de gasto por hora (ex: US$ 10/hora) por 1 ou 3 anos. A AWS aplica o desconto a qualquer uso que caiba dentro desse valor, e o que passar disso é cobrado On-Demand.
Dois tipos:
- Compute Savings Plans: o mais flexível de toda a lista. O desconto se aplica independente de família de instância, tamanho, região, sistema operacional ou tenancy, e cobre até Fargate e Lambda. Desconto um pouco menor que o EC2 Instance Savings Plan.
- EC2 Instance Savings Plans: desconto maior (próximo da RI Standard), mas restrito a uma família de instância dentro de uma região específica. Dentro dela, pode variar tamanho, SO e tenancy livremente.
Quando usar:
- Ambiente com múltiplos serviços de compute (EC2 + Fargate + Lambda) rodando ao mesmo tempo, onde faz sentido um desconto guarda-chuva → Compute Savings Plans
- Carga estável numa família de instância, mas onde o tamanho exato ainda pode mudar → EC2 Instance Savings Plans
Quando não usar:
- Quando o que importa é garantir capacidade física disponível, não desconto. Savings Plans não reserva nada, só aplica desconto a um gasto. Numa AZ lotada, isso não impede um
InsufficientCapacityError.
A confusão mais comum: RI e Savings Plans não se somam para o mesmo uso, é uma ou outra cobrindo aquela hora de instância. A pergunta que decide entre elas não é "qual desconta mais", é "eu preciso que a AWS reserve a máquina, ou só preciso que ela me cobre menos?".
Spot: usar a capacidade que sobra
Spot vende a capacidade ociosa da AWS com desconto de até 90%. A contrapartida: a AWS pode retomar a instância a qualquer momento, com 2 minutos de aviso via evento no metadata da instância e no EventBridge.
O preço Spot varia com oferta e demanda de cada tipo de instância em cada AZ, mas ao contrário do modelo antigo de leilão, hoje você não define um lance: paga o preço Spot vigente, e a instância só é interrompida por falta de capacidade, nunca por alguém "dar lance maior".
Na prática, Spot funciona bem quando combinado com:
- Auto Scaling Groups com múltiplos tipos de instância elegíveis, para o grupo migrar automaticamente se um tipo específico ficar escasso
- Checkpoints frequentes, para o trabalho perdido numa interrupção ser pequeno
- EC2 Fleet / Spot Fleet, para diversificar entre vários tipos e AZs ao mesmo tempo e reduzir a chance de interrupção simultânea de tudo
Quando usar:
- Processamento em lote, renderização, jobs de CI/CD, treinamento de ML, processamento distribuído (EMR/Spark) e qualquer workload stateless que se recupera sozinho de uma instância sumindo
- Frotas de Auto Scaling que toleram perder e repor instâncias sem impacto perceptível
Quando não usar:
- Banco de dados de produção, ou qualquer processo com estado local que não sobrevive a uma interrupção abrupta
- Qualquer carga onde 2 minutos de aviso não é tempo suficiente para reagir
Dedicated Host e Dedicated Instance: quando o hardware físico importa
Nenhuma das duas dá desconto. As duas custam mais que uma instância equivalente compartilhada, porque você paga por isolamento físico, não por economia.
- Dedicated Host: um servidor físico inteiro dedicado à sua conta, com visibilidade e controle sobre exatamente qual core e socket cada instância ocupa. É a única forma de rodar licenciamento por socket/core (ex: BYOL de Windows Server, SQL Server) de forma compatível, e é o único caminho para instâncias
mac. - Dedicated Instance: roda em hardware dedicado à sua conta, mas sem visibilidade sobre o posicionamento exato, e ainda pode compartilhar o host físico com outras instâncias dedicadas da mesma conta.
Quando usar:
- Exigência de compliance que obriga isolamento físico de outras contas AWS
- Licença de software atrelada a core/socket físico, que exige saber exatamente onde a instância roda (Dedicated Host)
Quando não usar:
- Sem requisito explícito de compliance ou licenciamento. O custo extra não compra desempenho nenhum, só isolamento que ninguém está pedindo.
On-Demand Capacity Reservations: comprar capacidade sem comprar tempo
Aqui a lógica se inverte: você reserva capacidade de um tipo de instância numa AZ específica, sem se comprometer com 1 ou 3 anos, e pode cancelar quando quiser. Mas paga o preço On-Demand cheio esteja usando a capacidade reservada ou não.
Isso resolve um problema que nem RI nem Savings Plans resolvem sozinhos: nenhum dos dois garante que a AWS terá a máquina fisicamente disponível na hora que você precisar, exceto a RI zonal. Capacity Reservation é essa garantia isolada do desconto.
Quando usar:
- Evento com data marcada, como lançamento de produto ou pico sazonal conhecido, onde ficar sem capacidade na hora H é inaceitável
- Plano de disaster recovery, para garantir que a região de contingência tem capacidade de fato disponível
- Combinada com Savings Plans, para ter desconto e garantia de capacidade ao mesmo tempo, já que uma cobre o preço e a outra cobre a disponibilidade
Quando não usar:
- Sozinha, sem nenhum desconto por cima. Você paga o preço cheio de qualquer forma, então usá-la sem necessidade real de garantia de capacidade é desperdício puro.
Como as opções se combinam na prática
Nenhuma empresa madura usa uma opção só. O padrão comum é em camadas:
- Base previsível (o piso que a carga nunca fica abaixo) coberta por Savings Plans ou RI, porque esse uso é certo de qualquer forma.
- Picos tolerantes a falha (batch, processamento assíncrono, CI/CD) cobertos por Spot, aproveitando o desconto máximo onde a interrupção não dói.
- O que sobra, imprevisível ou de curtíssimo prazo, em On-Demand como fallback.
- Capacity Reservation só entra quando existe um evento específico onde faltar máquina custa mais caro que reservar.
Essa camada é ortogonal ao tipo de instância: você primeiro decide a família certa para o gargalo, depois decide como pagar por ela. Misturar as duas decisões numa só costuma levar a comprar RI da família errada só porque "estava com desconto".
Trade-offs
| Ganha | Paga |
|---|---|
| RI / Savings Plans: até 72% de desconto | Compromisso de 1-3 anos, risco de ficar preso a uma carga que muda |
| Spot: até 90% de desconto | Interrupção com 2 min de aviso, exige workload tolerante a falha |
| Compute Savings Plans: flexibilidade total entre serviços | Desconto menor que EC2 Instance Savings Plan |
| RI zonal / Capacity Reservation: garantia de capacidade | Sem desconto (Capacity Reservation) ou rigidez de AZ (RI zonal) |
| Dedicated Host: controle total de posicionamento físico | Custo mais alto, sem ganho de performance |
Referências
- AWS. Amazon EC2 Pricing. Visão geral de todos os modelos de preço.
- AWS. Reserved Instances. Diferenças entre Standard e Convertible, e escopo zonal vs. regional.
- AWS. Savings Plans User Guide. Como o compromisso de gasto por hora funciona.
- AWS. Spot Instances. Como o preço Spot é definido e como funciona o aviso de interrupção.
- AWS. On-Demand Capacity Reservations. Como reservar capacidade sem compromisso de tempo.