Você foi solicitado a cortar trinta por cento do gasto em nuvem sem prejudicar a confiabilidade. Qual é o seu plano?

Consiga visibilidade primeiro, alocando o gasto por serviço, ambiente e time, e então trabalhe a lista em ordem de esforço e risco. Comece pelo desperdício que não tem impacto em confiabilidade: recursos ociosos, volumes desanexados, instâncias superdimensionadas, ambientes fora de produção rodando de madrugada e retenção de logs. Depois assuma compromissos de capacidade reservada ou planos de economia para a linha de base estável. Só depois disso considere mudanças arquiteturais, e leve toda proposta ao time dono com dados.

Eu não começaria cortando, começaria medindo, porque sem alocação por time e ambiente toda conversa vira discussão. Assim que eu consigo atribuir o gasto, trabalho em ordem de risco. A camada gratuita da economia é puro desperdício: volumes desanexados, snapshots velhos, load balancers ociosos, ambientes de desenvolvimento rodando vinte e quatro horas por dia para um time que trabalha oito, e retenção de logs configurada como para sempre quando a conformidade diz noventa dias. Só isso já me levou a maior parte do caminho mais de uma vez. Em seguida vem o redimensionamento com base em percentis de utilização reais em vez do que alguém escolheu dois anos atrás, feito gradualmente e com monitoramento. Depois os compromissos, capacidade reservada ou planos de economia contra a linha de base que claramente não vai a lugar nenhum, o que é um desconto por uma promessa e não uma mudança em nada. Só então eu olho arquitetura, coisas como padrões de transferência de dados ou mover dado frio para armazenamento mais barato, e isso vai para o time dono como proposta com números. A última parte é impedir a regressão: orçamentos, alertas de anomalia e custo visível nos mesmos dashboards que a confiabilidade.