AWS 成本最佳化資料庫解決方案

成本最佳化的資料庫設計，決定了雲端費用是隨著客戶成長線性擴展，還是每個月悄悄侵蝕毛利率。AWS SAA-C03 考試的任務陳述 4.3 要求你在 Amazon RDS、Amazon Aurora、Amazon DynamoDB、Amazon ElastiCache 和 Amazon Redshift 之間，設計出成本最佳化的資料庫解決方案。這意味著選擇正確的引擎、正確的容量模式、正確的承諾期限，以及正確的輔助層（快取、副本、TTL），讓每一分資料庫費用都對應到真實的工作負載需求。本指南涵蓋 RDS 執行個體類別的適當調整、穩定工作負載的 Reserved Instances、儲存體與 IOPS 調整、讀取副本的成本效益分析、Aurora Serverless v2 ACU 經濟模型、Aurora Global Database 副本費用、Aurora backtracking 成本、DynamoDB on-demand 與 provisioned 的取捨、DynamoDB auto scaling、DynamoDB Reserved Capacity、TTL 自動資料過期、DAX 與自行管理快取的比較、ElastiCache Reserved Nodes，以及 Redshift Reserved Nodes 與 Redshift Serverless 的選擇。每個章節都直接對應 SAA-C03 考試用來測試成本最佳化資料庫思維的情境線索。

什麼是 AWS 上的成本最佳化資料庫架構

成本最佳化的資料庫架構，是指每一個資料庫服務、容量模式、執行個體類別、儲存層級與承諾期限，都經過刻意選擇，在不犧牲工作負載所需之可用性、延遲或耐久性的前提下，將總擁有成本降至最低。SAA-C03 考試將成本最佳化資料庫設計與高效能資料庫設計明確區分：高效能資料庫設計最佳化的是延遲、吞吐量和規模；成本最佳化資料庫設計最佳化的是每筆交易的費用、每 GB 儲存的費用，以及每個承諾小時的費用，同時仍符合最低服務等級要求。

為什麼成本最佳化資料庫決策主導雲端帳單

資料庫往往是 AWS 帳單中最大的單一費用項目，因為它們同時涵蓋全天候運算（RDS DB 執行個體、Aurora Provisioned 叢集、ElastiCache 節點）、付費儲存體（gp3、io2、Aurora 儲存體、DynamoDB 儲存體）、付費 I/O（provisioned IOPS、Aurora I/O、DynamoDB 讀寫請求單位）、付費備份、付費跨區域複寫，以及付費資料傳輸。成本最佳化的資料庫策略從每個維度著手：適當調整運算規模、分層儲存、承諾可預測的基準、彈性擴展尖峰流量、用 TTL 讓資料過期，以及積極使用快取，讓主要的成本最佳化資料庫引擎減少昂貴的讀取操作。

成本最佳化資料庫在 SAA-C03 藍圖中的位置

任務陳述 4.3 位於領域 4（設計成本最佳化架構，佔 SAA-C03 考試 20%）之中。成本最佳化資料庫主題是考試用來測試你能否在 DynamoDB on-demand 與 DynamoDB provisioned 之間、Aurora Serverless v2 與 Aurora Provisioned 之間、RDS Reserved Instance 與 Savings Plans 涵蓋的 EC2 自建資料庫之間，以及 Redshift Reserved Nodes 與 Redshift Serverless 之間做出正確選擇的核心題目。請預期成本最佳化資料庫題目會要求你在滿足特定 RTO、RPO 或延遲需求的同時，將花費降至最低。

白話文解釋 Cost-Optimized Database

如果成本最佳化資料庫的服務矩陣讓你感到不知所措，以下類比可以用日常生活的角度重新詮釋這些取捨。選一個你在考試當天最容易記住的類比。

類比一：夜市攤位租金方案

把成本最佳化資料庫的選擇，想成夜市攤位的租金方案。On-Demand DynamoDB 是「臨時擺攤」：想擺就擺、隨時結束，偶爾出攤很划算，但天天開攤就太貴了。Provisioned DynamoDB 搭配 auto scaling 是「月租固定攤位」，你鎖定基本租金，但市集管理員會在生意爆棚時幫你多開幾張桌子。DynamoDB Reserved Capacity 是「年租優惠合約」，提前簽一年的攤位費，換取大幅折扣。Aurora Serverless v2 是「依人流計費的快閃店」，有客人才開燈、沒人就熄燈，費用依實際使用時間計算。Aurora Provisioned 是「全天候固定攤位」，只有一整天都擠滿客人才划算。RDS Reserved Instance 是「預繳年租的固定店面」。沒有成本最佳化計畫，就等於每分每秒都在付臨時擺攤費，適合無法預測的爆量情況，但對穩定工作負載來說代價慘重。

類比二：通勤交通策略

想像每天通勤上班。RDS On-Demand 是計程車：按錶計費，臨時出行很方便。RDS Reserved Instances（1 年或 3 年）是月票：前期投入較多，但每次搭乘的成本大幅降低。Aurora Serverless v2 是共乘 App：只有在移動時才計費，容量隨需出現，費用精確到 ACU 秒級。Provisioned DynamoDB 搭配 auto scaling 是有彈性座位的公司通勤車：HR 設定基本座位數，調度員在大型活動週再加派巴士。DynamoDB Reserved Capacity 是公司與交通局議定的兩年通勤補貼合約。ElastiCache Reserved Nodes 是「最後一哩路」的年租 YouBike。成本最佳化的通勤者會選擇最便宜且準時到達的方式；不懂規劃的人每天早上都在叫計程車。

類比三：健身房會員方案

