Reserved Instances e Savings Plans

Reserved Instances e Savings Plans são instrumentos de compromisso de uso: a organização aceita gastar um valor definido, por hora ou por dólar, durante um prazo de um ou três anos, e o provedor troca essa previsibilidade por descontos que tipicamente chegam a 72% sobre o preço sob demanda. O trade-off é direto e financeiro: flexibilidade na hora de consumir de um lado, custo unitário menor do outro. A família completa de modelos de consumo tem quatro escalões, on-demand para elasticidade total, Spot para capacidade interrompível com desconto ainda maior, e os dois compromissos para a carga estável do dia a dia. Escolher bem a mistura é a decisão de FinOps de maior impacto absoluto em qualquer conta de nuvem relevante, pois ela opera sobre a parcela que roda 24 horas por dia, todos os dias. O arquivo cobre a mecânica de cada instrumento, as regras de aplicação, o papel do Spot e a estratégia de carteira que equilibra compromisso com risco de overcommitment.

Conceito e taxonomia

A Reserved Instance não é uma máquina reservada fisicamente, e sim um desconto aplicado ao consumo que casa com os atributos da compra: família de instância, tamanho, sistema operacional, tenancy e região. Ela existe em três escopos, regional com flexibilidade de tamanho dentro da família, zonal que ancora em zona e adiciona capacidade reservada, e no modelo compartilhado de conta via consolidated billing. A Savings Plan generaliza o conceito trocando atributos por dinheiro: o compromisso é um valor em dólar por hora, e qualquer consumo equivalente recebe o desconto, seja EC2, Fargate ou Lambda.

A hierarquia de flexibilidade é a chave de leitura da família toda. O Compute Savings Plan é o mais flexível, cobrindo qualquer mudança de família, tamanho, SO ou região, desde que o valor por hora seja cumprido. O EC2 Instance Savings Plan restringe a uma família na mesma região, com desconto um pouco maior. A Reserved Instance é a menos flexível em atributos, mas carrega propriedades que os Savings Plans não têm, como escopo zonal com capacidade garantida e aplicação a serviços que não aceitam savings plans.

Dois detalhes de mecânica confundem iniciantes e valem fixação. Primeiro, o compromisso é financeiro, e não uma reserva de recurso: o desconto segue o consumo, e nada garante que haverá capacidade física disponível em zona cheia, com a exceção da RI zonal. Segundo, a modificabilidade tem limites, pois Savings Plans não podem ser cancelados nem vendidos, e Reserved Instances regionais podem ser trocadas de atributos dentro da família, enquanto as zonais podem ser movidas entre zonas da mesma região. Entender esses limites antes de comprar evita a surpresa de um compromisso que a mudança de arquitetura deixou órfão.

• On-demand: preço cheio, sem compromisso, cancela a qualquer momento, baseline de comparação de todos os descontos.
• Reserved Instance: desconto por atributos de instância, prazos de 1 ou 3 anos, pagamento integral, parcial ou sem adiantamento.
• Compute Savings Plan: desconto por valor horário comprometido, flexível entre todos os serviços de computação.
• EC2 Instance Savings Plan: desconto maior, porém preso a família e região escolhidas.
• Spot: capacidade excedente com desconto de até 90%, interrompível com aviso de dois minutos.

O problema que resolve

Carga de produção tem uma fração estável e previsível: os serviços que rodam de madrugada, nos fins de semana e nas campanhas. Pagar essa fração inteira a preço on-demand é pagar o preço da flexibilidade por capacidade que nunca é flexível na prática, e essa ineficiência escala linearmente com o tamanho da conta. O compromisso resolve o problema transferindo risco contratado: a empresa assume gastar, o provedor devolve desconto, e a conta estável cai em dezenas de por cento sem mudar uma linha de infraestrutura.

O problema oposto também é real, e o padrão resolve os dois lados. Comprometer demais cria desperdício inelástico, pois dólares comprados não são devolvidos, e a fatura de compromisso vira custo fixo dentro do custo variável. A disciplina do padrão é exatamente a gestão dessa fronteira: comprometer a base mensurável e manter flexível a parte que cresce, oscila ou morre rápido.

Há ainda o risco silencioso de desalinhamento entre quem decide e quem paga. Compromissos são decisões de câmbio, prazo e caixa, mas costumam nascer de discussões técnicas isoladas, e o resultado é uma carteira que otimiza desconto e perde flexibilidade que o negócio precisaria no trimestre seguinte. Por isso a compra madura é sempre decisão compartilhada entre engenharia e finanças, com a curva de consumo como árbitro.

