Como reduzir o custo de nuvem em projetos de dados

A conta de nuvem cresce mais rápido que o valor entregue#

Quase todo projeto de dados que assumimos para sustentação chega com o mesmo sintoma: a fatura de nuvem sobe todo mês, mas ninguém sabe explicar por quê. O time olha o total, se assusta, e a reação clássica é cortar capacidade no susto ou congelar novas entregas. As duas coisas costumam ser erradas. Descobrir como reduzir o custo de nuvem em projetos de dados não é apertar um botão de economia, é entender onde o dinheiro realmente vai e mexer nas alavancas certas, na ordem certa, sem quebrar o que funciona.

Neste artigo eu vou direto ao ponto com as alavancas que mais movem a agulha em ambientes Microsoft, principalmente Microsoft Fabric e Power BI. Nada de promessa de percentual mágico: o que funciona é disciplina de engenharia somada a monitoramento honesto do consumo.

O custo em dados não é uma coisa só, é uma pilha de decisões#

Antes de otimizar, saiba que a fatura de um projeto de dados é a soma de coisas bem diferentes: computação para processar, computação para servir consultas, armazenamento e movimentação entre camadas. Cada uma tem uma alavanca própria. Tratar tudo como "custo de nuvem" e cortar linear é o caminho mais rápido para degradar performance sem economizar de verdade.

No Fabric, boa parte disso é medida em Capacity Units, ou CUs, a unidade que a plataforma consome quando executa pipelines, atualiza modelos, roda notebooks ou responde consultas. Você contrata uma SKU de capacidade, por exemplo uma F2, F4, F64 e assim por diante, e paga por essa capacidade reservada. Entender que o custo está atrelado a essa capacidade, e não a cada clique isolado, muda completamente a estratégia de otimização.

A tabela abaixo separa as fontes de custo e a alavanca principal de cada uma.

Fonte de custo	O que consome	Alavanca principal
Processamento (ETL/ELT)	Pipelines, notebooks, dataflows	Evitar reprocessar tudo, incremental
Servir consultas	Modelos semânticos, DirectQuery	Modelagem e cardinalidade
Capacidade reservada	SKU do Fabric (CUs)	Dimensionar e pausar
Armazenamento	Dados brutos e transformados	Camadas de armazenamento e retenção
Movimentação de dados	Cópias entre sistemas	Direct Lake, evitar duplicação

Repare que quase nenhuma dessas alavancas é "compre menos nuvem": a maioria é engenharia bem feita. Otimização de custo é, no fundo, um assunto de engenharia de dados e não só de negociação de contrato.

Dimensionar a capacidade do Fabric certo é a primeira decisão#

O erro número um que vejo é gente que provisiona capacidade grande "por garantia" e nunca revisita, pagando mês cheio por recursos que o time nunca usa. Do outro lado existe o erro oposto: espremer tudo numa capacidade pequena demais e sofrer com throttling, filas e atualizações que estouram o tempo.

O caminho honesto é dimensionar com base no consumo real observado, não no medo. Comece modesto, ligue o monitoramento e suba de SKU só quando os dados mostrarem pressão consistente. O Fabric permite escalar a capacidade para cima e para baixo, então tratar o dimensionamento como decisão dinâmica, revisada de tempos em tempos, é muito mais barato que fixar um número alto no primeiro dia.

Vale também separar cargas. Desenvolvimento, homologação e produção competindo na mesma capacidade criam picos que forçam você a superdimensionar. Isolar ambientes, mesmo em capacidades menores, costuma sair mais barato e previsível do que uma capacidade única e gigante tentando absorver tudo.

Pausar recurso ocioso é dinheiro parado na mesa#

Essa é a alavanca mais subestimada e uma das mais imediatas. A capacidade do Fabric pode ser pausada, e enquanto está pausada ela não consome. Se o seu ambiente de desenvolvimento não roda de madrugada, no fim de semana e nos feriados, por que ele fica ligado nesses períodos? Uma capacidade de dev ou homologação usada só em horário comercial pode ficar pausada boa parte do calendário.

Isso vale especialmente para ambientes que não são produção. Ninguém precisa de dev disponível às três da manhã de domingo. Automatizar a pausa e o retorno da capacidade em janelas previsíveis é um dos ganhos mais limpos que existem: não afeta nenhum usuário final e não exige reescrever pipeline nenhum.

A tabela a seguir resume onde a pausa faz sentido.

Ambiente	Padrão de uso	Estratégia de pausa
Produção	Consultas ao longo do dia	Manter ativo, dimensionar bem
Homologação	Testes em janelas de release	Pausar fora dos testes
Desenvolvimento	Horário comercial	Pausar à noite e fins de semana
Ambiente de POC	Uso pontual	Pausar sempre que não estiver em uso