把成本最佳化資料庫容量當成健身房會員等級。DynamoDB On-Demand 是單次入場券：零承諾，偶爾來訪很合適，但每週去三次就太貴了。Provisioned DynamoDB 是有課程點數上限的月費會員；超出上限時 auto scaling 會以略高費率補購點數。DynamoDB Reserved Capacity 是年繳優惠方案，每點費用降低約五成。Aurora Serverless v2 的 ACU 就像以 15 分鐘為單位計費的私人教練，只在你重訓時才出現。Aurora Provisioned 是全職專屬教練。RDS Reserved Instances 是含毛巾服務的白金年費會員。Redshift Reserved Nodes 是包租 12 個月的企業專屬健身樓層；Redshift Serverless 則是只在瑜珈墊鋪開時才計費的共享工作室。成本最佳化的健身房消費者，只為真正做到的訓練付費。

選擇符合成本效益的資料庫服務 — RDS、Aurora 與 DynamoDB

成本最佳化資料庫的第一個決策，是判斷工作負載屬於哪個引擎家族。SAA-C03 考試獎勵那些能在調整定價槓桿之前，先把工作負載形態對應到引擎家族的考生。

關聯式工作負載 — Amazon RDS 與 Amazon Aurora

如果工作負載需要 ACID 交易、SQL join、外鍵和結構化綱要，成本最佳化資料庫的選擇是 Amazon RDS 或 Amazon Aurora。Amazon RDS 在小規模的 MySQL、MariaDB 和 PostgreSQL 工作負載上通常較便宜，因為你可以用每天幾美元的代價運行單一 AZ 的 t3 或 t4g 執行個體。Amazon Aurora 的 Provisioned 叢集有較高的最低每小時費用（因為每個叢集都需要跨三個 AZ 支付儲存最佳化副本的費用），但在大規模下的每筆交易成本優於一般引擎，且 Aurora Serverless v2 可縮減至最低 0.5 ACU 的閒置底限，讓開發環境的成本最佳化資料庫花費降至最低。

NoSQL 鍵值工作負載 — Amazon DynamoDB

如果工作負載是具有可預測存取模式的鍵值或文件查詢（例如 session 儲存、使用者個人資料、購物車、IoT 設備狀態），Amazon DynamoDB 是成本最佳化資料庫的最佳選擇，因為你只需為消耗的儲存容量，以及實際 provisioned 或 on-demand 消耗的容量付費。沒有全天候執行個體的附加費用。使用 on-demand 模式的 DynamoDB，在閒置期間的費用可以接近零元。

在 EC2 上自行管理資料庫幾乎從不划算

SAA-C03 反覆出現的陷阱，是認為搭配 Savings Plan 在 EC2 上自行管理資料庫比使用 AWS 受管資料庫服務更便宜。在成本最佳化資料庫的情境中，一旦考量到修補、備份演練、Multi-AZ 容錯移轉工程和授權的人力成本，這個假設通常不成立。只有在舊有引擎或特定合規條款禁止使用受管服務時，才選擇自行管理。

成本最佳化資料庫架構，是指每個資料庫引擎、執行個體類別、容量模式、承諾期限、儲存層級、快取層與副本，都經過刻意選擇，在仍符合 SAA-C03 考試情境所定義之工作負載延遲、可用性、耐久性和復原目標的前提下，將總擁有成本降至最低。 Reference: https://aws.amazon.com/architecture/well-architected/

Amazon RDS 成本最佳化 — 執行個體類別的適當調整

RDS 運算依每個 DB 執行個體小時計費。在 RDS 上實現成本最佳化資料庫最快的途徑是適當調整規模（rightsizing）：選擇符合穩態 CPU、記憶體和連線需求的最小執行個體家族和規格，再於其上疊加 Reserved Instances 或類 Savings Plans 的折扣。

RDS 執行個體家族的選擇

通用型（m6i、m6g、m7g）— 混合 OLTP 工作負載的均衡成本最佳化基準。
記憶體最佳化型（r6i、r6g、x2g）— 適合工作集較大的工作負載；每小時費用較高，但所需執行個體數量較少。
可爆增型（t3、t4g）— 開發、測試及小型正式環境工作負載的成本最佳化甜蜜點；CPU 點數讓你在不升級規格的情況下吸收流量爆增。
Graviton（m6g、r6g、t4g）— 在引擎和版本支援 ARM 的情況下，通常比同等規格的 Intel 執行個體便宜 10% 至 20%，是成本最佳化資料庫的預設選擇。

從 CloudWatch 獲取適當調整的訊號

AWS Compute Optimizer 和 Amazon CloudWatch 提供成本最佳化資料庫適當調整決策所需的訊號：平均與尖峰 CPU、FreeableMemory 低谷、DatabaseConnections，以及持續的 ReadIOPS/WriteIOPS。如果尖峰 CPU 連續數週低於 40%，成本最佳化的做法是縮減一個執行個體規格。如果記憶體餘裕持續超過 50%，可從 r 系列降至 m 系列。

永遠不要對規格過大的 RDS DB 類別購買 Reserved Instance。對本應是 m6i.xlarge 的執行個體購買 3 年期 m6i.4xlarge Reserved Instance，等於將四倍的成本最佳化資料庫花費鎖定長達三年。先用 Compute Optimizer 進行規模調整，以新規格觀察至少兩週，再針對正確的家族和規格購買 Reserved Instance。 Reference: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithReservedDBInstances.html

穩定工作負載的 RDS Reserved Instances

Amazon RDS Reserved Instances（RIs）在承諾一年或三年的 DB 執行個體使用量時，相較於 On-Demand 定價最高可節省 69%。對於任何具有可預測基準的成本最佳化資料庫（全天候運行的正式環境 OLTP），Reserved Instances 是必要選項，而非可有可無。

RI 期限與付款選項

1 年期 — 約可節省 40%，對於仍有成長不確定性的成本最佳化資料庫，鎖定風險較低。
3 年期 — 最高可節省 69%，適合成熟產品的主要 OLTP 儲存等穩定的成本最佳化資料庫工作負載。
No Upfront / Partial Upfront / All Upfront — 預付金額越高，有效折扣越大，AWS 在費率中內含的利率風險越低。

RI 涵蓋率的目標設定

