RDS for MySQL 8.0の延長サポート料金はいくら？2026年8月から始まった課金の止め方と8.4への移行手順【2026年版】
Amazon RDS for MySQL 8.0の標準サポートは、2026年7月31日に終了しました。8月1日以降も8.0のまま動いているDBインスタンスは、RDSの延長サポート（RDS Extended Support）に登録され、通常のインスタンス料金とは別に追加料金が発生しています。
東京リージョンの単価は、1 vCPUあたり1時間0.120ドルです。2 vCPUのインスタンス1台で月に約175ドル、Multi-AZ構成ならその2倍になります。さらに2028年8月からは単価が2倍に上がります。8月分の請求を見て、見慣れない費用に気づいた企業も多いはずです。
本記事では、RDS for MySQL 8.0の延長サポートでいくらかかるのか、自社の課金状況を確認する方法、延長サポートを外すときの注意点、MySQL 8.4へ移行する手順を整理します。
目次
想定読者
- AWSの請求に「Extended Support」の項目が増え、原因と金額を確認したい情報システム担当者・インフラ担当者の方
- RDS for MySQL 8.0を使い続けており、延長サポートで延命するか、8.4へ上げるかを判断したい方
- MySQL 8.4へのアップグレードで、アプリケーションに何が影響するかを事前に把握したい方
- 同じAWS環境にあるOSやミドルウェアの期限もあわせて整理したい方
RDS for MySQL 8.0の標準サポートは2026年7月31日に終了した
AWSの公式ドキュメントでは、RDS for MySQL 8.0のサポート期限が次のように定められています。
| 項目 | MySQL 8.0 | MySQL 8.4 |
|---|---|---|
| コミュニティ版のサポート終了 | 2026年4月30日 | 2029年4月30日 |
| RDSの標準サポート終了 | 2026年7月31日 | 2029年7月31日 |
| 延長サポート1年目の料金開始 | 2026年8月1日 | 2029年8月1日 |
| 延長サポート3年目の料金開始（単価が上がる） | 2028年8月1日 | 2031年8月1日 |
| 延長サポートの終了 | 2029年7月31日 | 2032年7月31日 |
MySQLの開発元であるOracleは、2026年4月30日にMySQL 8.0のコミュニティ版のサポートを終えています。RDSではその3か月後の7月31日まで標準サポートが続き、8月1日から有償の延長サポートに切り替わりました。
8月1日から自動で延長サポートに登録されている
延長サポートは、申し込まなくても自動で登録されます。インスタンスの作成時や復元時に延長サポートを無効にしていなかった場合、標準サポートの終了日を過ぎた時点で自動的に登録され、翌日から課金が始まります。
登録されてもデータベースのエンジンは変わらず、インスタンスが止まることも性能が落ちることもありません。そのため、請求書を見るまで気づかないケースがあります。
延長サポートで提供されるもの
延長サポートの期間中、AWSは次の対応を続けます。
- 深刻度がCriticalとHighの脆弱性（CVE）に対するセキュリティ更新
- 重大な不具合の修正とパッチ
- 通常のRDSのサービスレベルでのサポートケース対応
MySQLのコミュニティは8.0の新しいマイナーバージョンをもう出しません。そのため、延長サポート中の修正は「8.0.46-RDS.20260908」のようなRDS独自のバージョンとして提供されます。
延長サポートの料金はいくらかかるか
延長サポートの料金は、vCPU数×稼働時間で計算されます。単価は、エンジンのバージョン、リージョン、標準サポートの終了から何年目かで決まります。
東京リージョンの単価
AWSが公開している価格情報（2026年9月24日時点）では、東京リージョン（ap-northeast-1）のRDS for MySQL 8.0の単価は次のとおりです。
| 期間 | 単価（1 vCPU・1時間あたり） |
|---|---|
| 1年目・2年目（2026年8月1日〜2028年7月31日） | 0.120ドル |
| 3年目（2028年8月1日〜2029年7月31日） | 0.240ドル |
構成別の月額の目安
1か月を730時間として、東京リージョンでの延長サポート料金を試算すると次のようになります。インスタンスの利用料金は含まず、延長サポートの追加分だけの金額です。
| 構成 | 1〜2年目の月額 | 3年目の月額 | 1〜2年目の年額 |
|---|---|---|---|
| 2 vCPU・シングルAZ | 約175ドル | 約350ドル | 約2,100ドル |
| 2 vCPU・Multi-AZ | 約350ドル | 約701ドル | 約4,205ドル |
| 4 vCPU・Multi-AZ | 約701ドル | 約1,402ドル | 約8,410ドル |
| 8 vCPU・Multi-AZ | 約1,402ドル | 約2,803ドル | 約16,819ドル |
Multi-AZ構成では、スタンバイのインスタンスにも延長サポートの料金がかかります。本番と検証の両方で8.0を使っている場合や、リードレプリカを置いている場合は、MySQL 8.0で動いているインスタンスをすべて数えて試算してください。
延長サポートの料金は、8.0から標準サポート中のバージョン（8.4）へアップグレードするか、インスタンスを削除した時点で止まります。アップグレードが1か月遅れるごとに、上の表の月額がそのまま積み上がると考えてください。
自社の8.0インスタンスと課金状況を確認する
まずは、どのインスタンスが延長サポートに登録されているかを洗い出します。
AWS CLIで一覧を取る
次のコマンドで、MySQLのDBインスタンスごとのエンジンバージョンと延長サポートの登録状況を確認できます。リージョンごとに実行してください。
aws rds describe-db-instances \
--query "DBInstances[?Engine=='mysql'].[DBInstanceIdentifier,EngineVersion,DBInstanceClass,MultiAZ,EngineLifecycleSupport]" \
--output tableEngineLifecycleSupportが「open-source-rds-extended-support」で、エンジンバージョンが8.0で始まるものが課金対象です。
Cost Explorerで金額を確認する
実際にいくら請求されているかは、AWS Cost Explorerで確認します。サービスを「Relational Database Service」に絞り、使用タイプに「ExtendedSupport」を含むものを表示すると、延長サポート分だけの金額が分かります。東京リージョンのMySQL 8.0であれば、使用タイプは「APN1-ExtendedSupport:Yr1-Yr2:MySQL8.0」です。
複数のAWSアカウントを使っている企業では、アカウントごとに確認が必要です。検証用のアカウントに放置されたインスタンスが、延長サポートの料金だけを払い続けていることもあります。
延長サポートを外すと自動でアップグレードされる
請求額を見て、すぐに延長サポートを外したくなるかもしれません。しかし、ここには注意が必要です。
AWSのドキュメントでは、標準サポートの終了日を過ぎたインスタンスで延長サポートを無効にすると、次のメジャーバージョンへ自動的にアップグレードされると明記されています。つまり、MySQL 8.0のインスタンスで延長サポートを外すと、事前の検証なしに8.4へ上がります。
MySQL 8.4には8.0と互換性のない変更があります。アプリケーション側の確認をしないまま自動アップグレードが走ると、接続できない、SQLがエラーになるといった障害につながりかねません。
また、延長サポートは標準サポートの終了から最長3年、2029年7月31日までです。その日を過ぎても8.0のままであれば、AWSが自動でメジャーバージョンをアップグレードします。いずれにしても、8.4への移行は自社で計画して実施するしかありません。延長サポートは、その準備期間を買うためのものです。
取り得る3つの選択肢
8.0のインスタンスが見つかった場合の対応は、次の3つに整理できます。
| 選択肢 | 概要 | 向いているケース | 注意点 |
|---|---|---|---|
| 延長サポートのまま使い、計画的に移行する | 料金を払いながら、検証を済ませてから8.4へ上げる | アプリケーションの改修や検証に数か月かかる基幹系 | 月額の料金が続き、2028年8月からは単価が2倍になる |
| インプレースで8.4へアップグレードする | 既存のインスタンスをそのまま8.4へ上げる | 小規模で、メンテナンス時間の停止を許容できるシステム | アップグレード中はデータベースが停止する。失敗時は8.0へロールバックされる |
| Blue/Greenデプロイで8.4へ移行する | 8.4の環境（グリーン）を別に作り、同期させてから切り替える | 停止時間を短くしたい本番環境 | 一時的に2環境分のインスタンス料金がかかる |
どの選択肢でも、最初にやることは変わりません。本番とは別の環境で8.4へのアップグレードを試し、アプリケーションが動くかを確認することです。
RDS for MySQL 8.0の棚卸しや、8.4への移行計画でお困りでしたら、c3index にお気軽にご相談ください。
MySQL 8.4へのアップグレードで確認すること
RDSは、8.0から8.4へのアップグレードを始める前に、互換性の事前チェック（precheck）を自動で実行します。問題が見つかった場合は、インスタンスを止める前にアップグレードを中止し、詳細を「PrePatchCompatibility.log」というログファイルに記録します。事前チェックは省略できません。
事前チェックで引っかかりやすい項目
AWSのドキュメントに挙げられている主な非互換は次のとおりです。
- 廃止されたデータ型や関数を使っているテーブル
- 定義者（DEFINER）が欠けている、または不正なトリガー
- MySQL 8.4で新たに予約語になったキーワードを、テーブル名や列名に使っている
- sql_modeに廃止されたモードが設定されている
- 255文字または1,020バイトを超えるENUM・SET型の要素
- 64文字を超える外部キー制約の名前
- MySQL 8.4で削除された機能を使っている
本番で実行する前に、スナップショットから復元した検証用インスタンスでアップグレードを試し、PrePatchCompatibility.logに何が出るかを確認しておくと、本番当日のやり直しを防げます。
認証方式の既定が変わる
MySQL 8.4のRDSでは、新しく作るユーザーの認証方式の既定がcaching_sha2_passwordになりました。8.0からアップグレードした既存のユーザーは、従来のmysql_native_passwordのまま使えます。
注意が必要なのは、アップグレード後に新しく作ったユーザーです。caching_sha2_passwordのユーザーで接続するにはSSL/TLSが必要です。また、古いMySQLクライアントライブラリや、古いバージョンのORM・ドライバーは、この認証方式に対応していないことがあります。アプリケーションのサーバー側で使っているライブラリのバージョンを確認しておきます。
文字コードとログ
utf8（utf8mb3）は非推奨になっています。AWSは、utf8mb3を使っているオブジェクトをutf8mb4に変えることを勧めています。また、古いクライアントはutf8mb3で不明な文字セットのエラーを受け取ることがあるため、データベースより先にクライアントを更新するよう案内しています。
メジャーバージョンのアップグレードでは、slow_logとgeneral_logのテーブルが空になります。調査用にログを残しておきたい場合は、アップグレード前に退避してください。
旧世代のインスタンスクラス
旧世代のインスタンスクラスのままでは、8.4へアップグレードできません。先に現行世代のインスタンスクラスへ変更してから、エンジンのバージョンを上げる必要があります。インスタンスクラスの変更にも再起動が伴うため、2回の作業を1回のメンテナンスで済ませるかどうかも計画に含めます。
8.4への移行を進める5つのステップ
移行は、次の順序で進めます。
- 棚卸し：全アカウント・全リージョンで、MySQL 8.0のインスタンス、Multi-AZの有無、リードレプリカ、インスタンスクラスを一覧にする。Cost Explorerで延長サポートの月額も押さえる
- 検証環境でのアップグレード試験：本番のスナップショットから検証用インスタンスを復元し、8.4へアップグレードする。PrePatchCompatibility.logの指摘を解消し、アップグレードにかかる時間も測る
- アプリケーションの接続試験：アプリケーションを検証用の8.4に接続し、ログイン・主要な画面・バッチ処理・帳票出力まで確認する。クライアントライブラリ、ORM、文字コードの影響をここで洗い出す
- 本番の切り替え：停止を許容できるならメンテナンス時間にインプレースで、停止を短くしたいならBlue/Greenデプロイで切り替える。切り替え前に手動スナップショットを取っておく
- 切り替え後の確認：エラーログとスロークエリを数日監視する。翌月のCost Explorerで、延長サポートの料金が止まったことを確認する
小規模なシステムであれば、棚卸しから切り替えまで数週間で終わることもあります。アプリケーションの改修が必要な場合や、インスタンスが多数ある場合は、2〜3か月を見込んでおくと安全です。
ほかのOS・ミドルウェアの期限もあわせて確認する
RDSのエンジンを確認するタイミングで、同じAWS環境のOSやミドルウェアの期限も整理しておくと、停止の調整とテストを1回にまとめられます。
- Amazon Linux 2023の標準サポートは2027年6月30日に終了する（メンテナンスフェーズは2029年6月30日まで）
- Windows Server 2016は2027年1月に延長サポートが終了する
- SQL Server 2017は2027年10月に延長サポートが終了する
移行先のMySQL 8.4も、RDSの標準サポートは2029年7月31日までです。今回の移行作業を手順書やコードに残しておけば、次のアップグレードの手間を減らせます。
よくある質問
Q. 延長サポートに登録されていても、インスタンスはそのまま動きますか？
A. 動きます。延長サポートへの登録でエンジンが変わることはなく、停止や性能の低下もありません。変わるのは料金だけです。
Q. 延長サポートを外せば、料金はすぐに止まりますか？
A. 止まりますが、標準サポートの終了日を過ぎた8.0のインスタンスで延長サポートを無効にすると、8.4へ自動的にアップグレードされます。検証をしないまま本番で8.4に上がるため、先に検証を済ませてから、自社のタイミングでアップグレードする方法をおすすめします。
Q. 延長サポートはいつまで使えますか？
A. RDS for MySQL 8.0の延長サポートは2029年7月31日までです。その後も8.0のままであれば、AWSが自動でアップグレードします。また、2028年8月1日からは単価が2倍になります。
Q. Multi-AZ構成では料金が2倍になりますか？
A. なります。Multi-AZ構成のスタンバイのインスタンスにも延長サポートの料金がかかるため、同じvCPU数のシングルAZ構成の2倍になります。
Q. 8.0から8.4へのアップグレードに失敗したらどうなりますか？
A. 事前チェックで非互換が見つかった場合は、インスタンスを止める前にアップグレードが中止されます。事前チェックを通過したあとに失敗した場合は、RDSが自動で8.0へロールバックし、原因をupgradeFailure.logに記録します。いずれの場合も、本番の前に検証環境で試しておけば、当日の失敗を避けられます。
まとめ
- RDS for MySQL 8.0の標準サポートは2026年7月31日に終了。8月1日から延長サポートに自動で登録され、追加料金が発生している
- 東京リージョンの単価は1 vCPUあたり1時間0.120ドル（2028年8月からは0.240ドル）。2 vCPUのMulti-AZ構成で月約350ドル
- 延長サポートを外すと8.4へ自動でアップグレードされる。2029年7月31日を過ぎた場合も自動でアップグレードされる
- 8.4では事前チェック、認証方式の既定の変更、utf8mb3の非推奨、旧世代インスタンスクラスの扱いを確認する
- 移行は棚卸し → 検証環境でのアップグレード試験 → アプリケーションの接続試験 → 本番の切り替え → 課金停止の確認の5ステップで進める
延長サポートの料金は、アップグレードを先送りした月の分だけ積み上がります。まずはCost Explorerで今の月額を確認し、検証環境でのアップグレード試験の日程を決めるところから始めてください。
c3index に相談する
c3indexは、AWSアドバンストティアサービスパートナーとして、RDSの棚卸しからMySQL 8.4への移行設計・検証・切り替え、移行後の運用代行までを一貫してご支援しています。延長サポートの料金を早く止めたい、アプリケーションへの影響を事前に確認したいといったご相談も、まずはお気軽にお問い合わせください。
