The Economics of Waste: SQL Server on Burstable Cloud CPUs

By Research Team

Cloud migration changed the relationship between infrastructure provisioning and software licensing. Cloud computing promises elasticity and efficiency. You pay for what you use. Legacy software licensing frameworks, specifically those of Microsoft SQL Server, remain rooted in physical hardware paradigms. This friction is most obvious when deploying SQL Server on “burstable” compute instances: the B-series in Microsoft Azure, the T-series in Amazon Web Services (AWS), and the E2 or N1 shared-core machine types in Google Cloud Platform (GCP).

Burstable instances are designed to democratize access to compute for intermittent workloads. They present a deceptive value proposition for database applications. The infrastructure cost of a 2-vCPU burstable Virtual Machine (VM) is negligible. The software licensing obligations create a high “cost floor” that distorts Total Cost of Ownership (TCO). The mandate that every Virtual Operating System Environment (OSE) must license a minimum of four cores forces organizations to pay for non-existent capacity when utilizing small instance sizes.

1. The Licensing Trap

Modern cloud economics rely on granular metering. A burstable instance sells CPU cycles as a utility. The user purchases a baseline fraction of a physical core and accrues credits during idle periods. This model relies on the statistical probability that not all tenants on a physical host will burst simultaneously.

Microsoft SQL Server uses a core-based licensing model designed to capture value based on potential compute power. Since 2012, Microsoft has tied pricing to the number of processing cores. The “4-core minimum” rule dictates that even if a virtual machine acts on a single virtual core, the customer must purchase four core licenses. This applies to SQL Server 2022 and the 2025 updates.

The discrepancy creates a “value trap.” The low hourly rate of the infrastructure lures users into deployments where software licensing costs exceed the infrastructure cost significantly.

2. Technical Architecture: The “Steal Time” Risk

Performance on burstable instances depends on the interaction between the database engine scheduler and the hypervisor resource governance.

In standard instances, the hypervisor provides a rigid mapping for vCPUs. In burstable instances, physical cores are oversubscribed. The hypervisor manages this with a credit scheduler. When a VM demand exceeds its baseline entitlement, the scheduler checks the credit balance.

• Positive Balance: The scheduler allows the VM to consume physical cycles up to the burst limit.
• Zero Balance: The scheduler throttles the VM. It caps execution time to the baseline percentage.

For SQL Server, this throttling is opaque. The operating system may perceive the CPU as available. The instructions are not executed by the physical hardware. This creates “Steal Time” or “Hypervisor Wait.” The guest OS wants to run but is involuntarily paused.

The Death Spiral

SQL Server uses cooperative multitasking via the SQL Server Operating System (SQLOS). Threads voluntarily yield the CPU to allow other workers to run. On a throttled instance, the hypervisor unschedules the vCPU from the physical core. The SQL thread is stuck. Other threads waiting for resources locked by the frozen thread begin to spin. This burns remaining CPU capacity in a futile loop.

3. The “I/O Tax” Hidden Costs

While CPU credits garner the most attention, the storage subsystem of burstable instances presents a more immediate threat to database stability. SQL Server uses a Write-Ahead Logging (WAL) protocol. Every modification must be written to the transaction log on disk before the transaction commits.

Burstable instances (like Azure B-series v1 or AWS T3) throttle storage throughput (MB/s) and IOPS based on instance size. A 2-vCPU instance often has a baseline throughput as low as 8 MB/s. If a transaction log flush hits this ceiling, the SQL engine pauses, accumulating PAGEIOLATCH waits.

4. The Maintenance Window Paradox

Database maintenance tasks—index rebuilds, consistency checks (DBCC CHECKDB), and statistical updates—are resource-intensive. On dedicated hardware, these run during off-hours with no penalty. On burstable instances, these tasks consume accumulated CPU credits.

A nightly index rebuild at 2:00 AM can deplete the credit bank entirely. When the business day begins at 8:00 AM, the instance has 0 credits and operates at its baseline performance (often 10% to 20% of a core). The “morning spike” of user logins hits a throttled server, causing timeouts.

Credit Depletion Simulation

5. Platform Showdown & Cost Models

Each major cloud provider handles this architecture differently. Use the filter below to view specifics for your platform.

Azure B-Series Analysis

The B-series suffers from low disk throughput limits. SQL Server transaction log writes are sensitive to this. If the log cannot flush to disk, the database stalls regardless of CPU credits. Azure Hybrid Benefit allows you to bring licenses, but you still burn 4 cores of entitlement for a 2-core VM.

AWS T-Series Analysis

T3 instances default to “Unlimited” mode. When credits exhaust, the instance bursts using surplus credits billed at roughly 0.05 USD per vCPU-hour. If a SQL Server enters a spinlock loop, it runs at 100 percent CPU indefinitely, quadrupling the hourly cost.

GCP E2 Analysis

GCP uses shared-core machine types like e2-micro and e2-small. These offer sustained performance guarantees. E2 instances do not qualify for Sustained Use Discounts, which narrows the price gap between them and standard instances.

6. Strategic Recommendations

The “cheapest” option on the price list is often the least efficient. The 4-core minimum tax renders the cost savings of 2-vCPU burstable instances marginal compared to the performance risks.

Use Web Edition: For public-facing workloads, SQL Server Web Edition has a much lower cost floor. This is the only economically rational way to use burstable instances for production.

Switch to PaaS: Azure SQL Database Serverless or AWS Aurora Serverless abstract the core licensing. You pay for vCore-seconds. If the database pauses, billing stops.

Development Only: Use the free Developer Edition for non-production environments on burstable hardware to eliminate licensing costs.

Frequently Asked Questions