成本最佳化資料庫機群很少承諾 100% 的 RI 涵蓋率。正確的模式是用 Reserved Instances 涵蓋穩態基準（約為 provisioned 小時數的 70% 至 80%），並以 on-demand 吸收尖峰流量。任何為尖峰小時購買 RI 的成本最佳化資料庫，在每個非尖峰小時都會產生過度承諾的浪費。

成本最佳化資料庫的 Reserved Instance 範圍限定於特定區域、引擎（MySQL、PostgreSQL、SQL Server、Oracle、MariaDB）、資料庫版本（SQL Server 和 Oracle）以及執行個體類別家族。如果你計畫在期限內遷移引擎或移至其他區域，該 RI 將被浪費。成本最佳化資料庫的解決方案是利用「規格彈性」（Size Flexibility，大多數非 BYOL 引擎自動啟用），讓折扣可在同一執行個體家族的不同規格之間套用。 Reference: https://aws.amazon.com/rds/reserved-instances/

RDS 儲存體與 IOPS 的成本調整

RDS 儲存體依每個已 provisioned 的 GB 月計費，io1/io2 磁碟區另外依已 provisioned 的 IOPS 計費。成本最佳化資料庫會根據實際工作負載模式調整儲存類型和容量，而非預設使用最昂貴的層級。

gp3 vs gp2 vs io1 vs io2 Block Express

gp3 — 自 2021 年起的預設成本最佳化資料庫選擇；GB 和 IOPS 分開計費，每個磁碟區不需要膨脹 GB 就能獲得 3,000 IOPS 基準。
gp2 — 舊式規格；IOPS 以每 GB 3 IOPS 的比例擴展，意味著成本最佳化資料庫往往需要過度 provision GB 才能獲得足夠的 IOPS。
io1/io2 — Provisioned IOPS；費用較高，但在工作負載持續超過每磁碟區 16,000 IOPS 時為必要選擇。
io2 Block Express — 最高效能層級，保留給需要超過 64,000 IOPS 的資料庫使用。

儲存體自動擴展與保留期限

成本最佳化資料庫會開啟 RDS 儲存體自動擴展，從較小的 GB 配置開始，只在使用率超過 90% 時才擴展。備份保留期限也會在已配置的免費儲存體之外產生 GB 月費用，因此成本最佳化資料庫架構師應將保留期限設為合規和 RPO 政策實際要求的最低值，而非預設的 35 天。

RDS 讀取副本的成本效益分析

讀取副本可擴展讀取吞吐量，也可在災難復原時進行提升（promote），但每個副本都是完整的 DB 執行個體，具有自己的每小時費率及儲存費用。成本最佳化資料庫將副本視為需要付費的選擇，而非免費的午餐。

讀取副本的划算情境

否則會衝擊主要執行個體的報表和分析查詢。
地理位置分散的讀取者，跨區域副本可降低下游應用程式的延遲和出口流量費用。
災難復原，副本作為熱備援；對某些 RTO 目標而言，比在第二個區域設置完整的 Multi-AZ 更便宜。

讀取副本的浪費情境

如果主要執行個體的 CPU 低於 50% 且有充足的 I/O 餘裕，新增副本只會燒錢而不會降低延遲。
如果應用程式無法容忍副本延遲，成本最佳化資料庫的解法通常是升級主要執行個體或增加 ElastiCache 層，而非再加一個副本。
如果副本只在每晚兩小時的報表期間使用，成本最佳化資料庫應在其餘時間關閉它，或改用閒置時接近零費用的 Aurora Serverless v2。

Multi-AZ 是用於高可用性的同步備援，它不提供讀取服務。成本最佳化資料庫架構師有時會嘗試用讀取副本取代 Multi-AZ 來節省費用，但副本是非同步的，無法滿足 Multi-AZ 所提供的自動容錯移轉承諾。Multi-AZ 用於 HA，讀取副本僅用於擴展讀取能力——在 SAA-C03 考試中切勿混淆兩者。 Reference: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html

Aurora 成本模型 — Provisioned、Serverless v2 與 I/O-Optimized

Amazon Aurora 的計費方式與一般 RDS 不同。了解 Aurora 成本最佳化資料庫的調節槓桿，是 SAA-C03 備考中投資報酬率最高的項目之一，因為考試題目非常熱愛 Aurora 成本問題。

Aurora Provisioned 定價結構

Aurora Provisioned 依每個 DB 執行個體小時（寫入節點加上每個讀取節點）、每 GB 月儲存體，以及——在 Aurora Standard 模式下——每百萬次 I/O 計費。使用 Aurora 的成本最佳化資料庫必須同時關注這三個費用項目，因為 Aurora Standard 上的高 I/O 工作負載，可能讓那些原本期待 Aurora 儲存費用像 RDS gp3 一樣固定的架構師感到意外。

Aurora I/O-Optimized 設定

2023 年 AWS 推出了 Aurora I/O-Optimized，這是一種叢集層級的設定，你以較高的執行個體和儲存費率換取不收取每次 I/O 費用。對於 I/O 費用超過 Aurora 總成本約 25% 的成本最佳化資料庫工作負載，切換至 I/O-Optimized 通常更便宜。SAA-C03 考試中提到非常高讀寫吞吐量、並要求你控制不可預測 I/O 費用的情境，正是在指向 Aurora I/O-Optimized。

Aurora Serverless v2 — ACU 費用經濟學

Aurora Serverless v2 依每個 Aurora Capacity Unit（ACU）每秒計費。一個 ACU 約等於 2 GiB 記憶體加上相應比例的 CPU 和網路資源。Serverless v2 可以 0.5 ACU 的增量從可設定的最低值（低至 0.5 ACU）擴展到可設定的最高值（最高 128 ACU）。對於工作負載尖刺、不可預測或突發性的成本最佳化資料庫——開發環境、只在上班時間使用的內部工具、零星的批次作業——Aurora Serverless v2 通常是最便宜的成本最佳化資料庫選項，因為你只需為實際需求付費，而非為永久 provisioned 的 r 系列執行個體付費。

Aurora Serverless v2 損益兩平試算

