Optimización de costos y economía de los DBU en AWS

Las demás lecciones de este curso construyen algo; esta lección mantiene honesta la factura. Un lakehouse de datos de Databricks en AWS genera dos facturas independientes: Databricks te factura en DBUs (Databricks Units, la licencia de la plataforma, medida por segundo) y AWS te factura por el EC2, EBS, S3, NAT y CloudWatch que hay debajo. Olvida cualquiera de los dos medidores y tu «optimización de costos» es ficción: el lado de los DBU puede estar perfectamente ajustado mientras un NAT Gateway añade en silencio $0.045 por GB de tráfico hacia S3, y el lado de AWS puede ser todo spot mientras un cluster all-purpose pasa inactivo todo el fin de semana a $0.55/DBU.

La buena noticia es que el costo de Databricks es aritmética, no intuiciones. Cada tarifa de esta lección está fechada en octubre de 2026 y trazada hasta una fuente primaria o documental: las páginas de precios de Databricks y los archivos de datos de página (leídos 2026-10), el registro de proveedor UK G-Cloud 15 para las tarifas de lista de Jobs/All-Purpose (capturado 2026-09-25), la documentación de Databricks sobre las tablas de facturación y la parada automática (actualizada 2026-09-11 / 2026-10-08), la lista de precios de AWS para EC2/S3 (leída 2026-10-12) y las páginas de precios de AWS para NAT, Spot y CloudWatch (leídas 2026-10). Haz tú mismo la cuenta: es la única forma de operar un lakehouse que siga siendo asequible en el tercer año.

En esta lección vas a:

• leer la tarjeta de tarifas de DBU de oct-2026 por SKU de cómputo, jobs, all-purpose, SQL Classic/Pro/Serverless, pipelines de Lakeflow, con la procedencia de cada número explicada;
• aplicar las dos ecuaciones (clusters: nodos × emisión × tarifa × horas; warehouses: tarifa por tamaño × tiempo activo) en cinco ejemplos resueltos calculados a mano;
• tomar la decisión del punto de equilibrio entre serverless y classic con aritmética en lugar de doctrina;
• configurar parada automática, terminación automática, workers spot, pools de instancias y políticas de cluster como controles de costo, con los valores documentados y sus mínimos;
• atribuir cada dólar con system.billing.usage, presupuestos y etiquetas, y saber exactamente qué costos nunca aparecen ahí;
• ejecutar el caso de TCO mensual resuelto para un equipo de cinco personas (tres pipelines, un warehouse de BI, S3/NAT/logs) y recortarlo un 34.1% con tres palancas;
• sopesar el Veredicto comparativo: DBUs frente a créditos de Snowflake frente a los $5/TB escaneados de Athena;
• estudiar casos documentados de costos de clientes de AWS (Addepar, Nubank, Comcast), leer el recuadro de actualizaciones de 2026 y practicar con doce preguntas y cinco comprobaciones interactivas.

---

1. Dos facturas, no una: el modelo de costos de Databricks en AWS

1.1 Qué es un DBU

La propia definición de Databricks: "Databricks factura según las unidades de Databricks (DBUs), que son unidades de capacidad de procesamiento por hora según el tipo de instancia de VM" (docs.databricks.com/aws/en/getting-started/concepts, fecha del documento 2026-09-25). La página de precios lo dice al revés: "Una unidad de Databricks (DBU) es una unidad normalizada de potencia de procesamiento en la plataforma Lakehouse de Databricks, usada con fines de medición y fijación de precios" y "Paga solo por los productos que usas, con granularidad de segundo" (databricks.com/product/pricing, leído 2026-10).

Tres consecuencias deciden todo lo que sigue:

1. Para el cómputo de clusters, el consumo de DBUs = (nodos) × (DBU/h de ese tipo de nodo) × horas: el blog de gestión de costos de 2022 lo dice sin rodeos: "Con la excepción de un SQL Warehouse, la cantidad de DBUs consumida se basa en el número de nodos y la potencia de cálculo de los tipos de instancia VM subyacentes" (databricks.com/blog/best-practices-cost-management-databricks, 2022-10-18; la aritmética sigue vigente con las tarifas de oct-2026).
2. Para los warehouses SQL, el consumo de DBUs = (los DBU/h fijos de la talla) × horas que el warehouse está activo: esté ejecutando o no, el medidor gira mientras el warehouse está activo (documentación de precios, leída 2026-10).
3. El medidor es por segundo y no sabe si estás trabajando. Un cluster all-purpose inactivo y uno a plena carga emiten DBUs a la misma tarifa. Por eso el tiempo inactivo, y no la velocidad de las consultas, es el problema central de optimización de costos en el cómputo classic.

1.2 Los dos medidores

