Cloud no Brasil: onde a conta escapa e como achar a sua gordura

Se você opera na nuvem no Brasil já sentiu no bolso: a conta chega em reais, mas o preço é cotado em dólar, e ainda há imposto por cima. Some a isso as APIs de inferência cobradas por token e a cobrança por requisição do serverless, e gerenciar custo de cloud deixou de ser tarefa de fim de trimestre.

Uma nota sobre números, antes de qualquer coisa. Este post não traz tabela de preço. A versão anterior dele trazia duas dezenas de valores em reais e dólares, sem fonte e sem data, e foram removidos porque eu não consigo rastrear de onde saíram. Preço de cloud é a coisa mais perecível que existe num artigo técnico: um número sem data é uma afirmação sobre um dia que ninguém sabe qual foi. O que sobrevive à data é a estrutura: quais linhas da fatura crescem sozinhas e por quê, e é ela que está abaixo, com o roteiro para você levantar os números do seu caso, na data de hoje, na sua região.

---

1. Por que a mesma arquitetura custa mais aqui

Três camadas se empilham entre o preço de tabela e o que sai do seu caixa:

Câmbio. O preço é definido em dólar e a receita da sua empresa é em real. A conta de cloud é, na prática, uma posição vendida em dólar que você renova todo mês sem perceber.

Impostos sobre serviço importado. A carga que incide sobre serviço de nuvem contratado de fora não é pequena e não aparece na calculadora do fornecedor. Peça a fatura discriminada antes de comparar qualquer coisa com preço de tabela gringo: é lá que a diferença aparece.

Prêmio de região. A mesma instância custa diferente por região, e a região brasileira raramente é a mais barata do catálogo. Isso é uma decisão de arquitetura, não um imposto: se a latência para o usuário final não é crítica (API interna, processamento em lote, público global), a região deixa de ser obrigação e vira escolha.

A consequência prática: serviço com preço global único, os que cobram o mesmo independentemente de onde rodam, escapa das três camadas de uma vez. É a maior alavanca isolada disponível para quem fatura em real.

---

2. Os quatro lugares por onde a conta escapa

Egress

Dado que sai da nuvem costuma ser cobrado por gigabyte, e é o custo que ninguém projeta porque não aparece em nenhum diagrama de arquitetura. Ele cresce com o sucesso do produto: quanto mais gente baixa o seu conteúdo, mais você paga por tráfego que o seu código nem viu passar.

O que fazer: descubra qual fração da sua fatura é transferência de dados antes de otimizar qualquer outra coisa. Se for material, armazenamento de objeto sem cobrança de egress e CDN na frente resolvem mais do que qualquer tuning de instância.

Cobrança por requisição

Serverless é conveniente e a conveniência tem preço por evento. Enquanto o tráfego é irregular, ela ganha: você não paga pelo servidor parado. A partir do momento em que o tráfego vira constante, a conta inverte: você passa a pagar por requisição uma carga que uma instância reservada atenderia por um valor fixo.

O ponto de virada não é opinião, é aritmética: pegue o seu volume de requisições do mês, multiplique pelo preço por requisição do dia, e compare com o preço mensal da menor instância que aguenta o pico. Se a segunda ganhar, o serverless está te cobrando conveniência que você não está usando.

Dois casos em que ele quase sempre perde:

• Tráfego constante. API que recebe carga estável o tempo todo é o pior caso de cobrança por evento.
• Processamento em lote. Job noturno previsível não precisa de elasticidade: precisa de máquina barata, e instância interrompível é a mais barata que existe.

E um detalhe de faturamento que morde: função que roda por mais de um segundo acumula rápido, porque a cobrança é por fração de tempo de execução. Cold start, além de latência para o usuário, é tempo de inicialização que entra nessa conta.

Serviço gerenciado

Banco gerenciado, fila gerenciada, busca gerenciada: você paga um múltiplo do custo bruto da máquina para não cuidar de backup, replicação e atualização. Às vezes vale muito. O erro é não saber que está pagando isso, a decisão só é defensável se alguém já comparou o múltiplo com o custo da hora de quem cuidaria.

