RDS for MySQL 8.0は2026年7月31日で標準サポート終了｜8月から自動課金されるExtended Support費用の見抜き方と回避の段取り

結論：7月31日を過ぎると、何もしなくてもRDSの請求が増え始めます

AWS公式ドキュメントによると、Amazon RDS for MySQL 8.0の「RDS標準サポート」は2026年7月31日に終了します。コミュニティ版MySQL 8.0自体はすでに2026年4月30日にサポートが終わっており、AWSが独自に面倒を見てくれる期間も7月末で区切りを迎えます。8月1日以降、MySQL 8.0のまま動いているRDSインスタンスは、原則として有償の「RDS Extended Support(延長サポート)」に自動的に登録され、インスタンス料金とは別建てで、vCPU数×稼働時間に応じた追加課金が始まります。これは申し込み制ではありません。作成時に明示的に無効化していない限り自動で適用される仕組みで、AWS公式も「標準サポート終了日の翌日から課金が発生する」と明記しています。

経営にとっての意味はシンプルです。第一に、自社のシステムがRDS for MySQL 8.0を使っているなら、8月分の請求書から「RDS Extended Support」という見慣れない請求行が現れ、構成によっては月数万円から十数万円規模の固定費が増えます(概算根拠は本文で示します)。しかもMulti-AZ構成ならスタンバイ側にも課金されるため、冗長化しているまじめな会社ほど負担は倍になります。第二に、この課金は年を追うごとに上がります。AWSの料金体系では標準サポート終了後1〜2年目と3年目で単価が段階化されており、3年目(2028年8月1日以降)には単価が2倍水準になります。第三に、回避策は明確で、MySQL 8.4(LTS)など標準サポート内のバージョンへアップグレードすれば課金はその日から止まります。

つまりこれは「障害が起きる話」ではなく「静かに固定費が増える話」です。緊急停止のような派手なリスクがない分、社内の誰も気づかないまま課金が続きやすい。本稿では、8月の請求書でどの行を見るべきか、なぜ保守ベンダーからこの話が出てこないのか、そして「すぐ上げる」「あえて延長サポートで時間を買う」の判断をどう分けるかを、発注側の経営者・実務決裁者の目線で整理します。

この記事を読むべき人

• 自社サービスや業務システムがAWS上で動いていると聞いているが、データベースのバージョンまでは把握していない経営者・役員
• 8月以降のAWS請求書に「Extended Support」という行が現れ、意味が分からず調べている経理・管理部門の責任者
• 開発会社や保守ベンダーに運用を任せており、EOL(サポート終了)対応が契約範囲に入っているか自信がない発注責任者
• MySQL 5.7からの移行を過去に経験し、「またか」と感じているひとり情シス・兼任情シスの方
• クラウドコストの増加が続いており、原因の切り分けをしたい事業責任者

事実整理:何がいつ起きるのか

まず、AWS公式ドキュメント(MySQL on Amazon RDS versions)に記載されているRDS for MySQLのサポートカレンダーを整理します。

Extended Supportの中身と課金の仕組みは、AWS公式(Amazon RDS Extended Support、同・課金、同・概要)で次のように定義されています。

• 提供内容は、重要度Critical/HighのCVE(脆弱性)に対するセキュリティ修正、重大なバグ修正、通常のSLAでのサポートケース対応。新機能は提供されません
• インスタンス作成時に無効化していない限り、標準サポート終了日を迎えたDBインスタンスは自動的にExtended Supportへ登録されます
• 課金は標準サポート終了日の翌日から始まり、Multi-AZ構成ではスタンバイインスタンスにも課金されます
• 標準サポート内のバージョンへアップグレードするか、そのデータベースを削除した時点で、課金は自動的に止まります
• Extended Supportは最長3年間で、その後もアップグレードしない場合、AWSがメジャーバージョンを自動アップグレードします。つまり「ずっと8.0のまま」という選択肢はそもそも存在しません

費用の概算:前提を明示した試算

Extended Supportの単価はエンジン・リージョン・経過年数で決まるvCPU時間課金です。執筆時点(2026年7月22日)では、AWSの公式料金データ(Price List API・東京リージョン)にMySQL 8.0専用の単価はまだ掲載されていません(課金開始は8月1日のため)。そこで本稿の試算は、同APIで確認できる東京リージョンの既存Extended Support実単価を前提に置きます。確認できた実単価は、RDS for MySQL 5.7が1〜2年目0.120USD/vCPU時・3年目0.240USD/vCPU時で、東京リージョンの他エンジン(RDS for PostgreSQL各バージョン等)もすべて同水準でした。8.0も同水準と仮定し、1ドル150円、月730時間稼働で計算します。**以下はあくまで概算例であり、個社の請求額を保証するものではありません。**実額は必ずAWS料金ページと自社の請求書で確認してください。

