AWS RDS for MySQL 8.0 のサポート期限は2026年7月31日|8.4 LTSへの移行準備まとめ
AWS RDS を使って MySQL を運用している方にとって、見逃せないアナウンスがありました。
Amazon RDS では、MySQL 8.0 系のサポートが 2026 年 7 月 31 日をもって終了することが正式に発表されました。
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 を運用している方はこちらも参照してください。
今後どう対応すべきか?
ここでは、主に 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をサポートしているか確認 - RDS バージョンアップのスケジュールを逆算する
→ 標準サポート終了は 2026 年 7 月 31 日。間に合わない場合にどうなるかは、次章を必ず確認してください
間に合わない場合どうなる?(Extended Support の設定で運命が変わる)
ここが一番の注意点です。
標準サポートが終了しても、データベースが即座に止まるわけではありません。
ただし何が起きるかは、そのインスタンスの engine-lifecycle-support(RDS Extended Support への登録設定)によって真逆に分かれます。
| 設定 | 標準サポート終了後の挙動 | リスク |
|---|---|---|
| 有効 ( open-source-rds-extended-support) |
自動的に Extended Support へ登録される。 エンジンは変わらず、稼働にも影響なし |
気づかないうちに課金が始まる |
| 無効 ( ...-disabled) |
課金は発生しない。 その代わり RDS が自動でメジャーバージョンを上げる |
意図しないバージョンアップでアプリが壊れる |
つまり「何もしない」という選択肢は、どちらの設定でも安全ではありません。
課金されるか、勝手に上げられるかの違いでしかないからです。
さらに厄介なのは「既存インスタンスでは設定を変えられない」こと
この 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 倍(プライマリとスタンバイがそれぞれ課金される)
- 提供は最大 3 年間。それを過ぎると、結局 RDS が自動でメジャーバージョンを上げる
裏を返せば、Extended Support は「時間をお金で買う」仕組みとして使えます。
期日に間に合わないと分かった時点で突貫作業をするより、コストを把握したうえで計画的に移行するほうが安全なケースもあるでしょう。
大切なのは、どちらの挙動になるかを知らないまま期限を迎えないことです。
まとめ
| ポイント | 内容 |
|---|---|
| MySQL 8.0 のサポート | 標準サポートは 2026年7月31日まで(RDS)。上流の MySQL 8.0 は 2026年4月30日に EOL 済み |
| 期限を過ぎたら | Extended Support 有効なら自動登録され課金(vCPU 時間単位。Multi-AZ は実質 2 倍)/無効なら RDS が自動でメジャーバージョンを上げる。設定は作成・復元時にしか指定できない |
| 次期バージョン | 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)の比較は、以下の記事でまとめています。
本番を待たずに MySQL 8.4 をローカルで試したい場合は、Docker での構築手順が参考になります。
