Right-Sizing na Nuvem: Guia Prático 2026

Por Que o Right-Sizing É a Base de Qualquer Estratégia de Otimização de Custos

Vou ser direto: se você está investindo em Spot Instances, Savings Plans ou Reserved Instances sem antes fazer o right-sizing dos seus recursos, está construindo sua estratégia de economia sobre uma base frágil. É como negociar um baita desconto em um carro que simplesmente não cabe na sua garagem — o preço pode até ser ótimo, mas você está pagando por algo que não precisa.

Right-sizing — ou dimensionamento correto, pra quem prefere em português — é o processo de ajustar tipos e tamanhos das suas instâncias de computação, bancos de dados e outros serviços de nuvem para que correspondam exatamente às necessidades reais das suas cargas de trabalho. Parece simples na teoria, né? Mas a realidade mostra que a maioria das organizações falha miseravelmente nessa tarefa.

E os números comprovam isso. Segundo dados recentes da FinOps Foundation, entre 20% e 35% dos gastos com nuvem são desperdiçados com recursos ociosos ou superdimensionados. Em 2025, isso representou cerca de US$ 44,5 bilhões em desperdício global de infraestrutura cloud. Só isso já deveria tirar o sono de qualquer CFO.

No ecossistema Kubernetes, a situação é ainda pior: o relatório Enterprise Kubernetes 2025 da Komodor revelou que 82% das cargas de trabalho são superdimensionadas, com 65% usando menos da metade dos recursos de CPU e memória solicitados. Honestamente, esses números me surpreendem toda vez que releio.

A boa notícia? Cada provedor de nuvem oferece ferramentas nativas e gratuitas para identificar essas oportunidades. E neste guia, vamos mergulhar fundo em como usar cada uma delas, com exemplos práticos, scripts prontos e uma metodologia passo a passo pra implementar o right-sizing de forma segura.

O Que É Right-Sizing e Como Ele Se Diferencia de Outras Estratégias

Antes de colocar a mão na massa, vale esclarecer onde o right-sizing se encaixa no ecossistema de otimização de custos. Existem três pilares principais de economia na nuvem:

Right-sizing: usar o recurso do tamanho certo para a carga de trabalho
Desconto por compromisso: Reserved Instances, Savings Plans, CUDs (descontos por uso comprometido)
Desconto por modelo de preço: Spot Instances, instâncias preemptíveis

A ordem importa — e muito. Se você compra um Reserved Instance de um tipo de instância superdimensionado, está simplesmente pagando menos por algo que não precisa. O right-sizing deve ser sempre o primeiro passo, antes de qualquer decisão de compromisso financeiro.

Dimensione primeiro, comprometa-se depois.

Na prática, o right-sizing envolve três ações principais:

Downsizing: reduzir o tamanho de recursos superdimensionados (ex: trocar um m5.2xlarge por um m5.xlarge)
Upsizing: aumentar recursos subdimensionados que estão causando gargalos de performance
Mudança de família: migrar para famílias de instâncias mais adequadas (ex: de uso geral para otimizadas para computação, ou migrar para Graviton/ARM)

Métricas Que Indicam Oportunidades de Right-Sizing

Como saber se um recurso precisa de right-sizing? Essa é a pergunta de ouro. Aqui estão as métricas-chave e os limiares que você deve ficar de olho:

Regra Geral para VMs e Instâncias

Se a utilização média de CPU for inferior a 20% e o percentil 95 de CPU for inferior a 40% durante um período de 60 dias, considere reduzir o tamanho da instância em um nível. Parece agressivo? Talvez, mas depois de aplicar essa regra em dezenas de ambientes, posso dizer que funciona na grande maioria dos casos.

Após a redução, valide a performance contra métricas de experiência do usuário (latência, taxa de erro) antes de tornar a mudança permanente.

Métricas por Tipo de Recurso

