Databricks Workspace
Does ZopNight manage Databricks Workspace?
Databricks runs 2 meters at once: DBUs charged by Databricks and VM hours charged by the underlying cloud. Both roll up to the workspace that hosts the clusters, SQL warehouses, jobs, and pools incurring them. ZopNight discovers each workspace and parents every child resource beneath it for cost attribution.
Rules that fire on Databricks Workspace
No active rule family targets Databricks Workspace today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
A Databricks workspace is the environment that hosts clusters, SQL warehouses, jobs, pools, and serving endpoints on AWS, Azure, or GCP. Nothing meters at the workspace level itself, but both of Databricks’ parallel meters (the DBU charge and the underlying cloud VM charge) roll up through it, which makes the workspace the anchor of any honest cost picture.
Two invoices per workload
Databricks compute bills twice at once: DBUs at a rate set by workload type, invoiced by Databricks, and the VMs actually running, invoiced by the cloud provider. The meters move together: a cluster that runs an extra hour adds an hour to both. A per-workspace view has to overlay them. ZopNight prices the VM layer at per-region node rates. DBU spend is not modeled separately: it shows up only where it already reaches your cloud bill, and DBUs invoiced directly by Databricks are not imported yet.
How workspaces are found
On Azure, workspaces surface through Resource Graph as first-class resources and are then enriched through each workspace’s own REST API. On AWS and GCP, ZopNight connects at the account level via OAuth M2M and enumerates workspaces from there. Every discovered child (cluster, pool, SQL warehouse, job, serving endpoint) is parented to its workspace and inherits the workspace’s region, so VM rate lookups resolve against the right price list.
Failure degrades per list, not per workspace
When one API call inside a workspace fails, say a listing of pools returning an error, only that resource type drops out for the cycle; clusters, warehouses, jobs, and endpoints still land. One flaky endpoint never blanks a workspace’s inventory.
What scheduling means at this level
The workspace is not a start/stop target on AWS or GCP; scheduling applies to its children directly. On Azure only, a workspace-level executor can fan stop actions out to child resources.
Enumerate your workspaces
databricks account workspaces listRuns against the account plane, so it needs account-level credentials rather than a token scoped to any single workspace. That is the same plane the OAuth M2M integration authenticates to.