Azure SQL Elastic Pool
Does ZopNight manage Azure SQL Elastic Pool?
SQL elastic pools reserve a fixed allocation of eDTUs or vCores shared by member databases, billing for that capacity 24/7 even when every member is quiet. ZopNight reads pool sizing via Resource Graph, tracks 60 days of pool utilization, and flags over-provisioned pools plus servers whose standalone databases would consolidate well.
Rules that fire on Azure SQL Elastic Pool
No active rule family targets Azure SQL Elastic Pool 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; elastic pools cannot be paused. |
SQL elastic pools share a fixed allocation of compute resources across many databases with variable usage. A pool sized for peak load bills for that capacity constantly, even when member databases are quiet.
eDTUs and vCores are reserved at the pool, not the database
An elastic pool moves the meter up a level: member databases stop billing individually and the pool bills for its full reserved allocation (eDTUs on the DTU model, vCores on the newer one) around the clock. The economics work when many databases with staggered peaks share headroom; they invert when a pool is sized for a peak that arrives rarely, because the reservation bills at 100 percent while utilization sits far below it. Pools also cannot be paused, so unlike a Serverless database the meter never dips on its own.
Pool telemetry ZopNight works from
Discovered via Azure Resource Graph with pool sizing. Azure Monitor metrics with a 60-day lookback show pool-level utilization, Cost Management billing attributes spend, and rightsizing recommendations flag over-provisioned pools.
The consolidation check on standalone siblings
Pools cut both ways, so ZopNight also evaluates the opposite move: its consolidation rule lists the poolable standalone databases on each logical server, excluding master and databases already in a pool, and considers consolidation only when a server has at least 2 poolable siblings. The sibling list is deliberately capped at 100 databases, the Basic and Standard pool maximum (Premium allows 500); beyond that the rule stays silent rather than mis-pricing the saving, since consolidating a server that large is a capacity decision, not an automated one.
How elastic pools overspend
Three patterns dominate: pools provisioned at launch for growth that never came; pools kept at peak size after their busiest members were migrated out; and single-database pools, which pay the pooling premium for sharing that cannot happen.
Reviewing pools in the portal
Azure portal → SQL elastic pools lists each pool with its server and configured size. A pool’s blade charts its resource utilization, which is the fastest visual check on whether the reserved allocation matches what members actually draw.