A regra mental é simples: se ninguém está usando e nada crítico está rodando, aquilo deveria estar pausado. Recurso ligado sem trabalho é desperdício puro.

Atualização incremental no Power BI para de reprocessar o passado#

Aqui está uma das maiores fontes de custo escondido em BI. Muita gente configura o modelo do Power BI para recarregar a base inteira toda vez que atualiza. Se você tem cinco anos de histórico de vendas e atualiza tudo de novo várias vezes por dia, está gastando computação para reprocessar dados que não mudaram desde 2021. Isso é caro e é lento.

A atualização incremental resolve isso processando apenas a janela nova de dados. Você define uma política, por exemplo manter três anos de histórico e atualizar somente os últimos sete dias, e o Power BI passa a carregar só o que mudou. O histórico antigo fica particionado e intocado. O resultado é atualização mais rápida, menos pressão na capacidade e menos consumo de CUs por refresh.

Na prática, essa mudança costuma ser uma das primeiras que aplicamos em projetos de Power BI que chegam pesados. Se o seu modelo grande ainda faz full refresh, provavelmente há economia esperando ali com pouco esforço.

Evitar reprocessar tudo vale para o pipeline inteiro, não só o BI#

O mesmo princípio se aplica ao ETL como um todo. Pipeline que trunca a tabela e reconstrói do zero a cada execução é confortável de escrever e caro de rodar: sempre que o volume cresce, o custo cresce junto, de forma linear e sem necessidade.

Trabalhar com cargas incrementais, capturando apenas registros novos ou alterados, é o que separa um pipeline sustentável de um que vira problema de fatura. Combine isso com uma arquitetura em camadas bem desenhada, onde o dado bruto é ingerido uma vez e as transformações reaproveitam o que já foi processado, e você para de pagar várias vezes pela mesma computação. Vale a leitura sobre como estruturar isso no Microsoft Fabric.

Um bom teste diagnóstico: pergunte ao time quanto do que roda todo dia processa dados que não mudaram. Se a resposta for "quase tudo", você achou uma mina de economia.

Modelar para reduzir cardinalidade encolhe o modelo e a conta#

Essa alavanca é técnica, mas o impacto é grande e pouca gente aproveita. O Power BI e os modelos semânticos do Fabric usam o motor VertiPaq, que comprime os dados em colunas. E o VertiPaq comprime muito melhor colunas com baixa cardinalidade, ou seja, colunas com menos valores distintos. Quanto mais valores únicos uma coluna tem, pior a compressão e maior o modelo na memória.

O caso clássico é a coluna de data e hora com precisão de segundo: ela pode ter milhões de valores distintos e infla o modelo sozinha. Separar data e hora em colunas diferentes, ou reduzir a granularidade do tempo para o que o negócio usa, derruba a cardinalidade e a compressão dispara. O mesmo vale para chaves gigantes, colunas de texto livre e campos de alta precisão numérica que ninguém consulta.

Modelo menor consome menos memória, cabe em capacidade menor e responde consulta mais rápido, o que reduz o consumo ao servir. É uma daquelas otimizações em que performance e custo andam juntos. As boas práticas estão detalhadas no guia de modelagem e DAX no Power BI, e valem cada minuto para quem paga a conta.

Algumas ações concretas que rendem redução de cardinalidade:

• Quebrar datetime em data e hora separadas quando a hora não precisa de precisão de segundo.
• Remover colunas não usadas, porque coluna que ninguém consulta ainda ocupa memória e piora a compressão geral.
• Reduzir precisão numérica onde o negócio não exige casas decimais extremas.
• Evitar chaves textuais longas e preferir chaves inteiras compactas nos relacionamentos.

Camadas de armazenamento colocam o dado no lugar certo pelo preço certo#

Nem todo dado precisa estar no armazenamento mais rápido e caro. O armazenamento em nuvem tem camadas com custos diferentes: uma camada quente para dados acessados com frequência e camadas mais frias e baratas para o que raramente alguém consulta. Manter cinco anos de log de auditoria na mesma camada premium do dashboard do dia é pagar preço de primeira classe por bagagem que fica no porão.

A estratégia é definir política de retenção e ciclo de vida: dado recente e consultado fica na camada quente, dado histórico e frio migra para camadas mais baratas, e o que passou do prazo de retenção é arquivado ou descartado conforme a regra de negócio e de compliance. Isso reduz custo sem tirar nada de relevante do alcance de quem usa.

Vale um alerta honesto: armazenamento costuma ser a menor fatia da conta na maioria dos projetos de BI, onde computação domina. Não comece por aqui. Mas em ambientes com muito dado bruto retido, essa alavanca deixa de ser detalhe e vira uma linha visível na fatura.

