Explanation
An Azure SQL Elastic Pool continues to incur costs even if it contains no databases. This can occur when databases are deleted, migrated to single-instance configurations, or consolidated elsewhere - but the pool itself remains provisioned. In such cases, the pool becomes an idle resource consuming budget without delivering value.
This inefficiency often goes undetected in large or decentralized environments where cleanup workflows are manual or inconsistent. Since the pool reserves compute and storage regardless of usage, it silently contributes to unnecessary spend over time.
Relevant Billing Model
- Azure SQL Elastic Pools are billed based on:
- Provisioned compute (eDTUs or vCores)
- Allocated storage
- Charges continue even when no databases are attached to the pool
Detection
- Identify SQL Elastic Pools with zero active databases
- Review recent database migration or deletion activity to determine whether the pool was previously used
- Evaluate whether the pool is intentionally retained for future deployment or placeholder provisioning
- Confirm that no scheduled reallocation or redeployment is planned
Remediation
- Decommission any Elastic Pool with no active databases unless a valid business case exists for retaining it
- Review infrastructure-as-code templates and automation pipelines to ensure pool cleanup is included in deprovisioning workflows
- Establish periodic audits to catch and remove idle pools across subscriptions and teams