Provisioned db.r6g.large 全天以固定費率運行。只要平均 ACU 需求乘以使用小時數低於等效 provisioned 每小時費率，Aurora Serverless v2 就更便宜。當平均需求遠低於已 provisioned 執行個體的容量時，成本最佳化資料庫架構師就選擇 Serverless v2。SAA-C03 常以「有長時間閒置期的不可預測工作負載」來描述這個情境——預期答案就是 Aurora Serverless v2。

Aurora Serverless v2 允許最低 0.5 ACU，可讓成本最佳化資料庫的閒置底限費用極低——但如果底限對流量形態而言過低，冷啟動和連線緩衝行為會劣化。對於面向正式環境的成本最佳化資料庫工作負載，最低值應設為 1 或 2 ACU 以吸收突發流量；對於開發/測試環境，0.5 ACU 通常就足夠了。 Reference: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.setting-capacity.html

Aurora Global Database 副本費用

Aurora Global Database 可將主要叢集延伸到最多五個次要 AWS 區域，典型的複寫延遲低於一秒。費用模型疊加在基本 Aurora 費用之上：你需要為每個區域的次要叢集執行個體和儲存體、跨區域複寫資料傳輸，以及每個區域的 Global Database 費用付費。

副本溢價值得付出的情境

對於需要跨區域次秒級 RPO 和次分鐘級 RTO 的成本最佳化資料庫工作負載，Aurora Global Database 比自行使用 DMS 和自訂編排建立跨區域複寫更便宜。架構師需支付每個區域的溢價，但換來受管的次秒級跨區域複寫。

副本溢價不值得付出的情境

如果工作負載的 RPO 和 RTO 目標是以小時而非秒計算，成本最佳化資料庫通常可以跳過 Global Database，改用跨區域讀取副本（適用於 MySQL/PostgreSQL 相容的 Aurora）或搭配生命週期政策的快照式 DR。考試的訊號是 RPO 數字：RPO 低於一秒選 Global Database，較寬鬆的 RPO 選傳統跨區域複寫或快照。

Aurora Backtrack 費用

Aurora Backtrack（用於 Aurora MySQL）讓你無需從備份還原即可將資料庫倒回過去最多 72 小時的某個時間點。它依儲存的變更紀錄小時數計費。對於意外寫入復原是合理風險的成本最佳化資料庫，Backtrack 通常比執行完整的 PITR 還原和手動資料對帳更便宜。

Backtrack 費用與價值

Backtrack 並非免費：你需要為所設定的 backtrack 視窗長度支付每個變更紀錄小時的費用。成本最佳化資料庫通常將 backtrack 視窗保持在適度範圍（例如 24 小時），以避免變更紀錄儲存費用過高。Backtrack 僅適用於 Aurora MySQL——Aurora PostgreSQL 使用 PITR 還原加快照，靜態費用較低但復原速度較慢。

提到「無需還原即可在數分鐘內倒回」的成本最佳化資料庫情境，指向的是 Aurora Backtrack，但 Backtrack 僅適用於 Aurora MySQL。如果情境是 Aurora PostgreSQL，正確的成本最佳化資料庫答案是 PITR 還原至新叢集並在應用程式層進行切換，而非 Backtrack。 Reference: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.Backtrack.html

DynamoDB On-Demand 與 Provisioned — 核心成本決策

DynamoDB 有兩種容量模式，兩者之間的成本最佳化資料庫選擇，是 SAA-C03 最常測試的成本最佳化問題之一。

On-Demand 容量

On-Demand 計費依消耗的寫入請求單位和讀取請求單位計費，無需任何承諾。成本最佳化資料庫選擇 on-demand 的理由是流量不可預測：新品發布、病毒式爆量、季節性零售、事件驅動工作負載，以及無法預測 RCU 或 WCU 的概念驗證建置。

Provisioned 容量

Provisioned 計費依你宣告的 RCU 和 WCU 每小時計費，不論實際使用量。當使用率保持穩定時，Provisioned 比 on-demand 便宜很多。AWS 文件歷史記載，在相同流量水準下，具有合理使用率的 provisioned 費用約為 on-demand 的七分之一，這也是為什麼具有可預測負載的成本最佳化資料庫應該優先選擇 provisioned。

WCU 和 RCU 的規格計算規則

1 WCU = 每秒一次針對不超過 1 KB 項目的寫入。
1 RCU = 每秒一次針對不超過 4 KB 項目的強一致性讀取（或每秒兩次的最終一致性讀取）。
交易會使費用加倍：一次交易型寫入消耗 2 WCU，一次交易型讀取消耗 2 RCU。

成本最佳化資料庫依據使用 CloudWatch ConsumedReadCapacityUnits 和 ConsumedWriteCapacityUnits 測量的工作負載來設定 WCU 和 RCU，而非依賴猜測。

損益兩平的經驗法則

成本最佳化資料庫的粗估損益兩平點：如果 provisioned 資料表的平均使用率能維持在約 15% 至 18% 以上，搭配 auto scaling 的 provisioned 模式勝過 on-demand。低於此門檻，on-demand 勝出，因為你不再為閒置容量付費。

考生有時認為 DynamoDB On-Demand 是成本最佳化資料庫的預設選擇，因為它說「只為使用量付費」。實際上，On-Demand 有每次請求的溢價，使其在穩定負載下相當昂貴。高吞吐量正式環境資料表的成本最佳化資料庫，通常選擇 Provisioned 搭配 auto scaling 和 Reserved Capacity，而非 On-Demand。 Reference: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html

DynamoDB Auto Scaling — 追蹤需求而不過度承諾

DynamoDB Auto Scaling 使用 AWS Application Auto Scaling，根據觀察到的使用率相對於目標值來調整已 provisioned 的 RCU 和 WCU。使用 provisioned 容量的成本最佳化資料庫應始終開啟 auto scaling；否則要麼為尖峰過度 provision（浪費），要麼在尖峰時節流（使用者體驗不佳）。

目標追蹤設定

