Savings Plans ou Reserved Instances: qual escolher para o seu cluster EKS

As duas opções dão desconto em troca de compromisso de 1 ou 3 anos, e por isso parecem equivalentes. Para um cluster EKS, a diferença está em o quanto você fica preso a uma família de instância e em se você precisa de capacidade garantida.

O que cada um é

• Compute Savings Plans são um compromisso de gasto por hora. Valem para EC2 de qualquer família, tamanho, região, sistema operacional e tenancy, além de Fargate e Lambda. É o mais flexível.
• EC2 Instance Savings Plans também são compromisso de gasto por hora, mas ficam presos a uma família de instância em uma região. Em troca, o desconto divulgado pela AWS é maior.
• Reserved Instances (RI) são um compromisso sobre atributos de instância. As Standard têm o maior desconto e atributos fixos. As Convertible permitem trocar atributos, com desconto menor.

Os percentuais variam por instância, região, prazo e forma de pagamento (tudo adiantado, parcial ou sem adiantamento). Confira a tabela da AWS antes de decidir.

As diferenças que importam no dia a dia

Um ponto que muda a decisão: Savings Plans não reservam capacidade. Se você precisa de garantia de que a instância existe naquela zona, isso se resolve com uma reserva de capacidade On-Demand, que pode ser combinada com um plano. Confirme as regras atuais na documentação da AWS.

Qual faz sentido com Karpenter

O Karpenter escolhe o tipo de instância na hora, e o mix muda conforme preço, disponibilidade e as suas regras de NodePool. Um compromisso preso a uma família funciona mal nesse cenário: se o cluster passar a usar outra família, o desconto deixa de cobrir o uso.

Por isso, para a base estável de um cluster EKS, o Compute Savings Plan costuma ser o ponto de partida. Ele acompanha mudanças de família, e também uma migração para Graviton, sem que você precise recomprar nada. O EC2 Instance Savings Plan só compensa se a família estiver estável pelo prazo todo.

Onde as Reserved Instances ainda aparecem

Alguns serviços gerenciados, como bancos de dados e caches, tradicionalmente usam Reserved Instances em vez de Savings Plans. A AWS tem ampliado a cobertura dos planos, então confirme na página de preços se o serviço que você usa já é coberto. Se não for, RI continua sendo o caminho para aquele gasto.

Uma ordem que funciona

1. Dimensione primeiro. Compromisso sobre requests inflados cristaliza desperdício por 1 a 3 anos. Use o rightsizing-check.
2. Defina o que vai para Spot. Spot não consome Savings Plans, então o que migrar sai da base comprometida. Veja como combinar Spot e Savings Plans.
3. Comprometa só a base estável, o que roda 24 por 7 e não vai para Spot. Comprometer o pico é o erro clássico.
4. Prefira Compute Savings Plans para o EKS e reserve RIs para o que os planos não cobrem.
5. Compre em camadas. Em vez de um compromisso único, compre em etapas ao longo do tempo, para não ficar preso a uma foto antiga do cluster.
6. Revise a cobertura e a utilização a cada trimestre, e antes de qualquer migração de arquitetura.

Erros comuns

• Comprar antes de dimensionar.
• Comprar um EC2 Instance Savings Plan e depois migrar para Graviton, o que deixa o compromisso apontando para uma família que você não usa mais.
• Mover cargas para Spot sem rever o compromisso, e continuar pagando por um plano subutilizado.
• Comprometer um valor baseado no mês de pico.
• Esquecer o prazo: 3 anos só se justifica para uma base muito estável.

Para estimar

O estimador de Savings Plans mostra o efeito de diferentes níveis de cobertura sobre a sua conta, e a calculadora de economia soma rightsizing, Spot e Graviton. Os números são estimativas: a medição real depende dos seus workloads. Se quiser que eu monte a estratégia de compromisso no seu ambiente, o assessment de eficiência é o ponto de partida.