Sejamos honestos, olhar para uma fatura da AWS pode parecer que estamos a tentar decifrar um pergaminho antigo. Num mês, os seus custos com o Lambda são uma ninharia, no seguinte disparam e você fica a coçar a cabeça. Não é o único.
A promessa do "pague apenas pelo que usa" parece ótima na teoria, mas a realidade dos preços do Lambda está repleta de variáveis que podem realmente apanhá-lo de surpresa. Este guia está aqui para traduzir esse pergaminho. Vamos desvendar como a AWS calcula a sua fatura, apontar os custos ocultos que são fáceis de ignorar e dar-lhe algumas estratégias reais para colocar os seus gastos com serverless sob controlo.
O que é o AWS Lambda?
Na sua essência, o AWS Lambda é um serviço de computação "serverless" (sem servidor). Ora, este termo é um pouco enganador, porque há definitivamente servidores envolvidos. A parte "serverless" significa apenas que você não tem de os gerir. Basta carregar o seu código e a AWS trata de todo o trabalho de bastidores para o executar e escalar por si.
Eis uma forma simples de pensar nisto: imagine que quer fazer uma sanduíche. Poderia alugar a cozinha de um restaurante inteiro 24/7, pagando por ela mesmo quando está a dormir. Ou, com o Lambda, pode simplesmente alugar uma única torradeira pelos exatos dois minutos que leva a torrar o seu pão. Paga apenas pelo que usa, ao milissegundo.
É por isso que é tão bom para tarefas orientadas a eventos, como redimensionar uma imagem no momento em que é carregada ou processar uma chamada de API, porque não está a pagar por um servidor que fica ocioso à espera que algo aconteça.
Os componentes centrais dos preços do Lambda
Ok, vamos aos pormenores. O modelo de preços do Lambda resume-se essencialmente a duas coisas principais: quantas vezes o seu código é executado (pedidos) e por quanto tempo é executado (duração). Vejamos cada uma delas.
Número de pedidos
Cada vez que a sua função Lambda é acionada para fazer o seu trabalho, isso é um "pedido". Não importa se é um evento de um bucket S3 ou uma chamada de API direta, cada execução conta como uma.
A boa notícia? A AWS começa por lhe dar um brinde bastante generoso. O AWS Free Tier oferece-lhe 1 milhão de pedidos gratuitos todos os meses. Para muitos projetos pequenos ou para simplesmente experimentar, isso é mais do que suficiente.
Depois de ultrapassar a marca de um milhão de pedidos, começa a pagar. A taxa padrão é de 0,20 $ por 1 milhão de pedidos. Parece uma ninharia, e é, mas se tiver uma aplicação com muito tráfego, esses cêntimos podem acumular-se mais rápido do que imagina. Para os números mais recentes, é sempre melhor verificar a página oficial de preços do AWS Lambda.
Duração da computação e memória (GB-segundos)
É aqui que as coisas ficam um pouco mais interessantes. Além de pagar por cada pedido, também paga pelo tempo em que o seu código está realmente a ser executado, medido ao milissegundo. Mas aqui está o truque: o preço que paga por esse tempo depende da quantidade de memória (RAM) que atribui à sua função.
Quando configura uma Lambda, escolhe um tamanho de memória entre 128 MB e 10.240 MB. Atribuir mais memória também lhe dá mais poder de CPU, o que pode fazê-la executar mais rapidamente, mas também custa mais por milissegundo. Esta combinação de memória e tempo é o que a AWS chama de "GB-segundos".
Tal como com os pedidos, existe um nível gratuito que inclui 400.000 GB-segundos de tempo de computação por mês. Assim que esgotar esse limite, paga pelo que usar. Para ter uma ideia, veja como o preço por milissegundo muda à medida que adiciona mais memória:
| Memória (MB) | Preço por 1ms (x86) | Preço por 1ms (Arm/Graviton2) |
|---|---|---|
| 128 | 0,0000000021 $ | 0,0000000017 $ |
| 512 | 0,0000000083 $ | 0,0000000067 $ |
| 1024 | 0,0000000167 $ | 0,0000000133 $ |
| 10240 | 0,0000001667 $ | 0,0000001333 $ |
Para além do básico: Outros fatores que afetam a sua fatura
Então, já calculou os seus pedidos e os seus GB-segundos, mas a sua fatura ainda é mais alta do que esperava. O que se passa? Provavelmente são alguns destes custos "ocultos" que nem sempre são óbvios à primeira vista. Vamos analisar os culpados mais comuns.
Escolhas de arquitetura de CPU
Pode escolher o processador para as suas funções: o padrão x86 ou os chips Graviton2 baseados em Arm da própria AWS. Para muitas cargas de trabalho, simplesmente mudar para o Graviton2 pode proporcionar uma melhor relação preço-desempenho, por vezes poupando uma quantia considerável sem ter de mexer no seu código.
Concorrência provisionada
Se a sua função tem absolutamente de responder instantaneamente sem qualquer atraso de "cold start" (arranque a frio), pode pagar pela Concorrência Provisionada. Basicamente, isto mantém um certo número das suas funções "aquecidas" e prontas a arrancar a qualquer momento. É uma ótima funcionalidade para aplicações críticas em termos de desempenho, mas tenha em atenção que tem o seu próprio preço e não está coberta pelo nível gratuito.
Custos de armazenamento de ficheiros temporários
Cada função Lambda vem com um pequeno espaço de armazenamento temporário gratuito (512 MB, para ser exato) num diretório "/tmp". Se o seu código precisar de mais espaço para manipular ficheiros ou dados temporários, pode configurar mais, mas ser-lhe-á cobrado qualquer armazenamento que adicione para além dessa quantidade inicial gratuita.
Transferência de dados: Um custo oculto
Este é o clássico "apanhado" que engana tanta gente. Mover dados não é gratuito. Se a sua função Lambda extrai dados da internet, ou envia dados para a internet ou mesmo para outra região da AWS, ser-lhe-á cobrado pelas taxas de transferência de dados padrão. Para aplicações que movem muitos dados, estas cobranças podem ser uma verdadeira surpresa.
Outros serviços da AWS
Lembre-se, as suas funções Lambda raramente vivem isoladas. Geralmente, estão a comunicar com outros serviços da AWS, como o API Gateway, S3 ou DynamoDB. Cada um desses serviços tem a sua própria fatura. É fácil focar-se no custo do Lambda e esquecer que todos os serviços a que ele se liga também estão a somar ao seu total mensal.
Este vídeo oferece um resumo conciso de como são calculados os preços do AWS Lambda.
Preços do Lambda vs. EC2: Quando é que o serverless deixa de ser mais barato?
Esta é a grande questão, certo? Quando faz sentido usar o Lambda e quando é que um bom e velho servidor virtual EC2 é, na verdade, a opção mais barata?
Para cargas de trabalho irregulares e imprevisíveis com muito tempo de inatividade, o Lambda é quase sempre o vencedor. Não está a pagar por um servidor que fica ocioso. Mas se tiver uma carga de trabalho estável e de alto volume que mantém um servidor ocupado 24/7, a taxa horária fixa de uma instância EC2 acabará por ser mais económica do que pagar por milhões de execuções individuais do Lambda.
Mas não se esqueça dos custos ocultos de gerir uma instância EC2. Com um servidor virtual, a sua equipa é responsável por aplicar patches ao sistema operativo, gerir a segurança e configurar o escalonamento. O Lambda trata de tudo isso por si, o que liberta os seus programadores para fazerem o que fazem de melhor: construir coisas.
O impacto empresarial de preços imprevisíveis
O problema com os preços do Lambda não é apenas uma dor de cabeça técnica; é também um problema de negócio. Como se pode definir um orçamento quando os seus custos operacionais principais podem oscilar drasticamente de um mês para o outro? Uma campanha de marketing bem-sucedida ou, pior, um ataque de bots maliciosos pode fazer a sua fatura disparar sem aviso.
Este tipo de incerteza financeira não é apenas um problema da infraestrutura na nuvem. Estamos a vê-lo surgir com muitas novas ferramentas de IA, especialmente no apoio ao cliente. Muitas delas cobram por ticket resolvido ou por conversação de IA. De certa forma, este modelo castiga-o por crescer. Quanto mais clientes ajuda, mais alta sobe a sua fatura de IA, tornando impossível prever as suas despesas.
Como a eesel AI oferece preços previsíveis para uma IA poderosa
Achamos que essa é uma forma retrógrada de fazer as coisas. Na eesel AI, acreditamos que as suas ferramentas devem apoiar o seu crescimento, não penalizá-lo por isso. É por isso que construímos a nossa plataforma em torno de preços previsíveis e transparentes desde o primeiro dia.
Vimos a ansiedade que a faturação baseada no uso causa e decidimos oferecer uma alternativa clara. Temos planos de preços simples e de taxa fixa que não lhe cobram por resolução. Isso significa que pode lidar com um enorme afluxo de perguntas de clientes sem se preocupar com uma fatura surpresa no final do mês. Pode escalar o seu apoio e o seu negócio com confiança.
Até criámos um modo de simulação na eesel AI que lhe permite testar a IA nos seus tickets de apoio anteriores. Pode ver uma estimativa sólida das suas taxas de resolução e do ROI antes mesmo de se comprometer, eliminando mais uma camada de incerteza da equação.
Assuma o controlo dos seus preços do Lambda
O AWS Lambda é uma ferramenta fantástica, mas o seu modelo de preços tem uma curva de aprendizagem. Assim que tiver um bom domínio sobre os pedidos, os GB-segundos e todos aqueles custos extra sorrateiros, pode usá-lo de forma poderosa sem ir à falência.
No final de contas, quer esteja a escolher um serviço na nuvem ou uma ferramenta de IA, a lição é a mesma: a previsibilidade importa. Optar por parceiros e plataformas com modelos de preços claros e transparentes não se trata apenas de poupar dinheiro; trata-se de poder fazer crescer o seu negócio sem ansiedade financeira constante. Foi por isso que construímos a eesel AI da forma como o fizemos, para lhe dar uma coisa a menos com que se preocupar.
Perguntas frequentes
Os componentes centrais dos preços do Lambda são o número de pedidos que a sua função processa e a duração da computação (GB-segundos), que combina o tempo de execução da função e a memória alocada. A AWS também oferece níveis gratuitos generosos tanto para pedidos como para duração da computação.
Para estimar os seus preços do Lambda, precisa de prever o número esperado de invocações (pedidos) e a duração/uso de memória médios (GB-segundos) por invocação. A AWS fornece uma calculadora de preços, e monitorizar o uso inicial pode ajudar a refinar as suas projeções.
Além dos pedidos centrais e dos GB-segundos, os fatores ocultos podem incluir custos de transferência de dados, a despesa da Concorrência Provisionada, cobranças por armazenamento adicional de ficheiros temporários e os custos de outros serviços da AWS com os quais a sua função Lambda interage. Estes podem ter um impacto significativo na sua fatura total.
Embora o Lambda seja excelente para cargas de trabalho irregulares ou imprevisíveis, uma instância EC2 tradicional pode ser mais económica para aplicações estáveis e de alto volume que funcionam continuamente 24/7. Em tais cenários, a taxa horária fixa do EC2 pode eventualmente superar os custos por invocação do Lambda.
A alocação de memória afeta diretamente o componente GB-segundos dos preços do Lambda. Mais memória normalmente fornece mais poder de CPU, o que pode levar a tempos de execução mais rápidos. Por vezes, aumentar a memória resulta numa duração mais curta, tornando o custo global de GB-segundos mais baixo, apesar de uma taxa por milissegundo mais alta.
Sim, para muitas cargas de trabalho, migrar as suas funções Lambda para processadores Graviton2 baseados em Arm pode levar a poupanças de custos significativas. O Graviton2 oferece frequentemente uma melhor relação preço-desempenho em comparação com os processadores x86, reduzindo potencialmente os seus custos de duração da computação sem necessidade de alterações no código.
Compartilhe esta postagem
Article by
Kenneth Pangan
Writer and marketer for over ten years, Kenneth Pangan splits his time between history, politics, and art with plenty of interruptions from his dogs demanding attention.