成本最佳化資料庫通常將目標使用率設在 60% 至 70% 之間。目標值越低，緩衝空間越大但費用越高；目標值越高，費用越低但遇到突發尖峰時偶有節流。Auto scaling 是反應式地向上擴展，因此極度尖刺的流量（次分鐘級）較適合 on-demand 模式；持續的日夜規律性流量模式才是 provisioned 搭配 auto scaling 的甜蜜點。

Auto Scaling 與 Reserved Capacity 的搭配

成本最佳化資料庫在自動擴展的底限下疊加 Reserved Capacity：對幾乎不會低於的基準進行承諾，讓 auto scaling 在上方彈性調整。Reserved Capacity 折扣適用於任何已 provisioned 的容量，因此規模適當的承諾在資料表向上擴展時仍能享有折扣。

可預測基準的 DynamoDB Reserved Capacity

DynamoDB Reserved Capacity 讓你承諾一年或三年的 provisioned RCU 和 WCU 基準，換取大幅折扣（歷史記載 3 年全額預付最高可節省約 53%）。對於運行穩定基準正式工作負載的成本最佳化資料庫，Reserved Capacity 是 RDS Reserved Instances 的對應機制。

Reserved Capacity 運作機制

範圍：特定區域、特定帳號。
單位：以 100 WCU 或 100 RCU 為一個區塊出售。
期限：1 年或 3 年。
付款：Partial Upfront 或 All Upfront。
適用對象：僅適用於 provisioned 容量資料表（不適用於 on-demand）。

該購買多少 Reserved Capacity

成本最佳化資料庫以 Reserved Capacity 涵蓋低包線基準——資料表幾乎不會低於的容量——並讓 auto scaling 以 on-demand 費率或 provisioned 費率吸收其餘部分。過度承諾至尖峰容量反而失去意義：你用 RC 折扣為鮮少需要的容量付費。

DynamoDB 成本最佳化資料庫的槓桿應依此順序疊加：(1) 流量穩定後選擇 Provisioned 而非 On-Demand；(2) 以 60% 至 70% 目標啟用 Auto Scaling；(3) 為基準購買 Reserved Capacity；(4) 新增 TTL 讓舊項目過期；(5) 僅在讀取模式確實需要微秒級快取讀取時才加入 DAX；(6) 保持項目大小精簡，並設計分割鍵以避免熱分割。跳過任何一個槓桿，都讓成本最佳化資料庫多花了不必要的費用。 Reference: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/reservedcapacity.html

DynamoDB TTL — 零 WCU 成本的自動資料過期

Time to Live（TTL）是 DynamoDB 的功能，讓你指定某個屬性為 epoch 時間戳記作為過期標記；DynamoDB 會在過期時間戳記後通常 48 小時內自動刪除已過期的項目，且不收取任何寫入容量費用。對於持有暫時性資料的成本最佳化資料庫——session token、快取物件、一次性密碼記錄、短期日誌——TTL 是最便宜的清除機制。

為什麼 TTL 對成本最佳化資料庫很重要

儲存成本降低，因為已過期的項目不再累積 GB 月費用。
資料表查詢延遲改善，因為資料表保持精簡。
你不需要撰寫發出刪除請求（會消耗 WCU）的應用程式碼。

TTL 設計模式

成本最佳化資料庫在每次寫入暫時性項目類型時都附加 TTL 屬性。對於需要稽核的記錄，TTL 可觸發 DynamoDB Streams 事件，讓下游程序（例如將資料封存至 S3 Glacier 的 Lambda 函數）在刪除前觀察到，實現便宜的分層保留。

成本最佳化資料庫通常將 DynamoDB TTL 與 DynamoDB Streams 加上 Lambda 搭配使用，在刪除前將即將過期的項目複製至 S3 Glacier Deep Archive。你可以在短期保留視窗享有 DynamoDB 的高速路徑效能，以每 GB 幾分錢的 Glacier 費用實現長期儲存，並且完全不需要為舊項目持續支付 WCU 費用。 Reference: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/TTL.html

DAX 費用與自行管理快取的比較

Amazon DynamoDB Accelerator（DAX）是 DynamoDB 的全受管寫入穿透式記憶體快取，可提供微秒級讀取延遲。DAX 依 DAX 叢集中的每個節點小時計費。對於成本最佳化資料庫，問題在於 DAX 是否能靠減少 RCU 消耗來補回費用，而非單純依賴 DynamoDB 本身或自行管理的 ElastiCache 層。

DAX 具有成本效益的情境

讀取密集的 DynamoDB 工作負載，快取命中率高到足以大幅減少 RCU 消耗。
微秒級延遲是產品需求的工作負載（遊戲、廣告技術、即時定價）。
沒有多餘人力自行維運快取層的團隊。

DAX 不具成本效益的情境

寫入密集或讀寫均衡的工作負載——DAX 增加了節點小時費用，但由於寫入會穿透，幾乎沒有節省 RCU 的效益。
由於隨機存取模式導致低快取命中率的工作負載。
工作負載規模小到 DAX 叢集的最低節點小時費用超過其所能節省的 RCU 費用。

DAX 與 DynamoDB 前端的 ElastiCache 比較

成本最佳化資料庫團隊有時會評估是否用 ElastiCache（Redis 或 Memcached）取代 DAX 放在 DynamoDB 前端。ElastiCache 每 GB 快取的費用可能較低，但需要應用程式實作 cache-aside 邏輯、處理寫入時的快取失效，並作為獨立的故障域來維運。DAX 是專為 DynamoDB 設計的、對 DynamoDB SDK 透明，且為寫入穿透式。在 SAA-C03 考試中，當情境強調「最少的應用程式變更」或「DynamoDB 專屬快取」時，成本最佳化資料庫應選 DAX；當情境強調「快取多個資料來源」或「通用鍵值快取」時，應選 ElastiCache。

ElastiCache Reserved Nodes

