2026.10.01 AWS

RDSのインスタンスタイプの選び方：エンジン別の対応クラス・東京単価と変更手順

Amazon RDSのインスタンスタイプは、AWSの公式ドキュメントでは「DBインスタンスクラス」と呼ばれ、db.m8g.largeのように種別とサイズで表します。この記事では、エンジンごとに選べるクラスの違い、東京リージョンの時間単価、メモリ量で決まる接続数の上限、バースト型db.t4gを本番で使うかどうかの損益分岐、稼働中のDBでクラスを変更する手順を順に扱います。単価はAWS Price List APIの2026年9月29日版から取得し、一覧を出すPythonコードとAWS CLIのコマンドを載せました。

まとめ：RDSのインスタンスタイプを決める順番と東京リージョンでの第一候補

クラスを決める順番は、エンジンとバージョン、必要なメモリ量、CPUの使われ方の3段階です。最初にエンジンを見るのは、Graviton搭載のdb.m8g・db.r8g・db.t4gがSQL ServerとOracleでは選べないためです。MySQL・PostgreSQL・MariaDBであれば、東京リージョンではdb.m8gとdb.m7gが同じ単価なので、新規に作るDBは第8世代のGravitonから選んで構いません。

本番DBの出発点は、汎用ならdb.m8g.large（2vCPU・8GiB、月170.82USD）、メモリを多く使うならdb.r8g.large（2vCPU・16GiB、月209.51USD）が目安になります。db.t4gは安く見えますが、24時間平均のCPU使用率がベースラインを超えると追加課金が発生します。db.t4g.largeは平均CPU 51%前後でdb.m8g.largeより高くなるため、開発・検証用か負荷の低いDBに限ってください。

クラスは後から変えられます。ただし変更時にはダウンタイムが発生するので、メンテナンスウィンドウでの適用を基本にし、Multi-AZ構成で停止時間を短くする段取りを組みます。

エンジンとバージョンで選べるRDSのインスタンスクラスが変わる条件と確かめ方

RDSのクラス名の読み方はEC2のインスタンスタイプと同じです。命名規則やEC2との対応はAWSのインスタンスタイプの選び方とRDSとの違いで解説しているので、ここではRDSに固有の制約に絞ります。DBインスタンスクラスの説明にあるとおり、クラスはCPUとメモリの量を決めるもので、選べる範囲はエンジン・バージョン・リージョンの組み合わせで変わります。

Graviton系がSQL Server・Oracleで選べないエンジン別対応表の読み方

クラスごとの対応エンジン表から、よく使う種別を抜き出しました。2026年10月1日に確認した内容です。

クラス種別	MySQL	PostgreSQL	SQL Server	Oracle
db.t4g	8.4・8.0	13〜17	不可	不可
db.m8g・db.r8g	8.0.32以上	13.11以上など	不可	不可
db.m9g	8.0.40・8.4.3以上	13.18以上など	不可	不可
db.m7i	8.0.32以上	13.11以上など	可	BYOLのみ
db.m8i・db.r8i	不可	不可	可	可
db.t3	可	可	可	可

読み取れることは2つあります。SQL ServerとOracleはIntel系（db.m7i・db.m8i・db.r8i・db.t3など）しか選べません。もう1つは、db.m8gやdb.r8gにはマイナーバージョンの下限があることです。MySQL 8.0.28のまま動いているDBは、先にマイナーバージョンを上げないとdb.m8gへ移れません。

AWS CLIで東京の作成可能クラスと対応するMySQLバージョンを確かめる手順

表はあくまで全リージョンを通した対応状況です。東京で実際に作れるかは、describe-orderable-db-instance-optionsで確かめます。リージョン別の対応を調べる手順に載っている例をもとに、gp3ストレージで絞り込む形にしました。

# 東京リージョンでMySQLの既定バージョンを取得し、そのバージョンで作成できるクラスをgp3で一覧する
VER=$(aws rds describe-db-engine-versions --engine mysql --default-only \
  --query "DBEngineVersions[0].EngineVersion" --output text --region ap-northeast-1)
echo "MySQL $VER"

