※本記事にはアフィリエイト広告が含まれます。
AWSのRDS for MySQL 8.0でPHP/Laravelのアプリを動かしているなら、2026年8月からRDSの延長サポート(RDS Extended Support)の料金がかかっているはずです。私も実務でRDSとLaravelを使っていて、「8.4へ上げるとして、アプリ側で何が壊れうるか」を公式ドキュメントで整理しました。
この記事では、延長サポートの課金が止まる条件と、8.4へ上げる前にPHP・Laravel側で確認することを、AWS・PHP・Laravelの公式ドキュメントをもとにまとめます。日付や仕様は、どれも確認日(2026-10-05)時点のものです。なお、この記事の内容は実際にアップグレードを実行して確かめたものではありません。公式ドキュメントに書かれている内容の整理です。
結論:課金を止めるには標準サポート中の8.4へ上げる(または削除する)。アプリ側は認証と予約語から確認する
RDS公式のリリースカレンダーでは、MySQL 8.0の標準サポートは2026年7月31日に終わり、2026年8月1日から延長サポートの1年目の料金がかかります。3年目の料金は2028年8月1日から、延長サポートの終了は2029年7月31日です。
| バージョン | 標準サポート終了 | 延長サポート1年目の料金開始 | 3年目の料金開始 | 延長サポート終了 |
|---|---|---|---|---|
| MySQL 8.0 | 2026-07-31 | 2026-08-01 | 2028-08-01 | 2029-07-31 |
| MySQL 8.4 | 2029-07-31 | 2029-08-01 | 2031-08-01 | 2032-07-31 |
課金が自動で止まるのは、「標準サポート中のエンジンバージョンへ上げる」か「標準サポートの期限を過ぎたメジャーバージョンで動いているDBを削除する」のどちらかをしたときです。DBを使い続けるなら、現実的な選択肢は8.4へ上げることになります。
アプリ側で先に確認したいのは、8.4で既定になる認証プラグイン(caching_sha2_password)と、RDSの事前チェックで引っかかりやすい予約語・文字コードです。
延長サポートの仕組み(RDS公式ドキュメント)
RDS公式の説明を要点だけ並べます。
- 延長サポートの料金は、標準サポート終了日の翌日からかかる。Multi-AZ配置のスタンバイインスタンスも対象
- 課金が止まるのは、標準サポート中のバージョンへ上げたとき、または期限切れのメジャーバージョンで動くDBを削除したとき
- 上げた先のバージョンが将来延長サポートに入れば、課金はまた始まる
注意したいのが EngineLifecycleSupport の設定です。公式では、標準サポートの期限をすでに過ぎたDBで登録状態を無効(open-source-rds-extended-support-disabled)にすると、そのDBは次にサポートされるメジャーバージョンへ自動で上がるとされています。「課金だけ止める」設定ではないので、アプリの確認が済む前に8.4へ上がってしまうおそれがあります。
また、延長サポートは標準サポート終了日から最長3年までで、それを過ぎてもサポート中のバージョンへ上げていなければ、RDSがメジャーバージョンを自動で上げるとされています。
料金の単価はMySQLのバージョン・リージョン・経過年数で変わります。金額は公式の料金ページ(Amazon RDS for MySQL pricing)の「RDS Extended Support」の欄で、自分のリージョンの値を確認してください。
8.4へ上げるときのRDSの事前チェック
RDSは、メジャーバージョンを上げる前に非互換がないかを調べる事前チェック(prechecks)を実行します。公式では次のように説明されています。
- 8.0から8.4への事前チェックは必須で、スキップできない
- DBインスタンスを止める前に実行されるので、チェック自体でダウンタイムは発生しない
- 非互換が見つかると、RDSはインスタンスを止める前にアップグレードを自動で取り消し、イベントを出す
- 非互換の詳細はログファイル
PrePatchCompatibility.logに記録される
RDS公式に載っている、8.0から8.4への主なチェック項目は次のとおりです。
- 廃止されたデータ型や関数を使うテーブルがない
- キーワード・予約語の違反がない(RDS公式は「以前は予約されていなかったキーワードが8.4で予約されている場合がある」としている)
sql_modeに廃止されたSQLモードが入っていない- 8.4でサポートされない機能を使っていない
- 64文字を超える外部キー制約名がない
utf8mb3を使うオブジェクトはutf8mb4への変換を検討する(utf8は現在utf8mb3の別名)
Laravelのマイグレーションで付けたカラム名やテーブル名が、8.4で予約語になっていないかは、事前チェックのログ(PrePatchCompatibility.log)で確かめられます。公式では、ログの多くの項目に修正方法のドキュメントへのリンクが付くとされています。
事前チェックで拾えなかった非互換があると、アップグレード自体が失敗することもあります。その場合、RDSは変更をロールバックして8.0に戻し、イベントID RDS-EVENT-0188 を出します。失敗の詳細は upgradeFailure.log で確認できます。
まだ5.7のDBが残っている場合、5.7から8.4へは直接上げられません。先に8.0へ上げてから8.4へ上げる必要があります。
PHP・Laravel側で確認すること:認証プラグイン
RDS for MySQL 8.0(8.0.34以降)の既定の認証プラグインは mysql_native_password で、8.0では default_authentication_plugin を変更できません。一方、RDS for MySQL 8.4の既定は caching_sha2_password です。RDS公式では「mysql_native_password は8.4でもまだ動くが、このプラグインのサポートは8.4で終わる」とされています。8.4で既定の認証プラグインを変えたいときは、カスタムパラメータグループを作って authentication_policy の値を変更します。
RDSはDBインスタンスへのシェルアクセスを提供しておらず、設定はパラメータグループで行います。そのため、自前のMySQLサーバー向けの記事にある起動オプションやmy.cnfの手順は、RDSではそのまま使えません。RDSの8.4で mysql_native_password を有効・無効にするパラメータがあるかどうかは、RDS公式ドキュメントでは記載を確認できませんでした。RDSで確認できたのは、上に書いた「8.4でもまだ動く」「既定は authentication_policy で変える」までです。
次にPHP側です。php.netのmysqliとPDO_MYSQLのページには、どちらにも「caching_sha2_passwordプラグインはPHP 7.4.4から完全にサポートされている」と書かれています。Laravelのドキュメントに載っているMySQL接続の設定例は pdo_mysql 拡張を前提にしているので、PDO_MYSQLのページが直接の根拠になります。
php.netは、古いPHP(7.1.16より前、7.2系は7.2.4より前)向けの回避策として、my.cnfで default_authentication_plugin=mysql_native_password を設定する方法を案内しています。ただしRDSでは、8.0ではこの設定を変更できず、8.4では既定の認証プラグインを authentication_policy で変える仕組みなので、そのままは使えません。
アプリ本体が新しいPHPで動いていても、同じDBにつなぐ古いバッチや管理ツールが残っていることがあります。確認したいのは次の点です。
- 同じDBにつなぐPHPのバージョン(7.4.4未満が残っていないか)
- 既存のDBユーザーがどの認証プラグインで作られているか
- 8.4で新しく作るユーザーをどのプラグインにするか(
authentication_policyを変えるかどうか) - RDSのストアドプロシージャでレプリケーションを管理している場合、レプリケーション用ユーザーが
caching_sha2_passwordだと、SOURCE_SSL=1を指定してTLSを設定する必要がある
PHP・Laravel側で確認すること:文字コード・パラメータ・削除された機能
文字コード
Laravel 13のドキュメントに載っているMySQL接続の設定例では、charset の既定値は utf8mb4、collation は utf8mb4_unicode_ci です。Laravel 13が公式にサポートするMySQLは5.7以降とされています。
ただし、Laravelの設定がutf8mb4でも、昔のマイグレーションや手作業で utf8(=utf8mb3)のテーブルが作られていることがあります。RDSは、古いクライアントでは utf8mb3 で「unknown character set」のエラーになりうるため、DBより先にクライアントを上げるよう勧めています。
パラメータの既定値(RDS公式に載っているもの)
innodb_dedicated_server:既定で有効になったinnodb_buffer_pool・innodb_redo_log_capacity:エンジンが計算する(上書きは可能)innodb_log_file_size・innodb_log_files_in_group:8.4のパラメータグループから削除innodb_purge_threads:既定値はLEAST({DBInstanceVCPU/2},4)binlog_format:既定値はROW
8.0で innodb_log_file_size などをカスタムパラメータグループに入れている場合、8.4用のパラメータグループを作り直すときに見直しが必要です。
性能に関わる既定値は、mysql8.4のパラメータグループで確認する
RDS公式は、上のほかにも「性能に関わるMySQLコミュニティ版のパラメータがいくつか変わった」としていて、詳細はMySQLのドキュメント(What Is New in MySQL 8.4 since MySQL 8.0)を参照するよう案内しています。そのうえで、本番のインスタンスを移行する前に、RDS for MySQL 8.4でアプリの性能をテストするよう勧めています。
RDSでは、DBインスタンスが実際に使うのはDBパラメータグループの値です。8.4での値は、RDSのデフォルトパラメータグループ(ファミリー mysql8.4)で確認しておくと確実です。RDS公式では、AWS CLIの describe-engine-default-parameters の --db-parameter-group-family に mysql8.4 を指定できると案内されています(公式の例は mysql8.0 を指定したもの)。
aws rds describe-engine-default-parameters --db-parameter-group-family mysql8.4
性能のテストには、スナップショットから復元したコピーで先に上げて試す方法が公式で紹介されています。本番と同じクエリを流して、8.0のときと比べておくと安心です。
名前が変わったもの・使えなくなったもの
- RDS for MySQL 8.4では、インクルーシブな用語への変更が入っている。たとえば
SHOW SLAVE STATUSはSHOW REPLICA STATUSに置き換わった - パラメータ名も変わった(例:
log_slave_updates→log_replica_updates、slave_parallel_workers→replica_parallel_workers)。カスタムの8.4パラメータグループで値を変えるときは、新しい名前しか使えない - RDSのレプリケーション用ストアドプロシージャも名前が変わった(例:
mysql.rds_set_external_master→mysql.rds_set_external_source)。旧名は8.4の初期リリースでは使えるが、将来のリリースで削除される予定 - RDS for MySQL 8.4では、memcachedのインターフェースと
mysqlpumpが使えない - RDS for MySQL 8.4がサポートするTLSは1.2と1.3だけ
監視スクリプトや運用バッチで SHOW SLAVE STATUS を叩いていたり、バックアップに mysqlpump を使っていたり、Terraformなどでパラメータグループを旧名で定義していたりしないか、アプリの外側も含めて探しておくと安心です。
よくある誤解
- 「延長サポートに入れば何もしなくていい」:料金がかかり続け、8.0の延長サポートは2029年7月31日に終わる
- 「EngineLifecycleSupportを無効にすれば課金だけ止まる」:標準サポートの期限を過ぎたDBでは、次のメジャーバージョンへ自動で上がる
- 「事前チェックが通ればアプリも動く」:事前チェックはDB側の非互換を調べるもの。認証方式や性能など、アプリ側の動作は自分でテストする必要がある(RDS公式も本番前の十分なテストを勧めている)
まとめ
RDS for MySQL 8.0は、確認日時点で延長サポートの料金がかかる期間に入っています。確認の順番を整理すると次のとおりです。
- 課金が止まる条件(標準サポート中のバージョンへ上げる/DBを削除する)と、EngineLifecycleSupportを無効にしたときの自動アップグレードを把握する
- RDSの事前チェックの項目(予約語・sql_mode・外部キー名・utf8mb3など)を先に潰す
- 認証プラグイン:接続するPHPが7.4.4以上か、
authentication_policyをどうするか - 文字コード:utf8(utf8mb3)の古いテーブルがないか
- パラメータグループ:削除・改名されたパラメータと、mysql8.4ファミリーの既定値を確認し、コピーで性能をテストする
MySQLの仕組みやRDSの運用を体系的に学び直したいときは、技術書を1冊手元に置いておくと、公式ドキュメントを読むときの土台になります。楽天市場でもAmazonでも、MySQLやAWSの技術書は探せます。
Amazon RDSは、AWS認定のSAA(Solutions Architect – Associate)・DVA(Developer – Associate)・SOA(CloudOps Engineer – Associate)の各試験ガイドで、いずれも範囲内のサービスに挙げられています。資格の勉強の順番については、次の記事にまとめています。


