2026.08.08

RDS for MySQL 8.0 サポート期限切れ後の分岐｜課金か強制アップグレードかは設定で決まる

saratogax

記事内に商品プロモーションを含む場合があります

Amazon RDS で MySQL 8.0 のインスタンスを、まだそのまま動かしていませんか？

Amazon RDS の MySQL 8.0 系は、2026 年 7 月 31 日をもって標準サポートが終了しました。

とはいえ、期限を過ぎたからといってデータベースが止まったわけではありません。

問題は、放置したインスタンスが「課金される」か「勝手にバージョンを上げられる」かのどちらかに進んでいることです。

どちらに進むかは設定ひとつで決まり、しかもその設定は稼働中のインスタンスでは変更できません。

まずは自分のインスタンスがどちらの経路にいるのかを確認してください。

判定に使う確認コマンドは後述します。

Amazon RDS for MySQL バージョン管理

Contents

MySQL 8.0 サポート終了の背景
次期移行先：MySQL 8.4（LTS）
- 🎯 MySQL 8.4 の主な変更点（移行時の注意点）
Aurora MySQL については？（2026 年 5 月追記）
今後どう対応すべきか？
- ✅ 今からできる移行準備：
期限を過ぎた 8.0 インスタンスに何が起きているか
- さらに厄介なのは「既存インスタンスでは設定を変えられない」こと
- Extended Support の課金条件
まとめ

MySQL 8.0 サポート終了の背景

MySQL 本体の 8.0 系は、Oracle の Premier Support が 2025 年 4 月 30 日に、Extended Support も 2026 年 4 月 30 日に終了しました。

つまり上流の MySQL 8.0 は、すでに完全な EOL に到達している状態です。

それに伴い、AWS も RDS での 8.0 系の提供を段階的に終了させていく流れです。

このようなサイクルは過去の MySQL バージョン（5.6, 5.7）と同様であり、セキュリティパッチや脆弱性対応の観点からも、早めのバージョン移行が求められます。

次期移行先：MySQL 8.4（LTS）

MySQL 8.4 は 2024 年に LTS（長期サポート）版としてリリースされました。

8.4 は 8.0 の後継であり、バージョン番号の飛びがあったことに違和感を持つ方もいるかもしれませんが、これは LTS の導入に伴う整備の一環です。

🎯 MySQL 8.4 の主な変更点（移行時の注意点）

認証方式

デフォルトの認証プラグインは MySQL 8.0 の時点で既に caching_sha2_password に変わっていました。

MySQL 8.4 で起きるのは「デフォルトの変更」ではなく、古い mysql_native_password プラグインがデフォルトで無効化された (disabled by default) という方向の変更です。

廃止機能

いくつかの構文やステータス変数が削除・変更（SHOW PROFILE など）

セキュリティ

暗号化・TLS 関連機能の強化

パフォーマンス

一部クエリオプティマイザの改善、スレッドプールの最適化

特に認証方式は重要で、現在 mysql_native_password を使っているユーザーやアプリケーションがある場合、MySQL 8.4 への移行時に接続エラーとなる可能性があるため、事前に caching_sha2_password への対応状況を確認しておく必要があります。

Aurora MySQL については？（2026 年 5 月追記）

本記事を書いた時点では Aurora MySQL は v3 系 (MySQL 8.0 互換) のみでしたが、2026 年 5 月 21 日に Aurora MySQL 8.4.7 (MySQL 8.4.7 互換) がリリースされました。

Aurora MySQL のメジャーバージョン採番も、これを機に互換元の MySQL バージョンをそのまま使う形 (8.4.x) に変わっています。

サポート中の Aurora MySQL v3 クラスターからは、in-place アップグレード / スナップショット復元時のアップグレード / Blue/Green Deployments のいずれかで 8.4.7 に移行できます。

Aurora 固有のポイント (自動メモリ管理 aurora_enable_memory_management の挙動変化、v3.12.0 比の改善点など) は別記事にまとめたので、Aurora MySQL を運用している方はこちらも参照してください。

Aurora MySQL 8.4 が GA。Aurora 利用者目線でリリースノートを読み解く

今後どう対応すべきか？

ここでは、主に Amazon RDS for MySQL を利用している方向けに、MySQL 8.4 への移行準備として検討すべきポイントを紹介します。

Aurora MySQL をお使いの方は、現時点での影響はありませんが、将来的なエンジンアップグレードに備え、同様の観点で準備を始めておくことをおすすめします。

✅ 今からできる移行準備：