Serverless pliega el costo de la máquina dentro de una tarifa de DBU más alta. SQL Serverless a $0.70/DBU frente a SQL Classic a $0.22/DBU (databricks.com/product/pricing/databricks-sql, instantánea de página 2026-10) es una prima de $0.48 por DBU-hora que paga la flota, las operaciones y el tiempo inactivo que ya no controlas. Jobs Serverless $0.35 menos Jobs Classic $0.15 es el mismo cuadro con $0.20 por DBU-hora. Classic no es gratis: solo mueve media factura a AWS, donde puedes atacarla con spot y con el right-sizing.

⚠️ system.billing.usage no es tu factura total. Databricks es explícito: "El system.billing.usage solo contiene costos de Databricks. Esto significa que, en cualquier caso en que se use cómputo no serverless, el gasto de infraestructura de la nube no está incluido y habría que revisarlo en la consola de nube correspondiente (cómputo, redes, almacenamiento, etc.)" (databricks.com/blog/top-5-system-table-queries-understanding-your-databricks-costs, 2026-09-22). Un presupuesto que solo mira Databricks subestima la cifra real por toda la columna de AWS.

• 📚 ¿Sabías que…? Databricks mide los DBUs por segundo (FAQ de precios, leída 2026-10), mientras que Snowflake factura créditos "per second with a 60-second minimum" (resumen de warehouses de Snowflake + tabla de consumo del servicio, leída 2026-10). En jobs cortos y frecuentes, esa diferencia de 55 segundos es una línea real de la factura: una de las razones silenciosas por las que las cargas de trabajo con picos prefieren los jobs serverless de Databricks a una flotta classic siempre reanudada.

1.3 La tarjeta de tarifas de oct-2026 (AWS, regiones de EE. UU., nivel Premium, lista)

Lee la columna de procedencia antes de citar una tarifa. Las cifras de SQL y Lakeflow Pipelines provienen de las propias superficies de precios de Databricks (instantáneas de página y el archivo de datos de página del sitio de precios). Las cifras de Jobs y All-Purpose son documentales y corroboradas, el registro público de proveedor UK G-Cloud 15 (una presentación legal de Databricks Inc.) más seis lecturas independientes de 2026 que coinciden, porque databricks.com renderiza esas tarjetas en el cliente. Trata cada cifra como lista de EE. UU., nivel Premium: la FAQ de precios afirma "Databricks prices and Cloud Infrastructure prices may vary based on geographic region and cloud service provider" (leída 2026-10), y la verdad dentro de la cuenta vive en system.billing.list_prices (el precio de tu contrato).

Dos reglas prácticas con respaldo oficial:

• Misma pipeline, all-purpose frente a jobs = 3.7× la tarifa por DBU ($0.55 ÷$0.15 ≈ 3.7): antes de contar un solo minuto inactivo.
• Serverless cuesta ~1.3×: 2.3× más por DBU que classic para la misma familia de SKU, y de paso elimina la factura de EC2, la gestión de pools y el tiempo inactivo.

Efecto de la región: las tarifas classic son planas en todas las regiones de AWS porque pagas el precio local de EC2 por separado; las tarifas serverless siguen la infraestructura regional: SQL Serverless $0.70 en us-east-1 frente a $0.91 en eu-central-1 (lectura de hejlsvigconsulting.com del archivo de datos de la página de precios, 2026-08-07). Una cotización de EE. UU. nunca se traslada a Fráncfort.

1.4 Ejemplo resuelto E1: la ecuación básica y una factura combinada

El patrón resuelto del propio blog de gestión de costos de 2022, repricado con la tarifa Premium de Jobs actual (blog, 2022-10-18; lista de precios de EC2, us-east-1, leída 2026-10-12):

Esa última línea es el número que vas a reutilizar en toda la lección: $0.214 todo incluido por DBU-hora en jobs classic frente a $0.35 de los jobs serverless, por eso classic gana en formas calientes, largas y predecibles, y serverless gana en las cortas, con picos o erráticas (sección 3). La salvedad que el propio blog implica: combina la tasa de emisión de tu tipo de nodo con el precio de EC2 de ese tipo de nodo, y lee ambas en la calculadora de precios o en system.billing.list_prices, el par 3 DBU/hr + m5.xlarge de arriba es ilustrativo, no una forma emparejada.

---

2. La escalera de SKU: tu palanca de precios más poderosa

Antes de ajustar una sola consulta, comprueba que la carga de trabajo esté en el SKU correcto. Elegir SKU es gratis, instantáneo y, según los propios informes de campo de Databricks, vale más que la mayoría del trabajo de rendimiento.

2.1 Los tres crímenes de la escalera

