Otimização de custos entre hyperscalers: a vantagem do Azure

Embora os times da AWS, do GCP e do Azure invistam tempo e dinheiro para destacar as diferenças entre seus serviços, alguns princípios de otimização de custos valem para todos eles. Afinal, a adoção da nuvem não é movida só por funcionalidades e capacidades, mas também por eficiência — e os clientes deixaram bem claro nos últimos anos que querem mais visibilidade sobre seus custos e mais oportunidades de reduzi-los.

A FinOps Foundation, por exemplo, vem promovendo uma abordagem mais padronizada para analisar custos de nuvem e caçar ineficiências. Se você quiser saber mais sobre o trabalho deles, dá uma olhada aqui: https://www.finops.org/

Mas deixa eu parar de divagar. Quer você esteja partindo para sua primeira migração para a nuvem ou já rode lá desde a época em que o SimpleDB era novidade, vamos agora explorar 3 dos princípios fundamentais de otimização de custos que se aplicam tanto à AWS quanto ao GCP e ao Azure.

O conceito de right-sizing é um clássico da nuvem: garantir que os clientes usem recursos sob medida para o que precisam, nem mais, nem menos. Como na maioria das escolhas na nuvem (e na vida), o tamanho do seu recurso (seja uma instância de banco gerenciado, um container, um pod, uma VM, um sistema de arquivos etc.) é um trade-off entre o que você precisa agora, o que pode precisar no futuro e a velocidade com que vai precisar.

Todos os hyperscalers cruzam dados de cobrança com métricas operacionais (como uso de rede, memória ou CPU em instâncias, por exemplo) para sustentar a recomendação de reduzir o tamanho do recurso ou até excluí-lo de vez, mostrando uma estimativa do quanto você vai economizar.

O Azure não fica para trás e oferece suas recomendações pelo Azure Advisor que, assim como o Compute Optimizer da AWS e o Recommender do GCP, sugere como fazer right-sizing de recursos ou apagar os ociosos.

Não pule essas recomendações: você vai se surpreender com a quantidade de recursos que poderiam ser excluídos. Mais adiante neste artigo vamos explorar alguns recursos extras que o Azure oferece, então fica por aqui.

Pré-pagar por recursos computacionais com um compromisso de tempo fixo reduz bastante os custos em todas as nuvens. Em todos os hyperscalers, esse modelo de compra está disponível para uma ampla gama de serviços (Compute, Storage, bancos de dados...). Pode parecer intimidador no começo, mas é a forma mais rápida de economizar na nuvem: sem mudanças de configuração, sem rearquitetura, só alguns cliques e o preço por unidade do seu recurso despenca.

O Azure oferece uma Reservation Recommendation API, além de exibir recomendações no nível da subscription pelo Azure Advisor; no entanto, se você quiser ver as recomendações para todo o seu escopo de cobrança (como deveria, para maximizar a utilização da reserva), o caminho é meio engessado: no portal do Azure, vá em Reservations > Add e lá você encontra todos os serviços aos quais as reservas se aplicam, junto com as recomendações.

Na minha opinião, os portais da AWS e do GCP são mais fáceis de usar, ambos trazem as recomendações de reservas para os serviços elegíveis em um único lugar, sem precisar ficar clicando para todo lado. Mas vamos deixar a estética de lado: o importante é analisar essas recomendações e aplicar as que se encaixam no seu caso de uso o quanto antes. https://azure.microsoft.com/en-us/pricing/offers/savings-plan-compute

Se você roda workloads que toleram interrupções (pense em ambientes de teste e sandbox, batch jobs, processamento assíncrono), as três plataformas oferecem instâncias Spot. A ideia central por trás das instâncias Spot vem da capacidade ociosa que os hyperscalers têm em seus data centers: em vez de deixá-la parada, eles permitem que os clientes usem essa capacidade extra com um desconto agressivo. Na AWS e no Azure, os clientes podem até definir um preço máximo que estão dispostos a pagar por essas VMs, ganhando muito mais controle sobre os custos.

