Estimación de costes en Fabric: Pago por uso vs Capacidades reservadas

Uno de los mayores retos al implementar Microsoft Fabric no es la arquitectura del Lakehouse ni el diseño de los pipelines, sino la predictibilidad de la factura a final de mes. A diferencia de las licencias fijas por usuario de Power BI Pro o Premium Per User, Fabric se basa en capacidades (F-SKUs) que consumen unidades de capacidad (CU). El modelo de facturación es flexible, pero esa flexibilidad es un arma de doble filo: si no se gestiona con criterio, el coste puede dispararse; si se gestiona con miedo, el rendimiento de los informes penalizará la adopción del usuario final.

Como consultores, nuestra labor es determinar qué modelo financiero encaja mejor con el patrón de carga de trabajo del cliente. No se trata solo de elegir la opción más barata, sino la que ofrezca el mejor equilibrio entre rendimiento, escalabilidad y compromiso financiero. En este análisis desglosamos las dos vías principales: el Pago por uso (Pay-as-you-go) y las Capacidades reservadas a 1 o 3 años, evaluando el punto de equilibrio donde una reserva empieza a ser rentable.

Conceptos fundamentales: CU, Suavizado y Throttling

Antes de comparar precios, es imperativo entender qué estamos pagando. En Fabric, compramos una capacidad nominal (por ejemplo, una F64 que equivale a una P1 de Power BI). Esta capacidad nos otorga una cantidad determinada de segundos de CPU por cada segundo de tiempo real. Sin embargo, Fabric introduce el concepto de Smoothing (suavizado). El suavizado permite que una tarea pesada (como un proceso de Spark en un Notebook) consuma más CUs de las disponibles momentáneamente, repartiendo ese exceso de consumo en una ventana de 24 horas.

Este mecanismo es vital porque evita que tengamos que sobredimensionar la capacidad para picos puntuales. Si el consumo acumulado supera el límite de la ventana de suavizado, entramos en Throttling (estrangulamiento). Aquí es donde las consultas de Power BI empiezan a degradarse o los refrescos de datos se rechazan. Antes de realizar cualquier estimación, es fundamental desplegar la Microsoft Fabric Capacity Metrics App para monitorizar el uso real. En muchos casos, un problema de rendimiento no requiere una capacidad mayor, sino una optimización del motor de consultas en Fabric Warehouse para reducir el consumo de CU por ejecución.

Pago por uso (Pay-as-you-go): Flexibilidad con prima de coste

El modelo de pago por uso es la opción por defecto. Pagas por segundo que la capacidad está activa. Su principal ventaja es la capacidad de pausa y reanudación. En entornos de desarrollo o en empresas con ciclos de carga muy marcados (por ejemplo, solo procesan datos de 8:00 a 20:00), este modelo permite ahorrar costes apagando la capacidad fuera de horas de oficina.

Sin embargo, el precio por hora de una unidad F en pago por uso es significativamente más alto que en el modelo reservado. Además, hay que tener cuidado con el impacto del suavizado al pausar: si apagas la capacidad mientras tienes consumo «adelantado» (deuda de CUs), Fabric te cobrará ese consumo pendiente antes de permitir el apagado completo o lo mantendrá en espera hasta la reanudación.

¿Cuándo elegir Pago por uso?

• Entornos de Sandbox y Desarrollo: Donde no se requiere disponibilidad 24/7.
• Pruebas de concepto (PoC): Para medir el consumo real antes de comprometer presupuesto.
• Cargas de trabajo altamente estacionales: Si solo usas Fabric una semana al mes para el cierre financiero.
• Incertidumbre en el dimensionamiento: Si no sabes si necesitas una F32 o una F128, empieza con pago por uso.

Capacidades reservadas: El descuento por compromiso

Las capacidades reservadas requieren un compromiso de permanencia (generalmente 1 año) a cambio de un descuento sustancial, que suele rondar el 40-41% respecto al precio de pago por uso. Este modelo es ideal para producción, donde la disponibilidad constante es un requisito y el patrón de consumo es predecible.

Es importante destacar que la reserva se aplica a una región y a una serie de SKUs. Aunque es más rígida, proporciona la estabilidad presupuestaria que los departamentos financieros suelen exigir. Aquí ya no tiene sentido pausar la capacidad (aunque técnicamente se pueda), porque el coste es fijo independientemente del uso. El objetivo en este escenario cambia: ya no queremos gastar menos tiempo, sino maximizar el uso de las CUs que ya hemos pagado, moviendo tareas de procesamiento a horas de baja demanda de informes.

-- Ejemplo de consulta para identificar el consumo de CU por query en el Warehouse
-- Ayuda a decidir si una reserva F64 es suficiente
SELECT 
 request_id,
 distributed_statement_id,
 command,
 duration_ms,
 cpu_time_ms, -- Este es el valor clave para estimar CUs
 start_time
FROM sys.dm_exec_requests_history
WHERE start_time > DATEADD(HOUR, -24, GETDATE())
ORDER BY cpu_time_ms DESC;

