Azure Synapse Analytics Workspace
Does ZopNight manage Azure Synapse Analytics Workspace?
Azure Synapse workspaces are an anchor resource: the workspace itself carries little cost, while its dedicated SQL pools and Spark pools generate the real spend. ZopNight discovers the workspace with child-pool topology via Resource Graph, attributes spend through Cost Management, and applies Synapse rules that flag idle pools for pausing.
Rules that fire on Azure Synapse Analytics Workspace
No active rule family targets Azure Synapse Analytics Workspace today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
At a glance
| Field | Value |
|---|---|
| Scheduling notes | discovery and cost visibility only at the workspace level; dedicated SQL pools are paused individually. |
Azure Synapse Analytics unifies data warehousing, big-data processing, and pipelines in one workspace. The workspace anchors dedicated SQL pools and Spark pools where the real spend accrues.
A billing parent, not a billing meter
The workspace itself is close to free: it is the container that holds pipelines, linked services, and, critically, the compute pools. Dedicated SQL pools bill continuously in DWU blocks while online, Spark pools bill per node while sessions run, and serverless SQL bills per terabyte of data processed. Reading a Synapse bill therefore means reading the children. A workspace showing significant spend with no obvious activity almost always has a dedicated pool someone forgot to pause.
Topology-aware discovery of Synapse
Discovered via Azure Resource Graph with child-pool topology. Cost Management billing attributes workspace-level spend, and Synapse recommendation rules flag idle pools. ML auto-tagging covers this type. Mapping the parent-child structure matters because action happens one level down: the workspace is discovery and cost visibility only, while each dedicated SQL pool is paused individually on its own schedule. See the synapse-pool resource type for those mechanics.
Waste flows through the pools
Three patterns account for most Synapse overspend. Dedicated SQL pools left online overnight and across weekends between load windows, billing their full DWU allocation for idle hours. Spark pools configured with generous autoscale maximums and long session timeouts, holding nodes after notebooks finish. And proof-of-concept workspaces that were never decommissioned, each dragging a small constellation of pools and storage behind it.
Reading a workspace before acting on it
A useful review order: list the workspace’s dedicated pools and their online/paused state first, then Spark pool configurations, then serverless usage. That ordering matches how the spend usually ranks, and it turns an opaque workspace-level number into two or three specific, pausable decisions.
Navigating to Synapse in the portal
Azure portal → Azure Synapse Analytics lists every workspace; opening one shows its Analytics pools blades (SQL pools and Apache Spark pools), where each pool’s status (Online or Paused) is the number that actually moves the bill.