Check in advance whether your desired combination of "1 year / 3 years" and "no upfront / partial upfront / full upfront" is available for Amazon RDS Reserved Instances.

Good evening, this is Chiba (Ko).

As ways to reduce the running costs of Amazon RDS DB instances, there are Database Savings Plans (DB SP) and Amazon RDS Reserved Instances (RDS RI). Both are mechanisms that provide discounts in exchange for committing to a certain period of use.

Organizing the "commitment period" and "payment options" for both gives us the following.

DB SP only supports 1-year no upfront, while RDS RI supports 6 types of purchase options.

That said, it doesn't mean that all 6 options are always available with RDS RI. Depending on conditions such as the DB instance class, the available purchase options may be limited.

This time, we'll focus on RDS RI and introduce how to check the available purchase options for each combination of "region" and "DB engine," as well as the results of checking differences across different combinations.

Summary First

• The only available purchase option for DB SP is "1-year no upfront"
• Purchasing RDS RI with "3-year no upfront" is almost impossible (possible in only a very limited number of cases)
• Within the same region and same DB engine, there are generally no differences in available purchase options based on the following perspectives (though some exceptions exist)
  • Differences based on whether Multi-AZ or not
  • Differences based on size within the same DB instance class type
• As of August 2026, the following trends are common (but not universal) for 7th and 8th generation DB instance classes
  • db.m7i/db.m8g/db.r7i/db.r8g: 3-year purchases are not available
  • db.m7g: 3-year partial upfront/all upfront purchases are available

The vagueness of the last 3 lines really conveys the complexity of RDS RI.

Terminology for DB Instance Classes

In this blog, we use the following terminology distinctions.

From https://dev.classmethod.jp/articles/rds-dont-have-db-instance-family/

Taking db.r6g.2xlarge as an example, each term refers to the following parts:

• DB instance class: db.r6g.2xlarge
• DB instance class type: db.r6g
• Size: 2xlarge

The terminology differs slightly from EC2 instance types, which can be confusing. You might be tempted to say "DB instance family," but officially no such term exists.

Verification Environment

The commands in this blog were executed in the following environment. They may not work correctly in other environments.

• macOS
• Zsh version: zsh 5.9 (arm64-apple-darwin25.0)
• AWS CLI version: aws-cli/2.36.19 Python/3.14.6 Darwin/25.5.0 exe/arm64
• Jq version: jq-1.6

Retrieving a List of RDS RI Offerings for a Specific Region and DB Engine

Details on what RDS RI purchase options are available can be retrieved as offering information using the following AWS CLI command.

• describe-reserved-db-instances-offerings — AWS CLI 2.36.33 Command Reference

Information is returned in the following format.

