Como evitar desperdícios em nuvem eliminando os "Cost Smells"

No desenvolvimento de software, chamamos de "Code Smells" todo código ruim que pode gerar um problema na aplicação. De forma análoga, utilizo a ideia de "Cost Smells" para nossas aplicações na nuvem. É um termo que indica sinais de gastos desnecessários que, de forma silenciosa, podem evoluir para uma parte relevante da fatura.

Nesse post, vou comentar alguns dos elementos que já identificamos como “cost smells” na Wiipo. Até costumo brincar que os serviços em nuvem seguem o modelo “Everything as a Cost” (EaaC), ou seja, tudo como custo.

CloudWatch

Um serviço essencial para monitorar as aplicações, registrar logs e ter alarmes. Mas em diversos cenários o Cloudwatch pode virar um vilão em termos de custos como:

• Logs em excesso — Tudo que seu time não usa é custo desnecessário pois, há cobrança por envio (upload) e armazenamento. Então é necessário ajustar os níveis de log em produção. No nosso caso, no último trimestre de 2023 (Figura 1), o custo saltou 214% com a atualização de uma biblioteca do nosso ambiente serverless. E em Maio/25, uma lambda gerou um aumento de 85% até o ajuste.
• Muitos Alarmes — Na empolgação de ativar alarmes, tivemos uma lição EaaC. Em Agosto/2024, nosso custo de CloudWatch saltou 126% (Figura 1). Isso ocorre porque cada dashboard tem custo e os alarmes custam por métrica monitorada. No nosso caso, foram ligados muitos alarmes através de um script. Para corrigir, analisamos cada um dos alarmes de forma individual.

Além dos casos mencionados, o CloudWatch também pode gerar aumento de custo com processamento de logs insights, pois o processamento é por gigabyte. E finalmente, outro ofensor é a retenção excessiva de logs. Na Wiipo, usamos 3 meses de retenção configurado por padrão no projeto serverless.

Figura 1 — Evolução do CloudWatch no ambiente serverless Wiipo

Data Transfer

A transferência de dados é outro elemento que pode gerar custos desnecessários. E isso pode ocorrer por diferentes razões:

• Tráfego entre diferentes AZs ou regiões — Quando há serviços que precisam se comunicar, o custo de transferência de dados pode se tornar um ofensor. No caso da Wiipo, temos dois ambientes em regiões distintas, e precisamos calibrar essa comunicação. Por exemplo, entre Junho e Julho de 2023, o custo aumentou mais de 82% com esse ofensor (Figura 2).
• Transferência para internet — Serviços que precisam enviar/obter muitos dados da internet (como integrações) podem gerar custo alto de data transfer. Na Wiipo, o envio de dados de observabilidade já gerou um impacto significativo no ambiente serverless como mostra a Figura 3. Um custo que se mantinha abaixo de 100 USD, chegou perto de 400 USD por três meses até o ajuste.
• Tráfego via NAT Gateway — Outro ofensor comum é quando são usados serviços da AWS públicos como S3 e Dynamo sem a criação de private links ou endpoints de VPC. Conforme o volume da infra aumenta, esse custo pode ficar significativo.

Figura 2 — Impacto no custo de Data Transfer na comunicação entre 2 regiões da AWS

Figura 3 — Aumento de custo em Data Transfer por envio de dados via internet

Nuvem é Everything as a Cost (EaaC)

Diferente de um ambiente on-premise, soluções que usam serviços gerenciados geram custos em todas as direções. E nem sempre somos treinados a prestar atenção nisso. Pois nosso processo de aprendizado é em geral usando recursos locais, onde exageros em logs, uso de internet, processamento e memória não geram custo adicional.

Na nuvem, existem muitos elementos além de Data Transfer e CloudWatch que podem gerar custos significativos como:

• Dependências entre Lambda — Se uma Lambda chamar outra de forma síncrona, você paga pela execução de ambas ao mesmo tempo. Ou seja, o tempo de espera vira custo. Sempre que possível, use chamadas assíncronas via eventos ou SQS (vide Figura 4).
• Consumo de memória/processamento — Na Wiipo, havia um módulo que rodava em máquinas EC2. Quando migramos para containers (Fargate), o custo aumentou, diferente da nossa expectativa. Foi necessário ajustar a aplicação para remover processos desnecessários e segregar funções em grupos de containers. Pois parte do custo do Fargate é pelo consumo de memória e processamento.

Figura 4 — Custo da Lambda B sendo incorporado na Lambda A

Como evitar surpresas?

A essência em nuvem é projetar, evoluir e modificar a arquitetura continuamente para reduzir custos, reforçando o conceito de "Low cost architecture". Para isso, é preciso ser crítico com os números, acompanhar diariamente, identificar oscilações e aprofundar sobre cada serviço periodicamente.

De forma resumida, o que buscamos na Wiipo para combater os Cost Smells são ações como:

• Conhecer os números — Só há gestão sobre o que você entende e acompanha;
• Cuidado com a vaidade — Olhar de forma crítica os volumes e a performance sem se deixar levar pelo orgulho de grandes números;
• Revise/Inspecione/Questione — Atuar com uma visão externa ajuda o time a identificar desperdícios. Selecione elementos e aprofunde com eles a razão de cada consumo e a utilidade dos logs gerados;
• Reforce conceitos — O uso de modelos assíncronos, arquitetura de baixo custo deve ser compartilhado com o time constantemente. É uma construção cultural.
• Métricas cruzadas — Analise o custo do ambiente através de elementos como número de usuário e quantidade de chamadas. Isso permite avaliar se o custo está se mantendo estável ou aumentando, um sinal de Cost Smell.