Como Cortamos uma Conta de Lambda em 96% em um Ambiente AWS que Ninguém Achava Ser um Problema

O cliente é um grupo global de serviços financeiros com operações em múltiplas jurisdições. A plataforma roda na AWS — onde esta história se passa. Quando começamos a olhar o ambiente, o Lambda saltou aos olhos quase imediatamente como um grande dreno de custo. Não é algo que eles conseguiriam identificar sozinhos, e vale explicar o porquê.

O Problema de Visibilidade

Por padrão, a AWS não mostra custo por recurso individual. O console mostra o custo por serviço. Você consegue ver “o Lambda nos custou X esse mês”, mas não consegue ver qual função Lambda específica é responsável por esse número, ou qual padrão de invocação está gerando o custo.

A única forma de obter esse nível de detalhe é exportar os dados de billing através do CUR (Cost and Usage Report) ou do formato mais novo FOCUS, colocá-los em um lugar consultável e rodar análises em cima. A maioria das equipes de engenharia nunca faz isso. Não é por falta de vontade — é que a configuração não é trivial e a análise em cima dela é ainda mais difícil.

Esse é nosso ponto de partida padrão em qualquer engajamento na AWS. Os dados do CUR são a verdade absoluta.

O que Encontramos

Uma função Lambda era responsável por uma fatia desproporcional do gasto com Lambda. Quando olhamos o que ela estava fazendo, o quadro piorou.

A função estava chamando uma API de terceiro e esperando a resposta. Essa espera levava até 14 minutos por invocação. Além disso, a função tinha sido provisionada com uma alocação de memória alta — provavelmente “para garantir”.

O problema é o seguinte: Lambda é cobrado por tempo multiplicado por memória. Cada gigabyte-segundo de execução custa dinheiro. Uma função que fica parada por 14 minutos esperando o servidor de outra pessoa, com memória alta atrelada a ela o tempo todo, é o pior formato possível para uma carga de trabalho em Lambda. Você está pagando preço cheio por memória que não está fazendo nada — por quase quinze minutos de cada vez.

A Vitória Rápida

Antes de mexer na arquitetura, olhamos a alocação de memória. A função não precisava nem perto do que estava provisionado. Reduzimos a memória em 66%.

Como o preço do Lambda é linear em relação à memória, essa única mudança de configuração cortou o custo da função em 66% da noite para o dia. Sem mudança de código. Sem risco. Apenas uma configuração corrigida.

A Correção de Verdade

A vitória rápida foi boa, mas a arquitetura ainda estava errada. Uma função Lambda não é o lugar certo para esperar 14 minutos por um terceiro. O padrão correto é disparar a requisição, passar para uma fila ou step function, e só retomar a execução quando o terceiro responder. Assim você não está pagando por compute ocioso.

Depois que trabalhamos a mudança arquitetural com a equipe deles e o código foi remodelado em torno de um fluxo event-driven, o custo total dessa carga caiu mais de 96% em relação ao baseline original.

Por que Isso Importa

Duas coisas tinham que ser verdade para essa economia aparecer.

Primeiro, você precisa dos dados de custo no nível do recurso. Sem o CUR ou o FOCUS implementado, o alto custo desse Lambda era simplesmente invisível. A conta dizia “Lambda” e o número parecia o que números de Lambda costumam ser. Nada chamou atenção.

Segundo, com os dados na mão, você precisa de alguém que saiba lê-los e entender o que a função está realmente fazendo. Saber que o Lambda é cobrado por tempo vezes memória é uma coisa. Saber que uma espera de 14 minutos por um terceiro é um cheiro arquitetural — não apenas um problema de custo — é outra.

Essa é a diferença entre um dashboard de FinOps e FinOps de nível de engenharia. Um dashboard te diz que o Lambda está caro. Nós te dizemos qual função, por que está cara, o que mudar hoje para cortar a conta em dois terços, e o que mudar no próximo trimestre para cortá-la em 96%.

É esse tipo de ganho que a Koritsu foi construída para encontrar.