# ¿Pausar la capacidad cuando no se está utilizando reduce el costo? **Pausar una capacidad de tipo "Power BI Embedded" reduce el costo,** pues el cobro es por hora de uso. En el caso de una capacidad de Microsoft Fabric, aunque el cobro también es por hora, ese **ahorro no siempre ocurre.** ## Cuándo la pausa reduce el costo * **Fabric Capacity (SKU F)**: se cobra por hora de ejecución. Pausar la capacidad suspende el cobro mientras permanezca detenida, **siempre que no haya uso futuro preasignado pendiente**. * **Power BI Embedded (SKU A1 a A6)**: se cobran por hora de ejecución; pausar la capacidad (mediante Azure Portal, PowerShell o REST API) suspende el cobro. ## Smoothing, Bursting y Throttling Microsoft Fabric usa [**smoothing y bursting**](https://learn.microsoft.com/en-us/fabric/data-warehouse/compute-capacity-smoothing-throttling), lo que cambia la lógica tradicional de "pausar = ahorrar". ### **Smoothing (suavizado)** * El suavizado permite que las cargas de trabajo usen recursos más allá del límite aprovisionado (capacidad burstable) durante los picos de demanda, distribuyendo el consumo de recursos a lo largo del tiempo. * El suavizado sirve para evitar que procesamientos pesados consuman toda la capacidad disponible y que falle la ejecución o se afecte la visualización de los informes u otras tareas en ejecución. * Para ello, Fabric utiliza el concepto de "preasignación proporcional de uso futuro". Esto permite usar la capacidad con base en el uso promedio, no en el pico. * Cuando ejecuta tareas de background, como la actualización de informes o la ejecución de notebooks o pipelines, el sistema **amortiza y distribuye el costo a lo largo de las próximas 24 horas**. * Para las actividades interactivas (navegación en informes), hay un suavizado mínimo de 5 minutos. * Si **pausa la capacidad antes de que el smoothing se complete**, el sistema entiende que interrumpió la "ventana de pago" y cobrará por separado esas horas que ya estaban asignadas, lo que puede **incluso duplicar el costo estimado** si se considera únicamente la cantidad de horas encendidas, sin tener en cuenta el smoothing. * Ejemplo práctico: si en el informe Fabric Capacity Metrics se muestra que el procesamiento de background está en 50%, esto significa que el 50% de la capacidad ya está comprometido para las próximas 24 horas. Si PAUSA el recurso de Fabric, ese tiempo futuro que fue suavizado se COBRARÁ por separado y ese costo se mostrará en el informe de costos del portal de Azure. ### **Bursting** (capacidad elástica) * Permite que los workloads usen temporalmente más recursos que el SKU base, mejorando el rendimiento en los picos. * Cada SKU tiene un **factor de burst** (p. ej., F2 hasta 32x, F8 puede tener hasta 12x). ### Throttling (limitación) * Ocurre cuando el uso promedio de CU supera los límites suavizados del SKU. * Las operaciones en curso no se interrumpen; la limitación se aplica solo a las próximas operaciones después de que el consumo se suavice. * **Protección contra sobrecarga**: puede superar hasta 10 minutos de capacidad futura sin sufrir limitaciones de rendimiento. * Etapas del throttling: 1. **Delay interactivo**: después de 10 min de sobrecarga. 2. **Rechazo interactivo**: después de 60 min de sobrecarga. 3. **Rechazo de background**: después de 24 h de sobrecarga acumulada. ## Cuándo tiene sentido pausar **Microsoft Fabric** * Fuera de **horarios fijos de ejecución de pipelines** (ej.: 00:00–06:00). * La utilización de la capacidad está compuesta mayoritariamente por acciones interactivas (visualización y navegación en los informes). * Bajo consumo de capacidad por operaciones de background. * **Importante:** analice y siga siempre el consumo de la capacidad en la pantalla de Administración de costos de Azure para verificar si realmente se está logrando un ahorro. A partir del 2.º día después de modificar la programación de las pausas de la capacidad ya es posible analizar el costo diario. ## Cuándo tiene sentido pausar **Power BI Embedded** * Siempre que no haya informes incrustados en uso: no hay smoothing, solo cobro por el tiempo que la capacidad permanece encendida, por lo que el cálculo del ahorro es tan simple como contar la cantidad de horas que estuvo encendida x costo por hora de la capacidad. ## Buenas prácticas de uso de la capacidad 1. **Evite pausar inmediatamente después de tareas pesadas** en Fabric. 2. Use el informe de métricas para analizar el uso activo de background. 3. Planifique **ventanas fijas de disponibilidad de la capacidad** con programaciones alineadas. 4. Considere **escalar a un SKU menor en lugar de pausar**, si el uso es continuo pero liviano. 5. En muchos escenarios, tiene más sentido **activar la reserva de la instancia** y dejarla encendida 24x7 que estar pausando la capacidad para reducir costos. 6. Monitoree y siga siempre el costo diario de la capacidad para poder estimar cuánto será el costo mensual al final del mes desde la página de administración de costos del portal de Azure y evitar sorpresas. No espere a que llegue la factura para saber cuánto costará la capacidad. ## Capacidades con utilización por encima del límite Si su entorno tiene sobrecargas constantes o supera con frecuencia el límite de la capacidad, recibiendo mensajes de error e impedimentos para la actualización de los modelos o la visualización de los informes, esto puede indicar la necesidad de: * Evaluar si es necesario **aumentar el SKU** de la capacidad. * **Dividir los workloads** o distribuirlos en múltiples capacidades. * **Optimizar** las actividades interactivas: * Optimizar medidas DAX con alto consumo de capacidad. * Evitar columnas calculadas y tablas calculadas, si es posible. * Reducir el número de objetos visuales en la misma página (se recomienda no tener más de 10). * Optimizar el modelado de los modelos semánticos, como evitar relaciones N:N y filtrado bidireccional. * Identificar y eliminar columnas y tablas no utilizadas. * Preagregar los datos antes de importarlos a Power BI. * Analizar el consumo de las medidas que aplican filtro de seguridad por fila (RLS). * Optimizar la actualización de los modelos semánticos: * Optimización del código M (Power Query) y asegurar que el Query Folding esté ocurriendo. * Utilización de carga incremental de los datos. * Analizar los índices y el rendimiento general de las consultas y fuentes de datos. * Preagregar los datos antes de importarlos a Power BI. * Identificar y eliminar columnas y tablas no utilizadas. * Optimizar los tipos de datos de las columnas, como reemplazar "Número decimal" por "Número decimal fijo", cuando sea posible, especialmente en tablas de hechos con alta cardinalidad. * Evaluar las propiedades IsAvailableInMdx y el Encoding Hint de la columna. * Separar columnas datetime en una columna de fecha y otra de tiempo o solo hora, dependiendo del nivel de granularidad deseado. * Evaluar el uso de DirectQuery o DirectLake para volúmenes de datos muy grandes. Si necesita ayuda profesional de un equipo de especialistas para ayudar a su empresa a reducir el consumo de capacidad, [haga clic en este enlace](https://powertuning.com.br/reuniao-bi) para programar una reunión con nuestro equipo comercial. Tenemos diversos casos de empresas que lograron una gran reducción en el consumo de capacidades, pasando de F64 a F8, por ejemplo.