1. Una pipeline sobre cómputo all-purpose. Un job apuntado a un cluster all-purpose existente se factura con las tarifas de All-Purpose y se marca como carga de trabajo interactiva (Jobs API 2.0; digest 06, leído 2026-10). Databricks "no recomienda esta configuración para jobs de producción." Solo la diferencia de tarifa es de $0.55 →$0.15 por DBU.
2. El nivel Standard retirado en tu runbook. Jobs a $0.10/DBU era Standard; los workspaces Standard de AWS/GCP se actualizaron a Premium el 2025-10-01 (Azure 2026-10-01) según la página de precios (leída 2026-10). Cualquier tabla de tarifas anterior a 2025 que copies está desactualizada en un 50%.
3. Confusión entre Premium y Enterprise entre nubes. El "Premium" de AWS/GCP es la tarjeta "Enterprise" de Azure: AWS Jobs es $0.15 Premium / $0.20 Enterprise (un 33% de diferencia) y cada SKU serverless se mueve con él (registro G-Cloud 2026-09-25; licenseware 2026-10-06). Etiqueta siempre la nube y el nivel.

2.2 Ejemplo resuelto E2: una pipeline, un mes, all-purpose frente a jobs

La misma pipeline de 12 DBU/hr, 400 horas de cluster al mes, los mismos 4 × m5.xlarge en el lado de AWS (tarifas a oct 2026):

Una pipeline. Un desplegable en la definición del job. El resumen propio de Databricks de la versión a escala de toda la finca: "We've seen customers who have saved tens of thousands of dollars by simply moving just ten percent of their workloads from all-purpose clusters to jobs clusters" (blog de gestión de costos, 2022-10-18: fuente antigua, aritmética sin cambios).

• 📚 ¿Sabías que…? Las actualizaciones de vistas materializadas se facturan como uso de pipeline serverless, no como uso de warehouse: así que una pestaña de costos de 'warehouse' no las mostrará (blog de Databricks, 2026-10-07). La optimización predictiva está activada por defecto en las cuentas creadas el 2024-11-11 o después, y también se factura bajo registros de uso serverless. Si tus consultas de atribución solo agrupan por warehouse, estos dos SKU son fugas invisibles.

---

3. Serverless frente a classic: la aritmética del punto de equilibrio

"Serverless es 4× más caro" es la frase más cara de las discusiones sobre costos de Databricks, porque compara tarifas de DBU e ignora la columna de AWS del lado classic. La comparación honesta es el costo todo incluido por DBU-hora emitido.

Tres lecturas prácticas:

• Gana classic cuando el cluster corre caliente y largo con una forma predecible: ventanas de ETL por lotes, backfills nocturnos grandes, entrenamiento de ML con un número de nodos conocido. Ya estás pagando ~$0.192/h por un m5.xlarge (lista de precios de EC2, leída 2026-10-12); classic pliega eso en una licencia de $0.15/DBU en lugar de un paquete de $0.35/DBU.
• Gana serverless en trabajo corto, con picos, interactivo o impredecible, dashboards con huecos entre actualizaciones, notebooks ad-hoc, jobs dirigidos por eventos, porque "no se te cobra mientras está inactivo" (Databricks Answers, 2026-08-27) y la flota, el parcheo y la planificación de capacidad desaparecen.
• Las restricciones operativas pesan tanto como el precio. Los jobs serverless tienen un máximo de 7 días de ejecución documentado, no admiten tareas JAR/Spark-Submit, ni notebooks R/Scala, ni APIs RDD, ni perfiles de instancia, y los gatillos de Structured Streaming están limitados a Trigger.AvailableNow() (recomendado); mientras que classic existe precisamente donde esas restricciones aprietan (digest 06, docs leídas 2026-10). Migra el patrón (volúmenes en lugar de DBFS, la API DataFrame en lugar de RDDs) antes de cambiar de SKU.

---

4. Tiempo inactivo: parada automática, terminación automática y la regla de facturarse mientras está activo

La frase propia de Databricks sobre los warehouses: "Idle SQL warehouses continue to accumulate DBU and cloud instance charges until they are stopped" (docs.databricks.com/aws/en/compute/sql-warehouse/create, última actualización 2026-09-11). No hay forma más suave de decirlo: un warehouse que está activo es un warehouse que se factura. Diez horas dejadas activas para cuarenta minutos de dashboards se facturan como diez horas.

4.1 Los valores por defecto documentados (a oct 2026)

Dos matices. Primero, los valores por defecto de la parada automática difieren por un factor de 4.5 entre classic/Pro (45 min) y serverless (10 min): si tus dashboards se actualizan cada 20 minutos, el valor classic por defecto te garantiza pagar 25 minutos inactivos después de cada sesión. Segundo, autotermination_minutes = 0 (desactivado) es un valor legal de la API y la fuente número uno de gasto descontrolado de fin de semana; una política aplicada gana a un barrido manual semanal (sección 6.3).

4.2 Ejemplo resuelto E4: aritmética de parada automática en el warehouse de BI

Del caso de TCO mensual de la sección 9: un warehouse SQL serverless que sirve BI está activo 10 horas al día durante 21 días laborables (210 horas, 2,520 DBU con una emisión asumida de 12 DBU/h según la talla). El uso medido muestra que los dashboards consultan de verdad en una ventana de 6 horas:

No se reescribió ninguna consulta. No se movió ningún dato. Simplemente no se dejó el warehouse encendido. (La cifra de 12 DBU/h es la emisión de la talla Small que asume este caso: los tamaños de medición por talla de warehouse no se publican como tabla oficial, así que lee los tuyos en system.billing.list_prices en tu cuenta antes de reutilizar la aritmética.)

4.3 Ejemplo resuelto E5: una política de parada automática / terminación automática aplicada

Las políticas de cluster son conjuntos de reglas JSON administradas por administradores sobre atributos de la API de Clusters cuyos beneficios incluyen "cost control via price-driving attributes" (docs, leídas 2026-10). La referencia de políticas (leída oct 2026) documenta la ruta del atributo autotermination_minutes y un rango virtual de dbus_per_hour que hace de techo duro de DBU; la restricción de tipo de nodo es igualmente una capacidad de la política. Una política mínima de guardarraíl de costos para un workspace de equipo:

La mecánica que convierte esto en un guardarraíl y no en una sugerencia: una limitación por atributo; el cómputo creado por API ignora los valores por defecto de la política salvo que se establezca apply_policy_default_values: true; spark_version: auto:latest-lts solo se resuelve cuando el cómputo se edita, no de forma continua; y el derecho Unrestricted lo salta todo, por lo que "debería suprimirse para los usuarios que no son administradores" (guía de incorporación de políticas, blog 2025-04-17). Las grafías de las claves de atributo varían entre superficies de API: confírmalas en el editor de políticas de tu workspace antes de fiarte de este JSON literalmente.

⚠️ Los presupuestos y las políticas monitorizan y restringen; no detienen a un gastador determinado. Los presupuestos son "monitoreo y alertas, no un límite duro" (doc de presupuestos, actualizada 2026-10-07): un usuario con permisos suficientes todavía puede crear un warehouse que corra demasiado tiempo o se quede escalado más allá de lo esperado. El marco propio de Databricks: "Buenos controles mediante políticas de cómputo, configuraciones de tiempo de espera de jobs y presupuestos ayudan a los administradores de la plataforma Databricks a mantener el gasto dentro de los límites, pero siempre existe la posibilidad de que un usuario con permisos suficientes cree un job o un warehouse que corra demasiado tiempo o se quede escalado más allá de lo esperado y cause un pico inesperado de gasto" (blog de las cinco consultas de system tables, 2026-09-22). Los guardarraíles son por capas o son teatro.

---

5. Spot en AWS: lo que ahorra y lo que nunca toca

Las Spot Instances de AWS "save up-to 90% on On-Demand prices" (aws.amazon.com/ec2/spot, leído 2026-10), y AWS emite un aviso de interrupción de dos minutos antes de detener o terminar una instancia Spot (docs de AWS EC2, leídos 2026-10). En Databricks la regla de topología es fija: cuando marcas spot, "driver node is always on-demand, subsequent instances will be spot" (doc de configuración de cómputo, actualizada 2026-10-06).

5.1 Ejemplo resuelto E6: aritmética de spot, y la columna que nunca toca

Cinco workers m5.xlarge durante 200 horas al mes (lista de EC2, us-east-1, leída 2026-10-12):

Cuatro hechos operativos que hay que meter en el diseño: el driver se queda bajo demanda (docs de cómputo 2026-10-06); el desalojo de dos minutos llega a mitad de tarea, así que las pipelines necesitan etapas reiniciables e idempotentes (docs de AWS 2026-10), el gatillo AVAILABLE_NOW y el Structured Streaming con checkpoint de las lecciones 05 y 13 son los patrones compatibles; los pools son todo spot o todo bajo demanda (la API añade SPOT_WITH_FALLBACK), y la guía de Databricks es "No uses un pool con instancias spot como tu tipo de driver"; y spot no ahorra nada en serverless, serverless va incluido en la tarifa, y ninguna fuente afirma que los descuentos de EC2 spot se trasladen a las tarifas de DBU serverless.

• 📚 ¿Sabías que…? Spot puede ahorrar hasta un 90% y sigue siendo la decisión equivocada para un job de 20 minutos con SLA estricto: la guía actual de Databricks combina pools spot para cargas de trabajo que toleran el costo con pools bajo demanda para jobs cortos y de SLA estricto, y recomienda serverless en lugar de pools siempre que la carga de trabajo lo permita (docs, leídas 2026-10). Spot es una decisión de carga de trabajo, no un interruptor de ahorro de toda la cuenta.

---

6. Right-sizing, autoscaling, pools y el rendimiento como costo

6.1 Right-sizing del warehouse (la palanca proporcional)

