.png)
Most guides explain that RDS MySQL reserved instances are size-flexible. Few explain exactly what that means in practice, and almost none explain the part that actually changes how you should buy them: size flexibility also crosses deployment types.
A Single-AZ reserved instance is not locked to Single-AZ instances. It can apply to Multi-AZ instances too — at half the coverage per unit. Two Single-AZ RIs of the same type fully cover one Multi-AZ instance of that type. This means the optimal strategy for MySQL RI purchasing is always Single-AZ at the smallest size in your target family, regardless of whether your running instances are Single-AZ or Multi-AZ.
This guide explains the complete size flexibility mechanics, the cross-deployment type coverage rule, the strategies that follow from both, and the generation constraint that breaks coverage if you are not paying attention.
What Are Normalization Units?
AWS uses normalization units to create a common currency for comparing different instance sizes within the same family. Every RDS instance size has a unit value. When you purchase a reserved instance, you are buying a number of normalization units, not a specific instance size. AWS then automatically applies your RI discount to any running instances in the same family that match your total unit count.
The unit values are fixed and double with each size step:
db.micro = 0.5 units. db.small = 1 unit. db.medium = 2 units. db.large = 4 units. db.xlarge = 8 units. db.2xlarge = 16 units. db.4xlarge = 32 units. db.8xlarge = 64 units. db.16xlarge = 128 units. db.24xlarge = 192 units. db.48xlarge = 384 units.
Source: AWS RDS documentation and confirmed from the live Usage.ai MySQL RI guide. These values apply to all engines with size flexibility (MySQL, PostgreSQL, MariaDB, Aurora, Oracle BYOL). They have been stable since AWS introduced RDS size flexibility in October 2017.
The fundamental rule: if the total normalization units of your running instances equals or is less than the total units of your reservation, your instances are fully covered at the reserved rate. If your running instances total more units than your reservation, the excess is billed at on-demand rates.
Also read: Choosing the Right RDS MySQL Instance Size Before Committing to an RI
How Size Flexibility Works in Practice: Six Scenarios
Scenario 1: Exact Match (Most Common)
You purchase 1 db.r8g.xlarge Single-AZ RI (8 normalization units). You run 1 db.r8g.xlarge Single-AZ instance. The RI covers 8 of 8 units. Coverage: 100%. This is the straightforward case that everyone understands.
Scenario 2: Scaling Down Within the Same Family
You purchase 1 db.r8g.xlarge Single-AZ RI (8 units). You then right-size your database to db.r8g.large (4 units). The RI now has 8 units of coverage and your instance only needs 4 units. The remaining 4 units can cover another db.r8g.large in the same account and region. If you have two db.r8g.large instances running, both are covered. If you have one, the other 4 units are wasted — they do not carry forward to the next hour.
The financial implication: if you right-size a db.r8g.xlarge down to a db.r8g.large and you do not have another r8g instance to consume the leftover 4 units, you are paying for 8 units of reservation while only using 4. Launch a second db.r8g.large to consume the unused coverage, or plan the right-sizing around an upcoming RI expiration.
Scenario 3: Scaling Up Within the Same Family
You purchase 1 db.r8g.large Single-AZ RI (4 units). You later need more capacity and resize to db.r8g.xlarge (8 units). Your 4-unit reservation covers 50% of the xlarge. The other 50% is billed at on-demand rates. AWS does not split your bill into two line items — you see the blended rate: 50% at the reserved rate and 50% at on-demand.
This partial coverage is still valuable: if db.r8g.xlarge on-demand is $0.478/hr and the RI rate for a large is $0.160/hr (effective rate per 4 units), your blended cost is approximately (4 units at $0.160/hr equivalent + 4 units at $0.478/hr equivalent) / 8 units = roughly $0.319/hr versus $0.478/hr without any coverage. You save 33% on half the instance while the other half remains at on-demand.
Scenario 4: Covering Multiple Small Instances With One Large RI
You purchase 1 db.r8g.2xlarge Single-AZ RI (16 normalization units). You split your workload across 4 db.r8g.large instances (4 units each = 16 total). All 4 instances are fully covered by the single 2xlarge reservation.
This is the power of normalization: you did not need to purchase 4 separate RIs. One reservation covers the entire fleet as long as the total normalization units match. AWS confirmed this explicitly: ‘The discounted rate of this RI can automatically apply to 2 db.r8g.xlarge MySQL instances without you needing to do anything.’
Scenario 5: The Cross-Deployment Flexibility Rule (The One Most Teams Miss)
This is the scenario the AI Overview completely omits, and it changes the optimal purchase strategy.
A Single-AZ RI can apply to Multi-AZ instances. The normalization math accounts for the deployment type difference. A Multi-AZ instance uses 2x the normalization units of the equivalent Single-AZ instance because it runs two nodes (primary + standby).
Example: You purchase 1 db.r8g.large Single-AZ RI (4 normalization units). You run 1 db.r8g.large Multi-AZ instance. A Multi-AZ large counts as 8 normalization units (4 units per node x 2 nodes). Your 4-unit Single-AZ RI covers 50% of the Multi-AZ instance. The other 50% bills at on-demand.
To fully cover 1 db.r8g.large Multi-AZ instance: purchase 2 db.r8g.large Single-AZ RIs (4 units each = 8 total = 100% coverage of the Multi-AZ). Source: AWS official RDS Reserved Instances page (aws.amazon.com/rds/reserved-instances, May 2026): ‘The discounted rate of this RI can automatically apply to 50% of the usage of a db.r3.large PostgreSQL Multi-AZ instance in the same region.’
CRITICAL: The reverse is also confirmed by Duckbill Group (December 2024): if you have two Single-AZ RIs and switch to one Multi-AZ instance of the same size, the two Single-AZ RIs still fully cover the Multi-AZ instance at 100%. This means buying Single-AZ RIs does not lock you out of Multi-AZ coverage — it just requires twice as many Single-AZ RIs to cover one Multi-AZ instance.
Scenario 6: Mixed Fleet — Single-AZ and Multi-AZ Running Simultaneously
You have 3 db.r8g.large Single-AZ RIs (12 normalization units total). You run: 1 db.r8g.large Single-AZ (4 units), 1 db.r8g.large Multi-AZ (8 units = 4 per node x 2). Total running units: 12. Your 12 units of Single-AZ RIs cover all 12 units of usage. Full coverage on both the Single-AZ and Multi-AZ instances from the same pool of Single-AZ reservations.
This scenario demonstrates why the Duckbill Group and AWS re:Post both recommend purchasing size-flexible RIs as Single-AZ at the smallest size: you retain full flexibility to cover any combination of Single-AZ and Multi-AZ instances in the same family.
The Optimal Purchase Strategy: Single-AZ at the Smallest Size
Given the cross-deployment flexibility rule, the mathematically optimal strategy for MySQL RI purchasing on size-flexible engines is always:
- Buy Single-AZ RIs, never Multi-AZ RIs, regardless of your current deployment types.
- Buy at the smallest instance size within your target family rather than the specific sizes you are running.
Here is why both rules follow from the flexibility mechanics.
Why Single-AZ RIs Are Always Better
A Multi-AZ RI costs approximately 2x a Single-AZ RI of the same type. It covers Multi-AZ instances of that specific size. It does not cover Single-AZ instances at a proportional rate in return.
A Single-AZ RI costs 0.5x the Multi-AZ RI. Two Single-AZ RIs of the same size fully cover one Multi-AZ instance — identical coverage at the same total cost. But those same two Single-AZ RIs can also cover two Single-AZ instances of the same size — more coverage options for the same dollar.
If you later convert a Multi-AZ instance to Single-AZ (to save the HA premium), a Multi-AZ RI no longer applies to the Single-AZ instance. Your two Single-AZ RIs still cover the two resulting Single-AZ instances perfectly. The flexibility only runs one direction: Single-AZ RIs are more flexible. Multi-AZ RIs are not.
The AWS re:Post community guidance (confirmed from the official thread): ‘Because of the size flexibility, it makes sense to just purchase RIs with the lowest instance size within the family and Single-AZ deployment type.’ This is the AWS-endorsed optimal strategy for size-flexible engines. Source: repost.aws, confirmed May 2026.
Why Buying Smaller Sizes Is More Flexible
If you buy 1 db.r8g.xlarge RI (8 units) and your instance is resized to db.r8g.large (4 units), you have 4 unused units that can cover a second db.r8g.large — only if one exists. If no second instance is running, 4 units are wasted every hour.
If you buy 2 db.r8g.large RIs (4 units each = 8 total) and your instance is resized, you now have full coverage for 2 separate large instances, each individually covered. If one instance is deleted, the remaining RI covers the other — no partial waste scenario.
Smaller sizes create individually resalable, independently applicable units of coverage. Larger sizes create one monolithic reservation that generates waste if the specific instance it was sized for does not exist.
The only exception: if your database will never be smaller than a specific size and will never split into smaller instances, the larger reservation is cleaner to manage. For most MySQL fleets with right-sizing activity, the smaller-size strategy is more resilient.
The Generation Constraint: r7g and r8g Are NOT Interchangeable
This is the mistake that catches teams off guard when they migrate from Graviton3 to Graviton4. Size flexibility applies within the same instance family AND generation. The r7g and r8g families are separate.
A db.r8g.xlarge RI does not cover a db.r7g.xlarge instance. A db.r7g.large RI does not cover a db.r8g.large instance. If you have active r7g reservations and migrate your instances to r8g, those reservations stop applying to the migrated instances.
The generation boundary is hard. There is no normalization bridge between generations. An r7g RI applies only to r7g instances. An r8g RI applies only to r8g instances. The r6g, r7g, and r8g are each their own family for reservation purposes.
Migration sequence to avoid wasted reservations: let existing r7g reservations expire before migrating to r8g. Or migrate to r8g as the current r7g RI term ends and immediately purchase r8g RIs for the new instances. Do not migrate mid-term without a plan for the existing r7g reservations.
Note: within r8g, size flexibility applies fully: db.r8g.large, db.r8g.xlarge, db.r8g.2xlarge, and all other r8g sizes are all covered by any r8g reservation via normalization units.
Also read: RDS MySQL on Graviton: R7g and M7g Price-Performance Guide
Which Engines Get Size Flexibility and Which Do Not
Size flexibility applies to MySQL, PostgreSQL, MariaDB, Amazon Aurora (MySQL and PostgreSQL compatible), and Oracle BYOL. It does not apply to Microsoft SQL Server (License Included or BYOL) or Oracle License Included.
For SQL Server and Oracle LI: reserved instances are exact-size and exact-deployment-type. A db.r8g.xlarge SQL Server LI RI covers only db.r8g.xlarge SQL Server LI instances. No cross-size coverage, no cross-deployment-type coverage. Every resize requires a new RI purchase.
For Oracle BYOL: size flexibility applies, but the license model (BYOL) must also match. An Oracle BYOL RI does not cover an Oracle LI instance, and vice versa. The engine and license model are both hard constraints.
How to Save on RDS Reserved Instances (6-step guide)
What Happens When You Delete an Instance and Have Leftover Units?
Size flexibility is applied per hour. If you have 8 normalization units of reservation and you delete one of your two db.r8g.large instances (4 units each), you now have 8 units of coverage and only 4 units of running instances. The remaining 4 units are not wasted in the sense that they are perpetually lost — they are simply unused in that hour and any subsequent hours where no matching instance exists.
The reservation continues billing at the committed rate. In every hour that only one db.r8g.large is running, you are paying for 8 units and using 4. The remedy: launch another db.r8g.large (or any r8g instance totaling 4 normalization units) to consume the coverage. You do not have to notify AWS or adjust the reservation — the billing system automatically applies coverage to running instances.
This is why the monthly utilization report in Cost Explorer matters. Navigate to Reservations > Utilization Report > filter by Amazon RDS. An RI showing below 80% utilization indicates unused normalization units. Investigate immediately: an instance may have been deleted, resized out of the family, or converted between deployment types in a way that left units uncovered.
Worked Example: Coverage Math for a Real MySQL Fleet
Your fleet at the start of Q3: 2 db.r8g.xlarge Single-AZ MySQL (production primaries), 4 db.r8g.large Single-AZ MySQL (read replicas), 1 db.r8g.xlarge Multi-AZ MySQL (reporting database). All in us-east-1.
Total normalization units running: 2 xlarge Single-AZ (8 x 2 = 16 units) + 4 large Single-AZ (4 x 4 = 16 units) + 1 xlarge Multi-AZ (8 x 2 = 16 units for both nodes). Total: 48 normalization units.
Optimal RI purchase using Single-AZ smallest strategy: purchase 12 db.r8g.large Single-AZ RIs (4 units each = 48 total units). Cost: 12 x db.r8g.large 1-yr No Upfront RI at $0.160/hr = $1.920/hr total fleet, versus 48 units of on-demand at $0.239/hr equivalent = $2.868/hr. Annual fleet saving: ($2.868 – $1.920) x 8,760 = $8,300/year. Verify at aws.amazon.com/rds/mysql/pricing — rates change.
Alternative purchase (the suboptimal approach): buy exactly what is running — 2 xlarge Single-AZ RIs, 4 large Single-AZ RIs, 1 xlarge Multi-AZ RI. Same total units. Same total cost. But significantly less flexibility: if you resize the Multi-AZ xlarge to Single-AZ large, the xlarge Multi-AZ RI now covers nothing. The 12 large Single-AZ RI approach would have automatically adapted, with the freed units simply covering additional small instances launched later.
How Usage.ai Handles Normalization Unit Optimization
Managing normalization unit coverage manually — tracking unit counts across a dynamic fleet, watching for generation boundary issues, responding to right-sizing events that shift unit counts — is exactly the type of hourly-granularity work that manual RI management cannot do at scale.
Usage.ai analyzes your MySQL fleet’s normalization unit consumption every 24 hours. The platform identifies coverage gaps where running instances have more normalization units than the current reservations cover, and over-coverage situations where reservations have excess units that no running instance is consuming. Both situations generate actionable recommendations: purchase additional Single-AZ small-size RIs to close gaps, or flag unused coverage for investigation.
The platform also tracks generation boundaries. When an r7g reservation has 4 months remaining and the team’s instances have migrated to r8g, Usage.ai flags the unmatched r7g reservation explicitly — not as a billing line item the team has to discover in Cost Explorer, but as a direct alert showing the exact monthly waste and the corrective action (purchase r8g RIs to cover the migrated instances; wait for the r7g RI to expire).
For the cross-deployment flexibility mechanic, Usage.ai purchases Single-AZ RIs rather than Multi-AZ RIs by default for eligible engines. This ensures that reserved units remain applicable whether a given instance is running Single-AZ or Multi-AZ at any point during the term. If any reservation becomes underutilized because fleet changes shift unit counts, Usage.ai provides cashback in real money. Fee: percentage of realized savings only.
See how Usage.ai manages RDS MySQL normalization unit coverage across your fleet
Frequently Asked Questions
1. What is RDS RI size flexibility?
RDS RI size flexibility allows one reserved instance to automatically cover different instance sizes within the same instance family using normalization units. A db.r8g.xlarge RI (8 units) covers 2 db.r8g.large instances (4 units each), or 4 db.r8g.medium instances (2 units each), or any other r8g combination totaling 8 units. No configuration needed — AWS applies coverage automatically. Applies to MySQL, PostgreSQL, MariaDB, Aurora, Oracle BYOL. Does not apply to SQL Server or Oracle LI.
2. What are RDS normalization units?
Fixed unit values AWS assigns to each instance size for calculating RI coverage proportionally: db.micro = 0.5, db.small = 1, db.medium = 2, db.large = 4, db.xlarge = 8, db.2xlarge = 16, db.4xlarge = 32, db.8xlarge = 64, db.16xlarge = 128, db.24xlarge = 192, db.48xlarge = 384. Source: AWS RDS documentation. Values are stable since October 2017. A reserved instance covers any running instances in the same family whose total normalization units are less than or equal to the reserved units.
3. Can a Single-AZ RI cover a Multi-AZ instance?
Yes, proportionally. A Single-AZ RI covers 50% of a Multi-AZ instance of the same size, because Multi-AZ counts as 2x the normalization units of Single-AZ. To fully cover one Multi-AZ instance, purchase two Single-AZ RIs of the same size. Source: AWS official RDS Reserved Instances documentation (aws.amazon.com/rds/reserved-instances, May 2026): ‘The discounted rate of this RI can automatically apply to 50% of the usage of a db.r3.large PostgreSQL Multi-AZ instance in the same region.’
4. Should I buy Single-AZ or Multi-AZ reserved instances for MySQL?
Always Single-AZ for size-flexible engines (MySQL, PostgreSQL, MariaDB, Aurora, Oracle BYOL). Two Single-AZ RIs of the same size provide identical Multi-AZ coverage as one Multi-AZ RI at the same total cost — but can also cover two Single-AZ instances, giving more deployment flexibility. Multi-AZ RIs offer no coverage advantage over two Single-AZ RIs and provide less flexibility. Source: AWS re:Post community guidance and Duckbill Group analysis.
5. Does size flexibility work between r7g and r8g instances?
No. Size flexibility applies within the same instance family AND generation. db.r7g and db.r8g are separate families for RI purposes. A db.r7g.xlarge RI covers only r7g instances. A db.r8g.xlarge RI covers only r8g instances. If you migrate from r7g to r8g, your r7g RIs no longer apply to the migrated instances. Plan migrations around RI expiration dates to avoid paying for unmatched reservations.
6. What happens if I have more reserved units than running instances?
The excess normalization units generate no coverage in that hour — they are not lost, but they do not save you money either. The reservation continues billing at the committed rate. If you regularly have excess units, investigate whether instances were deleted, resized out of the family, or converted. Launch additional instances within the family to consume unused coverage, or wait for the RI to expire and adjust the next purchase accordingly.
7. Can I use one RI to cover instances across different accounts?
Yes, within an AWS Organization using consolidated billing. An RI purchased in one account in an Organization applies to matching instances across all accounts in the same Organization in the same region. This means a centralized RI purchase can cover instances in linked member accounts. Useful for organizations where different teams or environments run in separate accounts but share a consolidated billing structure.
8. Does size flexibility apply to Aurora Serverless v2?
No. Size flexibility and RDS Reserved Instances apply only to provisioned RDS instances. Aurora Serverless v2 uses ACU-based pricing and does not have a Reserved Instance product. For Aurora, size flexibility applies to provisioned Aurora instances (Aurora MySQL and Aurora PostgreSQL provisioned clusters) only, using the same normalization unit system as standard RDS.