Funcionamento dos compromissos

A aplicação do desconto é automática e por prioridade. Ao fim de cada hora, o consumo de cada conta é confrontado com a carteira de compromissos existente, primeiro com Savings Plans e depois com Reserved Instances regionais, e o restante é cobrado a on-demand. Em contas vinculadas de uma organização, o desconto flui para a conta que tiver consumo compatível, o que torna a carteira um ativo compartilhado e a recomendação de compra um exercício de nível de organização, e não de time.

# Recomendação de compra de Savings Plan com base no histórico
aws savingsplans-recommendation get-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days THIRTY_DAYS

# Cobertura e utilização atuais da carteira (visão consolidada)
aws ce get-savings-plans-utilization \
  --time-period Start=2025-05-01,End=2025-05-31 \
  --filter '{"Dimensions":{"Key":"SAVINGS_PLANS_TYPE","Values":["Compute"]}}'

Os dois números que governam a gestão da carteira são utilização e cobertura. Utilização mede quanto do compromisso comprado está sendo efetivamente consumido, e o alvo saudável fica acima de 95%, pois abaixo disso há dólar comprado dormindo. Cobertura mede quanto do consumo elegível está sendo atendido por compromissos, e o alvo típico fica entre 70% e 85%, deixando o topo da curva flexível para picos, experimentos e crescimento.

O quadro abaixo consolida as diferenças práticas entre os três instrumentos de compromisso, que é a consulta mais frequente no dia a dia de FinOps.

Em Azure e GCP o desenho é análogo com nomes distintos: reservas de VM e Savings Plans no Azure, e committed use discounts e sustained use discounts no GCP, sendo que este último aplica desconto automático por uso contínuo sem compromisso formal. A mecânica de gestão, comprometer a base e medir cobertura e utilização, se transpõe diretamente entre provedores.

Escolha de compromisso por previsibilidade

A decisão de compra começa pela curva de consumo dos últimos 30 a 90 dias, e não pelo catálogo de preços. A regra prática é comprometer o piso da curva, a carga que existe mesmo no domingo de madrugada, e nunca o pico. Uma carga com base de 10 mil dólares por hora e picos de 16 mil suporta compromisso de cerca de 10 mil, e o excedente de 6 mil fica em on-demand até que a base cresça e se confirme por semanas.

• Prazo de um ano: adequado para cargas em evolução, produtos jovens e ambientes cuja arquitetura pode mudar de família de instância.
• Prazo de três anos: desconto máximo, justificado por bases maduras, contratos de fornecedores e workloads de ciclo longo, como bancos de dados.
• Sem adiantamento: custo mensal sem capital antecipado, desconto um pouco menor, adequado quando caixa importa mais que otimização marginal.
• Parcial e integral: adiantamento maior compra desconto maior, decisão de tesouraria tanto quanto de engenharia.

A previsibilidade também tem fonte organizacional, e não apenas estatística. Contratos com SLA de disponibilidade, workloads regulados com ciclo de vida longo e ambientes de disaster recovery dimensionados por norma são candidatos a compromissos agressivos, porque o risco de a carga desaparecer é baixo. No extremo oposto, produtos em launch, times de growth e infraestrutura de experimentação devem permanecer on-demand até que a curva estabilize. Classificar cada workload em uma dessas duas pontas antes de olhar preço é o que evita comprar compromisso para carga que será desligada no trimestre seguinte.

Spot para cargas interrompíveis

O Spot ocupa o extremo oposto da tabela de descontos e exige um contrato de software diferente: a aplicação precisa tolerar interrupção com dois minutos de aviso. Três classes de carga adotam Spot com segurança e retorno alto: processamento em lote e render, filas de trabalho com reprocessamento idempotente, e camadas horizontais de computação tolerante a falhas, como clusters de inferência com réplica suficientes. O desenho correto combina grupos de capacidade diversificados, spot fleet ou nodegroups mistos, e checkpointing quando o trabalho é longo.

Cargas que não toleram interrupção nenhuma, como o primário de um banco transacional, ficam fora do Spot por princípio, e forçar essa fronteira transforma economia em incidente. O uso maduro do Spot aparece nos números: frações relevantes da computação em lote rodando a 20% do preço on-demand, com taxa de interrupção monitorada como métrica de primeira classe.

