Savings Plans vs Reserved Instances AWS (2026)

Por Que Você Precisa Entender os Modelos de Compromisso da AWS

Se você já leu nossos guias sobre Spot Instances e Right-Sizing, sabe que essas estratégias são pilares da otimização de custos na nuvem. Mas tem uma terceira peça do quebra-cabeça que, sozinha, pode representar a maior fatia de economia na sua fatura AWS: os modelos de compromisso — Savings Plans e Reserved Instances.

A lógica é bem direta: em troca de um compromisso de uso por 1 ou 3 anos, a AWS oferece descontos que chegam a 72% em relação ao preço On-Demand. Parece ótimo, né? E é — mas só se você souber escolher entre as opções disponíveis.

Segundo o relatório State of FinOps 2026, a otimização de compromissos continua sendo a prática mais adotada entre organizações com maturidade em FinOps, com mais de 80% das empresas usando alguma forma de reserva ou plano de economia. Ao mesmo tempo, o próprio relatório aponta que muitas organizações carregam compromissos "zumbis" — reservas que não correspondem mais à infraestrutura real e que ficam lá, drenando orçamento sem entregar valor nenhum.

Neste guia, vamos destrinchar cada modelo, incluindo os novíssimos Database Savings Plans que a AWS lançou em dezembro de 2024, com exemplos práticos usando AWS CLI e Terraform. O objetivo é que, ao final da leitura, você consiga montar uma estratégia de compromissos que maximize a economia sem comprometer a flexibilidade da sua operação.

O Que São Reserved Instances (RIs)

Vamos começar pelo modelo mais antigo. As Reserved Instances existem desde os primeiros anos da AWS e, apesar de os Savings Plans terem ganhado protagonismo nos últimos anos, as RIs continuam tendo seu lugar — especialmente em cenários específicos que vamos explorar daqui a pouco.

Um ponto crucial pra entender logo de cara: Reserved Instances não são instâncias físicas. São um desconto de faturamento aplicado automaticamente ao uso de instâncias On-Demand que correspondam à configuração reservada. Você não "liga" uma RI — o desconto simplesmente aparece na sua conta quando há uso compatível. Confesso que, quando comecei a trabalhar com AWS, essa distinção me confundiu bastante.

Standard Reserved Instances

As Standard RIs oferecem os maiores descontos entre todos os modelos de compromisso da AWS — até 72% em relação ao preço On-Demand. Em contrapartida, exigem o maior nível de comprometimento: você se amarra a uma família de instância, região, sistema operacional e tenancy específicos.

Características principais:

Desconto: até 72% (com pagamento total antecipado, 3 anos)
Escopo: Regional (aplica-se a qualquer AZ na região) ou Zonal (reserva capacidade em uma AZ específica)
Modificação: limitada — pode alterar AZ, escopo e tamanho dentro da mesma família
Marketplace: pode ser vendida no AWS Reserved Instance Marketplace se não for mais necessária

Essa última característica — a possibilidade de revenda — é o grande trunfo das Standard RIs. Se sua arquitetura mudar durante o período do compromisso, dá pra recuperar parte do investimento vendendo a reserva a outro cliente AWS. Nenhum outro modelo de compromisso oferece essa liquidez, e honestamente, é um diferencial que muita gente subestima.

Convertible Reserved Instances

As Convertible RIs sacrificam parte do desconto em troca de flexibilidade. Oferecem até 66% de economia e permitem que você troque a configuração da reserva — família de instância, sistema operacional, tenancy — durante o período de compromisso. A pegada é que o novo valor precisa ser igual ou superior ao original.

Características principais:

Desconto: até 66%
Flexibilidade: pode trocar por outras Convertible RIs de igual ou maior valor
Marketplace: não pode ser vendida
Ideal para: workloads que podem migrar entre famílias de instância ao longo do tempo

Escopo Regional vs. Zonal

