Coverage drift
A reservation can stop covering its instance and never expire.
A term that ends at least ends. Coverage drift does not. Here's the three ways a match breaks, the seven dimensions behind it, and why nothing tells you it happened.
First, the failure mode
A reservation neither expired nor sat idle, and still stopped paying for the instance you bought it for.
Every reservation is bought to cover one kind of instance. Reserver matches it against what is actually running on every scan. Coverage drift is what happens between two scans: the instance the reservation matched last time no longer matches this time.
The reservation is still active. It still bills every hour of its term. The instance it used to cover is gone, changed, or now covered by a different reservation. Either way, the discount stops applying, and the gap has no clock counting down to a fix.
A missed renewal at least ends. The term runs out, and a new term starts once somebody buys it. Drift has no term to run out. It bills at the wrong rate until a person compares two scans and finds the mismatch.
The three causes
A drifted match breaks on one of two sides, or the instance is simply gone.
Reserver's scanner sorts every drift event into one of three kinds, because the fix is different for each one.
The instance changed
The running instance was resized, moved to a new Availability Zone, or changed engine. Its own dimensions no longer match the reservation covering it.
The reservation changed
The instance never moved. The reservation covering it was modified instead, so it now matches a different instance, or nothing at all.
The instance disappeared
The instance was terminated or replaced. The reservation is still active and still billing, with nothing left to cover.
What can change
Seven dimensions decide whether a reservation still matches, and not every one applies to every service.
Class, family, engine, Availability Zone, Multi-AZ, tenancy, and platform. A reservation matches on all the dimensions its service uses. Change one enough, and the match breaks.
EC2: class, family, Availability Zone, tenancy, platform
Five of the seven dimensions apply. A resize outside the family, a zone move, or a tenancy or platform change can drop the match.
RDS: class, family, engine, Multi-AZ
Four dimensions apply. A Single-AZ to Multi-AZ change can drop the match. So can an engine change, such as a move between SQL Server editions.
ElastiCache: class, family, engine
Three dimensions apply. A node type change or an engine change is the common cause here.
Availability Zone only binds a zonal EC2 Reserved Instance. RDS and ElastiCache reservations are bought per Region, so a zone move never drops their match. Multi-AZ applies to RDS alone. Tenancy and platform apply to EC2 alone.
What size flexibility absorbs
Some changes are not drift at all.
A size-flexible Reserved Instance keeps applying across a resize within the same instance family. A Single-AZ to Multi-AZ flip on some RDS engines is a second case it absorbs. Regional scope, a separate property, absorbs an Availability Zone move on its own. None of that counts as drift, because the reservation keeps paying for the instance.
Drift is a change that neither size flexibility nor regional scope absorbs. A resize into a different family is one example. An Availability Zone move under a zonal RI is another. A zonal RI carries no flexibility to move with it. A tenancy or platform change on EC2 is a third example. See the size flexibility calculator for the exact ladder your own instance class sits on, and where it runs out.
The EC2 modification trap
Modifying an EC2 Reserved Instance retires it and mints a new one.
AWS lets you modify an EC2 Reserved Instance's Availability Zone. You can also change its scope between zonal and regional, or resize it within the same family and generation. AWS's own modification guide is explicit about what happens next. The change retires the original reservation and creates a new one in its place. The new reservation carries a new ID and a $0 fixed price. Any spreadsheet, tag, or runbook keyed on the old ID goes stale the moment this lands. Nothing warns you when it does.
AWS states the risk directly too. After a modification, the benefit applies only to instances that match the new parameters. An instance that no longer matches gets charged at the on-demand rate, unless another reservation happens to cover it. A zonal-to-regional change loses the capacity reservation that came with the zonal scope. A regional-to-zonal change loses the AZ and size flexibility the regional scope had.
The RDS and ElastiCache trap
You cannot modify these reservations at all, so only the instance side can drift.
AWS's own RDS documentation states this plainly. Region, engine, class, and deployment type are fixed at purchase, for the life of the reservation. There is no modification path at all. ElastiCache reservations work the same way.
Reservation-side drift cannot happen here. Instance-side drift still can. Modify the DB instance or the cache node past what the reservation specifies, and the discount just stops applying. There is no retired reservation, no new ID, no event of any kind. The bill is simply higher, from that hour on.
Why nothing tells you
There is no AWS event for a lost match.
A reservation's own utilization metric does not help either. AWS reports how much of a reservation's capacity was used. It does not report whether that capacity was used on the instance you meant.
A reservation that drifts onto a different, similar instance can report full utilization the whole time. Nothing about that number says whether it still covers the fleet the way you expect. Seeing the mismatch takes a comparison. Check what a reservation matched last scan against what it matches this scan.
What it costs
One drifted reservation, priced at 30, 90, and 180 days.
The same illustrative on-demand premium the renewal playbook prices a lapsed term with, run over a longer window. Drift has no term to end it, so the window stays open.
A lapsed renewal ends the day somebody buys the next term. A drifted reservation ends the day somebody notices the mismatch, and nothing on the bill points them to it.
How this scales with you
A manual check works once. It does not work on every scan, forever.
A handful of reservations covering a handful of instances is easy to check by eye, once. Drift still needs a second look after any resize or move, because nothing else will flag it.
Dozens of reservations across a few accounts move often enough that a manual check misses one sooner or later. A comparison run on every scan catches a drifted match the same week it happens, not the same year.
Thousands of reservations across many accounts make a manual comparison impossible. One drifted reservation is a rounding error. A few percent of a large portfolio, drifted and unnoticed, is real money every month.
Where Reserver fits
Reserver compares every scan against the one before it.
Every scan, Reserver checks each previously-covered instance against the fresh snapshot. It checks all seven dimensions, on both the instance side and the reservation side. A lost match shows up as soon as the next scan runs, not whenever somebody happens to look.
See it on your own fleet with the Coverage Check tool, free, no signup, nothing uploaded. Or see the full coverage view, drift included, on the product tour.
What is coverage drift?
Coverage drift is a reservation that stops covering the instance it was bought for. Both the reservation and the instance keep running. The term has not ended, and this is not an expiry. Nothing in AWS raises an alert when it happens.
How is drift different from a missed renewal?
A missed renewal ends when somebody renews the term. Drift has no end date. The reservation keeps billing, unmatched, until somebody compares two scans and notices.
Can an AWS Reserved Instance be modified without causing drift?
Size flexibility absorbs some changes on its own. A resize within the same instance family, under a size-flexible Reserved Instance, still applies the discount. A change outside what size flexibility covers is what causes drift. See the size flexibility calculator for the exact ladder.
Does AWS warn me when a reservation stops matching?
No. There is no AWS event for a lost match. A reservation that drifted onto a different instance can still show full utilization. AWS reports utilization for the reservation, not for the specific instance you expected it to cover.
Does this apply to RDS and ElastiCache the same way it applies to EC2?
No. An EC2 Reserved Instance can be modified in place, and that is itself a common cause of drift. An RDS reservation cannot be modified at all. Only the instance side can drift, and the discount simply stops applying when it does.
Sources, fetched and confirmed on 2026-09-10: modifying EC2 Reserved Instances; and working with RDS reserved DB instances.
Stop overpaying for a steady fleet.
Reserver is in early access. Join the list and we'll onboard you as capacity opens up. Your first recommendation lands within minutes of connecting.