En un warehouse, el costo en DBU es tarifa por tamaño × tiempo activo, así que bajar una talla de T-shirt es un recorte proporcional de DBU por cada hora que el warehouse está activo: el ahorro lineal más limpio de la plataforma. La escalera classic/Pro se construye sobre workers i3.2xlarge (2X-Small = 1 worker, doblando hasta X-Large = 32, y hasta 4X-Large = 256) con "a cluster for every 10 concurrent queries" como regla de concurrencia (docs, leídas 2026-10). Dimensiona a la concurrencia que sirves, no al pico que viste una vez; añade clusters (autoscaling a nivel de warehouse) en lugar de inflar la T-shirt para una cola que se limpia en minutos.

6.2 Autoscaling, pools y AVAILABLE_NOW

• El autoscaling encoge el pico. El autoscaling optimizado (Premium+) va de min a max en ≤2 eventos de redimensionamiento, y escala a la baja con una ventana de subutilización de 40 segundos en el cómputo de jobs y 150 segundos en all-purpose (docs, actualizadas 2026-10-06). Nunca lo combines con spark.dynamicAllocation.enabled: la documentación advierte de churn de executors y NODES_LOST.
• Los pools cuestan cero DBUs mientras están inactivos, y AWS completo mientras están inactivos. "Databricks no cobra DBUs mientras las instancias están inactivas en el pool. La facturación del proveedor de instancias sí se aplica" (mejores prácticas de costos, 2026-09-11). Dimensiona min_idle_instances e idle_instance_autotermination_minutes con criterio; mantén el tamaño máximo del cluster ≤ max_capacity del pool o el escalado fallará con INSTANCE_POOL_MAX_CAPACITY_FAILURE.
• AVAILABLE_NOW da forma a la pipeline. Ejecuta una pipeline disparada (Trigger.AvailableNow()) en un job cluster que termina al completarse en lugar de un cluster continuo que pasa inactivo entre micro-batches: la lista oficial de palancas lo recomienda (mejores prácticas, 2026-09-11).

6.3 Photon como palanca de costo (con cuidado)

Photon es el motor vectorizado en C++ que "replaces the JVM-based Spark SQL execution engine" mientras Catalyst sigue planificando la consulta (docs de Photon, actualizadas 2026-09-11). Su historia de costo son segundos facturables, no descuento: terminar antes significa menos segundos medidos por segundo, pero Photon también "consume[s] DBUs at a different rate than the same instance type running the non-Photon runtime", así que "Photon is faster" nunca implica "Photon is cheaper" (docs; haz tu propio benchmark de la carga de trabajo). Acelera SQL, ETL con DataFrame y streaming sin estado, y no acelera cuerpos de UDF de Python, RDDs, Datasets ni streaming con estado, las consultas de menos de ~2 segundos no ven una mejora significativa (docs, 2026-09-11). Photon está activado por defecto en serverless, warehouses SQL y la UI; los clusters creados por API deben fijar runtime_engine: "PHOTON" explícitamente (lección 06).

6.4 El ciclo de cuatro etapas

El propio marco de Databricks para controlar el gasto (Databricks Answers, leído 2026-10):

La mayoría de los equipos invierte este orden y empieza por la etapa 4: reescribiendo consultas mientras un cluster all-purpose inactivo factura $0.55/DBU en una esquina. Las etapas 1 y 2 son baratas (los datos del medidor ya están en tu cuenta); la etapa 3 es configuración; solo la etapa 4 es ingeniería.

---

7. Atribución de costos: system tables, presupuestos y la consola de AWS

7.1 system.billing.usage: cada DBU tiene una dirección

La system table de facturación (docs, actualizadas 2026-10-08) trae, entre otras: account_id, workspace_id, workspace_name, region, billable_usage_timestamp, billing_origin_time, billing_month, cloud, sku, usage_type, product_feature, record_type, run_as, metered_quantity, list_price, unblended_cost, databricks_contract_quantity, aws_public_list_price y tags. Las tres que hacen el trabajo en cada consulta de atribución:

• sku / usage_type / product_feature: qué tipo de cómputo (jobs frente a all-purpose frente a SQL frente a pipelines serverless);
• run_as: si la ejecución fue interactiva, un job, serverless, y así sucesivamente;
• tags / workspace_name: de quién es.

record_type separa las filas de uso de las filas de precios, y Databricks trae joins prefabricados con system.billing.list_prices y system.compute.clusters, más instrucciones para publicar el resultado en un dashboard AI/BI y lanzar una alerta (docs, 2026-09-11). También existe un Usage Dashboard prefabricado (blog, 2026-09-22): empieza ahí antes de escribir SQL.

7.2 Ejemplo resuelto E7: la auditoría de «recortar la factura» en SQL

Ordena la salida y trabaja de arriba abajo por la lista de palancas: (1) clusters all-purpose inactivos y su ajuste de terminación automática → (2) warehouses con parada automática en «never» o 45 minutos que sirven dashboards de 20 minutos → (3) cargas de trabajo sentadas en All-Purpose que en realidad son jobs → (4) bajar una talla / autoscaling → (5) spot para los workers → (6) poner en pool los nodos calientes → (7) ciclo de vida de S3 + un gateway endpoint → (8) presupuestos + alertas para que no vuelva a crecer. Dos tablas de apoyo cierran el ciclo: system.billing.list_prices (los precios de tu contrato: el sustituto dentro de la cuenta de cualquier tabla pública de tarifas) y system.compute.warehouse_events para la forense del ciclo de vida de los warehouses.