Essa distinção é frequentemente ignorada, mas faz diferença na prática:

RIs Regionais: aplicam o desconto a qualquer instância compatível na região, com flexibilidade de tamanho dentro da família. Não reservam capacidade.
RIs Zonais: aplicam o desconto apenas em uma Zona de Disponibilidade específica. A vantagem? Reservam capacidade garantida nessa AZ — essencial pra workloads críticos que não podem falhar por falta de capacidade.

Esse ponto é fundamental. Se sua aplicação precisa de garantia de capacidade (pense num banco de dados de produção que simplesmente não pode ficar sem instância disponível), as RIs Zonais são a única opção. Nem Savings Plans, nem Spot Instances garantem capacidade.

O Que São Savings Plans

Lançados em 2019, os Savings Plans representaram uma mudança de paradigma na forma como a AWS oferece descontos por compromisso. Em vez de se comprometer com uma configuração específica de instância, você se compromete com um valor em dólares por hora de uso de computação. A AWS então aplica automaticamente as tarifas com desconto ao seu uso elegível.

Pode parecer uma diferença sutil, mas na prática é transformadora. Significa que você pode trocar tipos de instância, migrar pra Graviton, mover workloads entre regiões ou até migrar de EC2 para Lambda — tudo sem perder o desconto. Bem mais tranquilo, não?

Compute Savings Plans

São os mais flexíveis de todos os modelos de compromisso. Oferecem até 66% de desconto e se aplicam automaticamente ao uso de:

Amazon EC2 — qualquer família, tamanho, região, SO ou tenancy
AWS Fargate
AWS Lambda

Na prática, um único compromisso cobre sua infraestrutura de EC2, seus containers no Fargate e suas funções serverless no Lambda. Se amanhã você decidir migrar de EC2 pra containers, o desconto simplesmente se redistribui. É o tipo de flexibilidade que faz dormir mais tranquilo.

EC2 Instance Savings Plans

Oferecem descontos maiores — até 72% — mas em troca exigem compromisso com uma família de instância específica em uma região. Dentro dessa restrição, você ainda tem flexibilidade de tamanho, SO e tenancy.

Exemplo prático: se você compra um EC2 Instance Savings Plan para a família m6i em us-east-1, o desconto se aplica a qualquer instância m6i nessa região — seja m6i.large, m6i.xlarge ou m6i.4xlarge, rodando Linux ou Windows.

Database Savings Plans — A Novidade de 2026

Lançados no AWS re:Invent em dezembro de 2024, os Database Savings Plans estendem o modelo flexível de compromisso por gasto/hora para os serviços de banco de dados gerenciados da AWS. Essa é uma adição bem significativa porque, até então, a única forma de obter descontos em serviços como RDS e DynamoDB era através de Reserved Instances específicas pra cada serviço.

Serviços cobertos:

Amazon Aurora
Amazon RDS (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server)
Amazon DynamoDB
Amazon ElastiCache
Amazon DocumentDB
Amazon Neptune
Amazon Keyspaces
Amazon Timestream
AWS Database Migration Service (DMS)

A lista é bem abrangente. Basicamente, se é um banco de dados gerenciado da AWS, provavelmente está coberto.

Descontos por tipo de deployment:

Instâncias provisionadas: até 20% de economia
Deployments serverless: até 35% de economia
DynamoDB on-demand throughput: até 18%
DynamoDB provisioned capacity: até 12%

Quatro dimensões de flexibilidade:

Cross-region: mova workloads entre regiões AWS sem perder o desconto
Cross-engine: troque de motor de banco (ex: RDS MySQL pra Aurora PostgreSQL)
Cross-instance: mude famílias e tamanhos de instância livremente
Cross-service: alterne entre serviços cobertos (RDS, Aurora, DynamoDB, etc.)

