AWS Reserved Instances Explained: Know Exactly How They Work—and Why They Matter

Introduction

Amazon Web Services (AWS) Reserved Instances (RIs) are a pricing option that can significantly reduce your cloud computing costs on services like Amazon EC2 and Amazon RDS. In simple terms, a Reserved Instance is not an actual virtual machine, but rather a billing arrangement – a discounted rate that you earn by committing to a usage plan. By agreeing to use a certain instance configuration for a 1-year or 3-year term, you receive a lower price compared to pay-as-you-go On-Demand rates. This upfront commitment can lead deliver savings of up to 72% off standard pricing. It’s similar to signing a long-term lease for an apartment: you commit to paying for a set period, and in return you pay a lower monthly rent than someone on a short-term stay.

Why Reserved Instances?

For AWS EC2 (virtual servers in the cloud), RIs offer a way to lock in savings if you know you’ll need certain compute resources over time. Likewise, AWS’s managed database service Amazon RDS offers reserved DB instances for database workloads with the same idea – you reserve a database instance for 1 or 3 years and get a cheaper rate. While AWS also provides Savings Plans (a newer, flexible discount model) that it actually recommends over RIs for compute services, it’s important to understand how Reserved Instances work. RIs remain relevant for specific scenarios – for example, they can reserve capacity in a particular Availability Zone, and they apply to services like RDS which are not covered by Savings Plans. In this comprehensive guide, we’ll focus primarily on AWS EC2 Reserved Instances (often referred to as reserved instances in AWS or AWS EC2 Reserved Instances) and cover everything from regional vs. zonal scopes, types and classes of RIs, how discounts are applied and billed, to practical aspects like how to purchase, modify, or even sell RIs on the marketplace. We’ll also touch on comparisons such as AWS Savings Plan vs Reserved Instances, and mention AWS RDS Reserved Instances where relevant. By the end, you should have a clear understanding of how AWS Reserved Instances work and how to use them to optimize your AWS costs.

Regional and Zonal Reserved Instances (Scope)

One of the first things to decide when purchasing an AWS Reserved Instance is its scope – whether it’s regional or zonal. This scope determines how and where the RI’s discount and capacity reservation apply:

• Regional Reserved Instances: These apply to a whole AWS Region. A regional RI’s discount can cover matching instance usage in any Availability Zone (AZ) within that region. Regional RIs do not reserve capacity ahead of time – they strictly function as a billing discount. The big benefit is flexibility: you aren’t locked to a specific AZ, and in many cases the RI’s savings can even apply across different instance sizes of the same family (more on “size flexibility” soon). For example, a regional RI for an m5.large instance in us-east-1 can apply to an m5.large running in any AZ (us-east-1a, 1b, etc.) of that region, or even to other sizes in the m5 family if applicable. This flexibility makes regional RIs easy to use across your deployments in the region.
• Zonal Reserved Instances: These are tied to a specific Availability Zone. A zonal RI does include a capacity reservation for the chosen AZ. In other words, if you purchase a zonal RI for us-east-1a, AWS guarantees you will be able to launch an instance in us-east-1a when you need to (even if the AZ is highly utilized by others). The RI’s discount only applies to instances launched in that same AZ. Zonal RIs are less flexible – they require an exact match of instance type and size to give you the discount, with no cross-size or cross-AZ applicability. Essentially, you trade flexibility for the assurance of capacity. Zonal RIs cannot be “queued” for future purchase (you must buy them to start immediately), whereas regional RIs can be queued for a future start date.

Despite these differences, it’s important to note that pricing for a given RI is the same whether you choose regional or zonal scope. The cost of the RI is determined by factors like instance type, term length, payment option, etc., not by scope. The choice between regional vs. zonal comes down to whether you need the capacity reservation (zonal RIs) or prefer flexibility across the region (regional RIs). For most users who are simply seeking cost savings, a regional Reserved Instance is preferable for its convenience. On the other hand, if you have a mission-critical workload that must run in a specific AZ (perhaps due to data locality or redundancy requirements) and you want to ensure AWS will have resources available there, a zonal RI can guarantee that capacity for you.

(Tip: AWS On-Demand Capacity Reservations are another feature to reserve capacity without the long-term commitment, but they don’t provide a discount – you could combine them with Savings Plans. Zonal RIs kind of give you both a capacity reservation and a discount in one package.)

Types of Reserved Instances (Offering Classes)

AWS Reserved Instances come in two offering classes: Standard and Convertible. These classes determine the RI’s flexibility after purchase, and they come with different discount levels. Let’s break down Standard vs. Convertible RIs (often a point of confusion when comparing AWS Reserved Instances vs Savings Plans as well):

• Standard Reserved Instances: These offer the highest discounts off the On-Demand price (the most cost savings). In exchange for that bigger discount, Standard RIs are the least flexible after you buy them. A Standard RI cannot be exchanged for a different configuration – once you pick an instance type, platform, etc., you’re locked into that for the term. You can, however, modify certain attributes of a Standard RI (like switching the Availability Zone, or splitting the RI across sizes – we’ll discuss modifications later). Standard RIs are also the only ones you can sell on the AWS Reserved Instance Marketplace if you no longer need them. In summary, Standard RIs = deepest savings, but fixed to your initial choice (no exchanges).
• Convertible Reserved Instances: These provide a slightly lower discount than Standard RIs (so you might save a bit less percentage-wise), but they introduce much more flexibility. As the name suggests, a Convertible RI can be exchanged during its term for another RI with a different configuration. This means if your needs change – say you reserved an m5.large but later want to use t3.medium instances, or you want to switch from Windows to Linux – a Convertible RI lets you make that change (subject to some conditions) by exchanging for a new RI. The rule is that the new RI(s) you receive in an exchange must be of equal or greater total value than the one you give up (you may pay a prorated difference if you move to a higher-value option). Convertible RIs can also be modified in the same limited ways as Standard RIs (e.g., change AZ) . The trade-off: Convertible RIs cannot be sold on the marketplace. So once you buy a Convertible RI, you’re essentially committed to using it or exchanging it within AWS – you can’t offload it to another buyer. Convertible RIs are useful if you want to commit for savings but worry you might need a different instance type or OS later. They offer peace of mind that you won’t be “stuck” with an RI that no longer matches your workload.

