こんにちは。SCSKのすぐろです。
AWSを利用していて、Amazon RDSの利用料に見覚えのない「RDS Extended Support」という項目が計上されていたことありませんか？
「延長サポートって何？」「なぜ発生するの？」「止められるの？」「事前に気づく方法はあるの？」 などの疑問について、AWS公式ドキュメントの記載を根拠にしながら整理してみました。
まず結論
| 疑問 | 回答 |
|---|---|
| 延長サポートとは何か | メジャーバージョンの標準サポート終了後も、有料で引き続きそのバージョンを使い続けられる仕組み |
| なぜ発生するのか | 対象バージョンのまま標準サポート終了日を迎えると、明示的な無効化操作をしない限り自動的に有効化・課金される |
| 回避できるか | できる。標準サポート終了日より前にサポート対象バージョンへアップグレードしていれば発生しなかった |
| すぐ止められるか | 止められる。EngineLifecycleSupportパラメータの変更、またはサポート対象バージョンへのアップグレードのいずれかで登録解除できる |
| いくらかかるか | vCPU数×稼働時間×単価で決まる。インスタンスの規模・台数が多いほど影響が大きくなる |
| 事前に気づけるか | 気づける。AWS Healthの「Planned Lifecycle Events」として最低180日前を目標に通知される設計になっている |
| 見落とさないためには | AWS User NotificationsでHealthイベント通知を事前に設定し、気づく仕組みを用意する |
以下では、それぞれの疑問について順番に見ていきます。
RDS Extended Support（延長サポート）とは何か
RDS Extended Supportは、RDSのメジャーエンジンバージョン（例: MySQL 8.0）が「RDS標準サポート終了日」を過ぎた後も、 そのバージョンを有料で使い続けられる仕組みです。
どんな仕組みか
出典: Amazon RDS Extended Support with Amazon RDS
“RDS Extended Support allows you to continue running a database on a major engine version past the RDS end of standard support date for an additional cost.”
延長サポートに登録されている間、AWSは重大なセキュリティ問題・バグに対するパッチを提供し続けます。
“RDS Extended Support provides the following updates and technical support: Security updates for critical and high CVEs for your DB instance or DB cluster, including the database engine / Bug fixes and patches for critical issues / The ability to open support cases…”
言い換えると、「本来ならサポートが切れて何の保証もなくなるはずの古いバージョンを、お金を払うことでもう少し使い続けられるようにする」ための仕組みです。
なぜこの仕組みが必要なのか
MySQLなどのエンジンは、オープンソースコミュニティ側で「このバージョンはもうサポートしません（End of Life）」という期限が決まっています。 この期限が来ると、コミュニティからのバグ修正・セキュリティパッチの提供が止まります。AWSはこれに合わせて「RDS標準サポート終了日」を設定しており、 この日を境にRDS側でも標準サポートが終了します。
延長サポートは、このタイミングで新しいバージョンへすぐに移行できない利用者のための「移行までの猶予期間」を有料で提供するものです。
なぜ延長サポート費用が発生するのか
延長サポートは、明示的に無効化しない限り、標準サポート終了日をもって自動的に有効化され、課金が始まります。利用者が能動的に申し込む契約ではありません。
出典: Overview of Amazon RDS Extended Support
“After the RDS end of standard support date, if you didn’t disable RDS Extended Support during the creation or restoration of your DB instances and DB clusters, then Amazon RDS will automatically enroll them in RDS Extended Support.”
出典: Amazon RDS Extended Support with Amazon RDS（MySQL 5.7の実例として記載）
“Amazon RDS automatically enrolls your databases in RDS Extended Support on February 29, 2024… Starting March 1, 2024, Amazon RDS automatically charges you for RDS Extended Support.”
つまり、「対象のメジャーバージョン（MySQL 8.0等）を使ったまま標準サポート終了日を迎えた」というだけで、何らかの申し込み操作をしなくても自動的に課金対象になります。 これが、気づかないうちに費用が計上されてしまう理由です。
この費用は回避できるのか
できます。 標準サポート終了日より前に、サポート対象の新しいメジャーバージョンへアップグレードを完了すれば、延長サポートへの登録自体が発生しません。
出典: Overview of Amazon RDS Extended Support
“If you upgrade to an engine that’s still under RDS standard support before the RDS end of standard support date, Amazon RDS won’t enroll your engine in RDS Extended Support.”
今すでに課金されている場合、止める方法はあるか
止められます。方法は2つあります。
出典: Overview of Amazon RDS Extended Support
“You can end enrollment in RDS Extended Support at any time. To end enrollment, you can change the EngineLifecycleSupport parameter using the AWS CLI or RDS API.”
“You can also upgrade each enrolled engine to a newer engine version that’s still under RDS standard support to end enrollment. The end of RDS Extended Support enrollment becomes effective the day that you complete an upgrade to a newer engine version that’s still under RDS standard support.”
- 方法1:
EngineLifecycleSupportパラメータをAWS CLIまたはRDS APIで変更する - 方法2: サポート対象の新しいメジャーバージョンへアップグレードする（アップグレード完了日をもって登録解除が有効になる）
ここで注意したいのが、方法1は「課金だけ止めて古いバージョンをそのまま維持する」手段ではないという点です。 標準サポート終了日を過ぎた後に方法1で無効化すると、次のように自動的に新しいメジャーバージョンへアップグレードされます。
出典: Amazon RDS Extended Support with Amazon RDS
“If you disable the enrollment status of a DB instance or DB cluster that is already past its standard support end date, the instance or cluster automatically upgrades to the next supported major version.”
つまり、標準サポート終了後は「延長サポートに加入して古いバージョンを有料で維持する」か「アップグレードする」かの二択で、 「無料のまま古いバージョンをサポートなしで動かし続ける」という第3の選択肢はありません。
逆に言えば、延長サポートに加入したまま新しいメジャーバージョンへアップグレードしない限り、延長サポートの課金は継続します。
出典: Amazon RDS and customer responsibilities with Amazon RDS Extended Support
“You’re also responsible for upgrading your engine to a newer engine version before the RDS end of Extended Support date.”
“If you don’t upgrade your engine, then after the RDS end of Extended Support date, Amazon RDS will attempt to upgrade your engine to a newer engine version that’s supported under RDS standard support. If the upgrade fails, then Amazon RDS reserves the right to delete the DB instance or Multi-AZ DB cluster that’s running the engine past the RDS end of standard support date.”
延長サポート自体にも期限があり、標準サポート終了日から最長3年間までとされています。3年を過ぎてもアップグレードしていない場合、AWSが強制的にエンジンをアップグレードします。
“RDS Extended Support is available for up to 3 years past the RDS end of standard support date for a major engine version. After this time, if you haven’t upgraded your major engine version to a supported version, then Amazon RDS will automatically upgrade your major engine version.”
責任の分担: AWS側はパッチ・バグ修正の提供までが責務であり、バージョン管理の計画立案・実行（期限内のアップグレード）は利用者側の責任と明記されています。アップグレードを「AWSが自動でやってくれる」ものと捉えてはいけません。
どのくらいの費用が発生するのか
延長サポートの料金は、インスタンスのvCPU数と稼働時間に比例して発生します（プロビジョニング型インスタンスの場合）。 たとえば2 vCPUのインスタンスを1台、1ヶ月（744時間）フル稼働させた場合、
2 vCPU × 744時間 × $0.12/vCPU時間 = 約$178.56/月
対象インスタンスが2台であれば、単純に2倍（約$357/月）になります。アップグレードを行わない限りこの課金が毎月継続するため、年間では数千ドル規模になり得ます。 vCPU数が多いインスタンスタイプほど、またインスタンス台数が多いほど、影響は大きくなります。
実際の金額は、対象インスタンスのvCPU数・台数・稼働時間・適用年次（延長サポートは年次が進むほど単価が上がる場合があります）によって変動するため、自分の環境のインスタンス構成に当てはめて見積もる必要があります。
事前に気づく方法はあるか
あります。 この種の終了予定は、AWS Healthの「Planned Lifecycle Events（計画されたライフサイクルイベント）」という正式なカテゴリで事前に通知される設計になっています。
出典: Planned lifecycle events for AWS Health
“Open source software end of support – Some AWS services run open source versions of software. If the open source community ends support for software versions, then AWS informs you when you need to take action to upgrade and avoid impact to your applications. Amazon RDS for MySQL engine version end of support“
通知のリードタイムも明記されています。
“Planned lifecycle events are designed to have a minimum lead time of 180 days for major versions/changes and 90 days for minor versions/changes, where possible.”
メジャーバージョンの変更は、最低180日前を目標に通知されます。この種のイベントは、AWS Health Dashboard（Calendar view / Affected resources view）、Amazon EventBridge、AWS Health APIのいずれでも確認できます。
実際に発行されるHealthイベントには、以下内容がすべて明記されていました。
- 延長サポート課金が発生する条件（標準サポート終了日までに未アップグレードの場合、翌日から自動課金開始）
- 回避する方法（標準サポート終了日までのメジャーバージョンアップグレード）
- 回避しなかった場合の挙動（定期メンテナンス時間中にAWSが延長サポートのマイナーバージョンへ強制アップグレードし、課金を開始）
- 延長サポートの単価（vCPU単位の時間課金）
- 課金が終了する条件（新しいメジャーバージョンへのアップグレード完了まで継続）
このHealthイベントを確認すれば、「何もしなければ課金される」「いつまでに何をすれば回避できるか」の両方が判断可能な状態となります。つまり、事前に気づく仕組みそのものは用意されていました。
見落とさないためにどうすればいいか
課題は「通知が来ること」ではなく、「その通知に気づけるか」です。 AWS Health Dashboardは、該当イベントの有無を都度コンソールにログインして確認する必要があり、多数のアカウント・多数のリソースを運用している場合、見落としなく目視で確認し続けるのは現実的ではありません。 180日という十分なリードタイムが用意されていても、確認を怠れば実質的に意味がなくなります。
これを解決する方法として、AWS User NotificationsでAWS Healthイベントの通知を事前に設定しておくのが有効です。
どんな仕組みか
出典: Manage AWS Health notifications in AWS User Notifications
“AWS managed notifications in AWS User Notifications lets you receive and manage notifications about events that affect your AWS accounts and services. When you use AWS managed notifications in AWS User Notifications, you can specify which AWS Health event categories to receive, set up organizational view for emails, and get consolidated notifications instead of multiple similar emails.”
設定方法
“To configure your AWS managed notifications subscription, complete the following steps: Open User Notifications in the AWS Management Console. In the navigation pane, choose AWS managed notifications subscriptions. You can manage your AWS Health event notifications by category.”
通知の受信先として、メール・チャット・AWS Console Mobile Applicationへのプッシュ通知を選択できます。
“You can choose the following additional channels to receive your AWS Health events through AWS User Notifications: Email / Chat / Push notifications to the AWS Console Mobile Application”
メリット
- コンソールに毎回ログインして確認する手間がなく、メールやチャットで能動的に気づける
- イベントカテゴリ単位で通知の種類を選べる
- Health Dashboardに比べて設定がシンプル
デメリット
- 通知の詳細度はAWS Health本体のツールに比べると簡易的
- 影響を受けるリソースIDや状態（PENDING/RESOLVEDなど）の正確な追跡には別のツールが必要
出典: 同ページの注記より
“While these notifications aren’t as detailed as direct AWS Health tools, they provide an effective way to notify stakeholders of issues and changes… it’s a best practice to use one of the following AWS Health tools: The AWS Health API / The aws.health source in Amazon EventBridge / The Health Dashboard”
つまり、User Notificationsは「気づくきっかけ」として設定し、詳細な対応状況の追跡はAWS Health Dashboard等で行う、という役割分担が適切と考えられます。
おすすめのユースケース
1アカウントのみ利用している場合でも、コンソールに毎回ログインして確認する手間を省けるため、メール等での通知受け取りはおすすめです。加えて、多数のアカウント・リソースを運用していて、Health Dashboardを都度確認する運用が現実的でない場合にも効果を発揮します。 特にRDSのようなメジャーバージョンのEOL（End of Life）は、気づかないまま時間が経つと延長サポート費用という形で確実にコストに跳ねてくるため、能動的に通知を受け取る仕組みを用意しておくのがおすすめです。
まとめ
- RDS Extended Supportは、メジャーエンジンバージョンの標準サポート終了後も有料で使い続けられる仕組みで、申し込みなしに自動で有効化・課金される点に注意が必要です
- 標準サポート終了日より前にサポート対象バージョンへアップグレードしていれば、延長サポートへの登録自体を回避できます
- 標準サポート終了後は「延長サポートに加入して古いバージョンを有料で維持する」か「アップグレードする」の二択で、無料のまま古いバージョンを動かし続ける選択肢はありません
- 課金はvCPU数×稼働時間×単価で決まり、インスタンスの規模・台数が多いほど影響が大きくなります。アップグレードが完了するまで課金は継続します
- AWS Healthの「Planned Lifecycle Events」として最低180日前を目標に事前通知される設計になっています
- AWS User Notificationsであらかじめ受信チャネル（メール・チャット・モバイルプッシュ）を設定しておくことで、Health Dashboardを都度確認しなくても能動的に気づける仕組みを作れます
AWS Healthは余裕をもって発行されるので、事前の検知と準備をしっかりしたいですね。
AWS User Notificationsは比較的簡単に設定できますので、まだ未設定の方はぜひ設定し、ご利用中のAWSアカウントに関する通知を受け取れるようにしてみてください！