Limitação importante: os Database Savings Plans oferecem apenas a opção No Upfront (sem pagamento antecipado) e estão disponíveis somente com compromisso de 1 ano. Ou seja, o desconto máximo acaba sendo menor do que o de uma RI de RDS com 3 anos e pagamento total antecipado. A proposta de valor aqui é flexibilidade, não desconto máximo — e dependendo do seu cenário, essa flexibilidade vale muito mais.

Tabela Comparativa Completa

Característica	Standard RI	Convertible RI	EC2 Instance SP	Compute SP	Database SP
Desconto máximo	até 72%	até 66%	até 72%	até 66%	até 35%
Compromisso	Instância específica	Instância (trocável)	Família + Região	$/hora	$/hora
Termos	1 ou 3 anos	1 ou 3 anos	1 ou 3 anos	1 ou 3 anos	1 ano
Pagamento upfront	All/Partial/No	All/Partial/No	All/Partial/No	All/Partial/No	No Upfront apenas
Reserva de capacidade	Sim (Zonal)	Não	Não	Não	Não
Marketplace (revenda)	Sim	Não	Não	Não	Não
Serviços cobertos	EC2	EC2	EC2	EC2, Fargate, Lambda	Aurora, RDS, DynamoDB +6
Flexibilidade de região	Não	Via troca	Não	Sim	Sim
Flexibilidade de família	Não	Via troca	Não	Sim	Sim

Ordem de Aplicação dos Descontos

Esse é um detalhe técnico que muita gente ignora, mas que impacta diretamente a eficiência da sua estratégia. A AWS aplica os descontos nesta ordem:

Reserved Instances — aplicadas primeiro ao uso compatível
EC2 Instance Savings Plans — aplicados ao uso restante que corresponda à família/região
Compute Savings Plans — aplicados por último, ao uso remanescente de EC2, Fargate e Lambda

O que isso significa na prática? Se você tem tanto RIs quanto Savings Plans, as RIs "consomem" o uso elegível primeiro. Os Savings Plans então cobrem o que sobra. Entender essa hierarquia é essencial pra evitar sobreposição e desperdício de compromissos.

Os Database Savings Plans seguem uma lógica separada: se você tiver tanto RIs de banco de dados quanto Database Savings Plans, as RIs de banco são aplicadas primeiro, e o Database Savings Plan cobre o restante.

Quando Usar Cada Modelo: Guia de Decisão

Bom, agora que já entendemos os modelos, vamos ao que interessa: quando usar cada um. Aqui vai um resumo direto ao ponto.

Escolha Standard RIs quando:

Você tem workloads estáveis e previsíveis que não mudarão de tipo de instância por 1-3 anos
Precisa de reserva de capacidade garantida (RIs Zonais)
Quer a opção de revender no Marketplace caso a arquitetura mude
Busca o desconto máximo absoluto (até 72%)

Escolha Convertible RIs quando:

Quer descontos significativos mas prevê possíveis mudanças de família de instância
Sua equipe está avaliando migração pra Graviton ou novas gerações de instância

Escolha EC2 Instance Savings Plans quando:

Você tem compromisso com uma família de instância em uma região, mas quer flexibilidade de tamanho e SO
Quer descontos equivalentes às Standard RIs (até 72%) com menos rigidez
Não precisa de reserva de capacidade nem de revenda no Marketplace

Escolha Compute Savings Plans quando:

Sua infraestrutura é dinâmica — muda de tipo de instância, região ou serviço com frequência
Você usa ou planeja usar Fargate e/ou Lambda além de EC2
Está em processo de modernização (migração pra containers, serverless, Graviton)
Prefere simplicidade de gestão — um único compromisso cobre tudo

Escolha Database Savings Plans quando:

Você usa múltiplos serviços de banco de dados da AWS
Está em processo de migração entre engines (ex: RDS MySQL pra Aurora)
Usa deployments serverless (Aurora Serverless, DynamoDB on-demand)
Quer flexibilidade cross-region e cross-service pros seus bancos de dados

Implementação Prática: AWS CLI