Suponha que haja mais demanda por capacidade na Availability Zone. Nesse caso, o preço Spot vai subir e pode ultrapassar o limite definido pelo cliente. Quando isso acontece, o provedor de nuvem inicia o processo de eviction, desligando a VM. O cliente tem a opção de manter a VM e seus discos (e continuar sendo cobrado por eles), aguardando o preço cair de novo, ou simplesmente excluir tudo e zerar as cobranças.

O Azure oferece Spot Virtual Machines com suporte a definição de preço máximo e comportamento de eviction, mas vale notar que máquinas da série B e tamanhos promocionais não são suportados. Os clientes podem inclusive implantar Virtual Machine Scale Sets para Spot VMs, combinando Spot VMs com escalonamento automatizado e reduzindo ainda mais o risco de sustos na fatura por escalonamento excessivo.

Já discutimos algumas abordagens comuns de otimização na nuvem que valem para todos os hyperscalers, mas e as particularidades do Azure? Será que o Azure tem benefícios únicos que dá para aproveitar para reduzir ainda mais os custos?

Clientes da DoiT pagam milhões de dólares por mês em licenças do Windows ao rodar workloads Windows na AWS ou no GCP, mas quem já tem um contrato de licença do Windows com Software Assurance pode aproveitar o Azure Hybrid Benefit: ele permite que os clientes levem licenças on-premises existentes de Windows Server, Microsoft SQL Server e produtos Linux para implantações em nuvem.

Eu sei que esse não é o assunto mais empolgante do mundo, mas vale destacar que esse programa permite, na prática, reaproveitar as licenças on-premise nos recursos do Azure, gerando um desconto enorme no caminho. Embora AWS e GCP tenham firmado acordos com a Microsoft que permitem BYOL ao usar produtos Microsoft em suas nuvens, o Azure Hybrid Benefit derruba o custo total de forma bem mais agressiva (às vezes em até 85%). Saiba mais neste link

Em uma jogada única, o Azure oferece preços especiais para ambientes que não são de produção (Dev/Test pricing) pelos seus programas de Enterprise Agreement. Comentamos acima como as Spot VMs podem ser usadas para reduzir custos em ambientes de teste, mas, na prática, essa estratégia fica restrita às VMs do Azure. Com o Dev/Test Pricing, uma variedade enorme de serviços entra na conta, incluindo SQL Database e App Service, reduzindo bastante o TCO dos ambientes de teste. Se seu time usa Azure DevOps ou subscriptions MSDN, garanta que as VMs e serviços sejam provisionados no tier de preços Dev/Test sempre que possível.

Esse aqui pode ter passado despercebido, principalmente se você é usuário de longa data do Azure Cosmos DB. Desde setembro de 2024, a Microsoft mudou a forma como o Cosmos DB escala seus bancos de dados, habilitando o Dynamic Scaling.

Antes, o escalonamento era disparado pela região ou partição mais ativa: à primeira vista, parece um comportamento bem-vindo, mas quando o banco tem workloads desiguais, com uma região ou partição sob pressão muito maior do que as outras, isso provoca scale-ups desnecessários e caros.

Agora, a Microsoft cobra os bancos de dados multi-região por região, e não mais com base na região mais ativa. Além disso, o escalonamento passa a acontecer por partição, o que permite uma cobrança mais precisa em relação aos seus padrões de uso.

Dica prática: se sua conta do Azure Cosmos DB foi criada depois de 25/09/2024, você não precisa fazer nada — já está habilitado por padrão. Para contas criadas antes dessa data, dá para ativar seguindo as instruções neste link.

Agora que vimos quais boas práticas são comuns à AWS, ao GCP e ao Azure e como o Azure tem alguns ases na manga para tornar nossos investimentos em nuvem mais eficientes, qual seria o seu próximo passo? Fale com a DoiT, claro, em doit.com/services 😊