先描述工作負載，再選執行個體
選規格的第一步不是比較不同雲端平台的機型，而是建立工作負載輪廓。至少要釐清讀寫比例、每秒交易量、同時連線數、常見查詢延遲、批次作業時段，以及尖峰是短暫突發還是會持續數小時。API 回應慢不一定代表 CPU 不足，也可能是索引缺漏、鎖競爭、連線池失控、磁碟延遲，或應用程式一次讀取過多資料。若未先拆解原因，升級機型通常只會延後問題再次出現。
關聯式交易系統通常需要同時觀察 CPU、可用記憶體、快取命中、磁碟 IOPS、吞吐量、連線數與鎖等待。記憶體不足會讓熱資料頻繁被逐出快取；儲存效能不足則可能在 CPU 看似閒置時仍造成高延遲。對文件型、鍵值型或分析型服務，也要確認資料分布、分割鍵、掃描範圍與背景壓縮等引擎特性。規格應由最受限制的資源決定，而不是只看平均 CPU。
- 基準負載：記錄平日穩定時段的交易量、延遲與資源使用，作為日後比較基線。
- 尖峰負載：用促銷、月底結算、資料匯入或報表產生等真實情境進行壓力測試。
- 查詢品質：檢查慢查詢、執行計畫、缺漏索引與全表掃描，先排除可修正的浪費。
- 連線模式：確認應用程式是否使用連線池，以及服務擴展後會不會超過資料庫連線上限。
容量估算要包含成長、日誌與維護空間
儲存容量不能只用目前資料表大小估算。完整模型應包含索引、交易日誌、暫存空間、版本資料、備份保留，以及重建索引或執行大型資料遷移時所需的額外空間。先從每日或每月的淨新增資料量推估未來容量，再確認成長是否線性；IoT 遙測、稽核紀錄與聊天歷史往往會隨裝置、使用者或整合來源增加而加速。保留政策也應在此階段確定，否則資料庫會被當成永久檔案庫。
儲存類型的選擇要同時考慮容量、IOPS、吞吐量與延遲。大量小型隨機交易重視 IOPS 與尾端延遲；備份、匯入與分析掃描則較依賴連續吞吐。部分服務會讓儲存自動擴充，但擴充通常不等於效能同步提升，也不能取代容量告警。工程團隊應設定可操作的門檻，並確認縮減容量是否受限，因為錯估過大的磁碟往往不像運算規格那樣容易調回。
備援規格應從 RTO 與 RPO 反推
高可用不是勾選多可用區就結束。先定義服務可容忍多久中斷，也就是 RTO；再定義最多可以遺失多少資料，也就是 RPO。跨可用區同步備援主要處理單一節點或機房層級故障，但不一定能防止誤刪、錯誤部署或資料被應用程式覆寫。這些情境仍需要自動備份、時間點還原、不可變或隔離副本，以及定期演練過的復原程序。
唯讀副本可以分擔查詢，也能提供額外復原選項，但非同步複寫會有延遲，不應假設副本永遠具備最新資料。跨區域複寫適合區域災難復原或資料就近讀取，代價則是複寫流量、更多執行個體、較複雜的故障切換，以及可能涉及的資料落地限制。設計時還要確認應用程式能否重連、DNS 或端點切換需要多久、未完成交易如何處理，並用實際演練驗證，而不是只接受平台標示的可用性名稱。
- 節點故障：驗證平台自動切換期間，應用程式的逾時、重試與連線重建行為。
- 資料損毀：驗證時間點還原所需時間，以及還原後如何核對與補接資料。
- 區域中斷：確認跨區副本、密鑰、網路、應用服務與操作權限都能在備援區域使用。
用完整成本模型做選擇，並保留調整路徑
月費估算至少要包含主要節點、備援節點、唯讀副本、儲存、配置型 I/O、備份超額、跨區或跨區域流量、監控，以及商用引擎授權。也要納入非生產環境與災難復原演練的支出。承諾用量或預留方案適合已穩定運行的基線容量；尚在快速成長、資料模型未定或可能更換引擎的系統，應先保留彈性，避免為錯誤架構鎖定長期成本。
實務上可先建立一個能承受正常尖峰並保留適度餘裕的起始規格，再透過負載測試與正式監控校正。監控應將資料庫指標與 API 延遲、佇列深度、錯誤率及部署事件放在同一時間軸，才能判斷瓶頸在哪一層。每次調整都記錄原因、前後指標與成本變化；同時預先定義垂直升級、增加副本、分區、封存冷資料或拆分服務的觸發條件。若系統牽涉 LINE、ERP、CRM 或 IoT 資料流，與整合團隊共同測試端到端尖峰，通常比單獨壓測資料庫更接近真實風險。