Chega de teoria — vamos pra prática. Aqui embaixo, você encontra os comandos de CLI pra consultar recomendações, verificar cobertura e comprar Savings Plans.

Consultando Recomendações de Savings Plans

# Ver recomendações de Savings Plans baseadas nos últimos 30 dias de uso
aws savingsplans get-savings-plans-purchase-recommendation \
  --savings-plan-type "ComputeSavingsPlans" \
  --term-in-years "ONE_YEAR" \
  --payment-option "NO_UPFRONT" \
  --lookback-period-in-days "THIRTY_DAYS" \
  --account-scope "PAYER"

# Ver recomendações para Database Savings Plans
aws savingsplans get-savings-plans-purchase-recommendation \
  --savings-plan-type "DatabaseSavingsPlans" \
  --term-in-years "ONE_YEAR" \
  --payment-option "NO_UPFRONT" \
  --lookback-period-in-days "THIRTY_DAYS"

Analisando a Cobertura Atual

# Verificar a cobertura atual dos Savings Plans
aws ce get-savings-plans-coverage \
  --time-period Start=2026-01-01,End=2026-02-01 \
  --granularity MONTHLY

# Verificar a utilização dos Savings Plans existentes
aws ce get-savings-plans-utilization \
  --time-period Start=2026-01-01,End=2026-02-01 \
  --granularity MONTHLY

Comprando um Savings Plan via CLI

# Comprar um Compute Savings Plan de 1 ano, No Upfront, $10/hora
aws savingsplans create-savings-plan \
  --savings-plan-offering-id "offering-id-aqui" \
  --commitment "10.0" \
  --purchase-time "2026-03-01T00:00:00Z"

# Listar ofertas disponíveis para escolher o offering-id
aws savingsplans describe-savings-plans-offerings \
  --savings-plan-type "ComputeSavingsPlans" \
  --plan-types "Compute" \
  --durations 94608000 \
  --payment-options "No Upfront" \
  --currencies "USD"

Monitorando Reserved Instances

# Listar todas as RIs ativas
aws ec2 describe-reserved-instances \
  --filters "Name=state,Values=active" \
  --query "ReservedInstances[].{ID:ReservedInstancesId,Type:InstanceType,Count:InstanceCount,End:End}" \
  --output table

# Verificar utilização das RIs via Cost Explorer
aws ce get-reservation-utilization \
  --time-period Start=2026-01-01,End=2026-02-01 \
  --granularity MONTHLY \
  --group-by Type=DIMENSION,Key=SUBSCRIPTION_ID

Implementação com Terraform

Se você gerencia sua infraestrutura com Terraform (e a essa altura, quem não gerencia?), dá pra automatizar tanto a consulta de dados de custo quanto o provisionamento de instâncias otimizadas pros seus compromissos.

Consultando Dados de Savings Plans com Terraform

# Data source para consultar Savings Plans existentes
data "aws_ce_cost_and_usage" "savings_coverage" {
  time_period {
    start = "2026-01-01"
    end   = "2026-02-01"
  }
  granularity = "MONTHLY"
  metrics     = ["UnblendedCost"]

  filter {
    dimension {
      key           = "RECORD_TYPE"
      values        = ["SavingsPlanCoveredUsage"]
      match_options = ["EQUALS"]
    }
  }
}

# Output para verificar a cobertura
output "savings_plan_covered_cost" {
  value = data.aws_ce_cost_and_usage.savings_coverage.results
}

Launch Template Otimizado para Savings Plans

# Launch template configurado para aproveitar EC2 Instance Savings Plans
resource "aws_launch_template" "optimized" {
  name_prefix   = "sp-optimized-"
  image_id      = data.aws_ami.amazon_linux_2023.id

  # Usando família m7g (Graviton3) — coberta pelo Savings Plan
  instance_type = "m7g.xlarge"

  metadata_options {
    http_endpoint = "enabled"
    http_tokens   = "required"
  }

  tag_specifications {
    resource_type = "instance"
    tags = {
      Name        = "sp-optimized-worker"
      CostCenter  = "engineering"
      Environment = "production"
      Commitment  = "ec2-instance-savings-plan"
    }
  }
}

