為什麼你該考慮使用 RDS，而不是繼續自建 EC2 維運 Database

很多團隊一開始使用 AWS 時，會很自然地把資料庫裝在 EC2 上。

原因也很直覺：以前在 IDC 或 VM 上就是這樣做的；自己安裝 MySQL、PostgreSQL 或 SQL Server，看起來比較自由，也比較容易沿用既有的維運方式。只要開一台 EC2、掛上 EBS、設定 Security Group，再把資料庫安裝起來，服務就可以開始連線。

但資料庫真正困難的地方，通常不是「安裝」。

真正困難的是持續維運：

• 磁碟快滿時，能不能在出事前擴容？
• 備份是否每天成功？真的還原過嗎？
• 發生誤刪資料時，能不能回到指定時間點？
• 連線數暴增時，是應用程式先倒，還是資料庫先倒？
• OS、資料庫版本與安全 Patch 要誰排程、誰驗證、誰負責回復？
• 監控是只看 CPU，還是能看出 IOPS、Latency、Connection 與 FreeStorageSpace 的異常？

如果這些事情都要自己處理，EC2 上的資料庫就不是一台便宜的 VM，而是一套需要長期投入人力的資料庫平台。

這篇文章不是說「所有資料庫都必須搬到 RDS」。而是想整理：在大多數常見的 Web、內部系統與企業應用場景中，為什麼應該優先考慮 RDS，而不是繼續把資料庫當成一台普通 EC2 來維運。

自建資料庫最大的成本不是 EC2 費用

自建資料庫常見的誤判，是只比較帳單上的 Instance 價格。

例如：

• 一台 EC2 + EBS 好像比同規格 RDS 便宜。
• 自己裝資料庫不用被 RDS 的限制綁住。
• 既有備份腳本可以沿用，不需要額外學習。

這些都不一定錯，但它們只看到了資源成本，沒有把維運成本放進去。

當資料庫放在 EC2 上，你至少要自己負責：

維運項目	自建 EC2 Database	Amazon RDS
OS 維護	自行更新、重啟、排程	由 RDS 管理底層 OS 維護
資料庫安裝	自行安裝與設定	建立時選擇 Engine 與版本
儲存擴容	自行擴 EBS、檔案系統與資料庫設定	可使用 Storage Autoscaling
備份	自行排程、保存、清理、告警	Automated Backup、Manual Snapshot、AWS Backup
PITR	自行管理 Binlog/WAL/Archive Log	可還原到備份保存期間內的時間點
高可用	自行建 Standby、Replication、Failover	可選 Multi-AZ 部署
監控	自行安裝 Agent 與整合工具	CloudWatch、Enhanced Monitoring、Performance Insights
Patch	自行追蹤 CVE、測試與套用	RDS 提供 Maintenance Window 與 Pending Maintenance

當然，RDS 不是免費幫你處理所有事情。你仍然要決定規格、備份保存期、維護時段、參數設定、監控告警與權限控管。但 RDS 把許多底層工作從「你要自己設計並執行」變成「你要設定策略並驗證結果」。

這兩件事的差異非常大。

磁碟容量：不要等到 storage full 才處理

資料庫最怕的狀況之一，是磁碟被寫滿。

EC2 自建資料庫雖然也可以擴 EBS，但實際流程通常不只按一個按鈕：

1. 發現磁碟快滿。
2. 擴大 EBS Volume。
3. 擴充 Partition 或 File System。
4. 確認資料庫使用的目錄能看到新容量。
5. 觀察 IOPS、Throughput 與延遲是否跟得上。

這些步驟並不難，但在半夜警報響起、磁碟只剩 2% 時，任何手動步驟都會變成風險。

RDS 提供 Storage Autoscaling。啟用後，當 RDS 偵測到可用空間不足，會依條件自動增加儲存容量。它不是萬靈丹，因為 RDS 儲存擴容後不能直接縮小，而且大型資料匯入仍可能讓資料庫短時間進入 storage full 狀態。因此還是要設定合理的初始容量、最大容量，以及針對 FreeStorageSpace 建立告警。

但它至少把最常見的「忘記擴容量」風險降下來。