aws rds describe-orderable-db-instance-options \
  --engine mysql --engine-version "$VER" \
  --query "OrderableDBInstanceOptions[?StorageType=='gp3'].DBInstanceClass" \
  --output text --region ap-northeast-1 | tr '\t' '\n' | sort -u

# 逆引き：db.m8g.largeを使えるMySQLのバージョンを東京で一覧する
aws rds describe-orderable-db-instance-options \
  --engine mysql --db-instance-class db.m8g.large \
  --query "OrderableDBInstanceOptions[?StorageType=='gp3'].EngineVersion" \
  --output text --region ap-northeast-1 | tr '\t' '\n' | sort -u

2本目の結果に今のバージョンが出てこなければ、そのままではクラスを変更できません。なお、AWSのドキュメントに掲載された実行例では、ap-northeast-1がdb.r8g.largeのMySQLに非対応と表示されています。一方、2026年9月29日版の料金データには東京のdb.r8g.largeが載っていました。掲載例の出力は取得時点のものなので、判断には自分のアカウントで実行した結果を使ってください。

東京リージョンの現行世代クラスの単価をPrice List APIで比べる手順と結果

Amazon RDSの料金ページは表をブラウザ側で描画するため、単価を機械的に読み取るにはPrice List Bulk APIが向いています。認証は要りません。

PythonでPostgreSQLの現行世代クラスと月額を一覧するコード

次のコードはPython 3の標準ライブラリだけで動きます。東京のRDSのオファーファイルは約25MBあるので、取得に1分ほどかかることがあります。

# 東京リージョンのRDSで作成できる現行世代クラスを、vCPU・メモリ・時間単価・月額（730時間）つきで一覧する
import json, urllib.request

BASE = "https://pricing.us-east-1.amazonaws.com"
ENGINE = "PostgreSQL"   # "MySQL" や "MariaDB" も指定できる
FAMILIES = ("t4g", "m7g", "m8g", "m7i", "r7g", "r8g", "r7i")

def get(path):
    with urllib.request.urlopen(BASE + path, timeout=300) as r:
        return json.load(r)

idx = get("/offers/v1.0/aws/AmazonRDS/current/region_index.json")
offer = get(idx["regions"]["ap-northeast-1"]["currentVersionUrl"])
print("version", offer["version"])

rows = []
for sku, p in offer["products"].items():
    a = p["attributes"]
    if p.get("productFamily") != "Database Instance" or a.get("databaseEngine") != ENGINE:
        continue
    if a.get("deploymentOption") != "Single-AZ":
        continue
    cls = a["instanceType"]
    if cls.split(".")[1] not in FAMILIES:
        continue
    for term in offer["terms"]["OnDemand"].get(sku, {}).values():
        for dim in term["priceDimensions"].values():
            rows.append((cls, int(a["vcpu"]), a["memory"], float(dim["pricePerUnit"]["USD"])))

for cls, vcpu, mem, usd in sorted(rows, key=lambda r: (r[0].split(".")[1], r[3])):
    if vcpu in (2, 4):  # 2vCPUと4vCPUのサイズだけ表示
        print(cls.ljust(16), vcpu, "vCPU", mem.rjust(6), f"{usd:.3f} USD/h", f"{usd * 730:.2f} USD/月")

# 出力例（version 20260929233006・抜粋）
# db.m7g.large     2 vCPU  8 GiB 0.234 USD/h 170.82 USD/月
# db.m7i.large     2 vCPU  8 GiB 0.247 USD/h 180.31 USD/月
# db.m8g.large     2 vCPU  8 GiB 0.234 USD/h 170.82 USD/月
# db.r8g.large     2 vCPU 16 GiB 0.287 USD/h 209.51 USD/月
# db.t4g.medium    2 vCPU  4 GiB 0.101 USD/h 73.73 USD/月
# db.t4g.large     2 vCPU  8 GiB 0.202 USD/h 147.46 USD/月

種別を増やしたいときは FAMILIES に追記します。Multi-AZの単価は deploymentOption を “Multi-AZ” に変えると取れ、どのクラスもSingle-AZのちょうど2倍でした。

m8gとm7gが同額でm9gは未掲載という2026年9月時点の東京の価格差