注目すべきは、これが「使った分」ではなく「動かしている限りかかり続ける」費用だという点です。Multi-AZのdb.m5.xlarge一つで年間約126万円。中堅企業が複数の業務システムでRDSを使っていれば、合計は簡単に年数百万円に届きます。そして放置すれば2028年8月から倍になります。

独自視点①:「何もしていないのに請求が増える」構造を理解する

今回の件で経営者がまず押さえるべきなのは、これがオプトイン(申込制)ではなくオプトアウト(明示的に断らない限り適用)の構造だという点です。

AWSの仕様では、Extended Supportを避ける設定(CLIでいう --engine-lifecycle-support open-source-rds-extended-support-disabled)は、インスタンスの新規作成時または復元時にしか指定できません。数年前に構築されて動き続けている既存のインスタンスは、この設定を後から変えられず、期日が来れば自動的に課金対象になります。「気づいたら課金されていた」は、担当者の怠慢というより、仕組み上そうなりやすい設計なのです。

さらに、通知が届いても意思決定者まで届かない構造的な問題があります。AWSからの告知は、AWSアカウントの登録メールアドレスやコンソールの通知に届きます。ところが中堅企業の実態では、(1)AWSアカウントの管理者が開発ベンダー側にある、(2)登録メールが退職者や共有アドレスで誰も見ていない、(3)通知は見たが「Extended Support」という語感から重要性が伝わらず流された、のいずれかが起きがちです。2024年のMySQL 5.7の標準サポート終了時にも同じ構造で、請求書を見て初めて気づいたという事態は広く発生しました。今回の8.0は5.7よりも利用者の裾野がはるかに広いバージョンです。「うちは大丈夫」ではなく「うちのどのシステムが該当するか」を確認する問題として扱ってください。

確認の第一歩は簡単です。ベンダーか社内担当に、次の一文をそのまま送ってください。「AWSのRDSでMySQLを使っているインスタンスを全て挙げ、それぞれのエンジンバージョン(8.0か8.4か)、vCPU数、Multi-AZの有無を一覧にしてください」。この一覧が1営業日で出てこないなら、その体制自体が論点です。

独自視点②:8月の請求書で確認すべき「行」

課金が始まったかどうかは、8月分(9月初旬に確定する請求)のAWS請求書で機械的に確認できます。見るべきポイントは次の通りです。

1. 請求書(Billing)のRDSセクションに「Extended Support」を含む行が現れていないか。AWSの課金データでは、Extended Supportは通常のインスタンス料金と別の使用タイプ(usage type)で計上されます。東京リージョンの場合、既存エンジンでは APN1-ExtendedSupport:Yr1-Yr2:MySQL5.7 のような形式であり、8.0でも同様の命名で現れると考えられます
2. Cost Explorerで「使用タイプ」に ExtendedSupport を含むものをフィルタする。これで、どのアカウント・どのインスタンスが課金対象かを金額つきで特定できます
3. 8月1日以降の日次コストの段差を見る。Extended Supportは時間課金なので、開始日からきれいに日額が増えます。日次グラフの段差は、社内へ説明する際の最も分かりやすい証拠になります
4. タグ付けの有無を確認する。システム別・部門別のコスト配賦タグが整備されていれば、どの事業のコストが増えたのかまで特定できます。整備されていなければ、これを機に入れるべきです

なお、請求額そのものより重要なのは「この行を誰が最初に発見する体制か」です。経理が発見して技術側に問い合わせる会社と、技術側が事前に把握して経営に報告している会社とでは、ベンダー統制の成熟度に大きな差があります。今回は自社がどちらだったかを確かめるリトマス試験紙にもなります。

独自視点③:なぜ保守ベンダーはこの話をしてこないのか

「保守費を毎月払っているのだから、こういう話はベンダーが先に教えてくれるはず」と考える経営者は多いのですが、実務ではそうならないことが珍しくありません。悪意というより、契約構造がそうなっているからです。

多くのシステム保守契約は、「現状のシステムを現状のまま動かし続けること」を役務範囲としています。障害対応、問い合わせ対応、軽微な修正までは含まれても、**データベースのメジャーバージョンアップは「別途見積もりの改修案件」**であるのが通例です。ベンダーの立場では、バージョンアップを提案することは、(1)自社の追加工数と検証リスクを背負い、(2)顧客に追加費用の稟議を求め、(3)失敗すれば責任を問われる行為です。一方、何も言わなければExtended Support費用はAWSから顧客に直接請求され、ベンダーの懐は痛みません。誰も動かないインセンティブ構造の中で、課金だけが静かに始まる。これが今回の本当の落とし穴です。