Storage Autoscaling 是保護機制，不是容量規劃的替代品。資料庫若持續快速成長，仍要定期檢查成長率、保留策略、索引膨脹與歸檔機制。

備份與 PITR：有備份不代表能還原

很多系統都有備份，但真正發生事故時才發現：

• 備份其實失敗好幾天了。
• 備份檔存在，但沒有人知道還原步驟。
• 還原時間太長，超過系統能接受的 RTO。
• 只能還原到昨天凌晨，無法回到誤刪前 5 分鐘。
• 備份和正式資料放在同一個權限邊界，誤刪或被入侵時一起消失。

自建資料庫當然也能做得很好。MySQL 可以搭配 mysqldump、XtraBackup、Binary Log；PostgreSQL 可以使用 pg_dump、pg_basebackup、WAL archive；SQL Server 也有完整備份、差異備份與交易紀錄備份。

問題是，這些都需要團隊自己設計、實作、監控、演練與交接。

RDS 的 Automated Backup 會在備份視窗建立 Snapshot，並保存交易紀錄，讓你可以在備份保存期間內做 Point-in-Time Recovery。對一般 RDS DB Instance，備份保存期可以設定為 0 到 35 天；設定為 0 代表停用自動備份。

這裡最重要的觀念是：PITR 還原不是覆蓋原本的 DB，而是建立一個新的 DB Instance。這反而是好事，因為你可以先驗證資料，再決定要讓應用程式切換到新資料庫、抽資料補回原庫，或只拿它來查詢事故前狀態。

如果組織已經使用 AWS Backup，也可以把 RDS 納入統一的 Backup Plan。AWS Backup 可以集中管理備份策略、保存週期、跨帳號或跨區複製，以及 Vault Lock 等治理需求。對有稽核、合規或多帳號管理需求的公司來說，這比每個團隊各自設定備份更容易治理。

備份策略至少要回答三個問題

不論使用 RDS 原生備份或 AWS Backup，都應該先定義：

問題	代表意義
RPO 是多少？	最多能接受遺失多久的資料
RTO 是多少？	最久能接受多久恢復服務
還原演練多久做一次？	確認備份真的可用，而不是只看狀態成功

很多團隊會設定每天備份，卻沒有做還原演練。這樣只能證明「有產生備份」，不能證明「事故時能恢復」。

我會建議至少在非正式環境定期做一次還原演練，並記錄：

1. 還原一份指定時間點的 DB 需要多久。
2. 應用程式切換連線字串需要多久。
3. 權限、Parameter Group、Option Group、Security Group 是否有遺漏。
4. 還原後的資料是否符合預期。

這些結果會比「我們有開備份」更有價值。

RDS Proxy：不要讓連線數成為第一個瓶頸

資料庫連線不是免費資源。

每一條連線都會消耗資料庫端的記憶體與 CPU。當應用程式水平擴展、Container 數量增加，或 Lambda 在短時間內大量啟動時，很容易出現 Connection Storm。結果不是查詢真的太重，而是資料庫忙著建立、驗證與維持大量連線。

在自建資料庫上，你可能會使用 PgBouncer、ProxySQL、HAProxy 或應用程式內建 Connection Pool。這些工具很好，但同樣要自己部署、監控與維護。

RDS Proxy 則是 AWS 提供的 Managed Proxy。它可以在應用程式和 RDS 之間維持連線池，重複使用既有連線，降低頻繁建立連線的成本。搭配 Multi-AZ 或故障切換時，RDS Proxy 也能協助應用程式更穩定地重新連到可用的 DB。

RDS Proxy 特別適合：

• Lambda 或短生命週期工作負載。
• 連線數容易暴增的 API 服務。
• 應用程式端 Connection Pool 設定不一致的環境。
• 希望搭配 Secrets Manager 管理資料庫憑證的系統。

但它不是查詢效能優化工具。如果 SQL 本身很慢、索引設計不良、交易持有太久，RDS Proxy 不會神奇地讓查詢變快。它主要處理的是連線管理與故障切換時的穩定性。

CloudWatch 與 Enhanced Monitoring：資料庫要看對指標

自建資料庫常見的監控方式，是先看 EC2 的 CPU、Memory、Disk Usage。這些很重要，但對資料庫來說還不夠。