# Auto Scaling Group com estratégia mista (On-Demand + Spot)
# O Savings Plan cobre automaticamente as instâncias On-Demand
resource "aws_autoscaling_group" "mixed" {
  name                = "sp-optimized-asg"
  desired_capacity    = 6
  max_size            = 12
  min_size            = 2
  vpc_zone_identifier = var.private_subnet_ids

  mixed_instances_policy {
    instances_distribution {
      # Baseline coberta pelo Savings Plan (On-Demand com desconto)
      on_demand_base_capacity                  = 2
      on_demand_percentage_above_base_capacity = 30
      # Restante usa Spot para economia adicional
      spot_allocation_strategy = "capacity-optimized"
    }

    launch_template {
      launch_template_specification {
        launch_template_id = aws_launch_template.optimized.id
        version            = "$Latest"
      }

      # Diversificação de instâncias — todas na mesma família m7g
      override {
        instance_type = "m7g.xlarge"
      }
      override {
        instance_type = "m7g.2xlarge"
      }
      override {
        instance_type = "m6g.xlarge"
      }
    }
  }
}

# Alarme de custo para monitorar gastos vs. compromisso
resource "aws_cloudwatch_metric_alarm" "cost_anomaly" {
  alarm_name          = "savings-plan-underutilization"
  comparison_operator = "LessThanThreshold"
  evaluation_periods  = 24
  metric_name         = "SavingsPlanUtilization"
  namespace           = "AWS/Billing"
  period              = 3600
  statistic           = "Average"
  threshold           = 80
  alarm_description   = "Alerta: utilização do Savings Plan abaixo de 80%"

  alarm_actions = [var.sns_topic_arn]
}

Script de Auditoria de Compromissos

#!/bin/bash
# audit-commitments.sh
# Script para auditar utilização de RIs e Savings Plans

echo "=== Auditoria de Compromissos AWS ==="
echo "Data: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
echo ""

# Período de análise (último mês)
START_DATE=$(date -u -v-1m +%Y-%m-01 2>/dev/null || date -u -d "1 month ago" +%Y-%m-01)
END_DATE=$(date -u +%Y-%m-01)

echo "--- Utilização de Savings Plans ---"
aws ce get-savings-plans-utilization \
  --time-period Start=$START_DATE,End=$END_DATE \
  --granularity MONTHLY \
  --query "Total.{Utilization:Utilization.UtilizationPercentage,TotalCommitment:TotalCommitment,UsedCommitment:UsedCommitment,UnusedCommitment:UnusedCommitment}" \
  --output table

echo ""
echo "--- Utilização de Reserved Instances ---"
aws ce get-reservation-utilization \
  --time-period Start=$START_DATE,End=$END_DATE \
  --granularity MONTHLY \
  --query "Total.{Utilization:UtilizationPercentage,PurchasedHours:PurchasedHours,TotalActualHours:TotalActualHours,UnusedHours:UnusedHours}" \
  --output table

echo ""
echo "--- RIs Expirando nos Próximos 30 Dias ---"
EXPIRE_DATE=$(date -u -v+30d +%Y-%m-%dT%H:%M:%S 2>/dev/null || date -u -d "+30 days" +%Y-%m-%dT%H:%M:%S)
aws ec2 describe-reserved-instances \
  --filters "Name=state,Values=active" \
  --query "ReservedInstances[?End<=\`$EXPIRE_DATE\`].{ID:ReservedInstancesId,Type:InstanceType,Count:InstanceCount,End:End}" \
  --output table