Recurso	Métrica	Limiar para Right-Sizing	Ação Recomendada
VMs/Instâncias EC2	CPU média	< 20% por 30+ dias	Reduzir tamanho
VMs/Instâncias EC2	Memória média	< 30% por 30+ dias	Reduzir tamanho ou mudar família
Bancos de dados (RDS/Aurora)	CPU média	< 5% por 30+ dias	Reduzir tamanho ou considerar serverless
Volumes EBS	IOPS utilizados	< 10% do provisionado	Migrar para gp3 ou reduzir IOPS
Containers (K8s)	CPU vs. requests	< 50% do solicitado	Ajustar requests e limits

AWS Compute Optimizer: A Ferramenta Mais Completa do Mercado

O AWS Compute Optimizer é, sem sombra de dúvida, a ferramenta nativa mais avançada para right-sizing que existe hoje. Ao longo de 2025 e início de 2026, a AWS expandiu bastante suas capacidades, tornando-o uma peça central de qualquer estratégia de otimização.

O Que o Compute Optimizer Analisa

O serviço analisa dados de utilização coletados pelo CloudWatch e gera recomendações para os seguintes recursos:

Instâncias EC2 (incluindo mais de 156 novos tipos adicionados em 2025)
Auto Scaling Groups (incluindo detecção de ASGs ociosas com GPUs, desde junho de 2025)
Volumes EBS (com regras de automação desde novembro de 2025)
Funções Lambda
Tarefas ECS no Fargate
Instâncias RDS
Clusters Amazon Aurora (recurso mais recente)
NAT Gateways ociosas (desde novembro de 2025)

A lista é longa — e continua crescendo a cada trimestre.

Novidades de 2025 Que Você Precisa Conhecer

Regras de Automação para EBS (novembro de 2025): Essa aqui é uma das que mais gosto. O Compute Optimizer agora permite criar regras de automação que aplicam recomendações de otimização de volumes EBS automaticamente. Você define critérios como região e tags, e as regras são executadas diariamente, semanalmente ou mensalmente. Um dashboard centralizado mostra o histórico e a economia estimada.

Detecção de GPUs Ociosas (junho de 2025): Com a explosão do uso de GPUs para IA, muitas organizações provisionam instâncias G e P que ficam paradas após a conclusão dos treinamentos. O Compute Optimizer agora detecta Auto Scaling Groups com GPUs ociosas quando o agente NVIDIA CloudWatch está habilitado. Se você trabalha com ML, vale muito a pena ativar isso.

Recomendações para NAT Gateways (novembro de 2025): O serviço identifica NAT Gateways sem tráfego por 32 dias, analisando métricas de conexões ativas e pacotes recebidos. Parece pouco, mas NAT Gateways ociosas são um daqueles custos "fantasma" que ninguém percebe na fatura.

Como Ativar e Usar o Compute Optimizer

# Ativar o Compute Optimizer via AWS CLI
aws compute-optimizer update-enrollment-status \
  --status Active \
  --include-member-accounts

# Verificar status da ativação
aws compute-optimizer get-enrollment-status

# Obter recomendações para instâncias EC2
aws compute-optimizer get-ec2-instance-recommendations \
  --filters "name=Finding,values=OVER_PROVISIONED" \
  --output json | jq '.instanceRecommendations[] | {
    instanceId: .instanceArn,
    currentType: .currentInstanceType,
    finding: .finding,
    recommendations: [.recommendationOptions[] | {
      instanceType: .instanceType,
      projectedUtilization: .projectedUtilizationMetrics,
      estimatedMonthlySavings: .estimatedMonthlySavings
    }]
  }'

# Exportar recomendações para S3
aws compute-optimizer export-ec2-instance-recommendations \
  --s3-destination-config "bucket=meu-bucket-finops,keyPrefix=right-sizing/" \
  --file-format Csv

Configurando Preferências de Right-Sizing

Essa funcionalidade aqui é poderosa e muita gente nem sabe que existe: você pode ajustar as preferências de recomendação, configurando a margem de segurança de CPU, o período de análise e até as famílias de instância preferidas.

