Snowflake Cloud Services: precios y monitoreo

El cálculo se realiza a diario en zona horaria UTC. Snowflake suma los créditos de cómputo de warehouse y los créditos de Cloud Services del día. El ajuste equivale al menor entre: (10% de los créditos de warehouse) o (los créditos de Cloud Services consumidos). El monto facturable son los créditos de Cloud Services menos el ajuste.

Ejemplo 1: por debajo del umbral (sin cargo)

• Cómputo de warehouse: 100 créditos
• Cloud Services: 8 créditos
• Ajuste: 8 créditos (Cloud Services queda por debajo del umbral del 10%)
• Cloud Services facturados: 0 créditos
• Total facturado: 100 créditos

Ejemplo 2: por encima del umbral (cargo parcial)

• Cómputo de warehouse: 100 créditos
• Cloud Services: 20 créditos
• Ajuste: 10 créditos (el monto correspondiente al umbral del 10%)
• Cloud Services facturados: 10 créditos
• Total facturado: 110 créditos

Excepción importante: las funcionalidades serverless como Snowpipe, Automatic Clustering y Materialized Views NO cuentan para el ajuste del 10%. Se facturan aparte como línea independiente.

Los créditos de Cloud Services se consumen por actividades de la capa de servicios de Snowflake:

• Compilación y optimización de consultas - Toda consulta pasa por una compilación antes de ejecutarse
• Operaciones de metadatos - Comandos DDL (CREATE, ALTER, DROP), zero-copy cloning, comandos SHOW y consultas a INFORMATION_SCHEMA
• Autenticación y control de acceso - Inicio de sesión, cambio de roles y validación de permisos
• Caché de resultados de consultas - Gestión y entrega de resultados en caché
• Operaciones de listado de archivos - Los comandos COPY listan archivos desde el object storage antes de cargarlos

El schema ACCOUNT_USAGE de Snowflake ofrece vistas para hacer seguimiento de Cloud Services con una latencia de 2 horas y retención de 365 días.

Facturación diaria de Cloud Services

Revisa qué días generaron cargos reales:

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;

Cualquier valor positivo en billed_cloud_services indica que ese día se generó un cobro.

Cloud Services por tipo de consulta

La vista query_history de Snowflake incluye una columna llamada credits_used_cloud_services, muy útil para identificar qué tipos de consulta consumen más 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;

Consultas con alto consumo de Cloud Services

Se puede aplicar el mismo enfoque para aislar consultas individuales con un gasto alto 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;

Al trabajar con clientes de Snowflake, hay ciertos patrones que aparecen una y otra vez como detonantes del costo de Cloud Services.

1. Consultas de metadatos de alta frecuencia

Ejecutar consultas simples como SELECT 1, SELECT CURRENT_SESSION() o consultas show decenas de miles de veces al día termina sumando. Además, las consultas contra INFORMATION_SCHEMA solo usan Cloud Services (no consumen cómputo de warehouse).

Solución: reduce la frecuencia de estos health checks si tu historial de consultas muestra que están inflando la factura. Puedes pasar a usar el schema account_usage en lugar de information_schema si la latencia es aceptable. Pero hazlo con cautela. Por lo general tiene más sentido evitar encender un warehouse.

2. Exceso de DDL y clonaciones

Las operaciones DDL son puramente operaciones de metadatos. Crear o eliminar schemas grandes con frecuencia, o clonar bases de datos completas como backup, dispara el consumo de Cloud Services.

Solución: clona al nivel más granular que necesites. Clona tablas individuales en lugar de schemas, y schemas en lugar de bases de datos. Reduce la frecuencia de clonación cuando sea posible. Asegúrate también de que solo se ejecute el DDL estrictamente necesario en tu cuenta.

3. Inserts de una sola fila y fragmentación de schemas

Snowflake no es un sistema OLTP. Los inserts de una sola fila consumen recursos importantes de Cloud Services porque a menudo reemplazan micro particiones completas. Además, las arquitecturas multi-tenant con un schema por cliente generan un exceso de metadatos.

Solución: usa cargas en batch o masivas. Para apps multi-tenant, cuando sea posible, Snowflake recomienda usar schemas compartidos con tablas clusterizadas por customer_id y vistas seguras para el aislamiento.

4. Comandos COPY con baja selectividad de archivos

Los comandos COPY listan archivos desde el object storage, lo que consume cómputo de Cloud Services. Listar miles de archivos para copiar solo unos pocos genera un consumo alto.

Solución: estructura el object storage con prefijos por fecha. Usa patrones de archivo precisos en los comandos COPY.

-- En vez de listar todo
COPY INTO target FROM @stage/raw_data/;

-- Lista solo rutas específicas: año/mes/día
COPY INTO target FROM @stage/raw_data/2025/10/24/;

5. Compilación de consultas complejas

Las consultas con demasiados joins, operaciones de conjuntos grandes (IN, NOT IN, EXISTS) o productos cartesianos consumen mucho Cloud Services durante la compilación.

Solución: simplifica la estructura de la consulta. Reemplaza listas IN grandes por tablas temporales y JOINs. Divide las consultas complejas en CTEs.

Monitorea con regularidad. Programa revisiones semanales del consumo de Cloud Services. Establece tu línea base para detectar anomalías rápidamente.

Agrupa las operaciones. Ya sea DDL, DML o carga de datos, el batching casi siempre es más eficiente que las operaciones individuales.

Revisa las consultas de herramientas de terceros. Las herramientas de BI, las plataformas de ETL y los sistemas de orquestación suelen generar patrones de consultas de metadatos que no controlas directamente. Ajustar la configuración puede reducir bastante las consultas innecesarias.

Configura alertas. Envuelve las consultas de monitoreo en tareas programadas con integraciones de notificación. Mejor aún, usa los monitors de SELECT para tener alertas listas para usar.