To decide between Standard and Convertible: choose Standard if you’re fairly confident in your long-term requirements and want the maximum savings, and choose Convertible if you value flexibility to adapt the reservation at some cost of a smaller discount. Both types can save you money, and AWS reports that Standard RIs generally have a higher discount percentage than Convertibles. Keep in mind that Savings Plans (the alternative commitment model) are even more flexible than Convertible RIs because they automatically apply to any usage, but those are a separate topic – here we focus on RIs themselves.

How Reserved Instance Discounts Are Applied

Now let’s get into the mechanics of how AWS Reserved Instances work at runtime. Remember, a Reserved Instance is essentially a billing discount that attaches to your usage. When you purchase an RI, nothing immediately changes in your EC2 environment – for example, no new instances pop up by themselves. Instead, AWS records that you have a reservation for a certain configuration, and then it automatically applies the discounted rate to any matching On-Demand instance usage in your account. Here’s how it plays out:

• Automatic discount on matching instances: If you already have a running On-Demand EC2 instance that matches the attributes of the RI you just bought (same region, instance type, platform, tenancy, etc.), AWS will immediately start billing that instance at the Reserved Instance rate instead of the On-Demand rate. You don’t need to restart or do anything to the instance – the change is seamless on the billing side. It’s as if you’ve presented a discount coupon for that instance’s hourly bill. If you don’t have a matching instance running at the moment, the RI simply sits as an unused discount until you launch an instance that meets the criteria. The moment you do launch a matching instance, the RI’s benefit kicks in automatically. (In other words, owning an RI doesn’t immediately spin up an EC2 for you; you have to run an instance to make use of it.)
• Match criteria: For the RI discount to apply, the running instance must match the RI’s key attributes. These attributes include the instance type (and possibly size/family), the platform/operating system, the tenancy (shared or dedicated), and (if applicable) the Availability Zone or Region scope. We will cover specific matching requirements in the next section (“Using Your Reserved Instances”) in more detail. Importantly, the offering class of the RI (Standard vs Convertible) does not affect how the discount is applied to instances – that only affects whether you can change the RI later. So a Standard and a Convertible RI with the same specs will both apply to an instance in exactly the same way in terms of billing.
• Zonal vs Regional application: If the RI is zonal (AZ-specific), the discount will only apply to usage in that exact Availability Zone, and the instance must match the exact instance type and size of the RI. For example, suppose you purchased two zonal RIs for c5.xlarge in us-west-2a. This will provide discounted billing for up to two running c5.xlarge instances in us-west-2a at any time. If you run a third c5.xlarge in that AZ, or any c5.xlarge in a different AZ, those would be charged at On-Demand rates because they exceed or fall outside your reservations. In contrast, if the RI is regional, the discount can apply to any matching instance in the region, regardless of AZ . So a regional RI for c5.xlarge in us-west-2 could cover a c5.xlarge in us-west-2a, or 2b, or 2c, etc. (any zone in us-west-2).
• Instance size flexibility: One powerful feature of regional RIs is instance size flexibility. This means the RI’s discount can apply not just to one specific size, but to any size within the same instance family (e.g., the c5 family) in that region, proportionally based on capacity. AWS accomplishes this by using a “normalization factor” for each size. For example, in the c5 family, maybe a c5.xlarge is considered 8 units, a c5.large 4 units, etc. If you bought one c5.xlarge regional RI, you could run two c5.large instances (each 4 units, totaling 8) and have them both fully covered by the one RI. Conversely, if you run an instance larger than your RI, the RI will cover part of it – e.g., a c5.2xlarge (16 units) running with one c5.xlarge RI (8 units) would get half its usage billed at the RI rate and the other half at On-Demand . AWS always applies the RI to the smallest instances first to maximize your savings . Note: Instance size flexibility only applies to regional RIs, and only for Linux/UNIX platform on shared tenancy (the standard no-license, non-dedicated instances) . Zonal RIs, or RIs for Windows and other licensed OS, and RIs on dedicated hosts do not have this cross-size capability . In those cases, the reservation is only for the exact size purchased.

To visualize this, consider a simple scenario of how RIs apply:

Example scenario: In step 1, a T2 instance is running on-demand ($$$ at on-demand rate). The user purchases a Reserved Instance that matches it, and now that T2’s cost is billed at the RI discounted rate ($$). In step 2, the user buys another RI for a C4 instance, but currently has no C4 running – so that RI is unused initially. In step 3, they launch a C4 instance that matches the second RI, and immediately it starts billing at the RI rate ($$).

In summary, Reserved Instances in AWS automatically “cover” matching resources. If you have purchased an RI and have an EC2 running that meets the criteria, you’ll pay the lower RI price for that instance instead of the normal price. If your usage exceeds what your RIs cover (like more instances or different types), the extra usage just falls back to normal On-Demand charges. AWS handles all this behind the scenes on a per-second basis – you don’t have to manually apply coupons or schedule when to use RIs. As soon as you own an RI, AWS will apply its discount to the appropriate usage in your account each hour.

(For completeness: If you’re using AWS Organizations with consolidated billing, the RI discounts can even apply across accounts – see the Billing section below. Also, RIs apply to pay-as-you-go usage; they don’t cover usage that’s already free, such as the free tier. For example, if you’re new to AWS and in the free trial period for EC2, purchasing an RI will cause you to be charged the RI rate rather than getting it free, effectively bypassing the free tier.)

Using Your Reserved Instances

Once you have purchased one or more Reserved Instances, how do you actually use them? The good news is that there’s nothing special you need to do in terms of turning them on – AWS automatically applies them. However, to take advantage of your RIs, you need to be running EC2 instances that match the RI’s specs. This section provides some practical guidance on ensuring your instances align so you realize the savings. This is essentially the flip side of the matching rules from the previous section, but we’ll phrase it as tips for launching or adjusting your instances.

When you launch a new EC2 instance (or manage existing ones) and you want it to benefit from an RI you’ve purchased, make sure the following attributes match the Reserved Instance:

• Platform (Operating System): Use an Amazon Machine Image (AMI) that corresponds to the platform of your RI. For instance, if you bought a Reserved Instance for “Linux/UNIX”, you should launch an EC2 instance with a Linux-based AMI (such as Amazon Linux or Ubuntu). If your RI was for Windows, then you’d use a Windows AMI, and so forth. Essentially, the OS and licensing (e.g., Linux vs. Windows Server vs. Windows with SQL Server, etc.) must match what you specified when purchasing the RI. AWS refers to this as the product description matching.
• Instance Type/Family: Make sure the EC2 instance type you run is compatible with your RI’s type. If you purchased a zonal RI, you need to launch exactly the same instance type to use the discount (e.g., an RI for t3.large will only apply to t3.large instances in that AZ) . If you purchased a regional RI, you have a bit more flexibility – you can launch any size within the same instance family and the discount will apply, thanks to instance size flexibility . For example, suppose you have a regional RI for t3.xlarge. That RI can cover a t3.xlarge, or two t3.large (since two large equal one xlarge in that family), or four t3.medium, etc., anywhere in the region. So as long as your instance is in the T3 family in this case, you’ll benefit. But if you launch a completely different family (say an M5 instance when you only have a T3 RI), that won’t match and thus won’t get a discount.
• Availability Zone (Scope): If your RI is scoped to a specific Availability Zone (zonal RI), you must launch the instance in that same AZ to use the RI . For example, a reserved capacity in us-east-1a only helps with instances you run in us-east-1a. If you launch in a different zone, the RI won’t apply (even if other attributes match). In contrast, if you have a regional RI, you are free to launch in any AZ within that region – the discount will follow your instance to whichever AZ it’s in, because the RI isn’t tied to one zone .
• Tenancy: Match the tenancy setting. AWS EC2 offers default (shared) tenancy, where your VMs run on shared hardware, and dedicated tenancy (dedicated instances or hosts) where you pay for isolated hardware. RIs are purchased with a specific tenancy in mind. So if you bought the RI for default (which is most common), the instance needs to be a normal shared tenancy instance to get the discount. If you happen to use dedicated tenancy, you’d need a matching dedicated RI. In short, don’t expect a default-tenancy RI to apply to a dedicated instance or vice versa. Most people use default tenancy unless they have a requirement for dedicated hardware.

If you follow the above points when launching instances, your Reserved Instances will automatically cover those instances’ usage. A good practice is to tag or keep track of which RIs you have and ensure you have equivalent instances running. AWS does provide tools to see RI utilization (e.g., in AWS Cost Explorer or Cost and Usage Reports) so you can confirm your RIs are being fully used.

One more thing: What if you have an RI but no matching instance to use it? In that case, the RI is considered unused for that time. You’ve essentially paying for capacity that you aren’t utilizing. This is something to watch out for – it’s usually best to only buy RIs for resources you know will run continuously. If your RI is unused and later you launch an instance that fits, it will start being used at that point onward (there’s no retroactive credit – any past unused hours are just lost). AWS won’t automatically launch instances on your behalf, so it’s up to you to make use of what you bought. For Amazon RDS reserved instances, the concept is similar: you purchase a reserved DB instance and then ensure you launch a database instance of the same type/size in that region to leverage the discount.

(Troubleshooting tip: If you think you have a matching instance but you’re not seeing the RI discount on your bill, double-check all attributes – OS, instance family, region/AZ, tenancy. A common oversight is the “platform” – e.g., an RI for Linux won’t apply to a RedHat Enterprise Linux instance if the RI was for generic Linux/UNIX and you launched an RHEL-specific instance, since RHEL usage is priced differently. AWS has a help article titled “Why aren’t my Amazon EC2 Reserved Instances applying to my bill as expected?” that can guide you through such issues.)

How Billing Works with Reserved Instances

Understanding the billing for Reserved Instances is crucial because it differs from pure pay-as-you-go. Here we’ll discuss how AWS charges you for RIs and how the discounts appear on your bill. We’ll also cover some special cases like consolidated billing across accounts and volume discount tiers. Here are the key points regarding aws reserved instances pricing and billing:

• Upfront payment and commitment: When you purchase a Reserved Instance, you are committing to pay for that instance for the entire term you selected, regardless of actual usage. Terms are either 1 year or 3 years. AWS offers three payment options for RIs: All Upfront, Partial Upfront, and No Upfront. If you choose All Upfront, you pay the whole cost in one lump sum at purchase time, and then nothing more for the rest of the term – your covered instance hours are prepaid. Partial Upfront means you pay a portion at purchase and the rest is charged at a discounted hourly rate over time. No Upfront means you pay nothing at purchase, but you will be billed a discounted hourly rate continuously for the instance throughout the term. No Upfront is essentially like a monthly installment plan – note that AWS may require you to have a good payment history to use this option. No matter which option you pick, you cannot cancel an RI purchase if you change your mind later. Also, the clock starts ticking on the term once you buy it. For example, a 1-year RI will expire exactly one year from the purchase start time (AWS counts a year as 31536000 seconds). When an RI expires, any instances you were running under it simply revert to normal On-Demand pricing at that point. AWS won’t automatically renew RIs for you – if you want to continue with reserved pricing, you’d have to purchase a new RI (or use the queue feature to schedule a renewal, described below).
• Charging for the RI vs. charging for usage: It’s important to differentiate two aspects of billing: paying for the RI itself and paying for instance usage. Since an RI is essentially a “right to a discounted rate,” AWS will charge you for owning the RI (either upfront or monthly as per your payment plan), and then charge your instance usage at the discounted rate. If All Upfront, you pay 100% at the start and nothing more for that instance’s usage (it’s pre-paid). If Partial or No Upfront, you’ll see recurring charges. A key aspect is that AWS charges (or counts as used) the RI for every hour in the term, whether you use it or not. For instance, if you have a No Upfront 1-year RI for an m5.large, AWS will bill you the hourly RI rate 24/7 for the whole year — even hours where you might not have an actual m5.large running. This is why it’s best to keep an actual instance running to utilize it; otherwise, you’re paying for idle hours. Each hour, you can consume up to 1 hour’s worth of instance usage under that RI. If you don’t, that potential savings is wasted for that hour.
• Per-second billing and multiple instances: AWS bills EC2 usage (for Linux-based instances) by the second, and they apply the RI discount at this granular level. One RI can cover up to 3600 seconds of instance running time per hour (which is one full hour of usage). If you run multiple instances concurrently, that one RI’s benefit can be shared within that hour across them, but only up to a total of 3600 instance-seconds. For example, say you have one RI and you launch two matching instances for 30 minutes each (1800 seconds each) within the same hour. Together they ran 3600 seconds, which equals one hour of instance time – so your RI will cover both of them for that half-hour each, and you pay zero On-Demand for those; effectively the RI covered two half-hours. On your bill it would show as 1 hour of RI-covered usage. In contrast, if you had two instances running for the entire hour (7200 seconds total), the RI covers 3600 seconds worth and the remaining 3600 seconds (the second instance for that hour) is billed at On-Demand rates. In other words, one RI can discount one instance hour each hour. If you run more concurrent instances than you have RIs, the extras are charged normally. AWS always tries to maximize your RI use by applying them to your usage in a way that minimizes on-demand spillover. The billing system will apply RIs to usage running at the same time if possible, up to the limit. If this sounds confusing, think of it this way: at the end of each hour, AWS looks at how many total instance-hours you ran of a given type, and how many RI-hours you had available, and charges accordingly. Any usage beyond your RIs is on-demand. The math happens automatically but it’s good to know so you’re not surprised by being charged for some instances even though you thought you had RIs – it could be simply that they were running concurrently beyond the count of RIs owned.
• Example: You have 1 m4.xlarge RI. At some point, you run four m4.xlarge instances concurrently for one hour. Outcome: one of those instances’ hour will be billed under your RI (free aside from the RI fee you paid), and the other three instances will be billed at on-demand price for that hour. Alternatively, if you ran those 4 instances sequentially such that each one only ran 15 minutes and they did not overlap (so still totaling 1 hour of m4.xlarge runtime in that hour), the RI could cover all of that usage since it was one hour’s worth in aggregate. The cost difference in these scenarios will appear in your bill details. This is where AWS’s Cost and Usage Report or detailed billing can help you verify RI utilization.

