Puedes leer todo sin registrarte. Solo crearemos un perfil anónimo cuando decidas guardar tu progreso.
Lección 4 de 5
Compute policies y budgets
Impone guardrails con compute policies y atribuye serverless mediante usage policies sin incluir información sensible en tags.
- Duración
- 17 min aprox.
- Objetivo
- Impone guardrails con compute policies y atribuye serverless mediante usage policies sin incluir información sensible en tags.
- Siguiente paso
- Continuar con la siguiente lección
Ver detalles del módulo
Compute, políticas, etiquetas y costes
Atribuye consumo, controla guardrails y optimiza coste sin degradar el valor del workload.
- Consultar costes con system tables
- Etiquetar y atribuir consumo
- Elegir modos serverless y políticas
04DiagnósticoCompute policies y budgets
Impone guardrails con compute policies y atribuye serverless mediante usage policies sin incluir información sensible en tags.
+
Compute policies y budgets
Impone guardrails con compute policies y atribuye serverless mediante usage policies sin incluir información sensible en tags.
Las compute policies restringen la creación de compute clásico: pueden fijar runtime, modo de acceso, Photon, límites de workers, autotermination y tags. Las familias de políticas aportan bases mantenidas por Databricks. Una buena policy reduce opciones peligrosas y deja editables sólo parámetros que el equipo debe decidir; instalar librerías mediante policies es preferible a init scripts.
Serverless usage policies son objetos distintos que asignan tags de coste a notebooks, jobs, pipelines y otros workloads serverless. Sus tags aparecen en `system.billing.usage.custom_tags`. Los tags viajan a registros y pueden replicarse globalmente: usa centro de coste, producto y entorno, nunca correo, nombre de cliente o datos confidenciales. Recuerda que un pipeline disparado por un job conserva su propia policy.
Modelo mental
Una policy es una barandilla ejecutable: transforma estándares de coste, seguridad y soporte en opciones permitidas antes de que nazca el compute. No reemplaza RBAC ni decide quién puede leer datos; limita cómo se configura la infraestructura, por ejemplo runtime, familia, Photon, autoscaling, autotermination o tags. En serverless, una usage policy sirve para atribuir consumo según metadatos y contexto disponibles, no para insertar secretos en etiquetas. La buena gobernanza ofrece caminos aprobados para clases de workload, con defaults sensatos y límites explícitos. Una policy demasiado abierta no controla; una demasiado rígida provoca excepciones manuales y equipos que mezclan cargas incompatibles en un único recurso.
Conjunto de reglas que limita y predetermina atributos al crear compute clásico.
Previene configuraciones inseguras o costosas sin depender de revisión manual posterior.Mecanismo de clasificación y atribución del consumo de productos serverless.
Permite FinOps cuando no existe un clúster propio al que adjuntar tags tradicionales.Vocabulario controlado de dimensiones como centro, entorno, producto y clase de workload.
Hace que la atribución sea agregable y evita cientos de etiquetas equivalentes o sensibles.{
"autotermination_minutes": {
"type": "range",
"maxValue": 60,
"defaultValue": 20
},
"autoscale.max_workers": {
"type": "range",
"maxValue": 12,
"defaultValue": 4
},
"custom_tags.cost_center": {
"type": "fixed",
"value": "finance-data"
}
}Completa la policy con familia y reglas del workspace; prueba que usuarios previstos pueden crear compute y no pueden superar guardrails.
Puntos clave
- Compute policies gobiernan configuración clásica; serverless usage policies atribuyen actividad serverless.
- Fija y oculta guardrails, permite sólo decisiones necesarias.
- Los tags no son un almacén seguro para datos personales o secretos.
Evita
- Usar la misma etiqueta `Name` que Databricks aplica al clúster y romper atribución/terminación.
- Incluir identificadores personales o secretos en tags de coste.
Recuerdo activo