AWS 把 MySQL 5.7 延長支援拉到 2029 年 6 月底：多出兩年多，價格不再往上加

一句話看懂：AWS 把 RDS 與 Aurora 上 MySQL 5.7 的「延長支援」從 2027 年 2 月底延到 2029 年 6 月底，官方說這次延長沒有漲價，但它仍然是付費續命，不是不用升級。

先用白話講：延長支援是什麼？

想像你住在一棟老公寓，管委會原本說「2027 年 2 月底以後，就不再派人來修水電了」。現在管委會改口：可以繼續修到 2029 年 6 月底，修繕費也沒有再加價。但是，公寓還是老公寓，只修最嚴重的問題，不會幫你裝新設備。

RDS 是 AWS 幫你代管資料庫的服務，Aurora 是 AWS 自家改良、相容 MySQL 的資料庫。MySQL 5.7 是很舊的版本，RDS 上它的標準支援在 2024 年 2 月 29 日就結束了（官方文件寫的）。過了這個日子還想繼續用，就得靠「RDS 延長支援（Extended Support）」：付一筆額外費用，AWS 繼續幫你補安全漏洞。

發生什麼事

AWS 在 6 月 17 日的 What’s New 公告：

• 範圍：Aurora MySQL 第 2 版（相容 MySQL 5.7）與 RDS for MySQL 5.7
• 新的結束日：2029 年 6 月 30 日，原本是 2027 年 2 月 28 日（自行換算，多出約 2 年 4 個月）
• 價格：公告說這次延長沒有漲價，延長期間繼續付「第 3 年價格」，具體金額請看 Aurora 與 RDS for MySQL 的價格頁，公告本身沒有列數字
• 內容：高風險與嚴重等級 CVE 的安全修補、嚴重問題的錯誤修正，以及在標準 SLA 內使用 AWS Support
• 地區：所有提供 Aurora MySQL 與 RDS for MySQL 的 AWS 區域

別把它當成「不用升級」

上表整理自官方文件與公告對延長支援內容的描述。

另外有一個容易踩到的設定：官方文件寫明，已經過了標準支援日的資料庫，如果把延長支援的登記關掉，系統會自動把它升級到下一個受支援的主要版本。所以關閉前，要先確認應用程式在新版本上測試過。

還有一個小地方：我讀到的 RDS 使用者指南頁面，目前仍寫「延長支援最多提供標準支援結束後 3 年」，與這次公告延到 2029 年的說法不一致。可能是文件還沒同步，這部分以 6 月 17 日的公告為準，日期也建議對照各引擎的支援日期頁面。

給開發者的技術細節

• 升級目標：官方建議升到 MySQL 8.0 或 8.4 相容版本
• 升級方式：官方列了三種，Blue/Green Deployments（先在旁邊建一套新版環境，測完再切換）、原地升級（in-place upgrade）、快照還原（snapshot restore）
• 登記狀態：可以在資料庫建立或還原時登記，也能隨時用 AWS CLI 或 RDS API 修改 EngineLifecycleSupport 參數，變更立即生效、不會停機
• 建議流程：先用快照還原出一份測試環境，把應用程式的完整測試跑過，再安排正式切換。MySQL 5.7 升到 8.x 常見要注意驗證外掛、保留字與 SQL 模式的差異，這是一般升級經驗，不是公告內容

我的看法

接案時很常遇到客戶的老系統，資料庫掛在雲端、版本很舊，沒人敢動。多了兩年多的緩衝，對這種情況確實是好消息，至少不會有「期限逼近就得被迫在年底前趕工」的壓力。

但我會把這段時間當成「排升級」的時間，而不是「可以不升級」的許可。延長支援還是每個月在花錢，又只補最嚴重的漏洞，拖越久，後面要跨的版本差距越大、測試越痛苦。比較實際的做法是：先用快照開一份測試環境跑一輪，估出工時，再跟客戶談預算。

名詞小辭典

• RDS（Relational Database Service）：AWS 代管關聯式資料庫的服務，備份、修補、故障轉移由 AWS 處理。
• Aurora：AWS 自家設計的資料庫引擎，相容 MySQL 與 PostgreSQL，常用在需要高可用的系統。
• CVE：公開的資安漏洞編號，每個漏洞都有一個，方便大家對照修補狀況。
• Blue/Green Deployments：先建一套新版環境（綠），驗證完再把流量從舊環境（藍）切過去的升級方式，出問題時比較好回頭。

資料來源

• AWS What’s New（2026-06-17）
• Amazon RDS User Guide：RDS Extended Support