• Viewing your bill and RI usage: In the AWS Billing console, RIs appear under the EC2 section of your bill. You’ll typically see charges for the RIs (any upfront fee or monthly recurring fee) and the usage of instances. The Bills page lets you expand details to see how many hours were charged as RI vs On-Demand for each region . AWS Cost Explorer also has an RI utilization report to show what percentage of your RIs are being used. It’s a good practice to monitor this, as consistently low RI utilization could mean you have more RIs than needed (or the wrong type). Remember that if you had RIs covering usage, your actual instance usage line items might show $0 for those hours because the cost was offset by the RI payment.
• Consolidated billing and sharing RIs: If you are using AWS Organizations with a master payer account and multiple member accounts (i.e., a consolidated bill for multiple accounts), Standard regional Reserved Instances will automatically apply their discount to usage in any account within the organization by default. AWS aggregates the usage of all member accounts when computing the bill, so the RIs can benefit the whole organization. For example, if Account A bought an RI but Account B is running a matching instance, the discount can still apply – this is great for centralizing purchases. Zonal RIs, however, do not share capacity with other accounts . The capacity reservation part is only for the owner account. The discount of a zonal RI could still apply to another account’s instance if the account is linked (since technically that usage would count, I believe, as long as it’s in the same org and zone), but practically speaking, cross-account sharing is mainly straightforward for regional RIs. Also note, if the account that originally purchased a regional RI is closed or removed, the RI’s discount will continue to apply to the organization as long as it’s still in effect (the master account will then “own” the RI’s costs) . The key takeaway is that you don’t need to buy separate RIs for each account if you have a consolidated setup – one account’s RIs can cover others’ usage, which can simplify management.
• Uninterrupted coverage and queuing: AWS allows you to “queue” the purchase of an RI up to 3 years in advance. This means you can schedule a future RI purchase to start exactly when an existing one expires, ensuring you don’t accidentally forget to renew and then pay on-demand. For example, if you have a 1-year RI ending December 31, you could queue another RI to begin January 1. Queued RIs don’t charge you until they activate, and you can cancel a queued purchase before it takes effect if plans change . Only regional RIs support queuing (zonal RIs must start immediately).
• Volume discount tiers: For very large RI users, AWS has discount pricing tiers. If in a given region you have accumulated a list price value of RIs above certain thresholds (e.g., $500,000), future RI purchases in that region may automatically come at an additional discounted rate. This is essentially AWS’s way of rewarding bulk commitment – the more you spend on RIs, the cheaper they get. These volume discounts apply only to Standard RIs (not Convertibles) and exclude RIs with certain premium licenses (like some SQL Server editions). They also don’t apply to third-party RIs bought from the marketplace. The tier thresholds are quite high (hundreds of thousands of dollars), so small-to-medium businesses may never hit them, but large enterprises might. For example, once you exceed $500k in RI purchases in a region, subsequent purchases might get about a 5% additional discount; above $4 million, maybe 10% (exact percentages can be found on AWS documentation). AWS calculates your “list value” of RIs (the theoretical full price of all your RIs) to determine the tier. This is done using the undiscounted price so that it’s fair regardless of what you actually paid. If you qualify, the discount is applied automatically at checkout for new RIs. The main point: most users won’t need to worry about this, but if you plan to invest very heavily in RIs, be aware of volume discounts.

In summary, with Reserved Instances you either pay upfront or commit to pay over time, and in return your EC2 usage bills get reduced at the agreed rate for the duration. Always keep an eye on when RIs end (set reminders or use the queue feature) so you’re not surprised by a jump in cost afterwards. And consider using AWS’s cost management tools to ensure you’re getting the most out of every RI you’ve purchased.

Buying Reserved Instances for Amazon EC2

Buying a Reserved Instance in AWS is a straightforward process, but there are a few things to consider to ensure you purchase the correct reservation. You can purchase RIs through the AWS Management Console, the AWS CLI, or SDKs. Here’s a rundown of how to buy RIs and what to keep in mind:

1. Selecting the RI attributes: In the EC2 console, go to the “Reserved Instances” section and click to purchase a new Reserved Instance. You will need to specify the attributes of the RI you want. This includes the instance type (e.g., m5.large), platform (e.g., Linux/UNIX, Windows, etc.), tenancy (default or dedicated), scope (region or specific AZ), term length (1-year or 3-year), and payment option (All, Partial, No Upfront). Essentially, you’re describing the exact kind of capacity you want to reserve. It’s important these choices align with the instances you intend to run (refer back to the “Using Your RIs” section for guidance). For example, if you know you’ll need a Windows server running for 3 years, choose the Windows platform; if you plan to run in any AZ in the region, choose regional scope, etc. AWS offers various platform options including Linux, Windows, and variants like “Windows with SQL Server Standard” or “RHEL Linux,” each with different pricing . Make sure to pick the right one (wrongly choosing “Linux” when you needed “Windows” would result in an RI that doesn’t match your actual instance usage!).
2. Searching and pricing: After you specify what you need, AWS will show you available RI offerings and their prices. Sometimes there might be offerings from AWS itself (new RIs) and also from third-party sellers in the Reserved Instance Marketplace (we’ll cover selling in the next section, but basically other customers can list their unused RIs for sale). AWS will quote you the price for your selection. When you proceed to purchase, AWS automatically sets a limit price equal to that quote. This means you won’t pay more than the shown amount. If, for some reason, the market price changes or there’s not availability at that price, the purchase won’t go through – preventing any surprise higher charges. On the other hand, if you’re buying from the marketplace and there’s an even cheaper offering that matches your criteria, AWS will actually give you the lower price automatically if available. So you don’t have to worry about manually picking the cheapest listing; AWS handles it when fulfilling your order.
3. Review and confirm: Before finalizing, double-check all the details of the RI in the confirmation screen. Once you click purchase, you cannot cancel an RI purchase (with the exception of those queued for future, which can be canceled before their start time). This is a critical point – an RI purchase is a financial commitment. AWS makes you acknowledge that it’s non-refundable. So ensure your quantities, instance types, region, etc., are correct. If you’re scheduling it for later (queueing), confirm the date is what you expect. After confirming, the purchase is processed. If it’s an immediate purchase (not queued), the RI becomes active right away and any matching running instances start benefitting immediately.
4. Third-party vs AWS direct: If you are buying an RI that another customer listed on the marketplace (this can happen if you, for example, filter for a shorter term remaining or sometimes a lower price than AWS’s standard offering), the process is largely the same. AWS abstracts the marketplace such that you still just click “buy” and get the RI. The difference is that the term might be whatever was remaining on that person’s RI (e.g., 8 months instead of a full 12) and the upfront price might differ. AWS will handle transferring the ownership to you once purchased. It’s good to know the marketplace exists – sometimes you can find shorter commitments or slightly discounted rates from sellers who want to exit their reservation early. We’ll talk about how selling works later, but as a buyer just know AWS ensures you never pay above what you agreed.
5. Permissions: If you’re using IAM users or roles to manage AWS, ensure the account used to purchase has the necessary permissions. Buying or modifying RIs may require permissions like ec2:PurchaseReservedInstancesOffering and the ability to describe offerings and zones. By default, the root user can do it, but enterprises often restrict who can spend. If you get an “unauthorized” error, you might need an admin to grant you rights or to perform the purchase for you.
6. After purchase – managing RIs: Once bought, the RI will appear in your EC2 Reserved Instances list. You can always view your Reserved Instances in the console to see details like how many you have, their end dates, etc. From there you can also see options to modify, sell, etc., if applicable. AWS will charge any upfront costs immediately to your account on purchase. If Partial or No upfront, the ongoing hourly charges will just appear on your bill over time. Keep an eye on your renewal dates; AWS may send reminders as expiration nears, but it’s good to plan ahead.

In summary, reserved instances can be purchased with a few clicks, but make sure you understand what you’re buying. It’s a bit like buying a plane ticket in advance – you commit and pay, and later you “use” it by flying (running an instance). If you’ve compared AWS Savings Plan vs Reserved Instances and decided RIs fit your needs (like specific instance types or the capacity guarantee of zonal RIs), the purchase process will lock in those savings for you.

(One more note: When purchasing, you’ll also see an option to “renew” an RI. Renewal isn’t automatic, but AWS makes it easy to buy a new one of the same kind as an existing RI that’s about to expire. This is essentially just a convenience feature to pre-select the same parameters as an expiring RI for a new purchase.)

Selling Reserved Instances on the EC2 Reserved Instance Marketplace

What if you have a Standard Reserved Instance that you no longer need? Perhaps your project ended early, or you need a different instance type, or you’re migrating to a new region. AWS provides the Reserved Instance Marketplace where customers can sell their unused Standard RIs to other AWS users. This is a great feature to mitigate some of the risk of long-term commitments, although there are rules and limitations. Here’s how selling RIs works:

• Who can sell and what can be sold: Only Standard Reserved Instances for EC2 can be sold on the marketplace. This includes both regional and zonal Standard RIs. Convertible RIs cannot be sold – AWS doesn’t allow those to be transferred, presumably because of their exchange flexibility. Also, RIs from other services like RDS, ElastiCache, Redshift, etc., are not sellable in this EC2 marketplace . It’s specifically for EC2 Standard RIs. You must also have at least one month remaining on the RI’s term to list it (you can’t try to sell an RI that’s about to expire in a few days; there needs to be a meaningful term left for someone else to buy). Additionally, you can’t sell RIs that you bought under a volume discount tier – AWS doesn’t want people flipping discounted RIs for profit.
• Registration and requirements: To sell, you need to register as a seller with AWS Marketplace (the same backend that handles selling any products on AWS Marketplace). Only the root account user can perform this registration. You will have to provide some info, notably a U.S. bank account for AWS to deposit your proceeds. AWS also requires completing a tax interview (online) because technically you’re selling something and that might have tax implications. One important restriction: currently, AWS accounts based in India (AWS India Pvt Ltd accounts) cannot sell RIs on the marketplace, even if they have a U.S. bank – presumably due to regulatory issues. So the marketplace is largely for accounts on the global AWS (not the dedicated India region accounts).
• Listing your RI: After registration approval, you can create a listing for the RI you want to sell. You’ll choose a selling price (the upfront amount you want someone to pay you for the remaining term of the RI). All listings are anonymous; the buyers won’t know who the seller is. AWS groups similar RIs together (by type, term remaining, etc.) in the marketplace. When a buyer comes to purchase an RI like yours, AWS will automatically fulfill from the lowest-priced listing available in that group. So if you price yours too high compared to others, it might not sell until others are gone. The minimum price you can set is $0.00 (you could technically give it away, but usually people try to recoup some cost). Your listing can be edited by canceling and re-listing if you want to change the price or quantity (there’s no direct edit; you remove the listing and make a new one).
• After sale process: When a buyer’s purchase is matched to your listing, AWS handles the transaction – they charge the buyer and transfer the Reserved Instance to the buyer’s account. For the seller (you), AWS transfers the funds to your specified bank account after deducting a service fee. AWS takes a 12% fee of the upfront price you set. For example, if you listed an RI for $100 and it sold, AWS would keep $12 and you’d get $88. The sold RI is removed from your account; you no longer own it. This means you also lose the capacity reservation and discount from that point forward. If you happened to still be running an instance that was using that RI’s discount, that instance will start being billed at On-Demand rates once the RI is sold (effectively immediately after sale). So be cautious: don’t sell an RI while you’re still depending on it unless you’re okay with paying On-Demand for the remainder of the term.
• Restrictions during sale: You cannot sell an RI until it has been in your account for at least 30 days. And if it was an upfront RI, AWS will only let you sell it after they have fully received your upfront payment (this is usually immediate if credit card, but basically the 30-day rule covers that too). Also, you can’t sell RIs in regions that are “disabled by default” (this refers to some AWS regions that new accounts have to specifically request access to; AWS likely doesn’t support marketplace in those).