出力から、クラス選びに効く差を拾いました。いずれも東京・Single-AZの時間単価です。

比較	単価（USD／時）	差
db.m8g.large／db.m7g.large	0.234 と 0.234	同額
db.r8g.large／db.r7g.large	0.287 と 0.287	同額
db.m7i.large／db.m8g.large	0.247 と 0.234	Intelが約5.6%高い
db.m8gd.large／m8g.large	0.2764 と 0.234	ローカルNVMe付きが約18%高い
db.m6g.large	0.209 と 0.221	旧世代はPostgreSQLが高い

表のm8g.largeはdb.m8g.largeの略記です。比較欄に並ぶクラスと単価は左から対応し、最終行のdb.m6g.largeではMySQL、PostgreSQLの順に単価を示しています。第7世代と第8世代のGravitonが同額なので、新規でdb.m7gを選ぶ理由はありません。第6世代のdb.m6gはMySQLで約11%安いものの、Database Savings Plansの対象外です。その点を含めた割引の比較はAWS RDSの料金を東京リージョンの実額で計算した記事にまとめています。

Graviton5のdb.m9gはクラス種別の一覧に載っていますが、2026年9月29日版の東京の料金データには含まれていませんでした。東京で使えるようになるまでは、db.m8gが最新の選択肢です。末尾にdが付くdb.m8gd・db.r8gdは、一時テーブルの処理をローカルNVMeに逃がすOptimized Reads向けのクラスで、大きなソートや集計が多いDBでなければ割増分の効果は出にくいと考えます。

メモリ量から決めるRDSのサイズ選定とmax_connectionsの既定値の関係

サイズを決めるとき、vCPUより先にメモリを見ます。RDSでは、同時接続数の上限の既定値がクラスのメモリ量から自動で計算されるためです。

MySQLはメモリ約12MBごと・PostgreSQLは約9MBごとに1接続となる既定式

RDSのクォータと制約では、max_connectionsの既定値を次の式で定めています。DBInstanceClassMemory はOSとRDSの管理プロセスが使う分を差し引いたバイト数です。表の式では、この値を「メモリ」と略記しています。

エンジン	既定値の式	8GiBのクラスでの目安
MySQL	メモリ／12582880	約630（公式記載）
MariaDB 10.5以降	LEAST(メモリ／25165760,12000)	340未満
PostgreSQL	LEAST(メモリ／9531392, 5000)	900未満

小さいクラスほど予約分の比率が大きくなり、1GiBのdb.t3.microで動くMySQLの既定値は約60と記載されています。Lambdaから接続する構成やコネクションプールを持たないアプリでは、60接続は簡単に埋まります。接続数のためだけにクラスを上げるより、RDS Proxyによる接続プールを挟むほうが安く済むことが多いです。

FreeableMemoryとSwapUsageで今のクラスが足りているか判定する手順

既存DBのサイズが妥当かは、RDSのCloudWatchメトリクスのうちFreeableMemoryとSwapUsageで判断します。FreeableMemoryは /proc/meminfo のMemAvailableを報告する値です。

判断の順番は単純です。SwapUsageが継続して増えていれば、メモリが足りていないのでdb.m系からdb.r系へ、またはサイズを1段上げます。FreeableMemoryに余裕があるのにCPUUtilizationが高止まりしている場合は、メモリを増やしても解決しません。同じメモリでvCPUが倍になるクラスはRDSに少ないため、まず遅いクエリを特定し、読み込みが多いならリードレプリカで読み書きを分ける構成を検討します。

バースト型db.t4gを本番で使うかを決めるCPUクレジットの損益分岐

RDSのdb.t4gとdb.t3で使われるモードは、Unlimitedに固定された設定です。クラス種別の説明では、24時間の平均がベースラインを超えた分に追加料金がかかると書かれています。メトリクスの説明でも、T系は開発・テスト用など本番以外での利用が推奨されています。

平均CPU51%でdb.t4g.largeとdb.m8g.largeの月額が逆転する計算