Amazon ElastiCache（Redis 和 Memcached）以節點叢集運行，每個節點依節點小時計費。對於長期運行的成本最佳化資料庫快取層，ElastiCache Reserved Nodes 在承諾 1 年或 3 年的情況下，相較於 on-demand 節點小時定價最高可節省約 55%。

ElastiCache Reserved Nodes 划算的情境

在 RDS、Aurora 或 DynamoDB 前端全天候運行的正式環境快取。
永不關閉的大型 Web 應用程式 session 儲存。
排行榜、功能旗標及其他長期保持暖機的快取。

On-Demand ElastiCache 適用的情境

非上班時間可暫停的開發和測試快取。
針對單一行銷活動設計的短期事件驅動快取。

比例的經驗法則

運行永久 ElastiCache 叢集的成本最佳化資料庫，應以 70% 至 90% 的 Reserved Node 涵蓋率為目標，讓基準以承諾方式涵蓋，成長或突發容量則以 on-demand 方式新增。

ElastiCache 用於降低主要資料庫的成本

在討論 Reserved Node 之前，更大的成本最佳化資料庫故事是：策略性地部署 ElastiCache，可以降低主要資料庫的規模（進而降低費用）。每一筆從 ElastiCache 中服務的讀取，就是一次你不需要支付的 RDS IOPS、Aurora I/O 單位或 DynamoDB RCU。

Cache-Aside 投資報酬分析

成本最佳化資料庫架構師將 ElastiCache 投資報酬率建模為：快取節點小時費用減去避免的主要資料庫費用（較小的執行個體類別、較少的讀取副本、較少的 DynamoDB RCU）。當避免的費用超過快取節點小時費用時，ElastiCache 勝出。對於熱門項目密集的工作負載（新聞動態、產品目錄、身分驗證查詢），計算結果幾乎總是有利的。

寫入穿透與懶惰載入

懶惰載入（cache-aside）——應用程式寫入主要資料庫並優先從快取讀取，在快取未命中時填充。費用低且簡單；缺點是 TTL 過期前可能讀取到過時資料。
寫入穿透——應用程式以原子方式同時寫入快取和主要資料庫。寫入費用較高但讀取一致。

成本最佳化資料庫通常從懶惰載入開始，因為它將快取寫入流量降至最低，並對主要資料庫的 RCU/IOPS 節省效益最大化。

Redshift Reserved Nodes 與 Redshift Serverless

Amazon Redshift 是成本最佳化資料庫組合中的分析型資料庫。其費用槓桿與 OLTP 引擎有很大的差異。

搭配 Reserved Nodes 的 Redshift Provisioned

Redshift Provisioned 運行一個全天候開機的運算節點叢集。1 年或 3 年的 Reserved Node 承諾相較於 on-demand 最高可節省 75%。對於全天候進行 ETL 且持續提供儀表板服務的成本最佳化資料庫資料倉儲，Reserved Nodes 是明顯的最佳選擇。

Redshift Serverless

Redshift Serverless 依消耗的每 RPU 秒（Redshift Processing Unit）加上獨立儲存計費。對於每天只運行兩次批次 ETL、每次提供幾小時互動式查詢的成本最佳化資料庫分析工作負載，Redshift Serverless 消除了全天候節點費用。當情境說「不可預測的查詢模式」、「間歇性分析」或「無需容量規劃」時，Serverless 就是成本最佳化資料庫的答案。

Provisioned 與 Serverless 的損益兩平

如果資料倉儲在有意義的負載下每天運作超過約 12 小時，Reserved Nodes 在每次查詢費用上通常優於 Serverless。低於此門檻，Serverless 勝出，因為沒有任何東西以全價閒置。SAA-C03 情境線索：

「24 小時 ETL 加上全天候儀表板」→ Redshift Reserved Nodes。
「分析師團隊每週進行幾次臨時查詢」→ Redshift Serverless。
「工作負載變動，無法預測 RPU 需求」→ Redshift Serverless。

Redshift 儲存體 — 受管儲存費用

Redshift RA3 節點將運算與受管儲存分離。當儲存成長速度快於運算需求時，成本最佳化資料庫架構師應選擇 RA3，這樣你只需為實際使用的儲存付費，而非為了取得磁碟空間而過度調整運算節點規格。

資料保留成本 — 快照與自動備份視窗

每個 AWS 資料庫服務都會對超出免費額度的備份收費。成本最佳化資料庫將保留期限裁減至符合合規要求和 RPO 的最低限度。

RDS 與 Aurora 備份保留

RDS 自動備份在 DB 執行個體已 provisioned 儲存大小內免費；超出後依每 GB 月計費。將非關鍵成本最佳化資料庫的保留期限設為 7 天而非最長的 35 天，可將備份費用降低約 80%。

DynamoDB Point-in-Time Recovery

PITR 在基本資料表儲存費用之上增加每 GB 月費用。成本最佳化資料庫只在需要 35 天內進行時間點還原的資料表上啟用 PITR。

Aurora 快照匯出至 S3

Aurora 可將快照匯出至 Amazon S3，其每 GB 月費用遠低於 Aurora 內部備份儲存費用。對於長期保留，成本最佳化資料庫將快照匯出至 S3，並透過生命週期規則將 S3 物件降級至 S3 Glacier Deep Archive。

資料庫遷移以降低成本 — 遷移至受管服務

一個常被忽視的成本最佳化資料庫槓桿是遷移本身。在 EC2 上自行管理的資料庫存在著受管服務可以消除的隱性人力成本。

異質遷移至 Aurora 或 DynamoDB

透過搭配 AWS Schema Conversion Tool 的 AWS Database Migration Service（AWS DMS），成本最佳化資料庫團隊可以從商業授權引擎（Oracle、SQL Server）遷移至 Aurora PostgreSQL 或 Aurora MySQL，消除每核心授權費用。許多實際 TCO 分析顯示，授權費用的節省遠超過原始基礎架構費用。

同質遷移至受管 RDS