Selling RIs is a useful safety valve. For example, if you reserved 10 instances for a project and after a few months you only use 5, you could list the other 5 for sale to recover some cost. The marketplace will expose them to buyers who maybe only need a shorter term (because when they buy, they’re buying whatever term is left on it). From the buyer’s perspective, they might get a deal like a 5-month RI at a lower price than a new 1-year RI. AWS acts as the intermediary to ensure the transaction is smooth for both sides.

Keep in mind that not every RI will sell – if the price of On-Demand or Savings Plans makes your listing unattractive, you might not find a buyer. It’s a bit like a second-hand market. You may need to lower your price over time to get it sold. The marketplace also naturally has more activity for popular instance types. Niche instance types or very large sizes might have fewer interested buyers.

In summary, the Reserved Instance Marketplace provides some liquidity for your commitments. It’s one of the distinguishing aspects of RIs (you can’t “sell” a Savings Plan, for example). This helps mitigate lock-in concerns: if business needs shift, you at least have an option to try to sell the remaining reservation. Just remember the rules: only Standard EC2 RIs, must register as seller (with a U.S. bank), at least a month remaining, 12% fee applies  . Many users may never need to use the marketplace, but it’s good to know it’s there as a fallback.

Modifying Reserved Instances

AWS allows you to modify your Reserved Instances in certain ways, which can be very handy if your deployment changes slightly. Modification is different from exchanging a Convertible RI; modification applies to both Standard and Convertible RIs and is more limited in scope (it doesn’t allow completely changing instance families, for example). The goal of modification is to let you fine-tune attributes like Availability Zone, instance size, or scope so that your RI continues to match your needs. Key points about modifying RIs:

• What can be modified: You can change the Availability Zone of an RI, switch its scope from zonal to regional or vice versa, and adjust the instance size (within the same instance family). For instance, you might have an RI for m5.large in us-east-1a, and you want to move that to us-east-1b – that’s a modification (changing AZ). Or you might have a regional RI for 4 units of t2.small and you want to merge them into a larger t2.medium RI – that’s changing the size. You cannot change the instance family or operating system or term through a modification (changing those would require a Convertible exchange or selling and re-buying). It’s also implied you can’t change between Standard and Convertible – that’s fixed at purchase.
• Splitting and merging reservations: One neat feature is that you can split an RI that covers multiple instances into smaller chunks, or merge multiple RIs into a bigger one, as long as it’s within the same family and region. For example, say you originally bought one RI that covered 4 instances (InstanceCount = 4 of t2.small). You could modify it into two RIs of 2 instances each, possibly in different AZs. Or if you had several RIs of smaller size, you could merge them into one RI of a larger size (the classic example: merge four t2.smalls into one t2.large, since that’s equivalent in normalization) . AWS uses the normalization factor (like we discussed in size flexibility) to allow these merges and splits. The total capacity covered remains the same, just redistributed.
• Process and immediacy: When you submit a modification request (which you can do in the console or via API), AWS processes it and if it succeeds, the change takes effect immediately for billing. In fact, the documentation notes that if your modification is effective at 9:15 PM, the new configuration’s pricing is applied starting from 9:00 PM (the beginning of that hour). The original reservation is essentially ended at that time and replaced with a new one (with new Reservation IDs). The new RI inherits the remaining term of the old one. For example, if you had 10 months left, after modification the new RI will have 10 months left (it doesn’t extend anything). If you had an All Upfront, the new one will show $0 upfront because you already paid – AWS notes that the new modified RIs will list a $0 fixed price since you’re not paying again for them. They also clarify that modifications do not reset any volume discount calculations – the original purchase price is what counted toward that.
• Effect on running instances: Once modified, your RI discount simply shifts to the new parameters. So if you changed AZ, then only instances in the new AZ get the discount going forward. If you had instances in the old AZ, those would lose the coverage unless you have another RI for them. It’s wise to coordinate modifications with how your instances are deployed. If you plan to move some instances to another AZ permanently, then modifying the RI to that AZ makes sense. The capacity reservation (for zonal) also moves accordingly.
• No cost or downtime for modification: There is no fee to modify an RI. You’re not buying anything new; you’re just altering the reservation you already paid for. AWS also imposes no limit on how often you can modify, aside from not modifying an RI that’s already in the process of being modified (no concurrent modifications on the same RI). You can’t cancel a modification request once submitted, but if it fails, nothing changes. If you really needed to undo a modification, you could submit another modification to more or less “merge/split back” to the original setup after it’s done.

To use modifications effectively, remember a few scenarios:

• Changing AZ or scope: If you find that your reserved capacity is needed in a different AZ than originally thought, modify the RI to that AZ (or convert a zonal RI to regional if you no longer need the capacity reservation, gaining flexibility). For example, perhaps us-west-2a had issues and you moved workloads to us-west-2b; you’d want your RI moved too.
• Right-sizing instances: If you purchased too many small RIs but decide to run larger instances instead, you can merge those RIs to cover the bigger instance. Or vice versa: break an RI into smaller pieces if you now want to run multiple smaller instances rather than one big one.
• Rebalancing reservations: Over time, you might accumulate multiple RIs. Modifications let you consolidate or redistribute them for simplicity or optimal coverage.

