一家跨境電商平台在業務快速成長時，遇到了資料庫效能瓶頸。他們最初使用AWS RDS MySQL，在大促期間頻繁出現延遲飆升和連接逾時。遷移到Aurora MySQL 後，讀取效能提升了5 倍，故障切換時間從數分鐘縮短到了30 秒以內，資料庫運作成本也降低了約40%。
但這並不意味著Aurora 適合所有場景。對於月訪問量不高的中小型應用，RDS 的成本優勢更為明顯。
AWS RDS 和Aurora 都是AWS 託管關係型資料庫服務，但架構差異顯著，選擇哪一個直接影響你的效能上限、成本結構和運作複雜度。
RDS 與Aurora 的核心架構差異
AWS RDS
RDS（Relational Database Service）是AWS 提供的傳統託管資料庫服務，支援以下引擎：
- MySQL
- PostgreSQL
- MariaDB
- Oracle
- Microsoft SQL Server
RDS 本質上是在EC2 執行個體上託管了資料庫引擎，儲存層使用EBS 磁碟區。計算和儲存是耦合的。
AWS Aurora
Aurora 是AWS 自我開發的雲端原生關係型資料庫，相容於MySQL 和PostgreSQL。它對底層架構進行了徹底重新設計：
- 計算與儲存分離：儲存層獨立於資料庫實例，自動擴展，最大128TB
- 六副本冗餘存儲：資料自動跨3 個可用區寫入6 個副本
- 分散式Redo Log：只傳輸日誌而非資料頁，大幅降低寫入放大
- 快速故障恢復：不依賴Redo Log 回放，實例重啟速度極快
全面對比：八個關鍵維度
1. 性能
| 維度 | RDS MySQL/PostgreSQL | Aurora MySQL/PostgreSQL |
|---|---|---|
| 寫入吞吐量 | 標準EBS 限制 | 比標準MySQL 高5× |
| 讀取擴充 | 最多5 個唯讀副本 | 最多15 個低延遲唯讀副本 |
| 副本延遲 | 通常秒級 | 通常毫秒（< 100ms） |
| 連接並行 | 受實例規格限制 | 可搭配RDS Proxy 大幅提升 |
結論：高並發、讀多寫少場景，Aurora 效能優勢顯著。
2. 可用性與故障轉移
| 維度 | RDS 多可用區部署 | Aurora |
|---|---|---|
| 故障轉移時間 | 60–120 秒 | 通常< 30 秒 |
| 儲存冗餘 | 主實例+ 同步備份 | 跨3 AZ 的6 副本自動寫入 |
| 資料持久性 | 高 | 極高（6 副本容許2 副本同時故障） |
| Serverless 選項 | 無 | Aurora Serverless v2 支持 |
結論：對於SLA 要求高的生產環境，Aurora 提供更強的高可用保障。
3. 成本
| 維度 | RDS | Aurora |
|---|---|---|
| 實例費用 | 較低（如db.t3.medium ≈ 0.068/小時）|約為同規格𝑅𝐷𝑆的20|存儲費用|0.115/GB/月（gp2） | 0.10/𝐺𝐵/月（自動擴展）||𝐼𝑂費用|無（包包含在存儲中）|標準模式按請求計費（0.20/百萬次） |
| 備份費用 | 超出備份視窗部分計費 | 100% 備份免費存儲 |
| Aurora I/O Optimized | 不適用 | 可選，高IO 場景省40% |
成本關鍵點：
- 低流量應用（如IO 請求< 100 萬次/天）：RDS 成本更低
- 高IO 應用（如電商、SaaS）：Aurora I/O Optimized 套餐可能更划算
- 間歇性負載：Aurora Serverless v2 以實際ACU 計費，彈性節省明顯
4. 擴展性
| 維度 | RDS | Aurora |
|---|---|---|
| 縱向擴展 | 需停機或短暫中斷 | 儲存無需操作，實例擴充中斷更短 |
| 橫向讀取擴展 | 最多5 個唯讀副本 | 最多15 個唯讀副本，延遲更低 |
| 自動擴充存儲 | 支援（Auto Scaling） | 原生支持，自動擴充至128TB |
| Serverless | 僅Aurora | Aurora Serverless v2 |
5. 相容性
| 維度 | RDS | Aurora |
|---|---|---|
| 引擎支援 | MySQL、PostgreSQL、MariaDB、Oracle、SQL Server | MySQL 和PostgreSQL（相容模式） |
| Oracle/SQL Server 遷移 | 直接遷移，無程式碼改動 | 不支援 |
| 與現有程式碼相容 | 完全相容 | 絕大多數相容，少數高級特性存在差異 |
結論：如果你使用Oracle 或SQL Server，只能選RDS。
6. 備份與復原
| 維度 | RDS | Aurora |
|---|---|---|
| 自動備份保留期 | 最長35 天 | 最長35 天 |
| 時間點恢復（PITR） | 支援 | 支持，恢復速度更快 |
| 快照恢復時間 | 與資料量正相關（較慢） | 幾乎即時（儲存層快照） |
| 回溯功能（Backtrack） | 不支援 | 支援（MySQL 相容版），可回溯到過去72 小時任意時刻 |
Aurora Backtrack 是什麼？
在Aurora MySQL 上，Backtrack 功能允許你直接將資料庫」回撥」到過去某個時間點，而無需從備份重建。這對於誤刪資料、誤操作的快速復原非常有價值，是RDS 不具備的核心優勢。
7. 監控與維
兩者都與CloudWatch、Enhanced Monitoring、Performance Insights 深度整合。差異不大，Aurora 額外提供：
- Aurora 全域資料庫（Global Database）：跨區域主從複製，延遲< 1 秒
- Aurora 機器學習集成：原生支援調用SageMaker / Comprehend
- 平行查詢（Parallel Query）：大數據量分析查詢加速
8. 遷移難度
| 方向 | 難度 | 工具 |
|---|---|---|
| RDS MySQL → Aurora MySQL | 低 | 快照導入，幾乎無程式碼改動 |
| 自建MySQL → Aurora | 中 | DMS（Database Migration Service） |
| RDS Oracle → Aurora PostgreSQL | 高 | SCT + DMS，需要程式碼改造 |
| Aurora → 自建MySQL | 中 | mysqldump 或binlog 同步 |
選型決策框架
根據以下問題，判斷你該選RDS 還是Aurora：
選Aurora 的訊號：
- 月活躍用戶> 10 萬，或QPS > 1000
- 需要< 30 秒的自動故障轉移
- 使用MySQL 或PostgreSQL，並有擴展計劃
- 需要多達15 個唯讀副本
- 有跨區域災備需求（Aurora Global Database）
- 負載波動大，考慮使用Aurora Serverless v2
選RDS 的訊號：
- 使用Oracle 或SQL Server（Aurora 不支援）
- 業務規模較小，預算敏感，IO 量低
- 需要特定資料庫引擎版本或進階特性（如Oracle RAC）
- 團隊已有RDS 使用經驗，無效能瓶頸
一句話總結
如果你用MySQL 或PostgreSQL，且業務在成長－優先考慮Aurora；如果你用Oracle/SQL Server，或業務規模較小－選RDS。
遷移從RDS 到Aurora 的步驟
如果你目前在使用RDS MySQL/PostgreSQL，想遷移到Aurora，整體流程如下：
方式一：快照遷移（適合可接受短暫停機）
先對RDS 實例建立快照，在快照復原介面選擇」恢復為Aurora 叢集」。修改套用連線字串後切換流量，停機時間通常在30 分鐘以內。
方式二：使用DMS 零停機遷移（適合生產環境）
啟用RDS 實例的binlog，建立DMS 複製實例，配置全量遷移任務同步資料。全量完成後啟用增量CDC 同步，等待延遲歸零後將應用連接字串切換到Aurora，整個過程對使用者無感知。
成本估算範例
以下以一個典型的B2B SaaS 應用為例（ap-southeast-1 新加坡區域，db.r6g.large）：
| 專案 | RDS MySQL | Aurora MySQL |
|---|---|---|
| 實例費用/月 | ~138| 166 | |
| 儲存（500GB）/月 | ~58| 50 | |
| IO 費用（500萬次/天）/月 | 包含 | ~30（標準模式）||備份存儲/月| 10 |
| 合計/月 | ~206∗∗|∗∗ 246 |
Aurora 在此場景下溢價約20%，但換來了5× 效能提升+ 更強高可用。若啟用I/O Optimized 模式（+25% 實例費，免IO 計費），高IO 場景下Aurora 總成本可能反而低於RDS。
結語：沒有最好，只有最合適
RDS 和Aurora 都是優秀的託管資料庫服務，核心差異在於：
- RDS：更廣泛的引擎支援+ 更低的基礎成本，適合標準化、中小規模場景
- Aurora：更高效能+ 更強高可用+ 雲端原生彈性，適合高並發和快速成長的生產系統
對於出海企業來說，如果你已經在使用MySQL，隨著業務成長，Aurora 幾乎是必然的升級方向。
🔧 免費取得AWS 資料庫架構評估
AWS-onCloudAI 提供專業的雲端資料庫選項諮詢，包括：
- 現有RDS/Aurora 配置審查
- 遷移成本與風險評估
- 高可用架構設計方案
👉 訪問 aws-oncloudai.com 預約免費架構諮詢
本文由AWS-onCloudAI 雲端架構團隊撰寫，專注於協助中國出海企業利用AWS 建構高可用、低成本的雲端基礎架構。