echo ""
echo "--- Recomendações de Savings Plans ---"
aws ce get-savings-plans-purchase-recommendation \
  --savings-plan-type ComputeSavingsPlans \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days THIRTY_DAYS \
  --query "SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationDetails[0:3].{HourlyCommitment:HourlyCommitmentToPurchase,EstimatedMonthlySavings:EstimatedMonthlySavingsAmount,ROI:EstimatedROI}" \
  --output table

Estratégia Combinada: O Framework dos 3 Níveis

Na prática, a maioria das organizações maduras em FinOps não usa apenas um modelo — usa uma combinação estratégica. Aqui vai um framework de 3 níveis que, pela minha experiência, funciona bem na maioria dos cenários:

Nível 1: Baseline com Savings Plans (60-70% do uso previsível)

Comece comprando Compute Savings Plans para cobrir 60-70% do seu uso On-Demand previsível. Esse é o seu "piso de economia" — flexível o suficiente pra absorver mudanças de arquitetura sem gerar desperdício.

Dica prática: use o Cost Explorer pra analisar seus últimos 30-60 dias de uso. O commitment ideal é o valor do percentil 10 do seu uso horário — ou seja, o nível de uso que você mantém 90% do tempo. Isso minimiza (e muito) o risco de comprometer demais.

Nível 2: Complemento com RIs ou EC2 Instance SP (mais 10-20%)

Para workloads específicos e estáveis que você tem certeza de que não mudarão, adicione EC2 Instance Savings Plans ou Standard RIs pra obter descontos maiores nesses recursos. Bancos de dados de produção, clusters de Kubernetes com baseline fixa e serviços core são bons candidatos.

Nível 3: Spot Instances para o Restante (10-30%)

O uso restante — picos de demanda, workloads tolerantes a falhas, ambientes de teste — pode rodar em Spot Instances com descontos de até 90%. Consulte nosso guia completo de Spot Instances para implementar essa camada com segurança.

Resultado esperado: com essa estratégia combinada, organizações tipicamente alcançam entre 40% e 55% de economia em relação ao preço On-Demand total (dados da FinOps Foundation). Não é pouca coisa.

Mudanças Importantes de Política em 2025-2026

Antes de sair comprando qualquer compromisso, preste atenção nessas mudanças recentes. Elas impactam como RIs e Savings Plans funcionam na prática.

Restrição de "Cliente Final Único" (Junho 2025)

A partir de 1º de junho de 2025, a AWS limitou RIs e Savings Plans a um "único cliente final". Na prática, isso restringe a capacidade de algumas organizações — especialmente MSPs e consultorias — de agrupar ou redistribuir compromissos entre entidades distintas. Se sua empresa opera com múltiplas subsidiárias ou presta serviços gerenciados, vale conversar com seu Technical Account Manager pra entender como essa regra afeta sua estratégia.

Proibição de Revenda de RIs com EDP (Desde 2024)

Clientes no Enterprise Discount Program (EDP) não podem mais vender Reserved Instances no Marketplace. Se você tem EDP e contava com a liquidez das Standard RIs como parte da sua estratégia, essa restrição muda a equação de forma significativa.

Janela de Reembolso Limitada para Savings Plans

Savings Plans podem ser devolvidos apenas nos primeiros 7 dias após a compra, desde que o compromisso horário seja de no máximo US$ 100 e a compra tenha sido feita no mesmo mês calendário. Na prática? Só compras pequenas e recentes são reembolsáveis. Compromissos maiores são irrevogáveis. Então, revise tudo com calma antes de confirmar.

Erros Comuns e Como Evitá-los

Depois de ajudar diversas equipes com otimização de custos AWS, esses são os erros que vejo com mais frequência:

1. Comprometer Demais (Over-Commitment)

O erro mais caro — e mais comum. Se você compra US$ 50/hora de Savings Plans mas seu uso médio é de US$ 35/hora, está pagando US$ 15/hora por capacidade que não usa. São mais de US$ 10.000 por mês jogados fora. Solução: comece conservador (percentil 10 do uso), monitore a utilização mensalmente e adicione compromissos de forma incremental.