It’s worth noting that Convertible RIs can also be modified in these same ways (size/zone changes) – converting is separate. And Standard RIs cannot change families via modification. If you need to change to a completely different instance family or OS for a Standard RI, the options are either to sell it or, if that’s not possible, you’re out of luck (this is where Savings Plans or Convertibles show their advantage). But within the constraints, modifications give Standard RIs some welcomed flexibility.

Finally, modifications do not alter your financial commitment. You’re not extending the term or increasing quantity (beyond splitting/merging equivalently). It’s just about making sure your reserved instances align to your actual usage. AWS provides an easy UI for this; you typically select the RI, choose “Modify Reserved Instances,” and then follow prompts to select new AZ or split sizes, etc.

Exchanging Convertible Reserved Instances

Convertible RIs have a special superpower: you can exchange them for other Convertible RIs. This is arguably the biggest benefit of Convertibles – you’re not stuck with the initial instance attributes if your needs evolve. Exchanging is like trading in your current reservation for a different one, as long as you keep the total value the same or higher. Let’s go through how exchanges work:

• Scope of exchange: You can change almost any attribute of a Convertible RI via an exchange. This includes the instance family (e.g., move from M family to C family), the instance type/size, the platform/OS, the tenancy, and even the payment option (All upfront to Partial, etc.) . Essentially you are turning in one reservation and getting a new reservation (or reservations) in return. However, two things cannot change: the Region cannot change (Convertibles are locked to the region you bought them in) , and the remaining term is effectively the same (you can’t use an exchange to extend beyond the original end date; the new RI will have the same end date as the old one had, since you’re not purchasing extra time, just converting what’s left).
• Equal or higher value rule: AWS requires that the new Convertible RI you get is of equal or greater total value than the one you give up . They calculate the “value” as the sum of the upfront paid plus the present value of remaining monthly charges. Practically, this means you can’t exchange for something cheaper and get money back – you must at least break even or pay more. If the thing you want is cheaper, you have two options: either increase the quantity of instances until the value matches up, or accept a shorter remaining term (not usually applicable since term is fixed) or add another different RI to use up the value. AWS will automatically compute how many of the new instances you can get. For example, suppose you have a Convertible RI for 1 m5.4xlarge which has a certain value, and you want to switch to m5.xlarge (which is 1/4 the size and cheaper per hour). AWS might determine that your one m5.4xlarge RI can be exchanged into four m5.xlarge RIs (because 4 of those have equal value) . If it doesn’t come out even, AWS will adjust the quantity to ensure no leftover value . They won’t give you a partial refund; instead you’ll just perhaps get an extra instance in the new RI to make up the value.
• Paying extra (true-up): If the new RI is more expensive than your current one, you’ll have to pay the difference, often called a true-up cost. For instance, you exchange a smaller instance RI for a larger one – you will be charged a one-time amount to cover the increased upfront value or you’ll start paying a higher hourly rate. AWS will tell you what that true-up cost is before you confirm the exchange. All exchanges must result in a true-up >= $0.00; if it would be negative (meaning you would theoretically be owed money because you picked something cheaper), AWS will adjust to $0 by upping the quantity as mentioned.
• Multiple RIs exchange: You can exchange more than one Convertible RI at once and get a single new RI out of it , effectively pooling their value. Conversely, you cannot directly split one Convertible RI into two different exchanges in one step. If you want to exchange a portion of one RI, you’d first use the modify operation to split it into two (for example, separate an RI of 10 instances into one of 6 and one of 4). Then you could exchange one of those parts and leave the other as is . This gives you partial exchange capability.
• Unlimited exchanges: There is no limit to how many times or how often you can perform exchanges over the RI’s life, as long as each time you meet the equal-or-higher value rule . This means if your needs keep changing, you could keep adjusting the reservation. Each exchange essentially issues you a new Reservation ID and retires the old one.
• Requirements: The Convertible RI must be active (not expired obviously) and not already in the middle of another pending exchange request . And it must have at least 24 hours left on it (you can’t exchange on the last day of its term). Also, AWS only lets you exchange for currently offered Convertible RIs – which makes sense, you can only choose from the menu of what AWS is selling now, not some legacy instance type that isn’t sold anymore.

To illustrate, imagine you purchased a 3-year Convertible RI for a fleet of c5.large Linux instances. A year later, you decide to shift to t3.large instances for cost efficiency. You can initiate an exchange: give up the remaining 2 years of c5.large RI and get an equivalent value of t3.large RI. Because t3.large is cheaper than c5.large, AWS might give you, say, two t3.large RIs for each c5.large RI (just hypothetically) so that the value matches. You might end up with more RIs covering more instances, which is fine. Or if it was the opposite (moving to something costlier), you’d pay a bit extra and end up with maybe fewer RIs covering bigger instances.

From a billing perspective, an exchange does not reset your term – the new RI will expire at the same time the original would have. Also, AWS handles exchanges atomically: when the exchange is done, your old reservation is gone and the new one is active immediately, with no gap (similar to modifications, exchanges take effect right away and you’ll see the new reservation ID in your account).

Note that exchanging is only possible for Convertible RIs. Standard RIs are not exchangeable – for those your only option if you need something different is to modify within the limited scope (AZ/size) or sell and then buy a new one. This is why Convertible RIs are attractive if you think you might change OS or instance families. They give you a hedge against future changes in tech or requirements.

Keep in mind that while exchanges are flexible, you are still committed to AWS in general. You can’t exchange a Convertible RI to a completely different service or to a savings plan; it has to be another Convertible RI for EC2. If later AWS introduces a new instance type family (say an m7 comes out and you have an m6 reserved), you could exchange to the new family as long as AWS has Convertible offerings for it.

Finally, it’s worth noting that performing an exchange can be done via the AWS console’s Reserved Instance section (there’s an “Exchange” option for Convertibles). AWS will walk you through selecting the new configuration and show any price adjustment needed. It’s generally a quick process.

Reserved Instance Quotas

AWS imposes some limits on how many Reserved Instances you can purchase, to prevent accidental overspending or abuse. These are often called RI quotas or limits. As of current AWS guidelines, the default quotas related to RIs are as follows:

• Monthly purchase limit: By default, you can purchase up to 20 new regional RIs per month, per region and 20 new zonal RIs per month, per Availability Zone. This is a rolling monthly quota of new purchases. For example, in a region that has 3 AZs, you could buy up to 20 region-scope RIs and 20 for each AZ (so 20×3 for zonal) in that month, which would be 80 total in that region for the month. These numbers are quite high for most use cases (buying 20 RIs every month per AZ is a lot), but AWS sets these to protect customers (and itself). If you for some reason needed more, you can request a quota increase.
• Instance count, not just orders: The quota counts the number of instances covered by RIs, not the number of RI purchases as such. So if you purchase an RI that has an instance count of 10 (meaning it covers 10 instances in one reservation), that counts as 10 towards the limit, not 1. Essentially, AWS is counting how many instances worth of reservations you’re adding. This is relevant if you do a bulk reservation.
• Running instance limits interplay: A critical consideration is your On-Demand instance limits. Each AWS account has a limit on how many On-Demand instances of each type you can run at once (commonly 20 per type, by default, per region). Regional RIs do not let you exceed your On-Demand limits because they do not reserve capacity. For example, if your account is limited to 20 m5.large instances running on-demand, and you already have 20 running, buying 20 more regional RIs for m5.large doesn’t mean you can launch 20 more instances – you’re capped by that 20 running instances limit. The RIs would apply to your existing 20, and any extra RIs would just sit unused unless you increase your instance limit. Therefore, AWS advises that before purchasing a large number of regional RIs, ensure your On-Demand instance limits are high enough to allow you to actually launch that many instances. If not, you should request a limit increase for running instances first.
• Zonal RIs and capacity: Zonal RIs can exceed your On-Demand limits in terms of running instances. Because a zonal RI includes a capacity reservation, AWS will let you launch an instance using that reservation even if it puts you over the usual limit for that instance type. For example, if your On-Demand limit is 20 and you’re already running 20 instances, purchasing say 5 zonal RIs in a particular AZ will allow you to immediately launch 5 more instances of that type in that AZ (for a total of 25 running) despite the normal limit. This is an important distinction – RIs with capacity reservation (zonal) effectively carve out an exception to instance count limits. But regional RIs do not.
• Viewing and increasing RI quotas: You can view your current RI purchase quotas in the AWS Service Quotas console or in the EC2 console under quotas. If you need more than the default (say you have a very large deployment plan), you can request a quota increase through AWS support. AWS will evaluate and often grant higher limits if you have a justified use case.

In practice, most users never hit the RI purchase limits – buying 20 RIs every month is quite a lot of capacity to reserve. These limits are mainly in place as a sanity check (for example, to prevent a runaway script from accidentally purchasing thousands of RIs). If you do strategic purchases (say, a big buy once a quarter), you won’t likely encounter a problem. But if you have a distributed team or CI/CD system that might be triggering RI buys, just be aware of the monthly cap.

Another subtle thing: The RI quota resets each month. So if you hit 20 in January, come February you have a fresh quota of 20 more in that region/AZ. It’s not a hard cap on total RIs owned, just on new purchases per month. You could accumulate more than 20 total RIs over time.

Also, note that RIs you purchase in the AWS Marketplace (third-party) count towards the same quota as ones direct from AWS, since they all go through the purchase system.

In summary, AWS’s default limits allow plenty of headroom for most, but ensure your “reserved instances AWS” purchases align with your “reserved instances in AWS” account limits for running instances. If you plan a large reservation and corresponding scale-up of usage, coordinate raising the limits first if needed. This will prevent a situation where you own RIs but can’t actually spin up enough instances to use them because of an account limit.

Cloudchipr Commitments — Keep Every Reserved-Instance Dollar Working

Before we wrap up, here’s a quick look at how Cloudchipr’s Commitments feature helps you turn the theory you just learned into day-to-day savings:

• One dashboard, zero guesswork – Real-time tiles show your coverage, utilization, and the FinOps-approved Effective Savings Rate (ESR) for EC2, RDS, Redshift, Lambda, and more. You instantly see what’s covered, what isn’t, and how much money is left on the table.
• FinOps-grade ESR tracking – Cloudchipr calculates ESR for every commitment, so you know whether your AWS Reserved Instances (and Savings Plans) are truly beating On-Demand pricing—not just in theory but in hard dollars.
• Smart alerts & recommendations – Slack / email / Teams notifications flag expiring or under-used RIs and suggest right-sized purchases or exchanges—often unlocking up to 65 % additional savings with a click.
• Actionable savings forecast – A “Potential Savings” card projects what you could save this month by following Cloudchipr’s recommendations, keeping teams focused on the highest-impact tweaks.

In short, the Commitments module gives you the continuous visibility and nudges you need to maintain high RI utilization, healthy coverage, and a strong ESR—so the cost-optimization tactics from this guide don’t slip once the billing cycle rolls over.

Conclusion:

AWS Reserved Instances (whether for EC2 compute or RDS databases) can be a powerful cost-saving tool when used correctly. We covered aws EC2 Reserved Instances in depth – from the basics of regional vs. zonal scope and Standard vs. Convertible types, through the nitty-gritty of how discounts apply and how billing works, to the practicalities of purchasing, modifying, exchanging, and even reselling reservations. In comparison to the newer Savings Plans, RIs require a bit more planning and active management, but they also offer unique benefits like capacity reservation and a secondary marketplace. For databases and other services (e.g., AWS RDS Reserved Instances), the concepts are very similar: you commit to a certain DB instance configuration and get billed at a lower rate .

When deciding between AWS Savings Plan vs Reserved Instances, consider your need for flexibility versus capacity assurance. Many users now opt for Savings Plans for EC2 due to simplicity (applying to any instance usage), but Reserved Instances remain indispensable in scenarios where specific resource reservation or service coverage (like RDS) is needed. Often, a combination might serve best: e.g., use Savings Plans for general compute coverage and a few zonal RIs for guaranteed capacity in critical zones.

By understanding how reserved instances work – how AWS applies them, how you can adjust them, and what the limitations are – you can confidently incorporate RIs into your cloud cost optimization strategy. With up to 72% savings on the table and the flexibility to adapt through modifications or exchanges, RIs can yield substantial value for steady-state workloads. Just be sure to monitor their utilization and align them with your actual usage (tools like AWS Cost Explorer’s RI reports can help) so that every Reserved Instance you pay for is pulling its weight in your environment. Happy cost optimizing!