# Databricks Spend Crosses Clouds. Governing It Shouldn't Stop at Two. > Databricks is one of the largest and most opaque line items on a data team's cloud bill. It is also one of the few that genuinely spans clouds: the same platform runs on AWS, Azure, and GCP, often… Source: https://zop.dev/resources/blogs/gcp-databricks-cost-governance Published: 2026-06-25 · Author: riya-mittal · Tags: finops, gcp, databricks, cost-optimization, multi-cloud --- Databricks is one of the largest and most opaque line items on a data team's cloud bill. It is also one of the few that genuinely spans clouds: the same platform runs on AWS, Azure, and GCP, often for the same company. Governing it on two of the three leaves the third as a [blind spot](https://zop.dev/resources/blogs/zopnight-claude-mcp-policy-aware-governance), and blind spots are where the all-purpose cluster runs all weekend. ZopNight already covered Databricks on AWS and Azure. It now covers GCP Databricks too: discovery, cost, recommendations, scheduling, and start/stop on GCP Databricks workspaces, with guided account-console setup and a provider chip on every Databricks card so you always know which cloud a workspace lives on. ## A line item that hides inside another bill Databricks is hard to govern because its cost hides one level down. The cloud bill shows compute and storage; the waste lives in how Databricks uses them. An all-purpose cluster left running because someone might need it. A job cluster sized for the largest run and used for the smallest. Interactive clusters that never auto-terminate. From the cloud's point of view this is just VMs. From the data team's point of view it is the [bill nobody](https://zop.dev/resources/blogs/the-idp-bill-180k-year-in-hidden-platform-toil) can explain. Architecture diagram With GCP added, every Databricks workspace on any of the three clouds shows up in one place with its real cost, its recommendations, and a start/stop control. The provider chip on each card means a cross-cloud data platform reads as one estate instead of three separate consoles. ## One estate, one set of moves Coverage parity matters because the moves are the same everywhere. Discover the workspaces. Read the cost. Schedule the clusters that should not run overnight. Rank the recommendations by dollars and act. Doing that on AWS and Azure but not GCP meant a team's third cloud quietly drifted. | Cloud | Discovery | Cost + recommendations | Scheduling and start/stop | |---|---|---|---| | AWS | Yes | Yes | Yes | | Azure | Yes | Yes | Yes | | GCP | Yes, now added | Yes | Yes | Recommendations also got easier to work through: you can now filter by multiple categories at once, for example Rightsizing and Idle together, with a removable chip per category, so a long list collapses to the few items worth acting on. ## When parity matters, and when it does not This matters most to teams genuinely running Databricks across clouds, or planning to. One view, one workflow, no console-switching, and no untracked third cloud. If all your Databricks lives on one cloud, the win is smaller and more about the workflow than the coverage. The honest case for parity is the multi-cloud estate, where the gap was never the tooling on each cloud. It was the seam between them.