Spot ou Savings Plans no Kubernetes: como combinar os dois sem desperdiçar compromisso

"Spot ou Savings Plans?" costuma ser tratada como escolha. Na prática, são ferramentas para partes diferentes do mesmo cluster, e o erro mais caro é usar as duas sobre a mesma carga.

O que cada um é

• On-Demand é o preço de tabela, sem compromisso.
• Spot usa capacidade ociosa da AWS com desconto grande, que a AWS divulga como de até 90% sobre o On-Demand. Em troca, a instância pode ser retomada com um aviso de dois minutos.
• Savings Plans são um compromisso de gasto por hora, de 1 ou 3 anos. Os Compute Savings Plans valem para EC2 de qualquer família, região e sistema, além de Fargate e Lambda. Os EC2 Instance Savings Plans têm desconto maior e ficam presos a uma família em uma região. Os descontos que a AWS divulga chegam a cerca de 66% e 72%, respectivamente.

Os percentuais variam por tipo de instância, região e prazo. Confira a tabela da AWS antes de decidir.

O ponto que muda a conta

Savings Plans abatem uso On-Demand. Uma instância Spot não consome o seu compromisso. Se você comprar um plano e depois mover a carga para Spot, o plano passa a cobrir menos uso, mas a cobrança por hora continua. Você paga o compromisso sem receber o desconto, e o Spot não rende o que parecia.

É por isso que o estimador de custo de Spot pede a parcela já coberta por compromissos: o ganho líquido de mover uma carga para Spot é a diferença entre o desconto do Spot e o que o plano já dava.

A ordem que funciona

1. Dimensione primeiro. Compromisso sobre requests inflados cristaliza desperdício por 1 a 3 anos. Use o rightsizing-check.
2. Descubra o que tolera interrupção. Réplicas, probes, PodDisruptionBudgets e tempo de encerramento decidem. O spot-readiness transforma isso em um plano.
3. Comprometa a base estável, aquilo que roda 24 por 7 e não vai para Spot, e só essa parte. Comprometer o pico é o erro clássico.
4. Coloque o elástico e o tolerante em Spot, com várias famílias de instância e fallback para On-Demand, por exemplo com um NodePool do Karpenter.
5. Deixe o resto em On-Demand e revise a cobertura a cada trimestre.

Erros comuns

• Comprar o plano antes de dimensionar.
• Mover para Spot cargas que já estavam cobertas pelo plano, sem rever o compromisso.
• Usar uma única família de instância no Spot, o que aumenta as interrupções e o fallback para On-Demand.
• Tratar Spot como "de graça" e ignorar o esforço de engenharia, que o estimador reflete na faixa realista.
• Comprometer um valor alto demais porque o gasto do mês do pico parecia a média.

Um exemplo de raciocínio

Um cluster gasta US$ 20 mil por mês em computação. Metade tolera interrupção e 20% já roda em Spot. Dos 30% que ainda poderiam mudar, parte já está sob plano. O ganho de mover essa parcela é menor do que o desconto do Spot sugere, e a calculadora mostra quanto, sem prometer o número exato. A medição real depende dos seus workloads, e é o que um diagnóstico técnico entrega.

Para somar os efeitos de rightsizing, Spot, desligamento fora do horário e Graviton, use a calculadora de economia. Se quiser que eu monte a ordem de execução no seu ambiente, o assessment de eficiência é o ponto de partida.