Reserved capacity is a commitment to buy a managed service's own billing unit for one or three years, such as database instances, vCores, request units, storage blocks or slots, in exchange for a lower rate per unit. Each provider runs separate programmes per service, and only some managed services fall under the commitments bought for compute. For the bill, every service needs its own commitment in its own unit, and the discount usually reaches only part of its cost, while storage, backups, networking and licences stay at the normal rate.
How it works
The commitment is bought in the unit the service bills in and applies automatically to matching usage, without being assigned to a particular database. What differs is the unit, how tightly it binds to region and configuration, and whether a broader plan can cover the same usage. What the services themselves cost is the subject of managed databases.
AWS
Reserved DB instances for Amazon RDS bind to region, engine, instance class and licence model. For Db2, MariaDB, MySQL, PostgreSQL and Oracle with bring-your-own-licence, size flexibility applies within one instance class type: a reservation for db.r6i.large covers part of a db.r6i.xlarge but not a db.r7g.large. The discount applies to the instance hour only, not to storage, backups or I/O. The EC2 counterpart is described in AWS Reserved Instances.
DynamoDB reserved capacity applies only to tables in provisioned capacity mode with the Standard table class; AWS states up to 54% off for one year and 77% for three. It can be neither sold, cancelled nor moved to another region.
Database Savings Plans come with no upfront payment only, according to the FAQ, at up to 35% off, for ten database services from Aurora to OpenSearch Service, from instance generation 7 on and for serverless usage. On the same workload they cannot be combined with Reserved Instances or DynamoDB reserved capacity. Lambda and Fargate, by contrast, fall under the Compute Savings Plans in AWS Savings Plans; how functions are billed is set out in serverless functions.
Azure
At Azure these commitments are reservations, under the rules in Azure reservations. For SQL Database and SQL Managed Instance the reservation binds region, deployment type and performance tier; it covers compute only, not software, networking or storage, and DTU-based databases are excluded. Cosmos DB reserved capacity brings up to 63% off according to Microsoft and applies across regions, with a ratio per region (FR South 1.625) and a factor of 1.5 for autoscale. Blob storage reserved capacity binds to region, access tier and redundancy and covers neither operations nor data transfer. Alongside these sits a savings plan for databases, covering SQL Database, SQL Managed Instance, Cosmos DB, PostgreSQL and MySQL among others. Where both fit, Azure applies the reservation first.
Google Cloud
For managed services Google sells spend-based committed use discounts per service, placed in context in Google Cloud committed use discounts. For Cloud SQL the documented discount is 25% for one year and 52% for three, in every region, and applies to vCPU and memory of all instances in the region except shared-core machine types, not to storage, backups, IP addresses, egress or licences. Comparable commitments exist for Spanner and Memorystore, for instance. BigQuery also has capacity commitments in slots through the BigQuery Reservation API, only in the Enterprise and Enterprise Plus editions, bound to a region and an administration project. Cloud Run and GKE fall under compute flexible commitments; Google no longer sells separate commitments for them.
Overview
| Service | Programme | Unit | Term | Reach |
|---|---|---|---|---|
| Amazon RDS | Reserved DB instance | instance class | 1 or 3 years | other sizes of the class type, not every engine |
| Amazon DynamoDB | Reserved capacity | 100 WCU or RCU | 1 year, 3 in some regions | the purchase region only |
| AWS databases | Database Savings Plan | USD per hour | 1 year | ten services, all regions |
| Lambda, Fargate | Compute Savings Plan | USD per hour | 1 or 3 years | EC2 as well |
| Azure SQL | Reservation | vCore | 1 or 3 years | other sizes in the same tier |
| Azure Cosmos DB | Reserved capacity | 100 RU/s | 1 or 3 years | all regions, with a ratio |
| Azure Blob storage | Reserved capacity | 100 TiB, 1 PiB | 1 or 3 years | Data Lake Storage as well |
| Azure databases | Savings plan for databases | amount per hour | 1 or 3 years | several services |
| Cloud SQL | Committed use discount | amount per hour | 1 or 3 years | all engines in one region |
| BigQuery | Capacity commitment | slots | 1 or 3 years | reservations in the region |
| Cloud Run, GKE | Compute flexible commitment | amount per hour | 1 or 3 years | Compute Engine as well |
What it means for your cost
In the AWS Cost and Usage Report, the ARN in reservation_reservation_a_r_n contains the service name and the purchase region, which separates database reservations from EC2. Cost Explorer reports utilisation and coverage for EC2, Redshift, RDS, OpenSearch Service and ElastiCache reservations; DynamoDB is missing from that list. Database Savings Plans appear like other Savings Plans.
In Azure cost details, a reservation for SQL, Cosmos DB or Blob storage behaves like any other: the purchase shows in actual cost as ChargeType = Purchase, covered usage carries a ReservationId and, in actual cost, an EffectivePrice of zero, and amortized cost shows unused hours as UnusedReservation.
The Cloud SQL commitment fee is billed monthly. Google is moving some spend-based CUDs automatically to a consumption model with discounts instead of credits; the console shows the date on the Billing overview page. The FOCUS export lists in x_Credits the type FEE_UTILIZATION_OFFSET for the new model and COMMITTED_USAGE_DISCOUNT_DOLLAR_BASE for the legacy one.
Upfront payments sit in the purchase month in the invoice view; only amortized cost spreads them across the term. How much a commitment can change a service's bill depends on the share of its cost that falls into the commitment's unit; for analytics that split is shown in data warehouses and analytics.
Where it goes wrong
- Storage and backups counted in. Symptom: after an RDS reservation or a Cloud SQL CUD, the database bill drops less than expected. Cause: both discount compute only, not storage, backups, egress or licences.
- Two commitments on one workload. Symptom: a Database Savings Plan sized on all database usage stays partly unused. Cause: AWS does not combine it with Reserved Instances or DynamoDB reserved capacity on the same workload.
- Resized, discount gone. Symptom: after scaling, a database on RDS for SQL Server pays the on-demand rate. Cause: size flexibility applies to some engines only, and only within one instance class type.
- Cosmos DB in an expensive region. Symptom: 100,000 RU/s of reserved capacity covers much less throughput in FR South. Cause: the regional ratio of 1.625 and the autoscale factor of 1.5 multiply consumption.
- Data moves to another tier. Symptom: a Blob reservation for hot stays unused after a lifecycle rule moved data to cool. Cause: the reservation applies only to the purchased region, tier and redundancy; the tiers are covered in block, object and file storage.
Sources
Read on 2026-10-16. AWS Reserved DB instances for Amazon RDS, DynamoDB reserved capacity, Savings Plans types, Savings Plans FAQs, Reservation columns, Using the default Cost Explorer reports; Microsoft Azure Reservations for Azure SQL Database and SQL Managed Instance, Azure Cosmos DB reserved capacity, Blob storage reserved capacity, What are savings plans?, How a savings plan discount is applied, EA and MCA reservation costs and usage; Google Cloud Cloud SQL committed use discounts, Committed use discounts, Manage workload commitments in BigQuery, Structure of the FOCUS data export.