# Configurar preferências no nível da organização
aws compute-optimizer put-recommendation-preferences \
  --resource-type Ec2Instance \
  --scope "name=Organization,value=o-xxxxxxxxxx" \
  --look-back-period DAYS_32 \
  --utilization-preferences '[{
    "metricName": "CpuUtilization",
    "metricParameters": {
      "threshold": "P95",
      "headroom": "PERCENT_20"
    }
  }]' \
  --preferred-resources '[{
    "name": "Ec2InstanceTypes",
    "includeList": ["m7g", "m7i", "c7g", "r7g"]
  }]'

Repare que neste exemplo estamos direcionando as recomendações para famílias Graviton (aquelas com sufixo "g"), que oferecem até 40% melhor relação preço-performance comparadas às instâncias x86 equivalentes. Sim, 40% — não é exagero.

Azure Advisor: Right-Sizing no Ecossistema Microsoft

O Azure Advisor é a ferramenta nativa do Azure para recomendações de otimização, incluindo right-sizing de máquinas virtuais. Não é tão abrangente quanto o AWS Compute Optimizer (vamos ser honestos), mas fornece informações que podem gerar economias bastante significativas.

Como o Azure Advisor Identifica Oportunidades

O Azure Advisor monitora a utilização das VMs durante 7 dias e identifica máquinas subutilizadas com base nos seguintes critérios padrão:

Utilização de CPU: 5% ou menos (configurável)
Uso de rede: 7 MB ou menos durante 4 ou mais dias

Quando essas condições são atendidas, o Advisor recomenda o desligamento ou a redução de tamanho da VM, mostrando a economia anual estimada.

Novidades de 2025: Copilot e AKS

A Microsoft trouxe o Copilot no Azure para otimização de custos — e isso muda bastante o jogo. Agora você pode fazer perguntas em linguagem natural sobre seus custos e receber recomendações de right-sizing personalizadas. Tipo: "Quais VMs estão superdimensionadas?" e receber uma análise detalhada com sugestões específicas. Bem prático.

Outra novidade importante foi a disponibilidade geral das recomendações de custo para AKS no Azure Advisor, trazendo visibilidade de right-sizing para clusters Kubernetes gerenciados.

Acessando Recomendações via CLI

# Listar recomendações de custo do Azure Advisor
az advisor recommendation list \
  --category Cost \
  --output table

# Filtrar recomendações de right-sizing para VMs
az advisor recommendation list \
  --category Cost \
  --query "[?contains(shortDescription.solution, 'Right-size')]" \
  --output json | jq '.[] | {
    resourceId: .resourceMetadata.resourceId,
    recommendation: .shortDescription.solution,
    impact: .impact,
    savings: .extendedProperties.annualSavingsAmount
  }'

# Exportar dados de custo para análise
az costmanagement export create \
  --name "RightSizingAnalysis" \
  --type "ActualCost" \
  --scope "/subscriptions/{subscription-id}" \
  --storage-account-id "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Storage/storageAccounts/{account}" \
  --storage-container "cost-exports" \
  --timeframe "MonthToDate" \
  --recurrence "Weekly"

Limitações e Como Contorná-las

O Azure Advisor tem uma limitação que incomoda: ele não aplica recomendações automaticamente. Todo o processo é manual. Pra quem gerencia dezenas (ou centenas) de VMs, isso se torna um problema real.

A solução? Usar Azure Automation com runbooks que consultam a API do Advisor e aplicam redimensionamentos automaticamente em horários de baixo tráfego:

# Script PowerShell para Azure Automation Runbook
# Aplica recomendações de right-sizing automaticamente

Connect-AzAccount -Identity

$recommendations = Get-AzAdvisorRecommendation `
  -Category Cost `
  | Where-Object { $_.ShortDescription.Solution -like "*Right-size*" }