資料庫問題經常出現在：

• Connection 數量持續升高。
• FreeStorageSpace 快速下降。
• ReadLatency 或 WriteLatency 變高。
• ReadIOPS、WriteIOPS 或 Throughput 撞到儲存限制。
• CPU Credit 耗盡。
• Replica Lag 擴大。
• Lock 或慢查詢增加。

RDS 預設會把多種指標送到 CloudWatch，並可搭配 CloudWatch Alarm 建立告警。需要更細的 OS 層級資訊時，可以啟用 Enhanced Monitoring；需要分析 DB Load、等待事件與 SQL 層級瓶頸時，可以使用 Performance Insights 或 CloudWatch Database Insights。

這裡的重點不是「工具越多越好」，而是要先建立 Baseline。

例如，CPU 70% 在某些系統可能很健康，因為它本來就是 CPU-bound；但在另一個平常只有 15% 的系統，突然升到 70% 可能就代表查詢計畫改變或流量異常。沒有 Baseline，告警門檻就容易變成猜測。

我通常會先針對正式資料庫設定這些基本告警：

指標	觀察目的
CPUUtilization	是否長期高於平常基準
FreeableMemory	記憶體是否不足或發生壓力
FreeStorageSpace	儲存空間是否接近告警門檻
DatabaseConnections	連線數是否異常增加
ReadLatency / WriteLatency	儲存延遲是否惡化
ReadIOPS / WriteIOPS	I/O 是否接近瓶頸
ReplicaLag	Read Replica 是否追不上 Primary

如果只有一個告警，我會先選 FreeStorageSpace。因為資料庫磁碟滿掉時，修復壓力通常最大，而且可能影響寫入、備份與後續維護。

Patch 與 Maintenance Window：維護不能靠記憶

資料庫不只要維護資料庫引擎，還要維護底層 OS、硬體與憑證。

在 EC2 自建資料庫時，這些事情通常會落到團隊自己身上：

• 追蹤 OS 安全更新。
• 判斷資料庫 Minor Version 是否需要升級。
• 安排停機或滾動更新。
• 準備回復方案。
• 更新後驗證應用程式相容性。

如果團隊有成熟的 SRE 或 DBA 流程，這些可以做得很好。但如果資料庫只是某個應用團隊「順手維護」的資源，它很容易變成長期沒有人敢動的基礎設施。

RDS 提供 Maintenance Window，讓你控制維護事件啟動的時間。某些更新可以選擇立即套用或排到下一個維護窗口；必要的安全或可靠性更新則不能無限期延後。對 Multi-AZ 部署，RDS 在部分維護場景下可以先處理 Standby，再進行 Failover，以降低影響。

這不代表 RDS Patch 完全沒有風險。你仍然應該：

1. 把 Maintenance Window 設在流量最低的時段。
2. 開啟事件通知，知道何時有 Pending Maintenance。
3. 在非正式環境先測試 Engine 升級。
4. 確認應用程式 Driver 與 ORM 是否相容。
5. 對正式環境保留 Snapshot 與回復流程。

RDS 的價值是讓維護流程變得可被管理，而不是讓你完全不用管維護。

Multi-AZ：高可用不是自己架一台 Standby 就結束

自建資料庫要做到高可用，通常會牽涉：

• Primary 與 Standby 的同步或非同步複寫。
• Failover 判斷。
• DNS 或連線端點切換。
• Split-brain 防護。
• 備份要從哪一台執行。
• 維護期間如何避免長時間中斷。

這些都是很專業的工作。最危險的是「看起來有一台備機」，但從來沒有演練過 Failover。等 Primary 出事時，才發現 Standby 延遲太多、權限不完整、應用程式不會自動重連，或 DNS TTL 讓切換時間超出預期。

RDS Multi-AZ 可以讓資料庫在不同 Availability Zone 之間具備更好的可用性與耐久性。它不是用來分擔讀取流量的功能；如果要讀寫分離，通常要另外使用 Read Replica。Multi-AZ 的主要價值，是在基礎設施故障、維護或某些更新情境下，降低單點故障造成的影響。

正式環境若資料庫是關鍵元件，我會把 Multi-AZ 視為預設選項，而不是事後有預算才補的項目。

