--- title: "Gestión de costes en Snowflake: cómo se cobra y cómo reducir la factura" description: "Qué pagas en Snowflake (créditos, almacenamiento, servicios cloud, serverless y transferencia) y ocho estrategias para medir, limitar y reducir la factura sin frenar al negocio." url: https://bidatia.com/ideas/gestion-de-costes-en-snowflake lang: es date: 2026-11-11 updated: 2026-11-11 author: "José Luis García" keywords: ["Snowflake", "costes Snowflake", "optimización de costes Snowflake", "créditos Snowflake", "FinOps", "plataforma de datos", "cloud"] publisher: Bidatia --- # Gestión de costes en Snowflake: cómo se cobra y cómo reducir la factura > Qué pagas en Snowflake (créditos, almacenamiento, servicios cloud, serverless y transferencia) y ocho estrategias para medir, limitar y reducir la factura sin frenar al negocio. ## Resumen ejecutivo - Snowflake cobra tres partidas: cómputo (créditos), almacenamiento (TB al mes) y transferencia de datos de salida. El cómputo suele ser más del 80 % de la factura. - Un warehouse se factura por segundo mientras está encendido, con un mínimo de 60 segundos por arranque, y cada tamaño dobla el consumo del anterior. Suspendido no cuesta nada. - Hay cargos menos visibles: servicios cloud por encima del 10 % diario, funciones serverless (vistas materializadas, search optimization, tareas, Snowpipe) y funciones de IA de Cortex. - Lo primero es medir y atribuir el coste por consulta, equipo y carga con las vistas de ACCOUNT_USAGE; después, ajustar warehouses, poner límites, optimizar consultas y revisar almacenamiento y contrato. - Un plan de 30 días con medidas rápidas (auto-suspend, tamaños, monitores) y una revisión de las 20 consultas más caras suele dar el primer ahorro sin tocar el negocio. Snowflake separa el almacenamiento del cómputo y cobra por lo que usas. Esa flexibilidad es su gran ventaja y también el origen de las sorpresas en la factura: nadie compra un servidor, pero cualquiera puede dejar un warehouse grande encendido o lanzar una consulta que recorre toda la tabla. Gestionar el coste de Snowflake no consiste en apagar cosas, sino en entender qué se cobra, medir quién lo consume y decidir con datos. Este artículo explica cómo factura Snowflake, dónde suele irse el dinero y qué estrategias aplicamos para reducir y optimizar el gasto sin frenar a los equipos. Los precios citados son los de la tabla de consumo de Snowflake a noviembre de 2026. ## Cómo cobra Snowflake La factura tiene tres partidas: **cómputo**, **almacenamiento** y **transferencia de datos**. Las tres se liquidan cada mes, bajo demanda (On Demand) o contra un importe comprado por adelantado (Capacity). ### El crédito: la unidad de cómputo Todo el cómputo se paga en **créditos**. El precio de un crédito depende de tres cosas: la edición de Snowflake (Standard, Enterprise, Business Critical o VPS), el proveedor de nube y la región. En las regiones europeas habituales (AWS Frankfurt, Azure West Europe, GCP Netherlands) el precio bajo demanda es hoy de 2,60 USD en Standard, 3,90 USD en Enterprise y 5,20 USD en Business Critical. Con un contrato Capacity se aplica un descuento sobre ese precio a cambio de comprometer consumo anual. La primera decisión de coste, por tanto, es anterior a cualquier consulta: edición y región. Enterprise cuesta un 50 % más que Standard por crédito y aporta funciones como los warehouses multi-cluster, 90 días de Time Travel o el enmascaramiento de datos. Si no se usan, se está pagando por ellas. ### Virtual warehouses: por segundo, con mínimo de un minuto Un warehouse es el motor que ejecuta consultas y cargas. Consume créditos por hora según su tamaño, y cada tamaño dobla al anterior: | Tamaño | XS | S | M | L | XL | 2XL | 3XL | 4XL | |---|---|---|---|---|---|---|---|---| | Créditos por hora | 1 | 2 | 4 | 8 | 16 | 32 | 64 | 128 | Tres reglas marcan la factura: - **Se factura por segundo** mientras el warehouse está en marcha, con un **mínimo de 60 segundos cada vez que arranca**. Una consulta de dos segundos en un warehouse que se despierta para ella cuesta un minuto entero. - **Suspendido no consume nada.** Por eso el auto-suspend y el auto-resume son el primer ajuste. - **Un multi-cluster multiplica** el consumo por el número de clústeres activos en cada momento. Los warehouses de **segunda generación (Gen 2)** usan hardware más reciente y cuestan 1,35 veces más por hora en AWS y GCP y 1,25 veces más en Azure. Como terminan antes las consultas, pueden salir más baratos por trabajo realizado, pero no siempre: hay que medirlo con la carga real. Los warehouses optimizados para Snowpark, con más memoria, tienen también su propia tabla de precios. ### Servicios cloud: la capa que coordina La capa de servicios cloud autentica, optimiza consultas, gestiona metadatos y transacciones. Su uso se mide a 4,4 créditos por hora, pero cada día quedan exentos los créditos equivalentes al 10 % de lo que han consumido los warehouses: **solo se factura lo que excede ese 10 %**. En la mayoría de cuentas no aparece en la factura. Aparece cuando hay muchísimas consultas pequeñas de metadatos, clonaciones masivas, herramientas que lanzan `SHOW` o `DESCRIBE` en bucle o consultas que se resuelven solo con la caché de resultados. ### Funciones serverless: cómputo que no se suspende Algunas funciones usan cómputo gestionado por Snowflake, sin warehouse. Unas se facturan en «horas de cómputo» equivalentes a un XS, multiplicadas por un factor propio de cada función; otras, por volumen de datos: - Mantenimiento de **vistas materializadas** y **Search Optimization Service**: factor 2. - **Tareas serverless**: factor 0,9 (0,5 en la modalidad Flex). - **Query Acceleration Service**: factor 1. - **Snowpipe**: 0,0037 créditos por GB ingerido. - **Snowpipe Streaming**: 0,0037 créditos por GB sin comprimir en la arquitectura de alto rendimiento. La arquitectura clásica se factura por cómputo (factor 1) más 0,01 créditos por cliente y hora. - **Clustering automático**: factor 2 en la modalidad clásica; en **Optima Clustering**, 0,007 créditos por GB sin comprimir, que puede reducirse según el solapamiento de los datos. Son cargos que se activan una vez y siguen consumiendo hasta que alguien los desactiva. Además, los monitores de recursos clásicos no los cubren; para ellos hacen falta los presupuestos (budgets), que veremos más adelante. ### Funciones de IA Las funciones de Cortex (resúmenes, clasificación, embeddings, Cortex Analyst, Cortex Search) se facturan por **tokens** procesados o por unidades, con sus propios «créditos de IA». Estos créditos tienen un precio y una escala de descuentos por capacidad distintos de los de plataforma: el descuento negociado para los créditos de plataforma no se les aplica. Si se incorporan a un pipeline diario conviene medir su coste por operación desde el primer día. ### Almacenamiento Se cobra una tarifa plana por **terabyte al mes**, calculada sobre la media diaria de bytes almacenados ya comprimidos. En las regiones europeas citadas está entre 20 y 24,50 USD por TB al mes bajo demanda (20 en GCP Netherlands, 23 en Azure West Europe y 24,50 en AWS Frankfurt), con descuentos por tramos en Capacity. Lo que muchos olvidan es qué se incluye en esa media: - Los datos activos de las tablas. - **Time Travel**: las versiones anteriores de los datos durante el periodo de retención configurado (de 0 a 90 días en Enterprise). - **Fail-safe**: 7 días adicionales de copia de seguridad en las tablas permanentes, que no se pueden desactivar. - Los **clones** solo pagan los datos que cambian respecto al original, pero las tablas copiadas con `CREATE TABLE AS` pagan íntegras. ### Transferencia de datos Traer datos a Snowflake es gratis. Sacarlos hacia otra región, otra nube o internet se cobra por TB. Afecta a las replicaciones entre regiones, a las descargas con `COPY INTO` a buckets de otra nube y a las conexiones desde fuera de la región. ## Un ejemplo de factura Una empresa mediana con Snowflake Enterprise en Azure West Europe: | Carga | Warehouse | Uso | Créditos al mes | |---|---|---|---| | Cargas ELT nocturnas | L (8 cr/h) | 2 h al día, 30 días | 480 | | Informes y Power BI | M (4 cr/h) | 8 h al día, 22 días | 704 | | Analítica ad hoc | S (2 cr/h) | 4 h al día, 22 días | 176 | | **Total cómputo** | | | **1.360** | A 3,90 USD el crédito, el cómputo son 5.304 USD al mes. Si almacena 10 TB comprimidos, el almacenamiento añade unos 230 USD. El cómputo es más del 95 % de la factura, y por eso casi toda la optimización se concentra ahí. Nótese además que el warehouse de informes cuesta la mitad por hora que el de cargas y, aun así, es el que más cuesta al mes: las horas encendido pesan más que el tamaño. ## Dónde se va el dinero Cuando revisamos una cuenta, los mismos síntomas se repiten: - **Warehouses encendidos sin consultas**, con auto-suspend de 10 minutos o desactivado «para que no tarde en arrancar». - **Tamaños elegidos a ojo**: un XL para consultas que caben en un S, porque alguien lo subió un día para una carga puntual y nadie lo bajó. - **Consultas sin poda**: `SELECT *` sobre tablas enormes, filtros con funciones sobre la columna, joins sin condición y consultas que vuelcan datos a disco (spilling) por falta de memoria. - **Pipelines demasiado frecuentes**: una carga cada cinco minutos cuando el negocio mira el informe una vez al día. - **Entornos de desarrollo y pruebas sin límites**, con el mismo tamaño que producción. - **Funciones serverless olvidadas**: search optimization en tablas que ya nadie consulta así, vistas materializadas de un proyecto cerrado. - **Copias de tablas y Time Travel de 90 días** en datos de staging que se regeneran cada noche. ## Ocho estrategias para reducir y optimizar el coste ### 1. Medir y atribuir antes de tocar nada No se gestiona lo que no se mide. Snowflake expone en el esquema `ACCOUNT_USAGE` todo lo necesario: - `WAREHOUSE_METERING_HISTORY`: créditos por warehouse y hora, incluido el tiempo ocioso. - `QUERY_HISTORY`: detalle de cada consulta (usuario, rol, warehouse, duración, bytes leídos, spilling). - `QUERY_ATTRIBUTION_HISTORY`: créditos de cómputo atribuidos a cada consulta. No incluye el tiempo ocioso del warehouse; ese coste se obtiene por diferencia con `WAREHOUSE_METERING_HISTORY` y hay que repartirlo con un criterio propio. - `METERING_DAILY_HISTORY`: cómputo, servicios cloud y serverless por día. - `STORAGE_USAGE` y `TABLE_STORAGE_METRICS`: almacenamiento activo, Time Travel y Fail-safe por tabla. Con eso se construye un panel de coste por equipo, aplicación y consulta. Para repartirlo bien hacen falta dos hábitos: usar **query tags** en cada herramienta y pipeline, y **etiquetas (tags) de objetos** en warehouses y bases de datos con el centro de coste o el dominio responsable. Snowsight incluye además una vista de gestión de costes con las consultas más caras. ### 2. Configurar los warehouses con criterio - **Auto-suspend corto**: 60 segundos es un buen punto de partida para cargas por lotes. Para BI interactivo puede compensar algo más, porque la caché local del warehouse se pierde al suspenderlo y la siguiente consulta tarda más. - **Auto-resume activado**, siempre. - **Un warehouse por tipo de carga** (cargas, informes, ciencia de datos), no uno gigante compartido. Permite dimensionar, medir y limitar cada uno por separado. - **Empezar pequeño y subir con pruebas.** Subir de tamaño dobla el coste por hora; solo compensa si la consulta termina en menos de la mitad del tiempo. Las señales para subir son el spilling a disco remoto y las colas; si no las hay, bajar. - **Multi-cluster para la concurrencia de usuarios**, con un máximo de clústeres razonable, en lugar de un warehouse mayor. La política Standard arranca clústeres en cuanto hay cola y es la adecuada para BI interactivo; la política Economy ahorra créditos a cambio de dejar consultas esperando, y encaja en cargas que toleran esa espera. - **Tiempos máximos**: `STATEMENT_TIMEOUT_IN_SECONDS` y `STATEMENT_QUEUED_TIMEOUT_IN_SECONDS` por warehouse evitan que una consulta olvidada consuma toda la noche. - **Evaluar Gen 2** con la carga real: en cargas pesadas suele reducir el coste por trabajo; en consultas pequeñas, no. ### 3. Poner límites que avisen y que corten - **Monitores de recursos (resource monitors)**: cuota mensual de créditos por cuenta o por warehouse, con hasta cinco umbrales que notifican y, si se quiere, un umbral que suspende el warehouse (al 100 % o en el porcentaje que se elija). Para desarrollo y pruebas, umbrales agresivos; para producción, notificar al 75 % y al 90 % y suspender solo si hay un plan de respuesta. - **Presupuestos (budgets)**: límite mensual de gasto que cubre también las funciones serverless y permite agrupar objetos. Avisan por correo o webhook cuando la previsión supera el límite, pero no cortan. - **Permisos**: quién puede crear warehouses, cambiar su tamaño o activar funciones serverless. La mayor parte del descontrol viene de que cualquiera puede hacerlo. ### 4. Optimizar consultas y modelo de datos - **Aprovechar la poda de particiones**: Snowflake solo lee las micro-particiones que necesita si los filtros van sobre columnas con los datos bien ordenados. Cargar las tablas grandes ordenadas por fecha y añadir **clustering keys** solo cuando la tabla es muy grande y se filtra siempre por las mismas columnas. - **Seleccionar solo las columnas necesarias**: el almacenamiento es columnar y cada columna de más se lee de disco. - **Evitar funciones sobre las columnas filtradas** y las conversiones de tipo en los joins, que impiden la poda. - **Cargas incrementales** en lugar de recalcular todo cada noche; **dynamic tables** con un retardo objetivo (target lag) acorde al negocio, no al mínimo. - **Caché de resultados**: una consulta idéntica sobre datos que no han cambiado se responde desde caché durante 24 horas sin gastar créditos de warehouse. Los paneles con consultas estables se benefician mucho si no se les añade `CURRENT_TIMESTAMP` o parámetros que cambian. - **Revisar el plan de ejecución** de las 20 consultas más caras cada mes. Suele haber una o dos que, reescritas, pagan todo el trabajo de optimización. ### 5. Revisar cargas y frecuencias - Ajustar la **frecuencia de los pipelines** a cuándo se usa el dato. Un informe diario no necesita una carga cada cinco minutos. - **Agrupar tareas** pequeñas en el mismo warehouse y en la misma ventana para amortizar el mínimo de 60 segundos y la caché. - Elegir entre **Snowpipe** (ficheros continuos, pequeños) y **COPY por lotes** (ficheros grandes a horas fijas) según el caso. Ficheros de entre 100 y 250 MB comprimidos cargan mejor que miles de ficheros diminutos. - Desactivar lo que ya no se usa: tareas, streams, vistas materializadas, search optimization. ### 6. Controlar el almacenamiento - **Time Travel por tipo de dato**: 1 día (o ninguno) en staging y datos derivados que se regeneran; más solo donde haya un requisito de recuperación. - **Tablas transitorias (transient)** para staging e intermedios: no tienen Fail-safe y ahorran los 7 días extra. - Eliminar **copias y clones** huérfanos y tablas de proyectos cerrados. `TABLE_STORAGE_METRICS` muestra cuánto de cada tabla es Time Travel y Fail-safe. - Mover histórico frío a **tablas Iceberg o externas** en el lago. El precio por TB del almacenamiento estándar de la nube es parecido al de Snowflake; el ahorro viene de no pagar Time Travel ni Fail-safe y de poder usar los niveles de almacenamiento frío del proveedor, y el dato sigue consultable. ### 7. Revisar el contrato - Pasar a **Capacity** cuando el consumo es estable: el descuento sobre el precio del crédito es la medida de más impacto a partir de cierto volumen. - Comprobar que la **edición** se corresponde con las funciones usadas. - Valorar la **región**: el precio del crédito y del TB varía entre regiones europeas, y la transferencia entre regiones no es gratuita. ### 8. Hacerlo costumbre: FinOps para datos Las medidas técnicas se deshacen en seis meses si nadie las sostiene. Lo que funciona es sencillo: un responsable de coste por dominio de datos, un panel que todos ven, una revisión mensual de las consultas y warehouses más caros, alertas que llegan a quien puede actuar y el coste por informe o por proceso como un KPI más del equipo de datos. Es la misma lógica que aplicamos en el [gobierno del dato](/capacidades/gobierno-del-dato): propietarios, métricas y decisiones registradas. ## Un plan de 30 días 1. **Semana 1. Medir.** Panel de coste por warehouse, consulta y equipo con `ACCOUNT_USAGE`; etiquetas en warehouses y query tags en herramientas. 2. **Semana 2. Medidas rápidas.** Auto-suspend a 60 segundos, bajar un tamaño los warehouses sin spilling ni colas, monitores de recursos en desarrollo y pruebas, tiempos máximos por consulta. 3. **Semana 3. Consultas.** Revisar y reescribir las 20 consultas más caras; ajustar frecuencias de pipelines; desactivar serverless sin uso. 4. **Semana 4. Gobierno.** Presupuestos por dominio, permisos sobre warehouses, Time Travel y tablas transitorias en staging, revisión del contrato y calendario de revisión mensual. En Bidatia diseñamos y operamos [plataformas de datos](/capacidades/plataformas-de-datos-e-ia) sobre [Snowflake](/tecnologias/snowflake), Microsoft Fabric y Databricks, y una de las primeras cosas que hacemos al entrar en una cuenta existente es exactamente este plan: medir, corregir lo evidente y dejar un sistema de control que el equipo pueda mantener. Si quieres que revisemos tu cuenta, [hablamos](/#contact). ## Preguntas frecuentes ### ¿Qué es un crédito de Snowflake y cuánto cuesta? Es la unidad con la que se paga el cómputo. Un warehouse XS consume un crédito por hora encendido, y cada tamaño dobla al anterior. El precio del crédito depende de la edición, la nube y la región; en las regiones europeas habituales está hoy entre 2,60 USD (Standard) y 5,20 USD (Business Critical) bajo demanda, con descuento en contratos Capacity. ### ¿Por qué aparece un cargo de servicios cloud en mi factura? La capa de servicios cloud es gratuita mientras su consumo diario no supere el 10 % de los créditos usados ese día por los warehouses. Si aparece, suele deberse a un volumen muy alto de consultas pequeñas de metadatos, herramientas que lanzan comandos SHOW o DESCRIBE en bucle, clonaciones masivas o muchas consultas servidas desde la caché de resultados. ### ¿Qué diferencia hay entre un monitor de recursos y un presupuesto? El monitor de recursos controla los créditos de los warehouses, avisa en varios umbrales y puede suspenderlos al llegar al límite, pero no cubre las funciones serverless. El presupuesto fija un límite mensual de gasto que incluye serverless y permite agrupar objetos, pero solo avisa: no corta el consumo. Conviene usar los dos. ### ¿Los warehouses Gen 2 son más caros? Por hora, sí: 1,35 veces en AWS y GCP y 1,25 veces en Azure. Como ejecutan las consultas más deprisa, en cargas pesadas suelen costar menos por trabajo realizado. En consultas pequeñas o en warehouses que están encendidos esperando, no compensan. Hay que probarlo con la carga real y comparar créditos por proceso. ### ¿Cómo sé qué consultas me cuestan más? Con la vista QUERY_ATTRIBUTION_HISTORY del esquema ACCOUNT_USAGE, que atribuye a cada consulta los créditos de cómputo que ha usado (sin el tiempo ocioso del warehouse), y con QUERY_HISTORY para ver el tiempo, los bytes leídos y el spilling de cada una. Si cada herramienta y pipeline usa un query tag, el coste se puede agrupar por equipo o aplicación. ### ¿Por dónde empiezo si la factura se ha disparado? Por medir: un panel de créditos por warehouse y por consulta de las últimas semanas localiza el origen en pocas horas. Después, auto-suspend a 60 segundos, bajar un tamaño los warehouses sin señales de falta de memoria, monitores de recursos en desarrollo y revisión de las consultas más caras. Son medidas de una o dos semanas que no afectan al negocio.