Explanation
Why the waste happens and who it affects.
Many SQL Server workloads, particularly OLTP, reporting, and data warehousing scenarios, are constrained by memory and storage throughput rather than raw CPU capacity. Organizations frequently provision large instance types to obtain the memory or IOPS their workloads require, but in doing so they also pay for a high vCPU count that remains largely underutilized. Because SQL Server licensing often represents the single largest cost component of an RDS for SQL Server instance, paying for unnecessary vCPUs translates directly into wasted licensing spend.
AWS offers an Optimize CPU feature on supported instance families (m7i, r7i, m8i, r8i, m8a, r8a, and x2m) that allows customers to reduce the active core count on their RDS for SQL Server instances while preserving the same memory and IOPS capacity. On these newer generation instances, hyperthreading is disabled by default, and vCPU reduction is achieved by lowering the physical core count. AWS benchmarks demonstrate that instances with reduced vCPU counts can match the transaction throughput of instances with double the CPU, with utilization remaining within acceptable thresholds. This feature is supported on Enterprise, Standard, and Web editions (License Included), as well as Enterprise, Standard, and Developer editions under Bring Your Own Media, for instance sizes of 2xlarge and above, with a minimum of 4 vCPUs after optimization. Organizations that have not evaluated or applied this configuration are likely overpaying for SQL Server licensing on every eligible instance in their fleet.
Billing model
The pricing dimensions that drive this cost.
RDS for SQL Server pricing is billed per database instance-hour consumed, in one-second increments with a 10-minute minimum charge following billable status changes. The License Included model bundles SQL Server licensing, Windows OS licensing, underlying infrastructure, and RDS management capabilities into a single rate.
- SQL Server and Windows licensing costs are charged per vCPU - making the vCPU count the primary driver of licensing expenses. Instances with more vCPUs incur proportionally higher licensing costs.
- Instance pricing varies significantly by SQL Server edition (Enterprise being the most expensive), instance class, region, and deployment type (Multi-AZ roughly doubles the cost).
- On 7th generation instances (M7i, R7i), infrastructure costs and licensing fees are billed separately (unbundled pricing), providing visibility into the licensing portion of the bill. Third-party licensing fees are not eligible for organizational discount programs.
- Storage, provisioned IOPS, backup storage beyond the free tier, and data transfer are billed separately from instance-hour charges.
Because licensing costs scale with vCPU count, reducing vCPUs through the Optimize CPU feature directly lowers the per-hour licensing charge while the infrastructure and memory capacity remain unchanged. The savings are most pronounced on larger instance types and Enterprise Edition deployments.
How to detect
6 checks to find it in your estate.
- Identify RDS for SQL Server instances running on instance families that support Optimize CPU (or candidates for migration to them) that have not been configured with the Optimize CPU feature.
- Review compute utilization patterns across RDS for SQL Server instances over a representative period to determine whether CPU capacity is consistently underutilized relative to memory and storage consumption.
- Assess which instances are running memory-intensive or I/O-intensive workloads that require large instance types primarily for RAM or IOPS rather than CPU capacity.
- Evaluate the SQL Server edition in use for each instance - Enterprise Edition instances represent the highest potential savings due to the largest per-vCPU licensing premium.
- Examine Multi-AZ deployments, where licensing optimization on the active node can yield significant savings on already-doubled deployment costs.
- Confirm the current vCPU configuration and core count for each eligible instance to identify those still running at default core counts without optimization applied.
How to fix
6 ways to remove the waste.
- For new RDS for SQL Server instances, configure the Optimize CPU feature at creation time by selecting a reduced core count appropriate for the workload's CPU requirements, using a supported instance family (m7i, r7i, m8i, r8i, m8a, r8a, or x2m) at 2xlarge or above, with core counts from the list of valid settings for that instance class.
- For existing instances, first validate the optimization in a non-production environment by reducing the core count and benchmarking under realistic workload conditions - ensure CPU utilization remains within acceptable thresholds after the change.
- Apply the Optimize CPU configuration to production instances during a planned maintenance window, as modifying the processor features requires a brief instance restart comparable to an instance class change.
- When restoring snapshots or performing point-in-time recovery from instances with Optimize CPU enabled, explicitly specify processor feature settings or use default processor features if changing instance types, to avoid restore errors.
- Establish a regular review cadence to evaluate CPU utilization on optimized instances and adjust core counts as workload patterns evolve, ensuring the reduced configuration continues to meet performance requirements.
- For instances still running on instance classes that do not support Optimize CPU, evaluate migration to a supported family (m7i, r7i, m8i, r8i, m8a, r8a, or x2m) to gain access to the Optimize CPU feature along with the broader pricing improvements these instance families offer.
Documentation
Vendor references for pricing and configuration.