mysql_native_password を使っていないか確認する
→ SELECT user, plugin FROM mysql.user; で確認可能
MySQL 8.4 の検証環境を用意する
→ Docker や一時的な RDS インスタンスでテスト
アプリケーションの対応状況を調査する
→ ORM やドライバが caching_sha2_password をサポートしているか確認
Extended Support の登録状態を確認する
→ 標準サポートは 2026 年 7 月 31 日で終了済み。今どちらの経路にいるかは、次章の確認コマンドで判定してください

期限を過ぎた 8.0 インスタンスに何が起きているか

ここが本記事で一番お伝えしたい部分です。

標準サポートが終了しても、データベースが即座に止まるわけではありません。

ただし何が起きるかは、そのインスタンスの engine-lifecycle-support（RDS Extended Support への登録設定）によって真逆に分かれます。

設定	標準サポート終了後の挙動	リスク
有効 (`open-source-rds-extended-support`)	終了日に自動的に Extended Support へ登録され、翌日から課金が始まる。エンジンは変わらず、稼働にも影響なし	気づかないうちに課金が始まる
無効 (`...-disabled`)	RDS が自動でメジャーバージョンを上げる。ただし事前チェックに失敗すると 8.0 へロールバックされ、 Extended Support 扱いのまま課金される	意図しないバージョンアップでアプリが壊れる／失敗すれば結局課金される

※表は横スクロールできます

つまり「何もしない」という選択肢は、どちらの設定でも安全ではありません。

課金されるか、勝手に上げられるかの違いでしかないからです。

とくに見落としやすいのが、無効にしていても課金される経路があることです。

自動アップグレードが事前チェックで弾かれると、RDS は安全側に倒して 8.0 へロールバックします。

そのインスタンスは Extended Support 扱いのまま残り、手動でアップグレードするまで課金が続きます。

「無効にしてあるから請求は来ないはず」と考えていると、ここで取りこぼします。

さらに厄介なのは「既存インスタンスでは設定を変えられない」こと

この engine-lifecycle-support は、DB インスタンスの作成時、またはスナップショットからの復元時にしか指定できません。

稼働中のインスタンスに対して、後から登録状態だけを切り替えることはできない仕様です。

そのため「課金されたくないから、期限前にオフにしておこう」と思っても、そのままでは設定変更できません（変えるには復元を伴う作り直しが必要になります）。

まずは、自分のインスタンスが今どちらの状態なのかを確認しておきましょう。

# 登録状態を確認する(EngineLifecycleSupport を見る)
$ aws rds describe-db-instances \
    --query 'DBInstances[].[DBInstanceIdentifier,EngineVersion,EngineLifecycleSupport]' \
    --output table

Extended Support の課金条件

Extended Support が適用された場合の課金は、次のようになります。

vCPU 単位・時間単位の課金（インスタンスが大きいほど高くなる）
Multi-AZ 構成では実質 2 倍（プライマリとスタンバイが同じインスタンスクラスで独立に課金される）
単価はリージョンと経過年数で変わる。1〜2 年目は同じ単価、3 年目に入った初日から高い単価に切り替わる
提供は標準サポート終了日から最大 3 年間。それを過ぎると、結局 RDS が自動でメジャーバージョンを上げる

裏を返せば、Extended Support は「時間をお金で買う」仕組みとして使えます。

期限を過ぎたことに気づいて突貫作業をするより、月あたりのコストを把握したうえで計画的に移行するほうが安全なケースもあるでしょう。

大切なのは、自分のインスタンスがどちらの経路にいるかを、請求書で知る前に把握しておくことです。

出典：Amazon RDS Extended Support／MySQL on Amazon RDS versions

まとめ

ポイント	内容
MySQL 8.0 のサポート	RDS の標準サポートは 2026年7月31日で終了済み。上流の MySQL 8.0 も 2026年4月30日に EOL 済み
期限後の分岐	Extended Support 有効なら自動登録され翌日から課金（vCPU 時間単位。Multi-AZ は実質 2 倍、3 年目から単価が上がる）／無効なら RDS が自動でメジャーバージョンを上げる。ただし事前チェックに失敗すると 8.0 へロールバックされ、結局課金される。設定は作成・復元時にしか指定できない
次期バージョン	MySQL 8.4（LTS）
移行の主な懸念	認証方式（`mysql_native_password` → `caching_sha2_password`）など
Aurora の状況	2026 年 5 月 21 日に Aurora MySQL 8.4.7 (MySQL 8.4.7 互換) がリリース。v3 系からは in-place / snapshot / Blue/Green で移行可能

RDS や Aurora を使って MySQL を運用している場合、この機会に今後の移行スケジュールを立てておくことを強くおすすめします。

Aurora MySQL 側の LTS バージョン（3.10.x / 3.12.0）の比較は、以下の記事でまとめています。

RDS for MySQL 8.0 サポート期限切れ後の分岐｜課金か強制アップグレードかは設定で決まる

MySQL 8.0 サポート終了の背景