Otimização de custos de cloud
Trabalho contínuo de reduzir o gasto com cloud mantendo desempenho e confiabilidade.
Otimização de custos de cloud é o trabalho contínuo de pagar menos pelos serviços de cloud mantendo o desempenho e a confiabilidade de que os workloads precisam. Existem duas alavancas. A otimização de uso muda o que você roda: para a FinOps Foundation, cada recurso precisa ter o tipo e o tamanho certos, rodar quando necessário e ficar bem utilizado. A otimização de taxa muda o que você paga por unidade, com Reserved Instances, Savings Plans, Committed Use Discounts e descontos negociados. Um banco dimensionado para um pico que nunca chega é problema de uso, e computação estável em on-demand é problema de taxa. A alocação de custos vem antes, para que cada achado chegue a um dono. O trabalho se repete, porque os times lançam serviços e os provedores lançam opções novas. AWS Compute Optimizer, Azure Advisor e os recommenders do Google Cloud publicam achados para a própria cloud. A LevelFour analisa o uso real em AWS, Google Cloud, Azure e Kubernetes e entrega cada economia como mudança na sua conta ou pull request para a sua engenharia dar merge.
Perguntas frequentes
Qual a diferença entre otimização de uso e otimização de taxa?
A de uso reduz o que você consome, e a de taxa reduz o que você paga por unidade. Rightsizing, agendamento e remoção de recursos ociosos são trabalho de uso, feito pela engenharia. Commitments e descontos negociados são trabalho de taxa, e um time de FinOps ou de compras consegue fazer sem mexer em workload. A FinOps Foundation avisa que os dois interagem: a recomendação de comprar um commitment para um recurso pode conflitar com a de mudar o tipo ou o tamanho dele.
Devo fazer rightsizing antes de comprar commitments?
Faça rightsizing primeiro onde der, e continue comprando commitments enquanto isso. A FinOps Foundation diz que, no mundo ideal, a otimização de uso vem antes da de taxa, e também alerta contra esperar um ambiente perfeito. Um commitment dimensionado para instâncias grandes demais trava o excesso, e meses de espera são meses em preço on-demand. Cubra a base em que você confia e aumente conforme o uso se estabiliza. As metas de exemplo da Foundation para cobertura de commitments vão de cerca de 60% em Crawl a mais de 80% em Run.
Por que a otimização de custos de cloud precisa ser contínua?
Porque as entradas mudam. Os times lançam serviços, o tráfego se move e o tamanho certo do trimestre passado envelhece. O AWS Compute Optimizer trabalha por padrão com os últimos 14 dias de métricas, então a recomendação acompanha o uso recente. Um projeto de limpeza resolve a lista de hoje, e um ciclo recorrente pega o próximo ambiente ocioso e o commitment prestes a vencer.
Como medir a otimização de custos de cloud?
Acompanhe a economia realizada separada da potencial. A potencial estima o que uma mudança pode economizar, e a realizada compara na fatura o custo de um recurso antes e depois da mudança. Some uma métrica de unidade, como custo por cliente, para o crescimento não esconder o progresso. O Savings Audit da LevelFour lista cada economia aplicada, com o valor mensal de cada uma.