そこで、保守契約書(または業務委託契約の別紙)で次の4点を確認してください。

• EOL管理の責務:利用しているミドルウェア・マネージドサービスのサポート期限を把握し、期限前に通知・提案する義務がベンダー側にあるか。条項が無ければ「誰の仕事でもない」状態です
• バージョンアップ作業の扱い:保守範囲内か、別途見積もりか。別途の場合、概算レンジと標準リードタイムの目安が示されているか
• クラウド利用料の名義:AWSアカウントが自社名義か、ベンダー名義の再請求か。再請求の場合、Extended Support課金が明細で見えず、保守費に紛れて転嫁されるリスクがあります
• 報告義務:月次報告にコスト推移とEOL予定が含まれているか

この確認は、ベンダーを責めるためではなく、次回の契約更新で「EOL管理と年次バージョンアップ計画」を役務に明記させるための材料です。保守契約の範囲と引き継ぎの考え方については、保守費用とベンダー切り替え・引き継ぎの実務ガイドで詳しく整理しています。

独自視点④:アップグレードの段取りと、「あえて延長サポートを使う」判断

回避策はMySQL 8.4(LTS)へのアップグレードで、AWSは8.0から8.4への直接アップグレードを公式にサポートしています。8.4の標準サポートは2029年7月31日までなので、一度上げれば約3年の猶予が得られます。ただし、メジャーバージョンアップは互換性リスクを伴う「改修案件」であり、雑にやると事故になります。発注側が押さえるべき段取りは次の5段階です。

1. 棚卸しと影響調査(1〜2週間):対象インスタンスの一覧化、アプリケーション側の接続ライブラリ・フレームワークが8.4に対応しているかの確認。MySQL 8.4では認証プラグインの既定値変更や非推奨機能の削除など、8.0との互換性差分が公式に告知されています。特に古いライブラリで接続しているアプリは要注意です
2. 検証環境での試験:本番のスナップショットから複製を作り、8.4に上げた状態でアプリの主要機能とバッチを回す。AWS公式も「スナップショットから復元した複製で安全に試験する」手順を案内しています。本番でいきなり上げるのは論外です
3. 停止時間の設計:通常のインプレースアップグレードは停止を伴います。停止許容時間が短いシステムでは、RDSのBlue/Greenデプロイのような切り替え方式の採用をベンダーと検討してください
4. 切り戻し計画:アップグレード直前のスナップショット取得、失敗時に誰の判断で・何分以内に・どの状態へ戻すかの合意。切り戻し計画の書面化を渋るベンダーには任せるべきではありません
5. 完了確認:アップグレード後、Extended Support課金行が消えたことを翌月の請求で確認して初めて完了です

一方で、Extended Supportをあえて短期利用するのが合理的なケースもあります。判断を「課金=悪」と単純化しないことが重要です。

• 数カ月以内にシステム自体の刷新・移行が確定している場合:廃止予定のシステムに検証コストをかけて8.4へ上げるより、数カ月分のExtended Support費用を払って計画通り移行する方が総コストは安くつきます
• 繁忙期を避けたい場合:小売・教育・会計など、事業の繁忙期にDB作業をぶつけるリスクを取るより、閑散期まで2〜3カ月を延長サポートで買う判断は健全です
• アプリ側の対応改修に時間がかかる場合:互換性調査の結果、アプリ改修が必要と判明したなら、改修完了までの橋渡しとして使うのが本来の用途です

逆に不合理なのは、「判断していないので結果的に払い続けている」状態です。同じ支出でも、期限と出口(いつ・何に移行して課金を止めるか)を決めた上での支払いと、無自覚な垂れ流しは経営上まったく別物です。3年目の単価倍増と、3年後の強制アップグレードという出口が公式に確定している以上、先送りのコストは時間とともに確実に上がります。

独自視点⑤:発注側が「マネージドサービスのEOL台帳」を持つべき理由

今回のMySQL 8.0は氷山の一角です。RDSの他エンジン(PostgreSQL等)にも同じExtended Supportの仕組みと期限が存在し、OSやフレームワーク、SaaSのAPIバージョンまで含めれば、企業のシステムは常に何かしらのサポート期限に囲まれています。実際、直近ではMySQL 5.7のExtended Supportが2026年3月からすでに3年目の倍額単価に入っており、5.7を放置してきた企業は今まさに倍額を払っています。次は8.0で同じことが繰り返されるだけです。

だからこそ提案したいのが、発注側(自社)がEOL台帳を持つことです。ベンダー任せにせず、A4一枚のスプレッドシートでよいので、次の列を持つ台帳を作ってください。

