雲端資料庫
全託管資料底座：Aurora 與 DynamoDB 深度解析
全託管資料底座：Aurora 與 DynamoDB 深度解析
在 AWS 上做後端，資料庫這一格幾乎都會落到 Aurora 或 DynamoDB 身上。很多團隊是憑印象選的：習慣寫 SQL 就選 Aurora，聽說要能扛就選 DynamoDB。
但這兩個東西根本不是同一種設計。看懂它們各自把哪一塊「拆開」，選型就不必再靠感覺。這篇從架構講到判斷準則，最後給一張對照表。
你將學到什麼
Aurora 的核心
運算執行個體與儲存層分離，資料放在跨可用區的叢集磁碟區，加減執行個體不必複製資料。
副本怎麼來的
讀取副本直接掛上同一份共用磁碟區，所以開得快，故障轉移時副本也已經有資料。
DynamoDB 的模型
先想清楚存取路徑再設計分割鍵，讓負載能被攤平，才拿得到穩定的高併發表現。
怎麼選
看三件事：資料關係複雜嗎、查詢路徑固定嗎、流量會不會突然暴衝。
「全託管」指的是一份很具體的責任切割：備份、修補、故障轉移、儲存擴充交給雲端，你留下來管的是資料模型、索引與查詢。
看懂這條線，你就會發現 Aurora 與 DynamoDB 的差別不在「誰比較快」，而在它們各自把哪一塊拆開來交出去。Aurora 拆的是儲存，DynamoDB 拆的是整台伺服器。
Aurora 的關鍵設計：運算與儲存分開
傳統資料庫的執行個體與它的磁碟是綁在一起的，換一台機器就得把資料搬一次。Aurora 把這層綁定拆開了。
AWS 官方文件的說法是：Aurora 的資料存放在叢集磁碟區，那是一個單一的虛擬磁碟區，由跨三個可用區的資料副本組成，複製份數與叢集裡有幾台執行個體無關。
這個設計會直接改變你的維運手感。文件明講：新增一台執行個體很快，因為 Aurora 不會再複製一份表格資料，它只是把新機器接上那份已經存在的共用磁碟區。
磁碟區本身也會隨資料量自動長大，刪掉資料時配置的空間會跟著縮回去。你不需要提前猜要開多大。
副本與跨可用區：為什麼故障轉移比較快
因為資料副本本來就已經存在其他可用區，所以某個可用區出事時，其他區的執行個體可以繼續服務請求，不需要臨時把資料搬過去。這是共用儲存架構順帶換來的好處。
- 讀取副本：掛在同一份叢集磁碟區上，開得快、關得也快，適合把報表與後台查詢從主寫入分流出去。
- 跨可用區的副本：由儲存層負責，與你開幾台執行個體無關，屬於架構自帶而不是你要配置的東西。
- 跨區域：需要跨 AWS 區域的災難備援或就近讀取時，才會走到 Aurora Global Database 這一層。
Aurora 叢集會給你寫入端點與讀取端點兩組位址。很多團隊全部接寫入端點，於是副本開了也沒人用。把唯讀查詢改接讀取端點，通常是最便宜的一次效能改善。
Aurora 的三種引擎與無伺服器模式
截至 2026 年 8 月，AWS 官方文件把 Aurora 描述為由三種引擎組成：PostgreSQL、MySQL 與 DSQL。前兩者提供開源相容介面，既有應用與工具多半不必改寫。
另一個常被問到的是 Aurora Serverless v2。它讓運算容量隨負載自動伸縮，適合流量起伏大或環境很多的情況，代價是你要接受容量變動帶來的行為差異。
Aurora DSQL 則是另一條路線。官方頁面把它定位為無伺服器的分散式 SQL 資料庫，採主動主動的分散式架構，讓多個區域都能讀寫並保持強一致，且不需要分片。
這一塊變動很快。DSQL 於 2025 年正式上線後仍在持續擴充區域與功能，Serverless v2 的平台版本也在更新。動手前請看 AWS 官方的服務頁與區域支援表，不要照抄任何教學文章裡的清單。
DynamoDB：把資料模型換成存取路徑
DynamoDB 是全託管的鍵值與文件資料庫。官方說明強調它沒有伺服器要佈建、修補或管理，也沒有軟體要安裝維護，這句話決定了它的使用方式。
它的效能來源是分割。每一筆項目由分割鍵決定落在哪一份分割上，設計得好，負載會被攤平；設計得差，所有請求擠向同一個鍵，再多容量也救不了。
- 先列出應用真正會發的查詢，不要先畫表格關係圖。
- 從查詢反推分割鍵與排序鍵，讓每一種查詢都能靠鍵直接命中。
- 剩下那些用主鍵撈不到的查詢，才交給全域次要索引處理。
- 掃描整張表是最後手段，不是日常做法。
容量有兩種模式。隨用隨付適合尖峰難預測、或會長時間沒有流量的工作負載；佈建容量適合流量穩定、可以事先算清楚的情況。
周邊能力也值得一提：DynamoDB Streams 提供變更資料擷取，可以把寫入事件推給後續流程；另外還有 TTL 自動清除過期項目與時間點還原。
AWS 在 2026 年 8 月 5 日宣布 DynamoDB 原生向量搜尋正式上線，可以把向量嵌入與其他欄位存在同一筆項目裡並即時查詢，常見用途是檢索增強生成與推薦。這代表「營運資料庫」與「向量庫」不一定要是兩套系統，但是否適合你的場景仍要實測，細節以官方公告為準。
選型：三個問題就能分出來
不要從「哪個比較強」開始問，那沒有答案。改成問這三題，多數情況會自己浮現。
| 你要判斷的事 | 偏向 Aurora | 偏向 DynamoDB |
|---|---|---|
| 資料關係 | 多表關聯、需要 JOIN 與交易一致性 | 存取路徑固定，資料可收斂成少數幾張表 |
| 查詢彈性 | 查詢條件會一直長出新組合，需要臨時查詢 | 查詢種類穩定，寫程式時就知道會怎麼撈 |
| 流量形狀 | 可預期，容量規劃做得出來 | 會突然暴衝，或長時間近乎沒有流量 |
| 團隊習慣 | 既有 SQL 工具、報表與 ORM 生態要留著 | 願意用單表設計換取免容量規劃 |
| 跨區域需求 | Global Database 或 DSQL 視一致性需求而定 | 全球資料表，並選定最終一致或強一致模式 |
還有一個現實面的建議：這兩者不是互斥的。訂單、帳務、後台報表放 Aurora，工作階段、事件記錄、購物車這類高頻小讀寫放 DynamoDB，是很常見的組合。
我會先問「這份資料未來會不會被沒想過的方式查詢」。答案是會，就選 Aurora，因為 SQL 的價值正是在你還沒想到的查詢上。答案是不會，DynamoDB 的維運成本會低很多。
動手前的三個提醒
- 先量再選：用真實資料量與真實查詢做一次壓測，比讀十篇比較文有用。
- 把可用區當設計條件：Aurora 的跨可用區副本是儲存層自帶的，但你的應用端故障轉移邏輯要自己驗過。
- 把成本模型看懂：兩者的計價維度不同，這篇不寫價格，請直接看官方定價頁，並用自己的流量估一次。
選型這件事沒有標準答案，但有標準做法：先把存取路徑寫下來，再讓架構去配合它。順序反過來的專案，通常都會在半年後重做一次。