2. Ignorar a Utilização de RIs Existentes

Muitas organizações compram Savings Plans sem verificar se já possuem RIs subutilizadas. Resultado: sobreposição e desperdício duplo. Solução: execute o script de auditoria acima antes de qualquer nova compra.

3. Não Considerar o Roadmap de Arquitetura

Comprar Standard RIs pra uma família de instância que será descontinuada ou migrada nos próximos 12 meses é jogar dinheiro fora. Parece óbvio, mas acontece mais do que você imagina. Solução: alinhe a estratégia de compromissos com o roadmap técnico da equipe de engenharia.

4. Esquecer dos Database Savings Plans

Com o lançamento dos Database Savings Plans, organizações que usam múltiplos serviços de banco gerenciado (RDS, Aurora, DynamoDB) agora têm uma opção flexível que antes simplesmente não existia. Solução: avalie o Cost Explorer pra recomendações específicas de Database Savings Plans.

5. Não Auditar Compromissos "Zumbis"

Compromissos que foram comprados pra workloads que já foram descomissionados. Continuam sendo cobrados, mas não geram valor nenhum. É dinheiro evaporando. Solução: revise utilização mensalmente; pra Standard RIs, liste no Marketplace pra recuperar pelo menos parte do valor.

Perguntas Frequentes (FAQ)

Qual a diferença real entre Savings Plans e Reserved Instances?

A diferença fundamental está no tipo de compromisso. Com Reserved Instances, você se compromete com uma configuração específica de instância (tipo, região, SO). Com Savings Plans, se compromete com um valor em dólares por hora de uso. Isso dá aos Savings Plans muito mais flexibilidade — se sua infraestrutura mudar, o desconto se adapta automaticamente. Em contrapartida, as RIs oferecem reserva de capacidade (Zonais) e a possibilidade de revenda (Standard), que os Savings Plans não têm.

Posso usar Savings Plans e Reserved Instances ao mesmo tempo?

Sim, e inclusive essa é uma estratégia recomendada. A AWS aplica os descontos em ordem: primeiro as RIs, depois os EC2 Instance Savings Plans e por último os Compute Savings Plans. Você pode usar RIs pra workloads estáveis com necessidade de capacidade garantida e Savings Plans pra cobrir o uso mais dinâmico. O importante é monitorar a utilização combinada pra evitar sobreposição.

Os Database Savings Plans substituem as Reserved Instances de RDS?

Não completamente. Os Database Savings Plans oferecem mais flexibilidade (cross-region, cross-engine, cross-service), mas os descontos máximos (até 35% pra serverless, até 20% pra provisionado) são menores do que os de RIs de RDS com compromisso de 3 anos e pagamento total antecipado. Se seus workloads de banco são absolutamente estáveis e previsíveis, as RIs de RDS podem oferecer descontos maiores. Pra cenários com migração entre engines ou uso de serverless, os Database Savings Plans são a melhor escolha.

Como saber se estou comprometendo demais ou de menos?

Monitore duas métricas no Cost Explorer: Utilização (percentual do compromisso efetivamente usado) e Cobertura (percentual do uso On-Demand coberto por compromissos). O ideal é utilização acima de 90% e cobertura entre 70-80%. Utilização baixa indica over-commitment; cobertura baixa significa que você poderia economizar mais com compromissos adicionais.

O que acontece quando um Savings Plan ou RI expira?

Quando o compromisso expira, o uso que era coberto volta automaticamente a ser cobrado ao preço On-Demand. Não há renovação automática por padrão, mas a AWS oferece a opção de enfileirar (queue) novos Savings Plans pra iniciar imediatamente após a expiração do atual. Configure alertas no CloudWatch pra ser notificado 30-60 dias antes da expiração — assim você tem tempo de planejar a renovação sem sustos na fatura.