7.3 Presupuestos, etiquetas y el lado de AWS

Presupuestos (doc, actualizada 2026-10-07): hasta 1,000 presupuestos por cuenta, cada uno con hasta 4 umbrales (%), expresados en USD a precio de lista incluidos los add-ons (sin aplicar descuentos/créditos), con alcance por equipo/proyecto/workspace y filtros, creados por administradores de cuenta (administradores de workspace para los presupuestos con alcance de UC). Otra vez: los presupuestos monitorizan, no limitan.

Las etiquetas son la articulación entre las dos facturas, con una trampa. Las etiquetas de Databricks y las etiquetas personalizadas aplicadas mediante políticas de cluster y políticas de uso serverless llegan a system.billing.usage (blog, 2026-09-22), y la propagación de etiquetas a los recursos en la nube es el camino documentado para la atribución del lado de AWS (mejores prácticas, 2026-09-11). Pero una etiqueta team puesta solo en un cluster de Databricks no se convierta por sí sola en una etiqueta de asignación de costos de AWS; y las etiquetas no se rellenan hacia atrás, la dimensión CostCenter de la factura de AWS solo existe desde el día en que la creas. En el lado de AWS, Cost Explorer conserva "up to the last 13 months" de historial y proyecta "the next 18 months" (docs de AWS, leídas 2026-10).

• 📚 ¿Sabías que…? Las nuevas query tags (Public Preview) llegan a system.query.history, dbt-databricks 1.11.0 añade etiquetado automático, y una Governance Hub Cost page (Beta) agrega la superficie de gasto (blog de Databricks, 2026-10-07). RBI reconstruyó el monitoreo y la previsión de costos sobre las system tables y reportó que funcionaba 3 to 4× más rápido que su proceso anterior (mismo blog): los datos del medidor ya están en tu cuenta; el dashboard es la parte barata.

---

8. El lado de AWS de la factura: EC2, EBS, S3, NAT, CloudWatch

Las ofertas de AWS Price List (us-east-1; EC2 leído 2026-10-12, oferta de S3 publicada 2026-09-28) y las páginas de precios de AWS (leídas 2026-10):

En esta tabla viven tres fugas silenciosas. El procesamiento de datos de NAT en el tráfico de S3: cada list/put/get de S3 a través de un NAT Gateway cuesta $0.045/GB más $0.045/h, mientras que un gateway endpoint de S3 es gratis, la corrección de red más barata de todo AWS (la sección 9 la usa). CloudWatch a $0.50/GB ingerido es el precio de dejar que los logs del driver y del cluster corran sin gestión. Y el desperdicio de almacenamiento se compone en silencio: la propia guía de costos de Databricks cita un bucket de cliente de 2.5 PB donde solo 800 TB eran datos reales y 1.7 PB eran versiones antiguas de objetos, a $0.023/GB-mes eso son unos $39,000 al mes de desperdicio puro, eliminables con una regla de ciclo de vida de S3 sin tocar un solo DBU (blog de gestión de costos, 2022-10-18; tarifa de S3 de la oferta del 2026-09-28).

---

9. El caso de TCO mensual: $3,011 →$1,985 en tres palancas

9.1 Supuestos declarados (AWS us-east-1, lista, oct 2026)

Un equipo de datos de cinco personas: 21 días laborables; un cluster all-purpose de desarrollo compartido (4 × m5.xlarge, emisión 12 DBU/h: la aritmética ilustrativa de E1: activo 6 h/día); 3 pipelines en jobs compute (4 nodos, 0.5 h/día cada uno, 30 días); BI en un warehouse SQL serverless medido en 2,520 DBU para el mes (10 h/día × 21 días con una emisión asumida de 12 DBU/h según la talla: confirma la tarifa por tamaño en system.billing.list_prices); 5 TB en S3; 500 GB de procesamiento de NAT; 60 GB de logs a CloudWatch.

9.2 El cuadro anterior

9.3 Tres palancas con fuente

Lee el gráfico de arriba abajo y la estrategia aparece: la línea de BI es la ballena (59% de la factura original) y cae un 40% con un solo ajuste de parada automática; el cluster de desarrollo cae un 33% con la terminación automática; las pipelines apenas se mueven porque ya estaban en el SKU más barato (jobs) con un tiempo inactivo estructuralmente nulo. El gráfico de cada cuenta es distinto, y por eso el paso de atribución de la sección 7 viene antes que cualquier optimización.

---

10. Almacenamiento, diseño y escaneo: las palancas que no tocan ninguna tarifa de DBU