どちらも2vCPU・8GiBで、東京の単価はdb.t4g.largeが0.202USD、db.m8g.largeが0.234USDです。バースト型のベースラインの表ではt4g.largeのベースラインが1vCPUあたり30%です。RDSのドキュメントにはベースラインの表が別途ないため、ここではEC2の同名タイプの値を使って計算しました。超過分は東京のRDS for MySQL／PostgreSQLで1vCPU時あたり0.075USDです。

24時間平均のCPU使用率	db.t4g.largeの月額	db.m8g.largeの月額
30%以下	147.46USD	170.82USD
40%	158.41USD	170.82USD
50%	169.36USD	170.82USD
60%	180.31USD	170.82USD
80%	202.21USD	170.82USD

月額は「0.202＋（平均CPU−0.30）×2vCPU×0.075」に730時間を掛けたものです。差額0.032USDを超過単価0.15USDで割ると、損益分岐は平均CPU約51.3%になります。平均がこれを超える負荷のDBなら、db.m8g.largeのほうが安く、性能も一定です。逆にdb.t4g.mediumは常にCPU 100%で回しても毎時0.221USDで、db.m8g.largeの単価を超えません。メモリ4GiBで足りる小さな本番DBに限っては、db.t4g.mediumが割安な選択肢として残ります。

CPUSurplusCreditsChargedで追加課金の発生を確かめるCLIの手順

すでにT系で動かしているDBは、追加課金の対象になったクレジット数をCloudWatchで確かめられます。CPUクレジットのメトリクスは5分間隔なので、1日単位で見る場合は合計（Sum）を使います。

# 過去7日間に追加課金されたCPUクレジット数を日別に表示する（1クレジット＝1vCPU分）
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name CPUSurplusCreditsCharged \
  --dimensions Name=DBInstanceIdentifier,Value=app-db-prod \
  --start-time 2026-09-24T00:00:00Z --end-time 2026-10-01T00:00:00Z \
  --period 86400 --statistics Sum \
  --query "sort_by(Datapoints,&Timestamp)[].[Timestamp,Sum]" \
  --output table --region ap-northeast-1

1クレジットは1vCPUを1分使った量なので、東京では0.075USDの60分の1、約0.00125USDになります。日別の合計が毎日数千クレジットに達しているなら、月に数十USDの追加課金が出ています。損益分岐の表と照らして、db.m8gへの変更を検討する時期です。

稼働中のRDSのインスタンスクラスを変更する手順とダウンタイムの扱い

DBインスタンスの変更設定の一覧では、クラスの変更はダウンタイムを伴う項目に分類されています。同じページは、Multi-AZ構成にしておけば変更時の停止を小さくできるとも説明しています。

modify-db-instanceによる即時適用とメンテナンスウィンドウの違い

変更はmodify-db-instanceの --db-instance-class で指定します。即時適用を付けなければ、次のメンテナンスウィンドウで反映されます。

# 次のメンテナンスウィンドウでdb.m8g.largeへ変更する（即時に適用しない）
aws rds modify-db-instance \
  --db-instance-identifier app-db-prod \
  --db-instance-class db.m8g.large \
  --no-apply-immediately \
  --region ap-northeast-1

# 保留中の変更とメンテナンスウィンドウを確認する
aws rds describe-db-instances \
  --db-instance-identifier app-db-prod \
  --query "DBInstances[0].[DBInstanceClass,PendingModifiedValues.DBInstanceClass,PreferredMaintenanceWindow]" \
  --output text --region ap-northeast-1

2本目の出力で、2列目に変更先のクラスが表示されていれば予約されています。メンテナンスウィンドウはUTCで表示されるので、日本時間に直して業務時間外かを確認してください。緊急でクラスを上げたい場合は --apply-immediately に替えますが、実行した直後から停止が始まります。ストレージはそのまま引き継がれ、変わるのはCPUとメモリです。

クラス変更の前に確かめるマイナーバージョンとリザーブドの適用条件

変更前に確認する項目は2つです。

変更先クラスが今のエンジンバージョンに対応しているか。前章の逆引きコマンドで確かめ、対応していなければ先にマイナーバージョンを上げる。バージョンの変更もダウンタイムを伴うので、同じメンテナンスウィンドウで順に適用する計画にする
リザーブドインスタンスを持っているか。リザーブドはクラスのファミリーを固定する契約なので、db.m6gからdb.m8gへ移ると割引が外れる

