Multi-cloud
AWS is the only major cloud whose reservation never renews itself.
A platform team that bought its first commitment discount on Azure learned a habit: leave the box checked and the renewal happens automatically. That habit is exactly backwards on AWS. It's only half-right on Google Cloud. Each cloud acts differently at term end. We checked each one against the vendor's own documentation.
The assumption that costs money
"It'll just renew itself" is true on two clouds out of three.
Multi-cloud teams don't learn commitment discounts from a blank slate. They learn them wherever they bought the first one, and carry that model everywhere else. On Azure, that model is right for reservations, which are created with auto-renew already on. On Google Cloud, it's half right: resource-based commitments renew themselves only if you opted in. On AWS, it's wrong every time. There is no auto-renewal setting, opt-in or otherwise, for Reserved Instances or Savings Plans. Usage just reverts to on-demand, silently, the moment the term ends.
None of this is a criticism of any one cloud's design. It's a mismatch between what a multi-cloud team expects and what actually happens, and mismatches are exactly where money leaks. A team running commitments across all three manages several renewal habits, because the default differs by cloud and, on Azure, even by instrument. Only one cloud has no renewal setting to get wrong. On that one, remembering the date is the entire safety net.
First, what each cloud actually sells
The same two commitment shapes everywhere. Three different renewal habits.
All three clouds sell the same two shapes. Reserved Instances, Azure reservations, and resource-based CUDs each fix a specific resource for the term. AWS Savings Plans, Azure savings plans, and spend-based CUDs each fix a dollar amount instead, and let the discount follow whatever qualifying usage turns up. What actually differs between the three clouds is what happens to it when the term runs out, not what they sell.
Head-to-head
Verified against each vendor's own renewal documentation.
No column here is the "winner." Each cloud's renewal behavior is a design choice, not a defect. The sources note at the bottom links the exact vendor pages this table was checked against.
| Dimension | AWS | Azure | Google Cloud |
|---|---|---|---|
| Offers a spend-based commitment, not tied to one resource | ✓Savings Plans | ✓Azure savings plans | ✓spend-based CUDs |
| Auto-renews at term end | ✗no auto-renewal setting exists for either instrument | ✓reservations on by default, savings plans opt-in | ~opt-in, resource-based CUDs only |
| Sends an expiry warning before the term ends | ~opt-in alerts, not on by default | ✓automatic, 30 days ahead and on the day | ✗none described in the renewal docs |
| Once enabled, keeps auto-renewing every cycle without re-opting-in | ✗no auto-renew setting exists to carry over | ✗each replacement resets to auto-renew off | ✓ |
AWS
- ✓Offers a spend-based commitment, not tied to one resourceSavings Plans
- ✗Auto-renews at term endno auto-renewal setting exists for either instrument
- ~Sends an expiry warning before the term endsopt-in alerts, not on by default
- ✗Once enabled, keeps auto-renewing every cycle without re-opting-inno auto-renew setting exists to carry over
Azure
- ✓Offers a spend-based commitment, not tied to one resourceAzure savings plans
- ✓Auto-renews at term endreservations on by default, savings plans opt-in
- ✓Sends an expiry warning before the term endsautomatic, 30 days ahead and on the day
- ✗Once enabled, keeps auto-renewing every cycle without re-opting-ineach replacement resets to auto-renew off
Google Cloud
- ✓Offers a spend-based commitment, not tied to one resourcespend-based CUDs
- ~Auto-renews at term endopt-in, resource-based CUDs only
- ✗Sends an expiry warning before the term endsnone described in the renewal docs
- ✓Once enabled, keeps auto-renewing every cycle without re-opting-in
What happens at term end, cloud by cloud
None, opt-in, and on-by-default, and the catch behind each one.
There's no catch to soften. This is the whole thesis. AWS is the only one of the three with no renewal setting to switch on in the first place, opt-in or otherwise.
The two instruments default in opposite directions: reservations are created with auto-renew on, savings plans with it off. And renewing never extends the original. It buys a replacement, which is itself always created with auto-renew off. Even the cloud that renews itself lapses on the cycle after that unless somebody switches it back on.
Auto-renew exists only for resource-based CUDs. Spend-based CUDs, the more flexible option, have no renewal setting at all, on or off; they expire. Where it is available, it's the one setting here that outlives its own reservation: once enabled, it carries forward onto every renewed commitment, unlike Azure's reset-to-off replacement.
Whether anyone warns you first
Notification behavior differs just as much as the renewal switch itself. On the one cloud that never renews, it's the only safety net there is.
What the gap costs
The dollar amount doesn't care which cloud taught you the wrong habit.
On the single illustrative AWS instance used throughout our renewal playbook, ten days of an unnoticed lapse costs about $134; a month costs about $403. That's one reservation, on one cloud. A multi-cloud team carrying an Azure-shaped assumption into its AWS footprint risks more than one lapse. It risks every AWS reservation it owns, for as long as the wrong habit holds.
Run the same math against your own AWS spend on the savings calculator. The model behind it assumes only 65% of spend is reservable and a 45% blended discount, deliberately conservative, the same numbers cited for startup (1–10 reservations · a single account), growth (dozens of reservations · a few accounts), and enterprise (hundreds to thousands · many AWS accounts & orgs) fleets alike.
What to do about it, at your size
The renewal-habit mismatch shows up earlier than you'd think.
A single AWS account is the common case at this size, and the fix is the cheapest one on this page: track every RI's end date somewhere that isn't a person's memory. Nobody here is renewing an Azure reservation into the wrong assumption yet. The risk shows up later, when the fleet does.
This is where the assumption transfers: a team that stood up its first Azure reservations with auto-renew on carries that mental model into its growing AWS footprint, and AWS never rewards it. On the AWS side, Reserver's expiry radar shows every end date, and you renew in the console. Renewal autopilot is on the roadmap, not built yet. The Azure side still needs its own eyes on the calendar.
At real multi-cloud scale, the three renewal models above are more than trivia. They're three different operational habits running in parallel, each with its own failure mode. One org-wide AWS coverage view doesn't need to guess what Azure or GCP just did; it needs to stop assuming AWS did the same thing.
Whatever size the AWS side of the fleet is today, get its real renewal calendar in seconds with the free Expiry Check tool. Paste your own aws ... describe-reserved-* output and download every end date as an .ics or CSV, no signup, nothing uploaded.
Where Reserver fits today
AWS today. Azure and Google Cloud are not supported.
Reserver connects to your AWS accounts read-only and covers Reserved Instances for Amazon RDS, ElastiCache, and EC2: coverage maps, purchase recommendations with the math shown, and an expiry radar for exactly the failure mode this guide describes. You buy in the AWS console. One-click buying and renewal autopilot are on the roadmap, not built yet. It does not scan, match, or manage Azure reservations or Google Cloud CUDs today; both are on the roadmap, not shipping. If your fleet already spans all three clouds, this guide, and the vendor docs it cites, is the fair version of that comparison; Reserver itself is only the AWS third of it, for now.
Sources, fetched and confirmed on the date shown: AWS: commitment and renewal terms, expiration alerts (2026-10-12); Azure: commitment and renewal terms, savings plan renewal (2026-08-06); and Google Cloud: commitment and renewal terms (2026-08-06).
Do AWS Reserved Instances or Savings Plans auto-renew like Azure reservations?
No. AWS has no auto-renewal setting for either instrument. There's nothing to switch on in the first place. When the term ends, usage reverts to the on-demand rate immediately, whether or not you've used Azure or Google Cloud before and expected otherwise.
If Azure reservations auto-renew, why would a renewal still lapse?
Because renewing doesn't extend the existing reservation. It buys a brand-new one, and that replacement is created with auto-renew switched off. Leave it alone and the cloud that renews itself still lapses on the cycle after that.
Does Google Cloud auto-renew every committed use discount?
Only resource-based CUDs, and only if you opt in. It's a checkbox at purchase or a setting you can enable later on an active (not expired) commitment. Spend-based CUDs, the more flexible option, have no renewal setting at all; they expire.
Does Reserver manage Azure or Google Cloud commitments?
Not today. Reserver covers Reserved Instances for Amazon RDS, ElastiCache, and EC2. Azure and Google Cloud aren't supported. See what's on the roadmap.
Stop overpaying for a steady fleet.
Reserver is in early access. Join the list, and we will onboard you when we have capacity. Your first recommendation lands within minutes of connecting.