数千人規模の従業員を抱え、基幹業務システムにRDS for MySQL（Amazonが管理するリレーショナルデータベースサービス）を使い、四半期ごとに内部監査を受けている企業のDB運用担当者は、2026年8月以降、毎月の請求書に見慣れない追加項目を見つけることになる。RDS for MySQL 8.0は2026年7月31日に標準サポートが終了しており、8月1日以降は何も手を打たなければ自動的に有償のExtended Support（延長サポート）の対象になっている[1]。これは新しい契約を結ぶ手続きではなく、対象インスタンスが8.0系のまま稼働していれば自動的に課金が始まる仕組みである[1]。追加費用はvCPU（仮想CPU）1時間あたりの従量課金で、稼働年数が進むほど単価が上がる[2]。一方でMySQL 8.4（長期サポート版）への移行には、互換性検証とダウンタイム設計という別のコストがかかる[3]。本稿は、延命と移行のどちらを選ぶかを、費用の推移と稟議・変更管理のタイミングから整理する。
予備知識
- Extended Support（延長サポート）: 標準サポート終了後もAWSが同じメジャーバージョンの運用を有償で継続させるオプション。
- 標準サポート終了（EOL）: セキュリティパッチや通常のマイナーバージョン更新が提供されなくなる区切りの日付。
- ブルーグリーンデプロイ: 新旧2つの環境を並行稼働させ、切り替え時のダウンタイムを数秒に抑える更新手法。
- vCPU時間課金: インスタンスの仮想CPU数×稼働時間で計算する従量課金方式。
RDSを含むAWS運用の基本と実務ノウハウを体系的に押さえたい担当者向け。
標準サポート終了とExtended Supportの自動移行
RDS for MySQL 8.0の標準サポートは2026年7月31日に終了した[1]。8月1日以降、8.0系のまま稼働しているインスタンスにはすでにExtended Supportの課金が発生している。
翌8月1日以降、8.0系のまま稼働しているインスタンスは自動的にExtended Supportへ組み込まれ、その時点から追加課金が発生する[1]。課金を止めるにはEngineLifecycleSupportパラメータでオプトアウトする。作成時・復元時に設定できるほか、稼働中のインスタンスでもAWS CLIやRDS APIからいつでも変更でき、ダウンタイムなく即時反映される[1]。ただし標準サポート終了日を過ぎたインスタンスでオプトアウトすると、次の対応メジャーバージョンへ自動的にアップグレードされる[1]。無償のまま8.0で居座る選択肢はない、というのが実際のところだ。
標準サポートとExtended Supportの違いは次のとおりである。
| 項目 | 標準サポート | Extended Support |
|---|---|---|
| 費用 | インスタンス料金のみ | インスタンス料金＋vCPU時間課金[2] |
| マイナー更新 | 提供される | 重要セキュリティ修正が中心 |
| 利用可能期間 | バージョンごとに規定 | 最長3年間 |
| 開始条件 | 通常利用 | 標準サポート終了後、自動 |
稟議を経て数年前に構築した基幹DBほど、このオプトアウト設定が未実施のまま、8月1日を境に自動課金が始まっている可能性が高い。
8.4移行のようなDB移行プロジェクトの進め方を体系的に学びたい人向け。
延命コストの試算：vCPU課金とMulti-AZの2倍化
Extended Supportの費用は米国東部リージョンを基準にすると、2026年8月1日から2028年7月31日までの年1〜2年目は1vCPU時間あたり0.10ドル（約15.5円、1ドル=155円換算）、2028年8月1日以降の年3年目は0.20ドル（約31円）に上がる[2]。単価は2倍になる。
具体例として4vCPUのインスタンス（db.r5.xlarge相当）をSingle-AZで運用した場合、年1〜2年目は月額292ドル（約4万5,260円）、年3年目は月額584ドル（約9万520円）が上乗せされる[2]。Multi-AZ構成では、プライマリとスタンバイの両方が同じvCPU数で個別に課金されるため、金額はそのまま2倍になる[2]。
基幹系で一般的なMulti-AZ構成なら、年3年目には4vCPU1台あたり年間14,016ドル（約217万円）の追加費用になる。インスタンス数が増えるほど負担は線形に積み上がる。
コンテナ基盤としてEKS（Amazon Elastic Kubernetes Service、AWSのマネージドKubernetesサービス）を採用し、複数の事業部でクラスタを分散運用する数千人規模の企業では、情報システム部門やSRE（シ[…]
8.4移行の実務：検証からBlue/Greenまでの3段階
AWSが推奨する8.0から8.4への移行手順は3段階に整理されている[3][4]。第1段階は、スナップショット上でMySQL Shellのアップグレードチェッカーを実行し、互換性の問題を本番影響なく洗い出すこと。第2段階は、Blue/Greenデプロイで新旧環境を並行稼働させること。単一リージョン構成では切り替え時のダウンタイムが通常5秒以下に収まるとされる[4]。第3段階は、切り替え後に逆方向レプリケーション（ネイティブレプリケーションまたはAWS DMS）を設定し、問題発生時のロールバック手段を確保することである[4]。
互換性面での主な変更点は、mysql_native_password認証プラグインの非推奨化、restrict_fk_on_non_standard_keyパラメータの追加、複数パラメータのデフォルト値変更である[4]。既存ユーザーはアップグレード後も引き続き接続できるが、新規に作成するユーザーはcaching_sha2_passwordになるため、ユーザー作成を自動化している箇所は移行前に見直しが要る[4]。
数百人規模で自社LLM基盤や生成AIサービスをAWS上に構築し、年次予算策定サイクルを持つ企業のインフラ担当・調達担当が対象になる。GPUインスタンスを一定期間確保できるCapacity Block（GPUインスタンスを予約購入できるAW[…]
判断基準：延命と移行のタイムライン比較
延命（Extended Support継続）と移行（8.4アップグレード）は、コストの出方が異なる。延命は初期コストが低く継続コストが年々増える一方、移行は検証工数という初期コストを先に払う代わりに継続コストを抑えられる。
| 観点 | 延命（Extended Support） | 移行（8.4アップグレード） |
|---|---|---|
| 初期コスト | ほぼゼロ | 互換性検証・テスト工数[3][4] |
| 継続コスト | 年々増加、3年目に単価2倍[2] | 通常のインスタンス料金のみ |
| 利用可能期間 | 最長3年間[1] | 制約なし（次のEOLまで） |
| 向いている状況 | 直近1年以内に更改・廃止予定のシステム | 長期継続利用するシステム |
3年以内に廃止・更改が決まっているシステムなら延命で逃げ切れる。今後も使い続ける基幹DBなら、検証工数を先に払ってでも8.4移行を今期の計画に乗せたほうが、3年目以降の費用増加を避けられる。
ガーミンは「値上げ」せずに、どうやって1台あたりの単価を上げたのか 結論を先に言えば、ガーミンは既存モデルの定価を横並びで引き上げるのではなく、その上に「より高い上位ティア」を新設し、購入者の選好を上へずらすことで平均単価（ASP）を押し[…]
SIer保守契約と稟議フローが延命コストに与える影響
日本企業でも、RDS for MySQL 8.0を基幹の一部に使っていれば、8月1日を境に同じ請求変化が起きる。自動でExtended Supportへ切り替わる仕組みは、契約主体や拠点に関わらず共通である[1]。
違うのは、そこから先の意思決定の速さである。日本企業の多くはSIer（システムインテグレーター）との保守契約でRDSの構成変更を委託しており、契約範囲外の作業には追加見積もりと契約変更が必要になる。四半期または半期ごとの変更管理委員会を通す社内手続きもあり、稟議が下りるまでに数週間から数ヶ月かかる企業も珍しくない。監査対象システムなら、バージョン変更自体が内部統制の証跡になる。
| 観点 | 海外の典型例 | 日本企業の典型例 |
|---|---|---|
| 実行判断 | 担当エンジニアが即決 | 変更管理委員会の承認が前提 |
| 作業主体 | 社内エンジニア | SIer保守契約の範囲内で委託 |
| 意思決定期間 | 数日 | 数週間〜数ヶ月（稟議次第） |
| 監査対応 | 事後報告で足りる場合が多い | 変更履歴を統制証跡として保存 |
IT部門の担当者は、8.4移行を今期の変更管理計画に前倒しで組み込む提案を今から出す必要がある。決裁側は、追加費用を先送りコストとして許容するか、移行予算を今期に確保するかを、次の稟議サイクルの前に判断する必要がある。
まとめ
RDS for MySQL 8.0は2026年7月31日に標準サポートが終了し、翌日から自動的にExtended Supportの課金対象になる[1]。追加費用はvCPU時間課金で、稼働年数が進むほど単価が上がり、Multi-AZ構成では単純に2倍になる[2]。8.4への移行はBlue/Greenデプロイでダウンタイムを数秒に抑えられるが、事前の互換性検証という別の工数がかかる[3][4]。
IT部門担当者の次の一手は、稼働中の8.0インスタンスを棚卸しし、今期の変更管理サイクルに8.4移行の提案を乗せられるか確認することである。決裁側の判断材料は、Extended Supportの追加費用と移行プロジェクトの検証コストを比較し、SIerとの契約更新時期に合わせて判断時期を決めることである。
先送りも選択肢だが、費用が自動的に積み上がる点は他の契約更新と違う。先延ばしにするほど、比較材料は増えずに請求額だけが増えていく。
よくある質問（FAQ）
Q. RDS for MySQL 8.0はいつまで無料で使えますか。
A. 標準サポートは2026年7月31日までで、8月1日以降は自動的に有償のExtended Supportに切り替わる[1]。
Q. Extended Supportを避ける方法はありますか。
A. EngineLifecycleSupportパラメータでいつでもオプトアウトできるが、標準サポート終了後に解除すると次の対応メジャーバージョンへ自動アップグレードされる[1]。8.0のまま無償で使い続ける方法はないため、実質的には8.4など対応版への計画的な移行になる。
Q. MySQL 8.0から8.4への移行にダウンタイムはどれくらいかかりますか。
A. AWSが推奨するBlue/Greenデプロイでは、単一リージョン構成の場合、切り替え時のダウンタイムは通常5秒以下とされる[4]。
出典
[1] AWS, “Amazon RDS Extended Support”(2026年時点) https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/extended-support.html[2] AWS, “Amazon RDS for MySQL pricing”(2026年時点) https://aws.amazon.com/rds/mysql/pricing/
[3] AWS Database Blog, “Upgrade strategies for Amazon RDS for MySQL 8.0 to 8.4″(2026年5月) https://aws.amazon.com/blogs/database/upgrade-strategies-for-amazon-rds-for-mysql-8-0-to-8-4/
[4] AWS Database Blog, “Best practices for upgrading Amazon RDS for MySQL 8.0 to 8.4 with prechecks, Blue/Green, and rollback”(2026年) https://aws.amazon.com/blogs/database/best-practices-for-upgrading-amazon-rds-for-mysql-8-0-to-8-4-with-prechecks-blue-green-and-rollback/
