Conheça 7 sinais sutis na sua fatura de nuvem que podem indicar antipadrões ou gastos excessivos — e o que fazer em cada caso.
Quando o assunto é otimizar custos de nuvem, às vezes é preciso ler nas entrelinhas da fatura.
A gente costuma olhar para os picos óbvios de custo, mas e os sinais mais sutis, escondidos no meio dos números?
Em um episódio recente do podcast Cloud Masters, reunimos três Technical Account Managers (TAMs) da DoiT para apontar sete sinais de alerta nada óbvios que eles identificaram nas faturas de nuvem dos clientes — e falar sobre o que fazer em cada situação.
Não estamos falando dos picos de custo "escancarados" de sempre; são pistas mais sutis de que algo pode não estar redondo, indicando gastos excessivos ou práticas pouco eficientes.
Confira o episódio completo abaixo ou continue rolando enquanto destrinchamos cada sinal e damos dicas práticas.
Sinal de alerta #1: Você está pagando pelo AWS CloudTrail
Se você está pagando pelo CloudTrail de qualquer valor, já tem aí uma oportunidade de economizar na fatura de nuvem. O primeiro trail do CloudTrail em uma região é gratuito, e o seu único trail deveria estar no nível da AWS Organization, já que os trails de Organization são criados automaticamente em todas as contas membro.
Vale lembrar que o novo trail é criado somando-se a quaisquer trails já existentes nas contas membro. Ou seja, se você criou trails separados em contas membro no passado, dá para economizar removendo-os.
Criar o trail do CloudTrail no nível da Organization ajuda a aplicar e padronizar a estratégia de log de eventos em todas as contas da organização, porque a configuração do trail da organização se propaga para todas elas. Por isso, vale conferir se a configuração do seu trail de Organization corresponde à forma como você quer os trails configurados em todas as contas dentro dela.
Sinal de alerta #2: Custos de armazenamento sobem de forma constante por falta de políticas de ciclo de vida dos dados
Se os seus custos de armazenamento na nuvem vêm crescendo de forma constante, isso pode ser sinal de que faltam políticas de ciclo de vida de objetos bem aplicadas.
Essas políticas automatizam a transição de dados para diferentes classes de armazenamento ou a exclusão deles com base em regras predefinidas, alinhando o custo ao valor e à acessibilidade dos dados. Assim, você não paga a mais para armazenar informações que não precisam de acesso imediato ou que já estão obsoletas.
Sem políticas de ciclo de vida, sobra acúmulo de dados, um repositório de logs que só cresce e/ou snapshots em excesso. Resultado: os custos de armazenamento sobem, principalmente quando dados antigos ou pouco acessados continuam em camadas de alto custo.
Na maioria dos casos, basta migrar de classe ou expirar os objetos depois de 30 a 90 dias. Mas o sinal claro de que vale olhar o armazenamento mais de perto é ver os custos em alta.
Sinal de alerta #3: Custos da API GetMetricData do CloudWatch estão altos
Serviços de terceiros como New Relic e Datadog varrem suas contas de nuvem — geralmente as métricas do CloudWatch — com frequência para ter informações atualizadas sobre o uso.
O que muita gente não percebe é que você também paga pelas requisições de API que esses serviços fazem. Elas aparecem no CloudWatch sob o SKU da API "GetMetricData". Sem cuidado, dá para gastar uma fortuna com CloudWatch só por causa dessas chamadas vindas das ferramentas de terceiros.
Por isso, fique de olho em:
- A frequência dessas chamadas de API; e
- Quais métricas e dados estão sendo varridos.
Por exemplo: você pode ter uma conta de dev com muitos recursos gastando bastante com CloudWatch porque as chamadas de API acontecem a cada minuto. Em casos assim, vale se perguntar se essa frequência — e talvez essa granularidade de dados — é mesmo necessária.
Para reduzir os custos do CloudWatch ligados a essas chamadas, em muitos casos basta pedir aos serviços de terceiros que ajustem a frequência e as métricas coletadas para contas/projetos específicos.
Sinal de alerta #4: Custos de logging passam de 20% da sua fatura de nuvem
O logging é essencial para monitoramento e troubleshooting, mas em excesso ele infla a fatura de nuvem.
Como na dica sobre chamadas de API do sinal anterior, vale se perguntar se a frequência e as métricas que você coleta nos logs combinam com o caso de uso. Por exemplo, se você está alimentando um dashboard com dados de logs, não precisa necessariamente de atualizações por segundo — uma a cada cinco minutos pode dar conta.
Como regra geral, você não deveria gastar mais de 20% da fatura de nuvem com logging. Se está acima desse limite, é sinal de que vale olhar mais de perto o que compõe esses custos. Pergunte aos times que usam os logs para que eles servem; é bem provável que dê para ajustar a frequência ou as métricas coletadas.
Aproveite também para olhar com atenção o logging em ambientes de não produção, já que eles não geram receita. Provavelmente você não precisa da mesma frequência ou das mesmas métricas usadas em produção. Se algo quebra fora da produção, basta ligar e desligar os logs — diferente da produção, onde você precisa de mais informação para entender o que deu errado.
Sinal de alerta #5: Não validar decisões com outras áreas
Esse sinal não é um item específico que você consegue ver na fatura ou em um relatório de custo e uso, mas deixar de validar suas decisões de tecnologia e arquitetura com outras áreas pode virar dor de cabeça na fatura de nuvem e em performance lá na frente.
Um exemplo bem comum é uma equipe comprar um desconto de commitment (por exemplo, um Savings Plan) de forma isolada, sem considerar a estratégia organizacional mais ampla nem as necessidades de outros times. A área de tecnologia pode estar planejando ir para serverless nos próximos dois anos, mas, do nada, alguém compra um Savings Plan de 3 anos e prende todo mundo ao uso de VMs.
Não existe decisão "objetivamente certa" quando se constrói na nuvem. Decidir de forma isolada leva a ineficiências e custos maiores. Pergunte-se como você está validando internamente, com colegas e/ou outras áreas, se as suas decisões fazem sentido. Na prática, isso pode significar conferir as decisões de infraestrutura de nuvem em relação à estratégia e visão de engenharia, ou aos documentos RFC/ADR relevantes.
Sinal de alerta #6: Você não está limitando regiões e tipos de instância com políticas organizacionais
As políticas organizacionais (veja a documentação do Google Cloud e da AWS) ajudam a definir como os usuários da sua nuvem podem acessar, utilizar e gerenciar os recursos da empresa.
Do ponto de vista de otimização de custos (e de segurança), elas são especialmente úteis para garantir que ninguém suba serviços onde não deveria.
Mais especificamente, sem políticas organizacionais para restringir tipos de instância e regiões, sua infraestrutura de nuvem fica exposta a vulnerabilidades de segurança e ao risco de gastos excessivos. Agentes maliciosos podem se aproveitar dessa falta de controle para subir instâncias em regiões não utilizadas, fugindo da detecção enquanto agem.
Limite os tipos de instância e as regiões àqueles que você de fato usa, para que ninguém — seja de má-fé ou sem querer — suba, por exemplo, uma instância x1 em vez de uma t4 na América do Sul quando todos os seus recursos estão na Europa.
Com políticas organizacionais bem definidas, você protege o ambiente de nuvem com eficácia e otimiza o uso dos recursos.
Sinal de alerta #7: Excesso de chamadas de API a buckets de armazenamento
Chamadas de API frequentes e desnecessárias a buckets de armazenamento inflam os custos e afetam a performance. Esse sinal aparece em muitas situações diferentes.
Pode ser que sua(s) aplicação(ões) façam chamadas de API constantes a buckets de armazenamento na nuvem. Isso fica ainda mais crítico em aplicações que geram um grande volume de dados ou fazem muitas transferências. Ou pode ser um processo agendado que conversa com os buckets e vai acumulando uma quantidade significativa de chamadas ao longo do tempo.
Além do custo, lembre que chamadas de API muito frequentes também afetam a performance da aplicação, causando lentidão, timeouts e até indisponibilidades.
Sem monitoramento adequado, é fácil gastar demais sem que nenhum alarme dispare — até a fatura chegar ou algum limite de quota ser atingido.
Por isso, revise e otimize o código da aplicação para reduzir o número de chamadas de API necessárias em cada operação. Implemente também mecanismos de cache para manter em memória os dados acessados com frequência, diminuindo a necessidade de chamadas repetidas aos buckets de armazenamento.
Fazendo as perguntas certas sobre a fatura de nuvem
Por mais que a gente liste sinais de alerta para observar, os pontos a investigar são infinitos. Por isso, no longo prazo, é fundamental manter a curiosidade sobre seus gastos de nuvem. Não aceite o valor da fatura como dado. Pergunte por quê — e pergunte de novo.
Por exemplo: se os custos do S3 estão subindo, descubra qual(is) bucket(s) está(ão) puxando esse aumento. Depois, veja quais SKUs são responsáveis pela alta nos buckets. Quando perceber que foram custos de transferência de dados, pergunte para você e para o time se esse aumento de transferência nesses buckets era esperado ou não. Talvez tenha subido por uma boa razão — mas você só vai saber se perguntar.
Com o tempo, isso contribui para uma cultura de otimização de custos em toda a empresa, em que todos têm consciência da sua contribuição para a fatura de nuvem e se sentem à vontade para agir.
Cada um desses sinais reforça a importância da responsabilidade compartilhada e da curiosidade sobre a fatura de nuvem. Identificar essas oportunidades de otimização não pode ficar só nos ombros do Head of Infrastructure ou do FinOps Lead. É uma jornada que só funciona com trabalho em equipe.