Snowflake Cloud Services: preços e monitoramento

O cálculo é feito diariamente, no fuso UTC. O Snowflake soma os créditos de computação dos warehouses e os créditos de cloud services consumidos no dia. O ajuste corresponde ao menor valor entre: (10% dos créditos de warehouse) ou (créditos de cloud services usados). O valor cobrado é o total de créditos de cloud services menos esse ajuste.

Exemplo 1: abaixo do limite (sem cobrança)

• Computação de warehouse: 100 créditos
• Cloud services: 8 créditos
• Ajuste: 8 créditos (o cloud services ficou abaixo do limite de 10%)
• Cloud Services cobrado: 0 créditos
• Total cobrado: 100 créditos

Exemplo 2: acima do limite (cobrança parcial)

• Computação de warehouse: 100 créditos
• Cloud services: 20 créditos
• Ajuste: 10 créditos (o valor correspondente ao limite de 10%)
• Cloud Services cobrado: 10 créditos
• Total cobrado: 110 créditos

Exceção importante: recursos serverless como Snowpipe, Automatic Clustering e Materialized Views NÃO entram no ajuste de 10%. Eles têm cobrança própria, em linha separada.

Os créditos de cloud services são consumidos por atividades da camada de serviços do Snowflake:

• Compilação e otimização de queries - toda query passa pela compilação antes de ser executada
• Operações de metadados - comandos DDL (CREATE, ALTER, DROP), zero-copy cloning, comandos SHOW e consultas ao INFORMATION_SCHEMA
• Autenticação e controle de acesso - login de usuário, troca de roles e verificação de permissões
• Cache de resultados de query - gerenciamento e entrega dos resultados em cache
• Listagem de arquivos - comandos COPY listam arquivos no object storage antes de carregá-los

O schema ACCOUNT_USAGE do Snowflake oferece views para acompanhar o cloud services, com latência de 2 horas e retenção de 365 dias.

Cobrança diária do Cloud Services

Veja em quais dias houve cobrança de fato:

SELECT
    usage_date,
    credits_used_cloud_services,
    credits_adjustment_cloud_services,
    credits_used_cloud_services + credits_adjustment_cloud_services AS billed_cloud_services,
    credits_used_compute,
    ROUND(credits_used_cloud_services / NULLIF(credits_used_compute, 0) * 100, 2) AS cs_pct_of_compute
FROM snowflake.account_usage.metering_daily_history
WHERE usage_date >= DATEADD(month, -1, CURRENT_TIMESTAMP())
    AND credits_used_cloud_services > 0
ORDER BY billed_cloud_services DESC;

Qualquer valor positivo em billed_cloud_services indica que houve cobrança naquele dia.

Cloud Services por tipo de query

A view query_history do Snowflake conta com a coluna credits_used_cloud_services, muito útil para identificar quais tipos de query consomem mais cloud services:

SELECT
    query_type,
    SUM(credits_used_cloud_services) AS total_cs_credits,
    COUNT(1) AS num_queries,
    AVG(credits_used_cloud_services) AS avg_cs_per_query
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
    AND credits_used_cloud_services > 0
GROUP BY query_type
ORDER BY total_cs_credits DESC;

Queries com alto consumo de Cloud Services

Dá para usar a mesma abordagem para isolar queries específicas com gasto elevado de Cloud Services.

SELECT
    query_id,
    user_name,
    warehouse_name,
    query_type,
    credits_used_cloud_services,
    SUBSTRING(query_text, 1, 100) AS query_snippet
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD(day, -7, CURRENT_TIMESTAMP())
    AND credits_used_cloud_services > 0.001
ORDER BY credits_used_cloud_services DESC
LIMIT 100;

Na convivência com clientes do Snowflake, alguns padrões aparecem repetidamente como vilões dos custos de cloud services.

1. Queries de metadados em alta frequência

Rodar queries simples como SELECT 1, SELECT CURRENT_SESSION() ou comandos show dezenas de milhares de vezes por dia acaba pesando. Além disso, consultas ao INFORMATION_SCHEMA usam só cloud services (sem computação de warehouse).

Solução: reduza a frequência desses health checks se o histórico de queries mostrar que esse tipo de consulta está inflando a fatura. Você pode migrar para o schema account_usage em vez do information_schema, se a latência for aceitável. Mas vá com cautela. Em geral, faz mais sentido evitar ligar um warehouse.

2. DDL e cloning em excesso

As operações de DDL são puramente de metadados. Criar e dropar schemas grandes com frequência ou clonar bases inteiras para backup elevam o consumo de cloud services.

Solução: clone no nível mais granular possível. Clone tabelas individuais em vez de schemas, e schemas em vez de bases inteiras. Reduza a frequência do cloning sempre que der. E garanta que só o DDL realmente necessário esteja rodando na sua conta.

3. Inserts de linha única e fragmentação de schemas

O Snowflake não é um sistema OLTP. Inserts de linha única consomem bastante cloud services, porque essas operações costumam reescrever micro partitions inteiras. Além disso, arquiteturas multi-tenant com um schema por cliente geram um volume excessivo de metadados.

Solução: use cargas em batch ou bulk. Para aplicações multi-tenant, sempre que possível, o Snowflake recomenda schemas compartilhados, com tabelas clusterizadas por customer_id e secure views para isolar os dados.

4. Comandos COPY com seletividade de arquivos ruim

Os comandos COPY listam arquivos no object storage, e isso usa computação de cloud services. Listar milhares de arquivos para copiar apenas alguns gera consumo alto.

Solução: organize o object storage com prefixos por data. Use padrões de arquivo precisos nos comandos COPY.

-- Em vez de listar tudo
COPY INTO target FROM @stage/raw_data/;

-- Liste apenas caminhos específicos: ano/mês/dia
COPY INTO target FROM @stage/raw_data/2025/10/24/;

5. Compilação de queries complexas

Queries com joins em excesso, operações de conjunto grandes (IN, NOT IN, EXISTS) ou produtos cartesianos consomem bastante cloud services durante a compilação.

Solução: simplifique a estrutura das queries. Troque listas grandes de IN por tabelas temporárias com JOIN. Quebre queries complexas em CTEs.

Monitore com regularidade. Faça revisões semanais do consumo de cloud services. Defina sua linha de base para detectar anomalias rapidamente.

Trabalhe em lote. Seja em DDL, DML ou carga de dados, processar em batch quase sempre é mais eficiente do que executar operação por operação.

Revise as queries de ferramentas de terceiros. Ferramentas de BI, plataformas de ETL e sistemas de orquestração costumam gerar padrões de queries de metadados que você não controla diretamente. Pequenos ajustes de configuração podem reduzir bastante as queries desnecessárias.

Configure alertas. Coloque as queries de monitoramento em tarefas agendadas, com integrações de notificação. Melhor ainda: use os monitores do SELECT para um alerta pronto para uso.