將 EC2 上自行管理的 MySQL 遷移至 Amazon RDS for MySQL，消除了修補、備份自動化和 Multi-AZ 工程的額外負擔。除非特定引擎版本、外掛程式或合規要求禁止使用 RDS，否則繼續自行管理引擎對成本最佳化資料庫幾乎沒有好處。

分析的欄式資料庫 — Redshift 與 Athena + S3

SAA-C03 中的一個經典成本最佳化資料庫問題，是 Redshift 與在 S3 上查詢資料的 Amazon Athena 之間的比較。兩者都有其適用場景；成本最佳化資料庫的答案取決於查詢模式。

Redshift 勝出的情境

對倉儲中 TB 級資料進行頻繁、重複的複雜 join 查詢。
每小時發出數千次查詢的全天候 BI 儀表板。
Reserved Nodes 能分攤全天候運算費用的工作負載。

Athena + S3 勝出的情境

每天或每週幾次的臨時查詢。
資料本就存放在 S3 中的稽核和日誌分析（VPC Flow Logs、CloudFront 日誌、AWS Config 快照）。
成本最佳化資料庫團隊希望零容量規劃且零全天候運算的情境。

Athena 依掃描的資料量（TB）計費。選擇 Athena 的成本最佳化資料庫應對底層資料進行分割、以 Snappy 或 ZSTD 壓縮檔案，並轉換為欄式格式（Parquet、ORC），以大幅降低掃描資料量，進而降低每次查詢的費用。

使用 AWS Cost Explorer 監控成本最佳化資料庫

AWS Cost Explorer 和 AWS Cost and Usage Reports 提供資料庫專屬的費用明細項目，成本最佳化資料庫團隊必須每月審查：RDS 執行個體小時、Aurora I/O、Aurora 儲存體、DynamoDB RCU、DynamoDB WCU、DynamoDB 儲存體、ElastiCache 節點小時、Redshift 節點小時或 RPU 秒、備份儲存體，以及跨區域資料傳輸。

用標籤進行費用分配

成本最佳化資料庫強制對每個 RDS DB 執行個體、Aurora 叢集、DynamoDB 資料表、ElastiCache 叢集和 Redshift 叢集設定標籤（環境、團隊、應用程式、成本中心），讓 Cost Explorer 能夠按擁有者分類費用。沒有標籤，成本最佳化資料庫的節省機會將無從可見。

異常偵測

AWS Cost Anomaly Detection 能在資料庫費用突然飆升（DynamoDB 全資料表掃描失控、不小心 provisioned 的 io2 磁碟區）在毀掉月度預算之前發出警報。對於任何稱得上成本最佳化的資料庫，異常偵測是基本要素。

成本最佳化資料庫情境必記數字

RDS Reserved Instances — 3 年全額預付相較於 On-Demand 最高可節省 69%。
Aurora Serverless v2 — 以 0.5 ACU 增量，從最低 0.5 ACU 擴展至最高 128 ACU。
Aurora Global Database — 最多五個次要區域，典型複寫延遲低於一秒。
Aurora Backtrack 視窗 — 最長 72 小時，僅限 Aurora MySQL。
DynamoDB Reserved Capacity — 相較於 provisioned on-demand 定價最高可節省約 53%，1 年或 3 年期。
DynamoDB TTL — 在時間戳記後 48 小時內刪除過期項目，不消耗 WCU。
DynamoDB Auto Scaling — 目標追蹤，典型使用率目標為 60% 至 70%。
ElastiCache Reserved Nodes — 最高可節省約 55%，1 年或 3 年期。
Redshift Reserved Nodes — 相較於 On-Demand 最高可節省 75%，1 年或 3 年期。
Redshift Serverless — 依每 RPU 秒計費，無全天候節點費用，適合間歇性分析。
RDS 免費備份儲存體 — 最高至已 provisioned 儲存大小；超出後依每 GB 月計費。
DynamoDB 項目大小限制 — 每個項目 400 KB（影響 RCU/WCU 規格計算）。

成本最佳化資料庫題目的常見考試陷阱

SAA-C03 考試有一組可預測的成本最佳化資料庫陷阱。反覆練習直到它們變得顯而易見為止。

陷阱一：對穩定工作負載預設使用 On-Demand DynamoDB

考生看到「serverless」就以為 On-Demand 永遠更便宜。對於穩定、可預測的工作負載，成本最佳化資料庫應選擇 Provisioned 搭配 Auto Scaling 和 Reserved Capacity，而非 On-Demand。

陷阱二：混淆 Multi-AZ 與讀取副本的成本角色

Multi-AZ 是 HA，而非讀取擴展器；讀取副本是讀取擴展，而非自動容錯移轉。成本最佳化資料庫無法用讀取副本取代 Multi-AZ，同時仍滿足自動容錯移轉的需求。

陷阱三：假設 Aurora Serverless v2 永遠比 Provisioned 便宜

Serverless v2 在閒置或尖刺工作負載上較便宜，在持續滿載的工作負載上，每個活躍 ACU 秒的費用比同等規格的 provisioned 執行個體更貴。成本最佳化資料庫架構師應計算損益兩平點，而非直接預設使用 Serverless。

陷阱四：以尖峰容量過度承諾 Reserved Instances

成本最佳化資料庫保留的是基準，而非尖峰。過度承諾的 RI 或 Reserved Capacity 會將折扣方案變成固定成本陷阱。

陷阱五：忽略 Standard 配置下的 Aurora I/O 費用

Aurora Standard 依每百萬次 I/O 收費。I/O 工作負載極高的成本最佳化資料庫，要麼切換至 Aurora I/O-Optimized 叢集設定，要麼接受一個令人意外的費用明細項目。

陷阱六：為臨時分析選擇 Redshift

如果工作負載是對 S3 中資料的偶發查詢，成本最佳化資料庫的答案是搭配欄式格式的 Athena，而非 Redshift。

陷阱七：忘記 DAX 是 DynamoDB 專屬的

DAX 只加速 DynamoDB。成本最佳化資料庫無法在 RDS 或 Aurora 前端使用 DAX；正確的快取選擇是 ElastiCache。