• Higiene del ciclo de vida y del versionado en S3: el ejemplo del desperdicio por versiones de $39,000/mes de la sección 8 es la plantilla: las reglas de ciclo de vida borran o cambian de nivel las versiones antiguas de objetos a tarifas de S3 ($0.023/GB-mes, oferta 2026-09-28) y nunca tocan un DBU.
• OPTIMIZE, liquid clustering y particionado (lecciones 04 y 14): menos bytes escaneados por consulta significa menos segundos facturables en un medidor por segundo, y el autoscaling basado en carga ve menos picos.
• Propagación de etiquetas a los recursos en la nube (mejores prácticas, 2026-09-11); sin ella, el lado de AWS de la factura no se puede dividir por equipo.
• NAT → gateway endpoint para S3 (sección 9) y right-sizing de la retención de logs de CloudWatch, a $0.50/GB ingerido.
• El anti-patrón de BI: la intuición por TB no aplica en Databricks: el warehouse factura tiempo × forma, de modo que un SELECT * que reescanea 400 GB cien veces al día factura los mismos DBU por ventana de escaneo… hasta que el trabajo extra alarga la ejecución, dispara el autoscaling basado en carga hacia más clusters y voltea el warehouse a una T-shirt más grande. El costo aparece como forma, no como bytes.

---

11. Prueba en el mundo real: lo que las palancas entregaron a los clientes

Resultados documentados de clientes (todos del blog de presupuestos/alertas de Databricks, 2026-10-07, salvo indicación):

• Lumen trasladó los informes basados en Looker a warehouses SQL serverless y reportó costos de cómputo un 30 to 40% más bajos con consultas ~90% más rápidas contra ~7 GB escaneados cada 10 minutos: el ahorro vino de eliminar el tiempo inactivo del warehouse classic y la factura de EC2, no de un descuento.
• GetYourGuide ejecutó el mismo patrón de migración sirviendo BI y reportó costos un ~20% más bajos con consultas ~35% más rápidas.
• RBI reconstruyó el monitoreo y la previsión de costos sobre las system tables y reportó 3 to 4× más rápido que su proceso anterior.

Las bandas de profesionales alrededor de estas cifras son consistentes: las victorias rápidas de configuración (migración a jobs compute, terminación automática, workers spot, apagar warehouses inactivos) se reportan en el rango del 20 to 40% en semanas (DataLane, 2026-04-08; SELECT, 2026-07-16; Cyfra Dane, 2026-07-15: artículos escritos por consultores, es decir, afirmaciones de proveedores). Todo lo que supera esa banda es rediseño de la carga de trabajo, no configuración.

Veredicto comparativo: Databricks (DBU) frente a Snowflake (créditos) frente a AWS nativo (Athena, $/TB escaneado)

• Medidores. Databricks factura DBU/h de forma y, en classic, la factura de EC2, dos medidores, las palancas más expuestas (jobs 0.15 · all-purpose 0.55 · SQL 0.22/0.55/0.70 por DBU, lista de oct 2026). Snowflake factura créditos con la máquina incluida, X-Small = 1 crédito/hora, doblando con la talla (Small 2, Medium 4, Large 8, X-Large 16), por segundo con un mínimo de 60 segundos, a $2.00 Standard / $3.00 Enterprise / $4.00 Business Critical por crédito en AWS US East (tabla de consumo del servicio de Snowflake + FAQ de la calculadora, leída 2026-10). El nativo de AWS, representado por Athena, factura dólares por TB escaneado, los ejemplos resueltos oficiales ponen las consultas a $5/TB con un mínimo de 10 MB por consulta (aws.amazon.com/athena/pricing, 2026-10), cero costo inactivo, pero la orquestación, el estado y la gobernanza son tuyos.
• Inactividad. Databricks classic factura EC2 (y DBUs) mientras está activo: la defensa es la parada automática de 45/10 min, la terminación automática y los pools. Snowflake se auto-suspende a cero. Athena no tiene inactividad alguna. Si dejas el cómputo de Databricks activo, es el más caro de los tres; si lo vigías, el cómputo de jobs es el medidor de ingeniería de ejecución larga más barato.
• Ilustración (168 h = 8 h × 21 d; tamaños de medición asumidos como T-shirts, confírmalos en tu cuenta): SQL Serverless Small 12 × 168 × $0.70 = $1,411.20; SQL Classic 2X-Small 4 × 168 × $0.22 = $147.84 + máquina; Snowflake X-Small 168 × $2 = $336 (Standard) y Large 168 × 8 × $2 = $2,688; Athena 1 TB/día × 30 = 30 TB × $5 = $150. Mismo equipo, mismos datos, tres medidores: la cifra depende de qué medidor te olvides de vigilar.
• Veredicto. Athena gana en cargas de trabajo raras, de poco escaneo y forma serverless, y pierde en cuanto necesitas estado de ETL, streaming o ML. Snowflake tiene la factura más simple (un medidor que se detiene solo) y es difícil de batir para BI elástico en tallas X-Small: Large. Databricks es el más caro si se deja inactivo y el más económico para ingeniería + ML de ejecución larga en job compute, porque las palancas: elección de SKU, terminación automática, spot, pools, atribución con system tables: están expuestas a nivel de carga de trabajo. Elige el medidor que estés dispuesto a operar.

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