{
    "ReservedDBInstancesOfferings": [
        {
            "CurrencyCode": "USD",
            "UsagePrice": 0.0,
            "ProductDescription": "oracle-se2(li)",
            "ReservedDBInstancesOfferingId": "005bdee3-9ef4-4182-aa0c-58ef7cb6c2f8",
            "MultiAZ": true,
            "DBInstanceClass": "db.m4.xlarge",
            "OfferingType": "Partial Upfront",
            "RecurringCharges": [
                {
                    "RecurringChargeAmount": 0.594,
                    "RecurringChargeFrequency": "Hourly"
                }
            ],
            "FixedPrice": 4089.0,
            "Duration": 31536000
        },
    ...some output truncated...
}

Without any filtering, an enormous amount of output will be generated, so it's best to limit the output by region and DB engine.

This time, we set the targets as environment variables in the following format.

REGION=ap-northeast-1
ENGINE=mysql

The DB engine type can be confirmed from the results of a command like the following.

% aws rds describe-reserved-db-instances-offerings \
  --region ap-northeast-1 \
  --output json \
| jq -r '[.ReservedDBInstancesOfferings[].ProductDescription] | unique[]'

The results as of 2026/08/28 for the Tokyo region are as follows.

aurora-mysql
aurora-postgresql
custom-sqlserver-ee(byol)
custom-sqlserver-ee(li)
custom-sqlserver-se(byol)
custom-sqlserver-se(li)
custom-sqlserver-web(li)
db2-ae(byol)
db2-ae(mpl)
db2-se(byol)
db2-se(mpl)
mariadb
mysql
oracle-ee(byol)
oracle-se2 (byol)
oracle-se2(li)
postgresql
sqlserver-ee(li)
sqlserver-ex(li)
sqlserver-se(li)
sqlserver-web(li)

Below is an example command for specifying the Tokyo region and MySQL to retrieve results. It includes the variable declarations at the beginning.

REGION=ap-northeast-1
ENGINE=mysql
TS=$(date +%Y%m%d_%H%M%S)

aws rds describe-reserved-db-instances-offerings \
  --product-description "$ENGINE" \
  --region "$REGION" \
  --output json \
| jq -r '
  ["1yr_NoUpfront","1yr_PartialUpfront","1yr_AllUpfront","3yr_NoUpfront","3yr_PartialUpfront","3yr_AllUpfront"] as $cols
  | [
      .ReservedDBInstancesOfferings[]
      | . as $o
      | ($o.Duration/3600) as $hours
      | (($o.RecurringCharges // []) | map(select(.RecurringChargeFrequency=="Hourly") | .RecurringChargeAmount) | add // 0) as $rec
      | (((($o.FixedPrice/$hours) + $rec) * 10000) | round / 10000) as $eff
      | {
          class: $o.DBInstanceClass,
          az: (if $o.MultiAZ then "Multi-AZ" else "Single-AZ" end),
          col: ((if $o.Duration==31536000 then "1yr" else "3yr" end) + "_" + ($o.OfferingType | gsub(" ";""))),
          val: $eff
        }
    ]
  | group_by([.class, .az])
  | map({
      class: .[0].class,
      az: .[0].az,
      cols: (map({key: .col, value: .val}) | from_entries)
    })
  | sort_by(.class, .az)
  | ( [["DBInstanceClass","MultiAZ"] + $cols]
      + map(. as $row | [$row.class, $row.az] + ($cols | map($row.cols[.] // "-"))) )[]
  | @csv
' > rds_ri_${ENGINE}_${REGION}_effective_hourly_usd_${TS}.csv

echo "rds_ri_${ENGINE}_${REGION}_effective_hourly_usd_${TS}.csv"

The overview of the processing is as follows.

• Set region/DB engine name/timestamp in variables, and retrieve the RI offering list in JSON format using describe-reserved-db-instances-offerings
• Group offerings by combination of instance class and AZ type (Single-AZ/Multi-AZ)
• Convert the contents of each group into an object keyed by the 6 purchase options, and sort by instance class/AZ order
• Assemble the header row and each data row and convert to CSV format strings
• Save as a CSV file with a timestamp-appended filename and display that filename on screen

The "effective cost per hour" is calculated by dividing FixedPrice (upfront amount) by the total hours of the contract period to convert it to an hourly equivalent, then adding the hourly usage RecurringCharges.

The image of the output CSV looks like this.

I'd like to paste the full output here, but since the results were 405 rows with nearly 27,000 characters, I'll skip that.

Can We Create a More Simplified Compatibility Table?

Even when limiting by region and DB engine, results can run into hundreds of rows. We'd like something more simplified to get an overall view.

If there are no differences from the following perspectives, we should be able to create a more compact table.

• Are there any differences in purchase options based on whether Multi-AZ or not?
• Are there any differences in purchase options based on size within the same DB instance class type?

We'll define the following function and run it with a CSV file as the argument to check.

check_diff() {
  local SRC="$1"
  tail -n +2 "$SRC" | awk -F, '
    {
      cls=$1; az=$2
      gsub(/"/,"",cls); gsub(/"/,"",az)
      split(cls,p,".")
      classtype=p[1]"."p[2]
      bits=""
      for(i=3;i<=NF;i++){ v=$i; gsub(/"/,"",v); bits = bits (v=="-" ? "0" : "1") }

      if (az=="Single-AZ") single[cls]=bits
      else multi[cls]=bits
      classlist[cls]=1

      if (!(classtype in ctPattern)) { ctPattern[classtype]=bits; ctRef[classtype]=cls }
      else if (ctPattern[classtype]!=bits) { ctDiffFlag[classtype]=1; ctDiff[classtype]=ctDiff[classtype]" "cls"("az")="bits }
    }
    END {
      print "=== Differences by AZ configuration ==="
      az_diff_found=0
      for (c in classlist) {
        if ((c in single) && (c in multi) && single[c]!=multi[c]) {
          print c"\tSingle="single[c]"\tMulti="multi[c]
          az_diff_found=1
        }
      }
      if (!az_diff_found) print "None"

      print "=== Differences within DB instance class type ==="
      ct_diff_found=0
      for (t in ctDiffFlag) {
        print t": "ctRef[t]"="ctPattern[t]" differs ->"ctDiff[t]
        ct_diff_found=1
      }
      if (!ct_diff_found) print "None"
    }
  '
}

• Process each row of the CSV by DB instance class (e.g., db.m5.large) and AZ configuration (Single-AZ/Multi-AZ), and convert the 6 purchase option columns into a 6-digit bit string where - becomes 0 and a value becomes 1
• Compare the bit strings for Single-AZ and Multi-AZ of the same DB instance class
• For each DB instance class type (e.g., db.m5), use the first bit string encountered as the baseline, and record any subsequent differences
• After reading all rows, output the differences by AZ configuration and within DB instance class type respectively
• If there are no differences in either, output "None"

The execution image when there are no differences is as follows.

% check_diff rds_ri_mysql_ap-northeast-1_effective_hourly_usd_20260828_135435.csv
=== Differences by AZ configuration ===
None
=== Differences within DB instance class type ===
None

The execution image when there are differences is as follows.

% check_diff rds_ri_sqlserver-ee_li_ap-northeast-1_effective_hourly_usd_20260828_135435.csv
=== Differences by AZ configuration ===
db.r5.12xlarge	Single=111011	Multi=011011
db.r5.24xlarge	Single=111011	Multi=011011
db.r5.8xlarge	Single=111011	Multi=011011
db.r5.xlarge	Single=111011	Multi=011011
db.r5.2xlarge	Single=111011	Multi=011011
db.r5.16xlarge	Single=111011	Multi=011011
db.r5.4xlarge	Single=111011	Multi=011011
=== Differences within DB instance class type ===
r5: db.r5.12xlarge=011011 differs -> db.r5.12xlarge(Single-AZ)=111011 db.r5.16xlarge(Single-AZ)=111011 db.r5.24xlarge(Single-AZ)=111011 db.r5.2xlarge(Single-AZ)=111011 db.r5.4xlarge(Single-AZ)=111011 db.r5.8xlarge(Single-AZ)=111011 db.r5.xlarge(Single-AZ)=111011

I summarized the results of checking differences (without distinguishing between AZ configuration and within DB instance class type) for each engine in the Tokyo, Osaka, and Northern Virginia regions.

• ○: No difference
• ×: Difference exists
• N/A: Engine not supported

We found that generally there are no differences in purchase options based on "whether Multi-AZ or not" and "size within the same DB instance class type."

One notable exception: in Northern Virginia's aurora-mysql, purchase option restrictions were applied only to specific sizes of db.r5.

• ○: Available
• ×: Not available

Only partial upfront purchases are available. That's unusual. (Note that in the case of Aurora, there is no concept of purchasing RDS RI with Multi-AZ.)

Creating a Simplified RDS RI Purchase Option Compatibility Table

Through the steps so far, we've been able to confirm whether there are differences based on "whether Multi-AZ or not" and "size within the same DB instance class type," so we'd like to create a simplified version for cases where there are no differences.

We'll define the following function and run it with a CSV as the argument to create the simplified table.

make_simple() {
  local SRC="$1"
  local OUT="${SRC/_effective_hourly_usd_/_simple_}"

  {
    head -1 "$SRC" | awk -F, '{h="ClassType"; for(i=3;i<=NF;i++){v=$i; gsub(/"/,"",v); gsub(/Upfront$/,"",v); gsub(/Partial/,"Part",v); gsub(/_/,"",v); h=h","v}; print h}'
    tail -n +2 "$SRC" | awk -F, '
      { cls=$1; gsub(/"/,"",cls); split(cls,p,"."); classtype=p[1]"."p[2]
        if (classtype in seen) next
        seen[classtype]=1
        line=classtype
        for(i=3;i<=NF;i++){ v=$i; gsub(/"/,"",v); line=line","(v=="-"?"×":"○") }
        print line
      }' | sort -t, -k1,1
  } > "$OUT"

  echo "$OUT"
}

• Create the output filename by replacing _effective_hourly_usd_ with _simple_ in the argument CSV path
• Shorten the header row column names (remove Upfront/Partial→Part/remove underscores) and create a new header with ClassType + 6 shortened column names
• Extract the DB instance class type (e.g., db.m5) from the 1st and 2nd dot-separated parts of DBInstanceClass in each data row, and skip subsequent rows with the same type
• Convert the 6 columns of the remaining rows to × if - or ○ if there's a value
• Sort by type name, combine with header, and save to the output file

The execution image is as follows.

% make_simple rds_ri_mysql_ap-northeast-1_effective_hourly_usd_20260828_135435.csv
rds_ri_mysql_ap-northeast-1_simple_20260828_135435.csv

The Tokyo region MySQL table we retrieved at the beginning could be simplified to this.

• ○: Available
• ×: Not available

The 3-year no upfront (3yrNo) is unsupported (not available) for all rows. m7i/m8g/r7i/r8g cannot be purchased with a 3-year term at all. I wondered if this was because they are newer types, but what's striking is that m7g is available for purchase.

Are There Differences in Availability Between Regions?

I compared the differences across the Tokyo, Osaka, and Northern Virginia regions for each engine based on the simplified tables.

• Match: The simplified table content is a perfect match
• Cannot determine: The simplified table cannot be created for one or both regions
• N/A: Engine not offered in the Osaka region
• {Tokyo/Virginia} only: There are DB instance classes only available in one of the regions
• Pattern difference: There are differences in patterns

※The prefix db. for DB instance class types is omitted

We can see that fewer DB engines match between regions. However, most of the differences are due to DB instance class types that exist in only one of the regions. Even in cases noted as {Tokyo/Virginia} only, no differences were observed for DB instance class types that are common to both regions.

One exception: for sqlserver-se(li), there was a pattern difference in m6i between the Tokyo and Osaka regions.

• ○: Available
• ×: Not available

In the Osaka region, 3-year partial upfront/all upfront—which are not available in the Tokyo region—are supported. That's quite an unusual pattern.

This time we picked up and compared only 3 regions, but since there seem to be considerable differences between regions, it would be best to retrieve information for the specific region you're actually considering purchasing in.

RDS RI Purchase Compatibility Table for Northern Virginia Region (Simplified)

Since the Northern Virginia region supports more DB instance class types compared to the Tokyo region, I'll include simplified RDS RI purchase option compatibility tables for major DB engines. Please use them as a reference for understanding trends.

• ○: Available
• ×: Not available

To state the results upfront, the trend seen with Tokyo region MySQL—"3-year purchases not available for m7i/m8g/r7i/r8g, available for m7g"—was largely the same in Northern Virginia as well.

aurora-mysql

aurora-postgresql

mariadb

mysql

oracle-se2(li)

Surprisingly, db.m8i/db.r8i can be purchased with a 3-year no-upfront option. In exchange, 3-year partial upfront/all upfront is not supported.

postgresql

sqlserver-se(li)

It is somewhat unusual that 3-year purchases are not available for M-series DB instance classes.

Summary (reposted)

• The only purchase option available with DB SPs is "1-year no upfront"
• "3-year no upfront" purchases are almost never available for RDS RIs (only possible for a very small subset)
• Within the same region and the same DB engine, differences in available purchase options based on the following factors are generally absent (though they do exist in some cases)
  • Whether Multi-AZ is used or not
  • Size differences within the same DB instance class
• As of August 2026, the following trends are common (though not universal) for 7th and 8th generation DB instance classes
  • db.m7i/db.m8g/db.r7i/db.r8g: 3-year term purchases are not available
  • db.m7g: 3-year partial upfront/all upfront purchases are available

Closing

We have examined various patterns of purchase options for Amazon RDS Reserved Instances.

We learned that not all purchase options are available universally, and that the supported DB instance class types differ by DB engine and region.

We hope this serves as a helpful reference for those considering purchasing RDS RIs.

That's all from チバユキ (@batchicchi).

References

• マネージドリレーショナルデータベース – Amazon RDS の料金 – Amazon Web Services
• Amazon Aurora の料金