When you’re looking to lower your AWS bill, you’re likely to come across AWS Reserved Instances (“RIs”).
We’re sharing the must-know facts and insights about RIs based on our extensive experience fixing our clients’ horrifying AWS bills through our work here at The Duckbill Group. In this article, you’ll learn what RIs are, how to pay for them, how they’re applied, and interesting edge cases.
We’ve also created a guide to AWS Savings Plans (“SPs”), another common vehicle for committed use discounts.
What are AWS Reserved Instances?
Reserved Instances are a mechanism AWS provides to commit to using a certain configuration of instances for a certain amount of time in exchange for a discount on the instance cost.
One of the things many people new to AWS get confused about is that RIs are not a reservation of capacity, but rather a billing construct (except EC2 zonal reservations, which we explain below). Put simply, you’re not paying for AWS to have the instance available for you; it is entirely possible — though generally rare, in practice — that you could have RIs and be unable to launch the instances that RI calls for.
In fact, the best way to think about RIs is actually by using Google Cloud’s nomenclature: a committed use discount. RIs are a financial construct, not a technical one.
Reserved Instances payment options
All RIs for all supported services have three payment terms: all upfront, partial upfront, and no upfront. Payment options cannot be modified after you’ve made the purchase, even for no-upfront purchases. Payment options don’t impact how Reserved Instances are applied–they only impact the discount you’re receiving and when you pay for commitment.
All-upfront payment terms are exactly what they sound like: You pay for the entire reservation upfront. This option provides the deepest discounts, but in Duckbill’s opinion, the increased discount is generally not enough to be worthwhile.
Partial-upfront payment terms mean you pay just some of the total cost when you purchase your RIs. There’s very little reason to use this unless you simply need to spend the cash but don’t want to spend as much now as an all-upfront payment.
No-upfront payment terms are, again, exactly as they sound. Rather than paying any amount of cash upfront for the purchase, you pay for it monthly. The no-upfront payment option provides the least discount but, in Duckbill’s opinion, should be the default choice for every organization.
Choosing no-upfront payment terms over all upfront or partial upfront comes down to how much you like cash in your bank account versus Amazon’s bank account. There are two exceptions to our recommendation to always use no-upfront terms:
- If you work in an organization that needs to spend its money within a certain budget period, paying upfront might be worthwhile.
- Paying upfront is a good way to shore up a potential shortfall in meeting your AWS contract’s Enterprise Discount Program (“EDP”) or Private Pricing Addendum (“PPA”) commitments.
Reserved Instances term length
All RIs for all supported services have two term lengths available: one year and three years. The term length cannot be modified after you’ve made the purchase.
Three-year terms receive the best discount, but as you might imagine, planning your infrastructure for three years out can be difficult for many organizations. While the delta between one-year and three-year terms can be substantial (think 21% vs. 60%), Duckbill recommends defaulting to one-year terms unless you are confident in your workload forecast.
What services are Reserved Instances available for?
RIs are available for five services: EC2, Elasticache, OpenSearch, RDS, and Redshift (as well as DynamoDB, which has an RI-like structure). Each of these services has its own configuration, and RIs are not swappable among services. In other words, you have to manage RI purchases for each of these services individually.
Amazon EC2 Reserved Instances
WARNING: If you’re considering purchasing RIs for EC2, consider using Savings Plans instead. They are superior to RIs in every way, offering much more flexibility and an easier-to-understand purchasing model, while offering the exact same discount levels as RIs (though, weirdly, Savings Plans for SUSE Linux generally discount deeper than the equivalent RI for some reason). If you’re insistent on purchasing EC2 RIs, then read on.
EC2 RIs have configuration options that make them distinctive from RIs for the other four AWS services: offer class, tenancy, and operating system/platform.
Due to all of the configuration options, it’s helpful to think about instance pricing as a SKU, which happens to be how the AWS API provides the data. For example, there’s a distinct SKU and price for the combination of:
- Standard RI
- c5.xlarge instance
- In us-west-2
- Running Linux
- On shared hardware
- For a one-year term
- Paid all upfront
Change any of these seven options, and you have a different SKU.
Regional and zonal RIs
There are regional RIs and zonal RIs. Generally speaking, people are talking about regional RIs when they discuss Reserved Instances.
Regional reservations apply to any availability zone in the chosen region. Regional reservations offer what AWS calls “instance flexibility.” With instance size flexibility, an RI may apply to any instances within the same instance family of a smaller size than what the RI configuration is for. For example, if you have one RI for a single db.m6.xlarge and later switch to using a smaller db.m6.large, the RI would cover two of the new, smaller instance types. The reverse is also true: smaller instance reservations can partially cover larger instances, or multiple reservations can combine to cover larger instances entirely. You can see exactly how this would work in the EC2 Reserved Instance normalization chart.
Zonal reservations are bound to a specific availability zone (remember, the naming of AZs is not guaranteed to be consistent between AWS accounts in your organization). Zonal reservations do not offer instance flexibility; you must know in advance what size instances you’re going to be using.
One little-known benefit to zonal reservations is that they provide a capacity reservation as well, unlike regional reservations.
Offering classes
There are two offer classes of EC2 RIs: Standard and Convertible. (Technically, there are also Scheduled Reserved Instances, but they support only a subset of older generation instances, the prices don’t make any sense, and it likely should have been formally deprecated ages ago.)
Standard RIs are suitable for static workloads. You cannot change instance family, tenancy, operating system, or payment option. For this inflexibility, Standard RIs offer a larger discount over Convertible RIs.
Convertible RIs allow you to modify instance family, tenancy, operating system, and payment option, providing more flexibility as your infrastructure evolves. For this privilege, your discount is smaller.
If you’re buying EC2 RIs, you generally want Convertible, not Standard, unless you’re covering highly static workloads.
Tenancy
Tenancy determines whether you’re running on underlying hardware other customers are or if you have the hardware all to yourself.
In the early days of the cloud, people didn’t really trust the isolation guarantees that AWS made, so customers required, for a fee of course, hardware platforms that other customers were guaranteed not to be running atop. In the modern era, these concerns are nowhere near as widespread as they once were. Nowadays, they’re generally reserved for commercial software license requirements, such as MacOS EC2 instances.
Operating System
This effectively bifurcates into free, open source OS vendors and commercial OS vendors, where commercial OS vendors include RHEL, SUSE, and, of course, Windows. The two options work the same way, but the discount level and pricing shift because the non-FOSS instances have software licensing costs baked into their pricing. As always, purchasing should follow what’s happening in your account; it shouldn’t lead the process.
ElastiCache Reserved Cache Nodes
ElastiCache Reserved Cache Nodes, as they’re technically called, are available for Memcached, Valkey, and Redis engine options. We’ll refer to them here as RIs, as they’re commonly called.
ElastiCache RIs are roughly equivalent to EC2’s Standard RI offering class in terms of flexibility: When you pick a specific instance family and region, you’re stuck with those choices. However, unlike other Reserved Instances, you can change engines between Redis and Valkey and still receive the discount. If you decide to change instance families or move regions, you have to purchase new RIs, and the old RIs are left unused. In 2024, AWS introduced Reserved Instance size flexibility to ElastiCache RIs.
Amazon OpenSearch Reserved Instances
OpenSearch’s RIs are roughly equivalent to EC2’s Standard RI offering class in terms of flexibility: When you pick a specific instance type and region, you’re stuck with those choices. If you decide to change instance types or move regions, you have to purchase new RIs, and the old RIs are left unused. In other words, there is no instance size flexibility as found with EC2 and RDS.
Amazon RDS Reserved Instances
Like EC2 RIs, RDS RIs have “instance size flexibility” (exception: Microsoft SQL Server and License Included Oracle RDS offerings). With instance size flexibility, an RI may apply to any instances within the same instance family and database engine of a smaller size than what the RI configuration is for. For example, if you have one RI for a single db.m6g.xlarge and later switch to using a smaller db.m6g.large, the RI would cover two of the new, smaller instance types. The reverse is also true: Smaller instance reservations can partially cover larger instances, or multiple reservations can combine to cover larger instances entirely.
This same flexibility also extends to the deployment type. If you have an RI that specifies a multi-AZ deployment and later switch two single-AZ deployments, the RI covers both as if you had purchased two single-AZ deployment RIs. The reverse is also true: If you have two single-AZ deployment RIs and later switch to a single multi-AZ deployment, the RIs are still used at 100%. You can see exactly how this would work in the RDS Reserved Instance normalization chart.
Aside from instance size flexibility and deployment type flexibility, RDS RIs are inflexible with respect to region and the database engine. If either of these changes after purchase, the RIs no longer apply.
One caveat applies to RDS RIs: No-upfront Reserved Instances are only available for a one-year term. To lock in the higher discount levels for multi-year commitments, you must pay at least some money upfront.
Amazon Redshift Reserved Nodes
Redshift’s Reserved Nodes, as they’re technically called, are roughly equivalent to EC2’s Standard RI offering class in terms of flexibility: When you pick a specific instance type and region, you’re stuck with those choices. (We’ll refer to Reserved Nodes here as RIs, as they’re commonly called.) If you decide to change instance types or move regions, you have to purchase new RIs or pay on-demand rates, and the old RIs are left unused.
Unique to Redshift, AWS has incentivized the migration to its newer RA3 node types by offering a Reserved Instance migration program in some regions. There are some constraints with this, however: The new cluster must be at least the same size and price when doing the migration, so you can’t switch to the RA3 nodes, downsize the cluster, and still retain your new RIs.
Amazon DynamoDB Reserved Capacity
DynamoDB Reserved Capacity works similarly to other AWS Reserved Instance offerings, providing a financial construct to save money by pre-committing to a certain level of usage.
With DynamoDB Reserved Capacity, you can purchase capacity for a one-year or three-year term, and then pay via the only payment option: partial-upfront in exchange for discounts over on-demand pricing. Like other RI offerings, DynamoDB Reserved Capacity is a billing construct rather than a technical one, meaning it doesn’t guarantee capacity availability but instead provides a discount on your usage.
It’s important to note that Reserved Capacity doesn’t work with Global Tables or On-Demand DynamoDB tables, so you’ll need to carefully consider your table configurations before making a purchase. As with other RI offerings, it’s generally recommended to start with one-year term unless you have a very stable and predictable workload forecast.
Note there’s also an interesting caveat here: Reserved Capacity doesn’t apply to tables with the Standard-Infrequent Access storage class. As a result, if you have a table that continually grows to the point where you may want to convert it at some point, you may wish to avoid purchasing reserved capacity for that table’s consumption based upon your projected timeline. A similar caveat exists for DynamoDB’s On-Demand billing model; if you suspect you may modify a table to use it, be forewarned when committing to usage.
How Reserved Instances are applied
A point of significant confusion for folks is that you can’t choose which instances an RI applies to. Many people think about RIs in terms of specific instances, then decide to buy an RI to cover that instance. However, that’s not at all how it actually works — and this mental model leads to some unexpected outcomes.
The application of RI-covered workloads is automatic and follows a principle of “deepest discount first.” In other words, if you have a handful of instance types running with different post-RI discount levels, then the RIs apply to workloads where the impact is the greatest until the RIs are exhausted.
For example, let’s say you have one c5.9xlarge instance running, and two otherwise-unused Reserved Instances that can apply to it. The first is a one-year no-upfront reserved instance providing 37% off of the on-demand price. The second is a three year no-upfront Reserved Instance that discounts on-demand by 58%. In this scenario, the second RI would apply for a 58% discount, while the first would go unused.
It’s best to adjust your mental model and think about your workload in aggregate, rather than by specific instances.
In some organizations that do chargeback to their individual teams, this situation can often lead to intense discussion from those whose compute resources aren’t being covered. On one hand, they’re being held accountable for their spend, and that spend is higher than they intended. On the other hand, the organization is better off this way (after all, money is fungible because it’s all company money). The various resolutions to this particular problem are a topic for another day.
Reporting and recommendations on AWS Reserved Instances
AWS provides two primary tools to stay on top of your Reserved Instances: the coverage report and the utilization report.
The coverage report is a measure of how much of your compute for a given service is covered by RIs. In the absence of further context that’s specific to your environment, a reasonable starting goal is 80%.
The utilization report is a measure of how much your RIs are being used. A good goal is 100%, though a case can be made for a few hours a day of overage depending upon the delta between the usage peaks and valleys.
There are effectively four scenarios you could find yourself in:
- Low coverage, low utilization: You have no RIs or the wrong RIs. Your spend isn’t being covered by any RIs, even if you have some.
- Low coverage, high utilization: Not enough RIs. You’re under-committed. Buy more to increase coverage.
- High coverage, low utilization: Too many RIs. You’re overcommitted.
- High coverage, high utilization: Everything is great!
What is the Reserved Instance Marketplace?
The Reserved Instance Marketplace is a mechanism provided and managed by AWS to buy and sell EC2 RIs on a secondary market. This sounds great in theory, but it comes with a lot of caveats in practice. These caveats make the RI Marketplace unreliable in terms of buying what you want or selling RIs for a reasonable return. As a result, the marketplace should be viewed more as an escape hatch to fix a suddenly changed situation, rather than a bulwark of your RI purchasing strategy. More realistically, the RI Marketplace should just be ignored.
It’s worth pointing out that “marketplace” evokes a sense of arbitrage, where you could resell sought-after RIs for a good price. However, because the retail rate of RIs is fixed by AWS, there is an upper bound preventing this sort of arbitrage. The best you can hope for is something less than the retail cost, which means you’re always going to lose some amount of money compared to what you paid. There’s also a 12% fee charged on all RI sales.
Let’s talk about some of the RI Marketplace limitations:
- Only EC2 Standard RIs can be sold in the RI Marketplace. EC2 Convertible RIs and RIs for all other services can’t be sold.
- You can’t sell RIs in any region that is disabled by default (as of 2024, the list is: Cape Town, Hong Kong, Hyderabad, Jakarta, Melbourne, Calgary, Zurich, Milan, Spain, Tel Aviv, UAE, Bahrain) as well as GovCloud East, GovCloud West, Beijing, and Ningxia.
- You must have a U.S. bank account. This means many non-U.S. companies can’t use the RI Marketplace.
- You cannot sell in the RI Marketplace if your account’s seller of record is in India (“AWS India Private Limited”), even if you have a U.S. bank account.
- You may only sell $50,000 in RIs or 5,000 RIs for the lifetime of your account, whichever you hit sooner.
- This specific point matters to large accounts: As per the AWS service terms, you cannot sell an RI on the marketplace if it was acquired at a discount (such as through private pricing discounts).
While it’s listed but before it’s sold, an RI continues to be yours and applies to resources as normal. After it’s sold, any resources that were covered by the RI revert to on-demand rates unless they’re covered by other existing RIs. You can cancel your listing at any time.
As a result of these restrictions, it’s been our experience that the primary users of the RI Marketplace are third-party RI management products, which they use as a source of liquidity for the RIs they purchase.
Using third-party Reserved Instance management products
There exist a slew of third-party products that automate buying and selling RIs, but they have substantial limitations and potential risks for customers. What bugs us the most is that they purport to charge a percentage of the savings they create, but in many cases, they’re simply taking a cut of the savings AWS created and providing no additional savings beyond what would have been possible without them.
Our opinion is that you shouldn’t bother using third-party RI management products as you can get the same result on your own for minimal effort. The value they add tends to be psychological far more than it is financial. While that’s not nothing, it significantly complicates what should be an internalized competency of your organization past a certain point of scale.
Put more directly, the process of buying and managing reservations isn’t that complicated, and certainly not for the fees these products charge.