Inferência de IA por token

É o item mais novo e o que mais pega time desprevenido, porque o custo cresce com o uso e não com a infraestrutura. Quatro alavancas, em ordem de retorno:

1. Modelo do tamanho da tarefa. Classificar sentimento e gerar código não precisam do mesmo modelo. Os modelos pequenos da mesma família costumam custar uma ordem de grandeza menos, e resolvem a maior parte dos casos de uso reais de uma aplicação.
2. Cache. Pergunta repetida não precisa de resposta nova. E há um segundo tipo de cache, o de prefixo: se o começo do seu prompt é sempre igual (instruções + ferramentas), dá para pagar por ele quase uma vez em vez de uma vez por mensagem. Meça o prefixo antes de decidir, a economia é proporcional à fração estável do payload, e essa fração você consegue medir.
3. Lote. Vários fornecedores cobram menos por processamento assíncrono, em troca de você aceitar o resultado mais tarde. Se o caso de uso tolera espera, é desconto sem contrapartida técnica.
4. Modelo local. Elimina o custo por token e o troca por custo de máquina. Vale quando o volume é alto e constante, que é exatamente o caso em que o custo por token dói.

---

3. As alavancas de redução, em ordem de esforço

Da mais barata de aplicar para a mais cara:

Instância interrompível para carga tolerante a falha. Processamento em lote, job noturno, CI/CD e ambiente de homologação não precisam de garantia de disponibilidade. É a alavanca com melhor relação economia/risco do catálogo.

Cache na borda. Conteúdo semi-estático, painel, catálogo, resposta de consulta, servido da borda não chega ao seu backend. Corta duas linhas da fatura ao mesmo tempo: computação e transferência.

Armazenamento sem egress. Trocar o armazenamento de objeto por um que não cobra saída é uma migração de dias, não de meses, e o efeito aparece na primeira fatura.

Função na borda no lugar da função regional. Quando o preço é global e único, some o prêmio de região junto com o câmbio da região.

Compromisso de uso. Para carga estável (banco, servidor de aplicação), os planos de compromisso de um ano existem justamente porque a carga é previsível. É desconto por dizer em voz alta o que você já sabia.

---

4. Como achar a SUA gordura

Não existe percentual médio de desperdício, e quem te oferece um está chutando. Existe um roteiro, e ele cabe em uma tarde:

1. Baixe a fatura discriminada dos últimos três meses. Três, não um: você precisa enxergar o que cresce.
2. Agrupe por natureza, não por serviço. Computação, armazenamento, transferência, gerenciado, inferência. É esse agrupamento que revela onde o dinheiro está, a visão por serviço esconde o egress espalhado em cinco linhas.
3. Ordene por valor e pare no que soma 80%. Otimizar a linha de baixo da fatura é o passatempo favorito de quem não quer mexer na de cima.
4. Para cada linha do topo, pergunte a natureza dela. Se é transferência, veja a seção sobre egress. Se é por requisição, faça a aritmética do ponto de virada. Se é gerenciado, compare o múltiplo com a hora de quem cuidaria. Se é por token, aplique as quatro alavancas na ordem.
5. Anote a data de cada preço que você usar na conta. Refaça em seis meses. O único jeito de uma comparação de preço continuar verdadeira é ela ter uma data colada.
6. Meça o depois com o mesmo agrupamento. Só assim a economia é sua e verificável, em vez de um percentual que alguém publicou num blog.

---

5. Conclusão

Cloud no Brasil exige duas decisões que nada têm a ver com tuning: onde a carga roda (região tem prêmio; preço global único não tem) e como ela é cobrada (por requisição, por gigabyte que sai, por múltiplo de gerenciamento, por token). Quase toda economia relevante vem de mudar uma dessas duas, não de apertar parâmetro.

E vale para este post como vale para qualquer outro sobre preço: se ele não te disser quando o número foi conferido, trate o número como uma história, não como um dado.

---

Douglas Haruo, engenheiro de software há 15 anos, cinco deles em risco e fraude numa fintech de pagamentos. haruo.dev