SAA-C03 考試幾乎從不問「抽象意義上什麼最便宜」。它問的是在特定流量形態下什麼最便宜：穩定、尖刺、不可預測或定期排程。不考慮流量形態的成本最佳化資料庫答案通常是錯的。Reserved 定價適合穩定流量；On-Demand 和 Serverless 適合不可預測流量；Reserved 搭配 Auto Scaling 適合有適度變動的可預測流量。 Reference: https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html

資料庫成本與效能 — 了解各自的最佳化時機

成本最佳化資料庫並不等於廉價資料庫。SAA-C03 情境設計獎勵那些能在不違反既定非功能性需求的前提下削減費用的架構師。如果工作負載要求個位數毫秒的讀取延遲，DAX 或 ElastiCache 就是成本最佳化資料庫答案的一部分——即便它增加了費用明細項目，因為若缺少這一層，主要資料庫就需要擴展至費用更高昂的設定。

優先順序框架

首先滿足既定的 RTO、RPO、延遲和一致性需求。
需求滿足後，依此順序施加費用槓桿：適當調整運算規模、承諾基準（Reserved Instances / Reserved Capacity / Reserved Nodes）、分層儲存、快取讀取、用 TTL 讓資料過期，以及自動化擴展。
在每次續約前重新審視所有承諾；流量形態會隨時間改變。

FAQ — 成本最佳化資料庫解決方案熱門問題

1. 成本最佳化資料庫何時應選擇 DynamoDB On-Demand 而非 Provisioned？

當流量不可預測、突發性或全新未知時，選擇 On-Demand。尚無穩定基準的成本最佳化資料庫，使用 On-Demand 的費用會低於讓 Provisioned 資料表保持低使用率的費用。一旦流量穩定且平均使用率可以建模，就切換至 Provisioned 搭配 Auto Scaling，並以 DynamoDB Reserved Capacity 涵蓋基準——這種組合在穩定負載下遠比 On-Demand 便宜。SAA-C03 考試透過「不可預測工作負載」（On-Demand）或「穩定正式環境流量」（Provisioned 搭配 Reserved Capacity）等措辭來暗示這個決策。

2. Aurora Serverless v2 永遠比 Aurora Provisioned 便宜嗎？

不。Aurora Serverless v2 對於有長時間閒置期或高度變動需求的工作負載較便宜，因為你只需為實際運行的 ACU 付費。對於持續承受穩定負載的工作負載，搭配 Reserved Instance 承諾的 Provisioned db.r 系列執行個體，每小時費用低於等效的 ACU 秒費用。成本最佳化資料庫架構師應計算損益兩平點：如果 24 小時內的平均 ACU 需求遠低於否則需要購買的已 provisioned 容量，Serverless v2 勝出。

3. 如果我可能更換引擎，RDS Reserved Instances 值得承諾嗎？

Reserved Instances 是引擎特定且區域特定的，因此如果成本最佳化資料庫計畫在下一年內從 Oracle 遷移至 Aurora PostgreSQL，購買 3 年期的 Oracle RI 會讓折扣白白浪費。成本最佳化資料庫的答案是將 RI 期限與信心期間相符：引擎穩定性不確定時購買 1 年期 RI，只有在確定仍會繼續使用的引擎上才購買 3 年期 RI。規格彈性（Size Flexibility）可在同一家族的執行個體規格之間協助調度，但無法跨引擎。

4. 在 DynamoDB 前端，成本最佳化資料庫應選擇 DAX 還是 ElastiCache？

當快取完全位於 DynamoDB 前端、應用程式已使用 DynamoDB SDK，且你希望以零應用程式碼變更獲得寫入穿透語義時，選擇 DAX。當快取需要服務多個資料來源、需要 Redis 特定的資料結構（排序集合、pub/sub），或團隊已為 session 運行 ElastiCache 叢集時，選擇 ElastiCache。對於只讀取 DynamoDB 的成本最佳化資料庫，DAX 通常在總成本上勝出，因為無需建置和維護 cache-aside 邏輯。

5. 何時應選擇 Redshift Reserved Nodes 而非 Redshift Serverless？

當分析工作負載每天在有意義的負載下運行超過約 12 小時時，選擇 Reserved Nodes——全天候的 BI 儀表板、持續的 ETL，以及大型專屬分析師團隊。1 年或 3 年的承諾大幅降低每小時費用，讓穩定的使用率極為便宜。當分析師每週只進行幾次臨時查詢、工作負載具有季節性，或無法進行容量規劃時，選擇 Redshift Serverless。對於成本最佳化資料庫的分析技術堆疊，一種常見模式是為核心資料倉儲使用 Reserved Nodes，同時用 Athena on S3 處理長尾臨時查詢。

6. 啟用 DynamoDB TTL 能同時節省儲存費用和寫入費用嗎？

TTL 能節省儲存費用，因為已過期的項目不再累積 GB 月費用；它也避免了刪除操作原本會消耗的寫入容量費用——TTL 刪除不消耗 WCU。如果業務需要保留過期記錄的稽核軌跡，或希望在項目消失前封存至 S3 Glacier，成本最佳化資料庫可將 TTL 與 DynamoDB Streams 搭配使用。SAA-C03 的考試線索是「無需應用程式碼即可在 X 天後自動讓項目過期」——這對應到 TTL。

7. 如何判斷讀取副本對成本最佳化資料庫是節省還是浪費？

在新增副本之前，先測量主要執行個體的 CPU、I/O 和連線使用率。如果主要執行個體因讀取流量而飽和，且垂直擴展主要執行個體的費用高於副本的每小時費用，則副本可節省費用。如果主要執行個體有餘裕，副本只會增加費用。成本最佳化資料庫也應評估 ElastiCache 是否能以比完整副本更低的費用實現相同的讀取卸載——對於熱門項目工作負載，通常確實如此。跨區域副本還會產生資料傳輸費用，因此讀取地理分佈的業務價值必須能夠抵銷出口費用。