📋 Caso A: Addepar (gestión de patrimonios, Nube: AWS): $2 millones menos de infraestructura, entrega 5× más rápida Desafío. Equipos de ingeniería y de datos en silos; entrega de pipelines lenta; costo de infraestructura creciente en una plataforma que modela más de $8 trillion en inversiones. Stack en AWS. Databricks corriendo en AWS, Unity Catalog, notebooks compartidos, Databricks SQL: Cloud: AWS en la página de la historia. Resultado reportado. "Addepar models over $8 trillion in investments on Databricks running on AWS. Shared notebooks, Unity Catalog and collaborative data access bring engineering and data teams together in one place, accelerating pipeline delivery by 5x and cutting infrastructure costs by $2 million." (https://www.databricks.com/customers/addepar/aws, página sin fecha, consultada 2026-10). Ángulo de la lección. La historia clásica de «la unificación es la estrategia de costos»: una plataforma compartida en una sola escalera de SKU reemplazó stacks duplicados, y la métrica de colaboración y la métrica de gasto se movieron juntas. Mapeo principal: esta lección (L15), secundaria L11.

📋 Caso B: Nubank (fintech de LATAM, almacenamiento en AWS S3): +40% de ahorro anual de costos mientras el volumen de consultas se duplicaba Desafío. Una finca muy regulada y en rápido crecimiento (más de 100 millones de clientes) que necesitaba eficiencia de costos y continuidad durante una migración de plataforma de warehouses de 12 meses. Stack. Databricks SQL y Unity Catalog; la capa de almacenamiento "mostly is based on AWS in S3" (transcripción de Databricks Answers, 2026-08-27). Resultado reportado. "Zero-downtime throughout the 12-month migration period … Successfully scaling platform to handle 100% query growth (20MM to 40MM monthly queries) … 17k users globally … +40% annual cost savings … Leverage of UC for centralized data governance in highly regulated FSI industry" (https://www.databricks.com/dataaisummit/session/how-nubank-migrated-databricks-sql-reducing-costs-40-and-doubling, página de sesión sin fecha, consultada 2026-10). Ángulo de la lección. El costo por consulta, y no el gasto total, es la métrica honesta: un gasto total más o menos plano mientras el volumen se duplicó es una reducción de costo unitario de nivel 50% lograda migrando al medidor correcto (Databricks SQL) con gobernanza (UC) acoplada. Mapeo principal: L15; secundarias L08 y L11.

📋 Caso C: Comcast (comunicaciones y medios, Nube: AWS): reducción de 10× en costos de cómputo, 640 máquinas → 64 Desafío. Petabytes de telemetría y miles de millones de interacciones de voz desde más de 20M de mandos de voz; pipelines frágiles; dolor de ingesta de archivos pequeños; cientos de modelos desplegados en la nube, on-prem y edge. Stack en AWS. Databricks, Delta Lake (ingesta/enriquecimiento/optimización de archivos pequeños), MLflow gestionado, autoscaling + spot instances, notebooks; Tableau aguas abajo: Cloud: AWS en la página de la historia; listado entre clientes "already leveraging Databricks on AWS" (nota de prensa, 2022-05-10). Resultado reportado. "10x Reduction in overall compute costs to process data · 90% Reduction in required DevOps resources"; "Delta Lake has enabled Comcast to optimize data ingestion, replacing 640 machines with 64 while improving performance"; despliegue de modelos de "weeks to minutes" (https://www.databricks.com/customers/comcast, página sin fecha, origen de la historia 2019, consultada 2026-10). Ángulo de la lección. La optimización más barata es estructural: el manejo de archivos de Delta colapsó la flota 10× antes de cualquier ajuste de tarifa o de tiempo inactivo, y las spot instances atacaron después la columna de AWS que quedaba. Enseña las métricas como lo que Comcast reportó en su momento (historia de 2019), no como capacidad actual de la plataforma. Mapeo principal: L14; secundaria esta lección.

📋 Caso D: Lumen y GetYourGuide (de la sección 11): serverless SQL como recorte de costos El salto de Looker a serverless de Lumen recortó el cómputo SQL un 30 to 40% con consultas ~90% más rápidas; GetYourGuide recortó el servicio de BI un ~20% con consultas ~35% más rápidas (blog de Databricks, 2026-10-07). Ambos ahorros son historias de tiempo inactivo y eliminación de flota: la misma aritmética que el ejemplo resuelto E4, a escala empresarial.

---

Preguntas de Práctica (Practice Questions)