foreach ($rec in $recommendations) {
    $vmId = $rec.ResourceMetadata.ResourceId
    $vm = Get-AzVM -ResourceId $vmId

    # Extrair tamanho recomendado da descrição
    $recommendedSize = $rec.ExtendedProperties.targetSku

    if ($recommendedSize) {
        Write-Output "Redimensionando VM $($vm.Name) de $($vm.HardwareProfile.VmSize) para $recommendedSize"

        # Parar a VM antes de redimensionar
        Stop-AzVM -ResourceGroupName $vm.ResourceGroupName `
                   -Name $vm.Name -Force

        # Aplicar novo tamanho
        $vm.HardwareProfile.VmSize = $recommendedSize
        Update-AzVM -ResourceGroupName $vm.ResourceGroupName -VM $vm

        # Reiniciar a VM
        Start-AzVM -ResourceGroupName $vm.ResourceGroupName `
                   -Name $vm.Name
    }
}

GCP Active Assist e o VM Machine Type Recommender

O Google Cloud aborda o right-sizing através do Active Assist, um conjunto de ferramentas de recomendação que inclui o VM Machine Type Recommender e o Idle VM Recommender. A abordagem do GCP é um pouco diferente dos outros provedores, mas igualmente eficaz.

Como Funciona o VM Machine Type Recommender

O Recommender do GCP analisa métricas de CPU e memória durante os últimos 8 dias e gera recomendações de mudança de tipo de máquina. As instâncias precisam estar ativas por pelo menos 24 horas para que recomendações comecem a ser geradas, mas o ideal é esperar os 8 dias completos pra resultados mais confiáveis.

O Idle VM Recommender complementa isso identificando máquinas virtuais que não foram usadas nos últimos 14 dias — e recomenda o desligamento.

Acessando Recomendações via gcloud CLI

# Listar recomendações de right-sizing para VMs
gcloud recommender recommendations list \
  --project=meu-projeto \
  --location=us-central1-a \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --format="table(name,description,primaryImpact.costProjection.cost.units)"

# Listar VMs ociosas
gcloud recommender recommendations list \
  --project=meu-projeto \
  --location=us-central1-a \
  --recommender=google.compute.instance.IdleResourceRecommender \
  --format="table(name,description,stateInfo.state)"

# Aplicar uma recomendação específica
gcloud recommender recommendations mark-claimed \
  --project=meu-projeto \
  --location=us-central1-a \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --recommendation=RECOMMENDATION_ID \
  --etag=ETAG_VALUE \
  --state-metadata=reviewed=true

# Redimensionar uma VM com base na recomendação
# Primeiro, pare a instância
gcloud compute instances stop minha-vm --zone=us-central1-a

# Altere o tipo de máquina
gcloud compute instances set-machine-type minha-vm \
  --zone=us-central1-a \
  --machine-type=e2-standard-4

# Reinicie a instância
gcloud compute instances start minha-vm --zone=us-central1-a

Active Assist em Escala com BigQuery

Pra organizações grandes (aquelas com centenas ou milhares de projetos GCP), existe a exportação de recomendações para o BigQuery. Isso permite análises customizadas e a criação de dashboards sob medida — e é o padrão que as equipes de FinOps mais maduras adotam:

-- Query BigQuery para análise de recomendações de right-sizing
SELECT
  cloud_entity_id AS project_id,
  r.name AS recommendation_name,
  r.description,
  r.recommender_subtype,
  r.primary_impact.cost_projection.cost.units AS savings_per_month,
  r.state
FROM
  `meu-projeto.recommendations_export.recommendations_export` r
WHERE
  r.recommender = 'google.compute.instance.MachineTypeRecommender'
  AND r.state = 'ACTIVE'
ORDER BY
  savings_per_month DESC
LIMIT 50

Right-Sizing em Kubernetes com Vertical Pod Autoscaler (VPA)

Quando falamos de right-sizing em ambientes Kubernetes, o cenário muda completamente. Aqui não estamos dimensionando VMs individuais, mas sim os requests e limits de CPU e memória dos pods.

E lembra daquele dado? 82% das cargas de trabalho em Kubernetes são superdimensionadas. Então, sim, tem muito dinheiro na mesa esperando pra ser recuperado.

O Que É o VPA e Como Ele Funciona

