The most surprising thing about RDS Reserved Instances (RIs) is that they aren’t actually about reserving instances; they’re about reserving a billing discount.
Let’s see this in action. Imagine you have a db.r5.large instance running in us-east-1 for your production database. It’s on-demand, costing you $0.138 per hour. You know this workload is stable and will be around for at least a year.
Instead of paying the on-demand rate, you can purchase a 1-year term, db.r5.large RDS Reserved Instance for us-east-1. The upfront cost is $784.00. This might seem high, but let’s look at the hourly breakdown. This RI effectively gives you a rate of $0.056 per hour. That’s a 59.4% discount compared to the on-demand price. Over a year (8760 hours), you’d pay $490.56 for the RI, saving you $651.44 compared to paying on-demand.
Here’s the mental model: RDS RIs are a commitment to spend a certain amount on RDS usage over a period (1 or 3 years) in exchange for a significant discount. They are not tied to a specific instance ID. Instead, they apply to a specific instance type, region, and database engine. When you have an active RDS instance that matches the attributes of your RI, the RI’s discounted rate is automatically applied to that instance’s usage. If you have multiple instances matching an RI’s attributes, the discount is applied to the most expensive eligible instances first.
The key levers you control are:
- Instance Type:
db.r5.large,db.m5.xlarge, etc. The RI must match the instance type you’re running. - Region:
us-east-1,eu-west-2, etc. The RI is region-specific. - Database Engine: PostgreSQL, MySQL, Aurora, etc. The RI must match the engine.
- Term Length: 1 year or 3 years. Longer terms offer greater discounts.
- Payment Option: All Upfront, Partial Upfront, or No Upfront. All Upfront offers the largest discount, while No Upfront has the highest effective hourly cost but no capital expenditure.
- Scope: Regional or Zonal. Regional RIs can apply to instances across any Availability Zone within a region, offering more flexibility. Zonal RIs are tied to a specific Availability Zone.
The core mechanism is that AWS essentially "pre-sells" capacity at a discount. By committing to use a certain instance type in a certain region for a year or more, you’re helping AWS smooth out its capacity planning. In return, they give you a lower price. You don’t "assign" an RI to a specific database server. It’s a billing construct that automatically finds eligible usage and applies the discount. This is why you can modify the instance type (within the same family, e.g., db.r5.large to db.r5.xlarge) or even delete and re-create instances, and the RI discount will still apply as long as the new instance matches the RI’s attributes.
The discount doesn’t apply to certain types of RDS usage, like provisioned IOPS for io1/io2 volumes or storage itself, only to the compute cost of the instance. It also doesn’t cover the costs associated with features like Multi-AZ (the standby instance is charged at the on-demand rate unless you have a separate RI that covers it) or Read Replicas, unless those replicas match the RI’s attributes.
The next concept you’ll run into is understanding how to manage a fleet of RIs effectively, especially when dealing with different instance families and regions.