ポイントは「対応方針」と「判断期限」を空欄にしないことです。台帳の目的は網羅ではなく、期限の1年前に必ず一度、経営判断の机に載せる仕組みを作ることにあります。年に一度、保守ベンダーとの定例でこの台帳を更新するだけで、今回のような「請求書で初めて知る」事態はほぼ防げます。ベンダーへの発注力という意味でも、EOL台帳を持っている発注者は「分かっている客」として扱われ、提案の質が変わります。

よくある質問(FAQ)

Q1. 自社がRDS for MySQL 8.0を使っているか、どう確認すればよいですか?

A. AWSコンソールのRDS画面で、インスタンス一覧の「エンジンバージョン」列を見れば分かります。自社でコンソールに入れない場合は、開発・保守ベンダーに「RDSインスタンスの一覧と、各エンジンバージョン・vCPU数・Multi-AZ有無」を依頼してください。CLIが使えるなら aws rds describe-db-instances で一覧化できます。

Q2. 8月1日にすぐ何かが壊れたり、止まったりしますか?

A. いいえ。AWS公式によれば、Extended Supportへの自動登録はデータベースエンジンを変更せず、稼働や性能にも影響しません。壊れるのではなく、課金が始まるだけです。だからこそ気づきにくい、というのが本稿の主題です。

Q3. Extended Supportの料金は具体的にいくらですか?

A. エンジン・リージョン・経過年数で決まるvCPU時間課金です。執筆時点でMySQL 8.0の東京リージョン単価は公式料金データに未掲載ですが、同リージョンの既存Extended Support単価は1〜2年目0.120USD/vCPU時・3年目0.240USD/vCPU時で確認できています。仮に同水準なら、2vCPUのMulti-AZ構成で月約350USDが目安です。必ずAWS公式料金ページで最新単価を確認してください。

Q4. アップグレードすればすぐ課金は止まりますか?

A. はい。AWS公式は、標準サポート対象バージョンへのアップグレード完了日、またはデータベース削除の時点で課金が自動的に止まると明記しています。月の途中でも日割り(時間割)で止まります。

Q5. MySQL 8.4に上げれば、次はいつまで安心ですか?

A. RDS for MySQL 8.4の標準サポート終了日は2029年7月31日です。約3年の猶予がありますが、「上げて終わり」ではなく、EOL台帳に次の期限として記録し、2028年中に次の判断をする前提で計画してください。

Q6. ベンダーから何の連絡もありませんでした。契約違反ではないですか?

A. 契約にEOL管理・通知義務の条項が無ければ、法的にはベンダーの義務違反とは言いにくいのが実情です。多くの保守契約でバージョンアップは範囲外だからです。責任追及よりも、次回更新時にEOL管理を役務へ明記する交渉材料として使う方が建設的です。

GXOに相談すべきタイミング

この件は、AWSの操作の話ではなく「保守体制と発注側の統制」の話です。次のいずれかに当てはまるなら、ベンダーと利害関係のない第三者を一度入れる価値があります。

• RDSのバージョン一覧を依頼しても即答が返ってこない。あるいはAWSアカウントがベンダー名義で、請求の中身が自社から見えない
• ベンダーからアップグレードの見積もりが出てきたが、金額・停止時間・切り戻し計画の妥当性を自社で判断できない
• MySQLに限らず、自社システム全体のEOL・保守・クラウドコストを棚卸しした台帳が存在しない

GXOは開発会社ですが、この種の相談ではまず「今の構成と契約のどこにリスクと無駄があるか」の整理から入ります。既存システムの現状把握とEOL・コスト面の棚卸しはシステム・DX基盤の現状診断と再構築支援で、AI活用も含めた投資優先度の第三者評価はAI・システム投資のアセスメントで対応しています。ベンダーの見積もりが適正かどうかを判断したい場合は、開発・改修見積もりのセカンドオピニオンとして金額と作業範囲の妥当性を確認することもできます。

8月の請求書で「Extended Support」の行を見つけてから慌てるのではなく、7月のうちに一覧化と方針決定まで済ませておくのが理想です。自社だけで判断しきれない場合は、お問い合わせから現状をお知らせください。状況の整理だけでも判断材料になるはずです。

参考文献

• AWS公式ドキュメント「MySQL on Amazon RDS versions」
• AWS公式ドキュメント「Amazon RDS Extended Support with Amazon RDS」
• AWS公式ドキュメント「Amazon RDS Extended Support charges」
• AWS公式ドキュメント「Overview of Amazon RDS Extended Support」
• AWS公式「Amazon RDS for MySQL Pricing」
• AWS Price List API(AmazonRDS・ap-northeast-1)