O Vertical Pod Autoscaler (VPA) é um componente do ecossistema Kubernetes que ajusta automaticamente os requests de recursos dos pods com base no uso real. Ele é composto por três partes:

Recommender: monitora métricas de uso e gera recomendações de CPU e memória
Updater: compara recursos atuais com recomendações e reinicia pods com configurações subótimas
Admission Controller: intercepta a criação de pods e aplica as recomendações

Modos de Operação do VPA

O VPA oferece três modos, e escolher o modo certo é crucial pra não causar problemas em produção:

Off (Recomendação apenas): gera recomendações sem alterar nada. Comece por aqui em produção — sempre.
Initial: aplica recomendações apenas quando pods são criados, sem mexer nos pods em execução
Auto: aplica recomendações automaticamente, reiniciando pods quando necessário. Use com bastante cautela.

Exemplo Prático: Configurando VPA para uma Aplicação

# Instalação do VPA via Helm
helm repo add fairwinds-stable https://charts.fairwinds.com/stable
helm install vpa fairwinds-stable/vpa \
  --namespace vpa-system \
  --create-namespace

---
# vpa-recommendation.yaml
# Modo Off para análise inicial
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-server-vpa
  namespace: production
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  updatePolicy:
    updateMode: "Off"
  resourcePolicy:
    containerPolicies:
    - containerName: api-server
      minAllowed:
        cpu: "100m"
        memory: "128Mi"
      maxAllowed:
        cpu: "2000m"
        memory: "4Gi"
      controlledResources: ["cpu", "memory"]

# Verificar recomendações do VPA
kubectl describe vpa api-server-vpa -n production

# Saída esperada (exemplo):
# Recommendation:
#   Container Recommendations:
#     Container Name: api-server
#     Lower Bound:
#       Cpu:     100m
#       Memory:  256Mi
#     Target:
#       Cpu:     350m
#       Memory:  512Mi
#     Uncapped Target:
#       Cpu:     350m
#       Memory:  512Mi
#     Upper Bound:
#       Cpu:     800m
#       Memory:  1Gi

# Script para coletar recomendações de todos os VPAs
kubectl get vpa --all-namespaces -o json | jq '.items[] | {
  namespace: .metadata.namespace,
  name: .metadata.name,
  target: .status.recommendation.containerRecommendations[0].target,
  current: .spec.targetRef.name
}'

Regra de Ouro: VPA + HPA Sem Conflito

Dá pra usar o VPA (escalonamento vertical) junto com o HPA (escalonamento horizontal), mas tem uma regra que não pode quebrar: nunca configure ambos para escalar com base na mesma métrica. O padrão que funciona bem na prática é:

VPA: ajusta CPU e memória dos pods (right-sizing)
HPA: escala o número de réplicas com base em métricas customizadas (requests por segundo, profundidade de fila, etc.)

Playbook de Right-Sizing: Metodologia Passo a Passo

Tá, chega de teoria. Aqui vai um playbook estruturado e testado que pode ser aplicado em qualquer provedor de nuvem:

Fase 1: Descoberta e Inventário (Semana 1)

Ative as ferramentas nativas: AWS Compute Optimizer, Azure Advisor e GCP Active Assist — todas são gratuitas para o uso básico
Habilite métricas de memória: o CloudWatch Agent na AWS, o Azure Monitor e o Cloud Monitoring do GCP não coletam métricas de memória por padrão. Sem esses dados, as recomendações serão baseadas apenas em CPU — e isso é insuficiente
Defina o período de análise: use no mínimo 30 dias de dados, idealmente 60-90 dias para capturar picos sazonais
Gere um inventário completo: exporte todas as recomendações para uma planilha ou dashboard centralizado

Fase 2: Priorização e Análise (Semana 2)

Ordene por economia potencial: foque nos maiores ganhos primeiro (os famosos "big rocks")
Classifique por risco: ambientes de dev/teste têm risco praticamente zero e devem ser priorizados. Produção exige mais cuidado
Valide contra padrões de uso: confirme que o período de análise capturou picos reais e não foi atípico (Black Friday, por exemplo)
Agrupe por proprietário: use tags de cost allocation para enviar recomendações às equipes responsáveis