什麼情況仍然適合自建資料庫？

RDS 很適合多數場景，但不是所有場景。

以下情況仍可能需要自建：

• 需要 RDS 不支援的資料庫引擎、版本或 Extension。
• 需要 OS 層級權限或特殊 Kernel、檔案系統、Agent。
• 需要非常客製化的備份、複寫或拓樸。
• 授權模式或商業合約不適合 RDS。
• 延遲、效能或硬體需求超出 RDS 可提供的範圍。
• 團隊本身已有成熟 DBA/SRE 能力，且自建能帶來明確收益。

這些都是真實理由。但如果理由只是「我們以前都這樣做」或「RDS 看起來比較貴」，就應該重新把人力、事故風險、維護成熟度與還原能力一起算進去。

導入 RDS 前應該先確認的事

如果要從 EC2 自建資料庫搬到 RDS，我建議先做一份檢查表。

規格與容量

• 目前資料庫大小與近 3 到 6 個月成長率。
• CPU、Memory、IOPS、Throughput 與 Connection 基準值。
• 是否需要 Provisioned IOPS 或 gp3 的指定 IOPS / Throughput。
• Storage Autoscaling 的初始容量與最大容量。

可用性與還原

• 是否啟用 Multi-AZ。
• Automated Backup 保存天數。
• 是否需要 AWS Backup 做跨帳號、跨區或長期保存。
• RPO 與 RTO 是否已文件化。
• 是否完成還原演練。

應用程式相容性

• Driver、ORM 與資料庫版本是否相容。
• 是否使用 RDS 不支援的權限、Plugin、Extension 或系統資料表操作。
• 連線字串、DNS、TLS、憑證是否需要調整。
• 是否需要 RDS Proxy。

維運與安全

• Parameter Group 與 Option Group 如何管理。
• Maintenance Window 與 Backup Window 是否避開高峰。
• CloudWatch Alarm、Event Notification、Log Export 是否完成。
• IAM、Security Group、KMS、Secrets Manager 是否符合公司規範。

遷移本身可以用多種方式完成，例如 Dump/Restore、Snapshot Restore、原生複寫、AWS Database Migration Service。真正要先釐清的不是工具，而是停機時間、資料一致性與回復方案。

結論

把資料庫架在 EC2 上不是錯。錯的是低估資料庫維運的重量。

資料庫不是一般應用程式伺服器。它牽涉資料正確性、備份還原、容量成長、效能瓶頸、安全修補與事故回復。當團隊沒有足夠時間持續處理這些事情時，自建資料庫看似省下 RDS 費用，實際上可能只是把成本藏到未來的事故與人力裡。

RDS 的價值，不只是「AWS 幫你裝好資料庫」。它真正提供的是一套受管理的資料庫維運基礎：

1. Storage Autoscaling 降低容量不足風險。
2. Automated Backup 與 PITR 讓還原策略更容易落地。
3. AWS Backup 可以集中治理備份與保存政策。
4. RDS Proxy 改善連線管理與故障切換韌性。
5. CloudWatch、Enhanced Monitoring 與 Performance Insights 提供可觀測性。
6. Maintenance Window 讓 Patch 和維護更可控。

如果你的團隊已經有成熟 DBA 能力，自建可能仍然有它的價值。但對多數產品團隊來說，把時間花在資料模型、查詢效能、資料生命週期與應用穩定性，通常比自己維護底層資料庫平台更值得。

能被託管的基礎工作，就交給 Managed Service。把工程能量留給真正需要你理解業務與系統脈絡的地方。

參考資料

• Amazon RDS：Managing capacity automatically with Amazon RDS storage autoscaling
• Amazon RDS：Introduction to backups
• Amazon RDS：Backup retention period
• Amazon RDS：Restoring a DB instance to a specified time
• AWS Backup：Amazon Relational Database Service backups
• AWS Backup：Continuous backups and point-in-time recovery
• Amazon RDS：Amazon RDS Proxy
• Amazon RDS：Monitoring Amazon RDS metrics with Amazon CloudWatch
• Amazon RDS：Monitoring OS metrics with Enhanced Monitoring
• Amazon RDS：Maintaining a DB instance