Direct Lake evita a cópia que você pagava sem perceber#

Um custo silencioso em arquiteturas antigas é a duplicação de dados. O modelo tradicional importava os dados do lake para dentro do modelo semântico, criando uma cópia que precisava ser armazenada, atualizada e mantida em sincronia. Você pagava armazenamento duas vezes e computação para manter a cópia em dia.

O Direct Lake do Fabric ataca justamente isso: o modelo semântico lê os dados direto do OneLake, sem importar e sem criar cópia paralela, com performance próxima da importação. Menos cópia significa menos armazenamento redundante e menos processos de atualização gastando capacidade só para copiar dado de um lugar para outro. Para quem desenha arquitetura nova no Fabric, é uma decisão que reduz custo por construção.

Monitorar consumo é o que impede a próxima surpresa#

Todas as alavancas acima falham sem a última: monitoramento. Não dá para otimizar o que você não mede. O Fabric oferece formas de acompanhar o consumo de capacidade, e o mínimo aceitável é ter visibilidade de qual item, pipeline e modelo está queimando capacidade. Sem isso, você corta às cegas.

O que recomendamos como higiene básica de FinOps em dados:

• Acompanhar o consumo de capacidade de forma recorrente, não só quando a fatura assusta.
• Identificar os maiores consumidores, porque a regra de Pareto vale aqui: poucos itens costumam explicar a maior parte do custo.
• Definir alertas para picos e para uso próximo do limite da capacidade, evitando throttling e surpresa.
• Revisar o dimensionamento periodicamente, subindo ou descendo de SKU conforme o dado real, não a intuição.

Monitoramento contínuo é também o que sustenta as economias no tempo. Otimização não é evento único, é rotina. É esse acompanhamento que entra num bom serviço de sustentação de BI, onde alguém olha o consumo com regularidade e age antes de a conta virar problema.

Perguntas frequentes#

Reduzir custo de nuvem sempre significa piorar a performance? Não, e essa é a boa notícia. Várias alavancas melhoram custo e performance juntas: reduzir cardinalidade deixa o modelo mais leve e rápido, a atualização incremental encurta o refresh, pausar dev não afeta produção. Corte cego é que piora tudo, otimização bem feita não.

Por onde eu começo se tenho um orçamento apertado de tempo? Comece pelo que dá retorno rápido e baixo risco: pause ambientes ociosos, ligue monitoramento de consumo e configure atualização incremental nos modelos grandes. São três ações que não exigem reengenharia e já mudam a curva da fatura.

Vale a pena migrar para o Direct Lake só por causa de custo? Depende do estágio. Para arquitetura nova no Fabric, Direct Lake evita duplicação por construção e é escolha natural. Para um ambiente estável que já funciona bem em import, a migração precisa ser avaliada caso a caso, pesando esforço e ganho real. Não migre por moda, migre por conta.

Diminuir a capacidade do Fabric é a forma mais fácil de economizar? É a mais tentadora e também a mais arriscada se feita sem dado. Cair de SKU sem entender o consumo gera throttling, filas e atualizações que estouram. O certo é dimensionar pelo consumo monitorado, e frequentemente você economiza mais pausando ocioso e otimizando modelos do que descendo de capacidade.

Armazenamento é onde eu mais economizo em um projeto de BI? Normalmente não. Na maioria dos projetos de BI, computação domina a conta e armazenamento é a menor fatia. Camadas de armazenamento ajudam em ambientes com muito dado bruto retido, mas começar por aí num projeto típico é gastar energia na alavanca de menor impacto.

Como manter a economia depois de otimizar uma vez? Com rotina de monitoramento e revisão. Otimização de custo não é projeto com data de fim, é disciplina contínua. Consumo muda, volume cresce, novos relatórios entram. Sem acompanhamento recorrente, a fatura volta a subir. Por isso tratamos FinOps como parte da sustentação.

Como reduzir o custo de nuvem em projetos de dados sem sacrificar entrega#

Reduzir custo de nuvem em dados não é achar um desconto escondido, é engenharia disciplinada: dimensionar a capacidade pelo consumo real, pausar o que está ocioso, processar só o que mudou, modelar para comprimir bem, colocar cada dado na camada certa, evitar cópias desnecessárias e monitorar de perto. Cada alavanca sozinha ajuda, juntas elas transformam a curva da fatura.

Se a sua conta de nuvem cresce e ninguém no time consegue explicar por quê, esse é o momento de olhar com método: fale com a gente e a gente ajuda a mapear onde o dinheiro está indo e quais alavancas puxar primeiro.