Right-Sizing na Nuvem: Guia Definitivo para Dimensionar Corretamente Seus Recursos em AWS, Azure e GCP

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:

1. Downsizing: reduzir o tamanho de recursos superdimensionados (ex: trocar um m5.2xlarge por um m5.xlarge)
2. Upsizing: aumentar recursos subdimensionados que estão causando gargalos de performance
3. 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

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)

1. Ative as ferramentas nativas: AWS Compute Optimizer, Azure Advisor e GCP Active Assist — todas são gratuitas para o uso básico
2. 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
3. Defina o período de análise: use no mínimo 30 dias de dados, idealmente 60-90 dias para capturar picos sazonais
4. 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)

1. Ordene por economia potencial: foque nos maiores ganhos primeiro (os famosos "big rocks")
2. Classifique por risco: ambientes de dev/teste têm risco praticamente zero e devem ser priorizados. Produção exige mais cuidado
3. 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)
4. 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)

1. Comece por dev/teste: aplique todas as recomendações nesses ambientes primeiro — é o caminho mais seguro
2. 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
3. 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
4. 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)

1. Revise recomendações mensalmente: as cargas de trabalho mudam, e novas oportunidades surgem o tempo todo
2. 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
3. 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:

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:

1. Ative as ferramentas nativas do seu provedor — são gratuitas e já entregam insights valiosos
2. Habilite a coleta de métricas de memória — sem isso, suas recomendações serão incompletas
3. Comece pelos ambientes não-produtivos — risco zero, economia imediata
4. Reduza gradualmente — um nível por vez, com métricas de rollback definidas
5. Estabeleça uma cadência mensal de revisão — o right-sizing é processo contínuo, não projeto com data de fim
6. 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?