Fase 3: Implementação Gradual (Semanas 3-6)

Comece por dev/teste: aplique todas as recomendações nesses ambientes primeiro — é o caminho mais seguro
Reduza em um nível por vez: nunca pule dois tamanhos de instância de uma vez. Se a recomendação sugere ir de xlarge para medium, passe primeiro por large
Estabeleça métricas de rollback: defina limiares claros (ex: latência P99 > 200ms ou taxa de erro > 0.1%) que disparam um retorno ao tamanho anterior
Documente cada mudança: registre o tipo antigo, o tipo novo, a data da mudança e as métricas de baseline

Fase 4: Monitoramento e Iteração (Contínuo)

Revise recomendações mensalmente: as cargas de trabalho mudam, e novas oportunidades surgem o tempo todo
Automatize onde possível: use as regras de automação do AWS Compute Optimizer para EBS, configure VPA no modo Auto para workloads não críticos
Meça a economia realizada: compare gastos mensais antes e depois para quantificar o impacto real

Automação com Terraform: Right-Sizing como Código

Pra quem segue práticas de Infrastructure as Code (e deveria, sinceramente), o right-sizing pode ser integrado diretamente nos pipelines de IaC. Aqui vai um exemplo de como usar dados do Compute Optimizer no Terraform:

# Módulo Terraform para right-sizing automatizado
# Consulta recomendações do Compute Optimizer e aplica

data "aws_instance" "target" {
  instance_id = var.instance_id
}

# Script local que consulta o Compute Optimizer
data "external" "right_size_recommendation" {
  program = ["bash", "-c", <<-EOT
    RECOMMENDATION=$(aws compute-optimizer get-ec2-instance-recommendations \
      --instance-arns "arn:aws:ec2:${var.region}:${var.account_id}:instance/${var.instance_id}" \
      --query "instanceRecommendations[0].recommendationOptions[0].instanceType" \
      --output text 2>/dev/null)

    if [ "$RECOMMENDATION" != "None" ] && [ -n "$RECOMMENDATION" ]; then
      echo "{\"instance_type\": \"$RECOMMENDATION\", \"should_resize\": \"true\"}"
    else
      echo "{\"instance_type\": \"${data.aws_instance.target.instance_type}\", \"should_resize\": \"false\"}"
    fi
  EOT
  ]
}

# Usar o tipo recomendado na definição da instância
resource "aws_instance" "optimized" {
  ami           = data.aws_instance.target.ami
  instance_type = data.external.right_size_recommendation.result["instance_type"]

  tags = {
    Name           = "optimized-${var.instance_name}"
    RightSized     = data.external.right_size_recommendation.result["should_resize"]
    PreviousType   = data.aws_instance.target.instance_type
    OptimizedDate  = timestamp()
  }
}

Armadilhas Comuns e Como Evitá-las

Ao longo de diversas implementações de right-sizing, alguns erros aparecem com uma frequência preocupante. Veja como não cair neles:

1. Analisar Apenas CPU e Ignorar Memória

Esse é, de longe, o erro mais comum. Uma instância pode ter CPU ociosa mas estar usando 90% da memória. Se você reduzir o tamanho olhando só pra CPU, o aplicativo vai começar a fazer swap ou sofrer OOM kills — e aí o problema fica muito maior que a economia.

Sempre habilite a coleta de métricas de memória antes de tomar qualquer decisão de right-sizing. Sempre.

2. Usar um Período de Análise Muito Curto

7 dias de dados (que é o padrão do Azure Advisor) podem não capturar picos mensais como fechamento contábil, processamento de folha de pagamento ou promoções sazonais. Use no mínimo 30 dias, preferencialmente 60-90 dias.

3. Fazer Right-Sizing Antes de Otimizar a Aplicação

Se o aplicativo tem memory leaks ou queries mal otimizadas, o right-sizing vai esconder o problema temporariamente. Corrija os problemas de código primeiro, depois dimensione a infraestrutura. A ordem aqui importa.