# Grupo de nós EKS com mistura on-demand e Spot (nodegroups)
nodegroups:
  base-critica:
    instanceTypes: [m6i.xlarge]        # on-demand para carga sensível
    desiredCapacity: 3
    labels: { capacidade: on-demand }
  batch-spot:
    instanceTypes: [m6a.xlarge, m5a.xlarge, m6g.xlarge]  # diversificação
    capacityType: SPOT                  # interrompível com aviso de 2 min
    desiredCapacity: 6
    labels: { capacidade: spot }
    taints: { trabalho: batch:NoSchedule }  # só batch agenda aqui

A diversificação de tipos no grupo Spot é o detalhe que sustenta a disponibilidade, pois a capacidade interrompível é um mercado e pools estreitos oscilam de preço e de taxa de interrupção. Combinar três ou mais famílias e, quando possível, famílias de arquiteturas distintas dá ao orquestrador opções de reposição quando um pool esgota.

Estratégia de mistura

A carteira madura segue o desenho de camadas: base estável em compromissos de longo prazo, pico e crescimento recente em on-demand, e batch interrompível em Spot. A regra de ouro é nunca comprar compromisso para carga que ainda está sendo avaliada, e revisar a carteira mensalmente com base na cobertura real. O quadro a seguir resume o papel de cada camada na mistura.

A evolução da carteira é incremental: cobrir a base medida, observar por um ciclo, subir o compromisso quando a cobertura real confirma, e usar o relatório de utilização como guarda de que nenhum dólar comprado ficou ocioso. Compras de três anos sem histórico equivalente são apostas, e apostas não entram na carteira de FinOps.

O acompanhamento da mistura se apoia em três alarmes contínuos. Cobertura abaixo do alvo indica dinheiro deixado na mesa todos os dias, pois consumo elegível rodando a preço cheio. Utilização abaixo do alvo indica compromisso mal dimensionado, que merece revisão antes de qualquer compra nova. E preço médio efetivo por hora, o total pago dividido pelas horas consumidas, é o número único que resume se a mistura está melhorando ou piorando mês a mês.

Erros comuns

• Comprar pelo pico: compromissos dimensionados pela demanda máxima, que geram utilização baixa e desperdício contratado irreversível.
• Carteira por time: cada equipe compra a própria RI, fragmentando aplicação de desconto em vez de consolidar no nível da organização.
• Ignorar utilização: comprar cobertura nova com a utilização da atual abaixo de 90%, empilhando dólar ocioso sobre dólar ocioso.
• Spot no lugar errado: primário de banco transacional ou único nó de um serviço crítico em capacidade interrompível.
• Compromisso como projeto: comprar uma vez e revisar em um ano, quando a carteira exige cadência mensal de cobertura e utilização.
• Esquecer serviços fora do alcance: assumir que o desconto cobre tudo, quando cargas de contêiner serverless, por exemplo, precisam do Compute Savings Plan específico.
• Descontos sem dono: carteira comprada, mas ninguém responsável por utilização, cobertura e renovação, que então apodrece em silêncio.

Boas práticas

Estabeleça a rotina mensal de três números: cobertura atual, utilização atual e recomendação de compra da ferramenta, nessa ordem, e formalize a decisão de compra em comitê com visão de organização inteira. Prefira Compute Savings Plans como instrumento padrão para frotas em transformação, reservando RI zonal para os casos que exigem capacidade garantida. Marque com tag a intenção de cada workload, estável, pico ou interrompível, pois a mistura correta começa pela classificação correta. Por fim, trate o desconto de compromisso como alavanca financeira negociável em volumes altos, pois contratos de grande porte têm margem de conversa que nenhuma otimização técnica consegue igualar.

Sincronize as compras com o calendário de orçamento da empresa, comprando no início do ciclo quando a visibilidade da demanda anual é maior, e mantenha o histórico de decisões com a curva que justificou cada compromisso, pois é esse registro que transforma a renovação de um ano em cálculo e não em memória.

O critério de escolha do instrumento é a previsibilidade real da carga combinada com a governança da organização, e não o desconto máximo da tabela. Carteiras maduras de FinOps mantêm cobertura alta na base com utilização acima de 95%, pico em on-demand sem culpa e batch em Spot com métrica de interrupção visível, e revisitam o desenho a cada ciclo de orçamento.