リザーブドの残り期間が長い場合は、満了まで今のファミリー内のサイズ変更に留めるのが安全です。購入時の考え方はリザーブドインスタンスの購入判断と適用条件で扱っています。

受託開発でRDSのインスタンスクラスを決めるときの採用条件と見送る場面

ここまでの事実をもとに、新規構築と既存DBの見直しで使う判断基準を示します。

新規の本番はdb.m8g.largeかdb.r8g.largeから始める判断基準

MySQL・PostgreSQLの新規本番は、db.m8g.largeで始めます。InnoDBのバッファプールやPostgreSQLの共有バッファに載せたいデータ量が8GiBを超えそうなら、最初からdb.r8g.largeにします。小さく始めて、FreeableMemoryとCPUUtilizationを1か月見てから1段上げるか決めれば、作り直しは要りません。

db.t4gは開発・検証環境の標準にします。本番で採用するのは、メモリ4GiB以下で足り、平均CPUがベースラインの20%前後に収まるdb.t4g.mediumまでです。db.t4g.large以上を本番に置くのは見送ります。単価差は月23USDほどしかなく、平均CPUが51%を超えた時点で損になるうえ、性能が負荷によって揺れるためです。

SQL Server・Oracle案件とAurora移行予定の案件で選び方を変える場面

SQL ServerとOracleはGravitonを選べないため、db.m7i・db.r7iか、対応する第8世代のdb.m8i・db.r8iから選びます。ライセンス込みの単価はエンジン本体の費用が乗るので、クラスを1段下げたときの差額がMySQLより大きくなります。サイズの見直しで得られる効果も、そのぶん大きくなる案件です。

1年以内にAuroraへ移る予定があるなら、RDSのクラスを細かく詰める工数はかけません。Auroraのクラス体系とServerless v2の課金はRDSと別物で、移行後に選び直すことになるからです。違いはAmazon Auroraの仕組みとRDSとの違いで確認してください。世代移行やエンジンのバージョンアップを含めてクラスを見直したい場合は、データベース設計・移行支援で現状のメトリクスの読み取りから変更計画まで請け負っています。

よくある質問

RDSのインスタンスタイプについて、選定と変更の段階でよく出る質問に答えます。

RDSのインスタンスタイプとインスタンスクラスは同じ意味ですか？

実務ではほぼ同じ意味で使われます。AWSのドキュメントでは、db.r6gのような種別を「DBインスタンスクラスタイプ」、サイズまで含めたdb.r6g.2xlargeを「DBインスタンスクラス」と呼び分けています。CLIやAPIの引数名は --db-instance-class なので、コマンドを書くときは「クラス」と覚えておくと迷いません。

RDSで一番安いインスタンスタイプはどれですか？

東京リージョンのMySQL・PostgreSQLでは、db.t4g.microのSingle-AZが毎時0.025USD、730時間で月18.25USDでした（2026年9月29日版）。メモリは1GiBで、MySQLの既定の最大接続数は60程度に収まります。動作確認や個人の検証には足りますが、アプリの結合テストではメモリ不足になりやすいので、検証環境はdb.t4g.mediumを目安にしてください。

インスタンスタイプを変更するとデータは消えますか？

消えません。クラスの変更で変わるのはCPUとメモリで、ストレージのデータは引き継がれます。ただし変更中はDBに接続できない時間が発生するため、業務時間外のメンテナンスウィンドウに予約するのが基本です。念のため、変更前に手動スナップショットを取っておくと、想定外の問題が出たときに戻せます。

db.m8gなどのGravitonに変えるとアプリの修正は必要ですか？

RDSのドキュメントは、Graviton搭載クラスへの変更を他の変更と同じ手順で行えると説明しています。アプリはネットワーク越しにDBへ接続するため、CPUアーキテクチャの違いを意識する箇所はありません。確認が必要なのは、変更先クラスが今のエンジンのマイナーバージョンに対応しているかどうかと、リザーブドインスタンスの割引が外れないかの2点です。