4. Não Considerar a Migração para ARM/Graviton

Muitas vezes, a melhor recomendação não é simplesmente reduzir o tamanho, mas mudar para uma família de instâncias com melhor relação preço-performance. As instâncias AWS Graviton3 (família m7g, c7g, r7g) oferecem até 40% melhor preço-performance comparadas às equivalentes x86. O Azure Cobalt e o GCP Tau T2A seguem a mesma lógica com processadores ARM.

5. Tratar Right-Sizing como Projeto Único

O right-sizing não é algo que você faz uma vez e esquece. As cargas de trabalho mudam, novos tipos de instância são lançados, e a base de código evolui. Estabeleça uma cadência mensal ou, no mínimo, trimestral de revisão. Se não virar rotina, o desperdício volta.

Ferramentas de Terceiros para Right-Sizing Multi-Cloud

As ferramentas nativas são ótimas pra quem opera em um único provedor. Mas organizações multi-cloud frequentemente precisam de uma visão unificada — e é aí que entram as soluções de terceiros:

Ferramenta	Destaque	Melhor Para
Flexera (com Spot by NetApp)	Visão unificada multi-cloud, automação avançada de Spot e right-sizing	Grandes empresas multi-cloud
CloudHealth (Broadcom)	Governança e relatórios detalhados	Conformidade e chargeback
Kubecost / OpenCost	Right-sizing específico para Kubernetes	Equipes com foco em containers
Datadog Cloud Cost Management	Integração com observabilidade	Equipes que já usam Datadog
nOps / PerfectScale	Automação inteligente de right-sizing	Equipes que buscam automação total

Um movimento importante do mercado em 2025 foi a aquisição da Spot by NetApp pela Flexera, consolidando capacidades de gerenciamento de compromissos, otimização de Kubernetes e automação de spot instances numa única plataforma. Vale ficar de olho nessa integração ao longo de 2026.

Medindo o Impacto: KPIs de Right-Sizing

Pra convencer a liderança (e justificar o tempo investido), você precisa de métricas claras e tangíveis:

Taxa de cobertura de right-sizing: percentual de recursos que foram avaliados e ajustados
Economia mensal realizada: diferença entre o custo antes e depois — esse é o número que todo mundo quer ver
Utilização média: acompanhe se a utilização de CPU e memória está se aproximando da faixa ideal (40-60%)
Recomendações pendentes: número de recomendações ainda não implementadas e sua economia potencial
Tempo médio de implementação: quanto tempo leva desde a recomendação até a aplicação efetiva

As equipes de FinOps mais maduras reportam que, após resolver os grandes desperdícios iniciais, enfrentam retornos decrescentes — as oportunidades restantes são menores e exigem mais esforço individual. Isso é natural e esperado. O segredo é manter a disciplina e automatizar tudo que for possível.

Conclusão: Right-Sizing É o Alicerce da Economia na Nuvem

O right-sizing é, sem exagero nenhum, a prática mais fundamental de otimização de custos na nuvem. Sem ele, todas as outras estratégias — Spot Instances, Reserved Instances, Savings Plans — são construídas sobre uma base de desperdício.

Então, por onde começar? Aqui vai o resumo:

Ative as ferramentas nativas do seu provedor — são gratuitas e já entregam insights valiosos
Habilite a coleta de métricas de memória — sem isso, suas recomendações serão incompletas
Comece pelos ambientes não-produtivos — risco zero, economia imediata
Reduza gradualmente — um nível por vez, com métricas de rollback definidas
Estabeleça uma cadência mensal de revisão — o right-sizing é processo contínuo, não projeto com data de fim
Considere a migração para ARM/Graviton — muitas vezes é mais eficaz do que simplesmente reduzir o tamanho

Com 30-35% dos gastos com nuvem sendo desperdiçados e 82% dos workloads em Kubernetes superdimensionados, a oportunidade é gigantesca. A pergunta que fica é: quando você vai começar?