This FinOps policy recommends switching Azure SQL Database instances in non-production environments to the serverless compute tier with auto-pause enabled. Doing so allows the database to automatically pause during periods of inactivity, eliminating compute charges when the instance is idle.
Non-production environments such as development, staging, and testing frequently sit unused for hours or days at a time. Provisioned compute tiers charge continuously regardless of usage, making them a common source of avoidable spend in these contexts.
Why This Policy Matters
Azure SQL Database in the provisioned compute tier bills at a fixed rate per hour, regardless of whether any queries are running. In non-production environments, databases are often active for only a fraction of each day.
Auto-pause on the serverless tier stops compute billing after a configurable idle period. Storage charges still apply, but compute costs drop to zero while the database is paused.
This policy exists because non-production environments are frequently over-resourced and under-monitored. Without active governance, these environments accumulate cost silently over time.
How It Helps Reduce Costs
The serverless compute tier scales vCores dynamically based on workload demand. When the database detects no activity for a defined period, it pauses automatically and compute billing stops.
When a connection is made again, the database resumes within a few seconds. This behavior makes it well-suited for environments where usage is intermittent and predictability of availability is not a strict requirement.
This policy directly reduces compute waste by ensuring non-production databases do not accrue charges during nights, weekends, or extended idle periods.
Potential Savings
A provisioned Azure SQL instance running on General Purpose with 4 vCores costs approximately $370/month in continuous operation.
A serverless instance with equivalent max vCores and a 1-hour auto-pause delay, used for 8 hours per day on weekdays only, would cost approximately $80 to $100/month in compute charges. That represents savings of 70% or more depending on actual usage patterns.
For organizations running 10 or more non-production SQL databases, applying this policy can reduce Azure SQL compute spend by tens of thousands of dollars annually.
Implementation Guide
Infrastructure-as-Code Example (Terraform)
The following example shows a provisioned Azure SQL configuration that violates this policy, followed by a corrected serverless configuration with auto-pause enabled.
Non-compliant configuration (provisioned tier, no auto-pause):
resource "azurerm_mssql_database" "dev_db" {
name = "dev-database"
server_id = azurerm_mssql_server.example.id
collation = "SQL_Latin1_General_CP1_CI_AS"
max_size_gb = 32
sku_name = "GP_Gen5_4"
}This configuration provisions a General Purpose database with 4 vCores. It runs continuously and incurs charges 24 hours a day, 7 days a week. This is a common source of wasted spend in non-production environments.
Compliant configuration (serverless tier with auto-pause):
resource "azurerm_mssql_database" "dev_db" {
name = "dev-database"
server_id = azurerm_mssql_server.example.id
collation = "SQL_Latin1_General_CP1_CI_AS"
max_size_gb = 32
sku_name = "GP_S_Gen5_4"
auto_pause_delay_in_minutes = 60
min_capacity = 0.5
}Key changes in the compliant version:
- sku_name is changed to GP_S_Gen5_4, which specifies the serverless tier (indicated by _S_)
- auto_pause_delay_in_minutes is set to 60, pausing the instance after 60 minutes of inactivity
- min_capacity is set to 0.5, the minimum vCore allocation when active
Setting auto_pause_delay_in_minutes to -1 disables auto-pause. Always confirm this is not set to -1 in non-production environments.
Manual Step-by-Step Instructions
Use these steps to identify and remediate non-compliant Azure SQL databases manually.
Step 1: Identify provisioned-tier non-production databases
- Open the Azure Portal and navigate to Azure SQL Databases
- Filter by resource tags or naming conventions that indicate non-production (e.g., env: dev, env: staging)
- Check the compute tier in the “Configure” blade for each database
- Identify any databases using a provisioned SKU (e.g., GP_Gen5_2, GP_Gen5_4)
Step 2: Validate serverless eligibility
- Confirm the database is on the General Purpose service tier
- Serverless is not available on Business Critical or Hyperscale tiers
- Confirm the database is a single database (serverless is not supported on elastic pools)
Step 3: Migrate to serverless
- In the Azure Portal, navigate to the target database
- Select “Configure” from the left menu
- Change the compute tier from “Provisioned” to “Serverless”
- Set the maximum vCores to match your workload requirements
- Set the minimum vCores to 0.5 or as low as operationally acceptable
- Set the auto-pause delay to 60 minutes or your preferred idle threshold
- Apply the changes (no downtime required for this change)
Step 4: Update IaC definitions
- Update the sku_name in your Terraform configuration to the serverless equivalent
- Add auto_pause_delay_in_minutes with a value between 60 and 10,080 (up to 7 days)
- Set min_capacity to 0.5 or the minimum required by the workload
- Run terraform plan to validate the change
- Apply the change through your standard deployment pipeline
Step 5: Verify auto-pause behavior
- After deployment, monitor the database in Azure Monitor
- Confirm the database transitions to “Paused” state during idle periods
- Verify that connections resume successfully after auto-pause activates
Best Practices
- Tag non-production environments consistently. Use resource tags (e.g., environment: dev) to enable automated policy enforcement and cost allocation.
- Set auto-pause delay based on team working hours. A 60-minute delay is appropriate for most development environments. Longer delays may suit less-active staging environments.
- Set min capacity to the lowest acceptable value. A min_capacity of 0.5 vCores reduces cost during low-usage periods without fully pausing.
- Avoid auto-pause on databases with scheduled jobs. SQL Agent jobs and external processes that expect the database to be online will fail if the database is paused. Evaluate these dependencies before enabling auto-pause.
- Use auto-pause with connection retry logic. Ensure application connection strings include retry logic to handle the brief resume latency (typically 30 to 60 seconds).
- Review serverless suitability quarterly. If a non-production environment becomes more heavily used, re-evaluate whether serverless remains cost-effective or whether a provisioned tier is more appropriate.
Tools and Scripts to Help Implement
Infracost detects this policy violation automatically during infrastructure planning. When a Terraform plan includes an Azure SQL database using a provisioned SKU in a non-production environment, Infracost flags the configuration and shows the projected cost difference between the provisioned and serverless tiers.
Infracost integrates directly into CI/CD pipelines, enabling cost checks before infrastructure changes are merged or applied. This prevents non-compliant configurations from reaching production or accumulating in long-running non-production environments.
This policy is available in Infracost, including in the free trial. Teams can use Infracost to:
- Identify existing Azure SQL databases that are using provisioned compute unnecessarily
- Compare the cost of current configurations against serverless alternatives
- Track remediation progress over time as violations are resolved
- Enforce the policy in pull request workflows to prevent new violations
Infracost enables FinOps teams to burn down existing cost issues methodically and measure progress sprint by sprint.
Azure Policy can also be used to audit or deny the creation of provisioned-tier Azure SQL databases in non-production subscriptions. Combine with resource tagging to scope enforcement accurately.
Azure Monitor provides visibility into database connection and pause events, which helps validate that auto-pause is functioning as expected after deployment.
Examples of Impact
Example 1: Development environment with 8 databases
A software engineering team runs 8 Azure SQL databases in their development environment, each provisioned at GP_Gen5_2. Each database costs approximately $185/month. Total monthly cost: $1,480.
After migrating to serverless with a 60-minute auto-pause delay and observing that databases are actively used for approximately 6 hours per weekday, the team’s monthly compute cost drops to approximately $210 total. Annual savings: over $15,000.
Example 2: Staging environment for a financial services team
A financial services team maintains a staging environment with 3 Azure SQL databases at GP_Gen5_4. Each costs approximately $370/month. The staging environment is used for 2-week testing cycles, with significant idle time between cycles.
Switching to serverless with auto-pause reduces the per-database cost to under $100/month during active cycles and near zero during idle periods. Total annual savings across the 3 databases exceed $8,000.
Considerations and Caveats
- Serverless is not available on all service tiers. Only General Purpose (Gen5) supports the serverless compute tier. Business Critical and Hyperscale databases cannot use auto-pause.
- Auto-pause is incompatible with elastic pools. Serverless databases must be single databases. Databases in elastic pools cannot use the serverless tier.
- Resume latency affects some workloads. When a paused database receives a new connection, it takes 30 to 90 seconds to resume. This is acceptable for most developer workflows but may not suit automated testing pipelines with strict timeout requirements.
- Scheduled SQL jobs will fail when paused. Any SQL Agent jobs or external schedulers that connect to a paused database will fail until the database resumes. Evaluate this risk before enabling auto-pause.
- Minimum vCore billing applies during active periods. Even at min_capacity = 0.5, the database incurs a small charge when active. Serverless is not zero-cost; it is reduced-cost during inactivity.
- This policy applies to non-production environments. Production databases generally require guaranteed availability and predictable performance. Auto-pause is not recommended for production workloads.
- Cross-database queries may time out. If a serverless database is referenced by another database query while paused, the query may time out before the serverless instance fully resumes.