Comparativa financiera y Punto de Equilibrio

Para tomar la decisión, debemos calcular el «break-even point». Si una reserva anual ofrece un 40% de descuento, significa que pagamos el equivalente a unas 5.256 horas de pago por uso, pero disponemos de las 8.760 horas del año. Si tu capacidad va a estar encendida más del 60% del tiempo (unas 14 horas al día de lunes a domingo), la reserva ya es más rentable que el pago por uso.

En mi experiencia en proyectos de retail, donde los refrescos de datos ocurren de madrugada y los usuarios consultan informes de 9:00 a 19:00, la estrategia híbrida suele ganar. Mantener una reserva para la carga base y usar pago por uso para escalar en periodos críticos como el Black Friday es una táctica avanzada que optimiza el ROI. Para entender mejor cómo estructurar estos datos, te recomiendo leer sobre el Lakehouse vs Data Warehouse en Microsoft Fabric.

Errores frecuentes en la estimación de costes

He visto proyectos fracasar financieramente no por la herramienta, sino por una mala planificación. Estos son los errores más comunes:

1. No considerar el almacenamiento (OneLake): Las F-SKUs cubren el cómputo, pero el almacenamiento de datos en OneLake se factura aparte (aunque a precios de ADLS Gen2). Si tienes petabytes, el coste de almacenamiento no es despreciable.
2. Ignorar el tráfico de salida (Egress): Si extraes grandes volúmenes de datos de Fabric hacia nubes externas o on-premise, los costes de ancho de banda pueden darte un susto.
3. Subestimar el consumo de los Notebooks: Spark es potente pero voraz. Un bucle mal planteado en un Notebook puede agotar las CUs de una F64 en minutos. Es crucial optimizar mediante Checkpoints de Delta en Fabric para reducir el tiempo de ejecución.
4. Confundir licencias de usuario con capacidad: Recuerda que para que usuarios con licencia gratuita lean informes, necesitas al menos una F64. Por debajo de eso (F2 a F32), todos los lectores necesitan una licencia Power BI Pro.

# Ejemplo de monitorización de consumo en Notebooks
# Permite identificar picos de consumo de CU antes de pasar a Producción

from notebookutils import mssparkutils

# Obtener contexto del consumo actual (simulado para lógica de control)
def check_capacity_usage():
 # En implementaciones reales, consultaríamos la API de métricas
 print("Analizando métricas de consumo para el job actual...")
 # Lógica para alertar si el job supera un umbral de tiempo/recursos

check_capacity_usage()

Estrategia de implementación recomendada

Para una transición segura a producción, como explicamos en nuestra guía sobre Fabric September 2026, sugiero seguir este orden:

• Mes 1: Utiliza Pago por uso. Monitoriza cada minuto con la Capacity Metrics App. Identifica quién gasta qué (Spark, SQL, Power BI).
• Mes 2: Optimiza. Aplica RLS/CLS para eficiencia de seguridad y refactoriza DAX o SQL ineficiente. Puedes consultar cómo hacerlo en RLS y CLS en Microsoft Fabric.
• Mes 3: Con el patrón de consumo estable, calcula el ahorro de pasar a Reserva. Si el uso medio supera el 60% de la jornada, compra la reserva.

Checklist final para la toma de decisiones

• ¿La capacidad estará activa más de 14 horas al día? (Si es sí: Reserva).
• ¿Necesito que usuarios sin licencia Pro vean los informes? (Si es sí: Mínimo F64).
• ¿Tengo picos de carga muy agresivos y cortos? (Si es sí: Pago por uso con escalado dinámico).
• ¿Tengo presupuesto CAPEX anual o OPEX mensual? (CAPEX favorece Reservas).
• ¿He optimizado mis procesos de Spark y Warehouse antes de dimensionar? (Obligatorio).

Preguntas frecuentes

¿Puedo cambiar de una F32 a una F64 si tengo una reserva?

Sí, las reservas de Fabric son flexibles. Puedes intercambiar una reserva por otra de mayor valor, pagando la diferencia prorrateada. Esto permite escalar si el negocio crece más de lo previsto.

¿Qué pasa si mi consumo de CU supera el límite de mi reserva?

Entrará en juego el suavizado. Si el exceso persiste, Fabric aplicará throttling, lo que ralentizará las consultas. No se te cobrará extra automáticamente, pero la experiencia de usuario se degradará hasta que el consumo baje.

¿El almacenamiento en OneLake está incluido en el precio de la F-SKU?

No. El cómputo (F-SKU) y el almacenamiento (OneLake) se facturan de forma independiente. El almacenamiento es un coste fijo por GB/mes similar a Azure Blob Storage.

¿Es posible automatizar la pausa de una capacidad Pay-as-you-go?

Sí, se puede automatizar mediante Azure Logic Apps, PowerShell o la API de Azure para encenderla y apagarla según horarios específicos, maximizando el ahorro en entornos de no-producción.