資料庫升級路線：從最便宜一路走到 Aurora Serverless
寫給耀達 Lite 雲端進銷存（2026-11-02）。接續 aurora-serverless.html、postgres-design-sql.html。
起因：Jesse 看完 Aurora Serverless 的費用，覺得一開始負擔不起，想知道能不能從最便宜的方案開始，再一步一步升上去。
價格來自 AWS 東京價目表（2026-10-29 發布）的隨選價，一律是美元、未稅，一個月算 730 小時，不含資料傳輸費。容量、儲存量和 I/O 都是假設。標示 Claude 的看法 的內容都還沒拍板。
1. 先講結論
- 可以。AWS 有官方的搬遷路徑，可以從 RDS PostgreSQL 開始，之後搬到 Aurora，再換成 Serverless。全程都是 PostgreSQL，程式幾乎不用改。
- 起步約每月 21 美元：RDS
db.t4g.micro（1 GiB 記憶體）加 20 GB 儲存。 - 只有一步比較麻煩：從 RDS 搬到 Aurora，要短暫停止寫入、換連線字串。其他升級都是在主控台改設定。
- 不一定要走到終點：Aurora Serverless 變成「需要時才去」的選項。如果負載一直很平穩，留在 RDS 可能反而比較划算。
- 最大的取捨：前期省錢的代價是沒有自動擴充、要自己盯監控，單機階段故障時也沒有自動接手。
- 已拍板（Jesse 2026-11-02，Claude 推薦）：第一階段改用 RDS，把 Aurora 從「起點」改成「升級目標」（第 12 節）。後面各階段的順序與時機仍是 Claude 的看法。
2. 為什麼現在看到的費用比較高
有一部分是 Claude 之前的試算偏高，應該先講清楚：
aurora-serverless.html第 14 節建議試用期最小 1 ACU，光這台主機每月至少 109.50 美元。那是 Claude 的看法，不是 Aurora 的最低價。- 第 11 節的 154.88 美元是假設用量算出來的情境。
- Serverless 真正的優勢是「忙閒差很大、不想管規格」，不是便宜。同樣的記憶體，它比固定規格貴不少：
| 記憶體 | RDS 固定規格（單機） | Aurora 固定規格 | Aurora Serverless 全月停在這裡 |
|---|---|---|---|
| 約 1 GiB | t4g.micro 18.25 美元 | — | 0.5 ACU 54.75 美元 |
| 約 2 GiB | t4g.small 36.50 美元 | — | 1 ACU 109.50 美元 |
| 約 4 GiB | t4g.medium 73.73 美元 | t4g.medium 82.49 美元 | 2 ACU 219.00 美元 |
只比運算費。記憶體相同不代表 CPU 相同：t4g 平時只有 10%～20% 的 CPU 基準（第 9 節），ACU 則附帶相對應的 CPU。所以這不是完全對等的比較，但店家少、負載低的時候，t4g 通常夠用。
3. 六個階段
| 階段 | 配置 | 適合的時機 | 換來什麼 | 升到下一階段要做的事 |
|---|---|---|---|---|
| 0. 開發 | 本機 PostgreSQL。今天的實測就是這樣跑的 | 還沒有外部使用者 | 免費，測試資料隨便灌 | 建 RDS，匯入結構和測試資料 |
| 1. 開放試用 | RDS db.t4g.micro，單機，20 GB |
少數試用店家、還沒有付費 | 有人代管修補、備份 | 改規格，短暫中斷 |
| 2. 店家變多 | RDS db.t4g.small，單機 |
記憶體或 CPU 開始不夠 | 記憶體變 2 倍 | 開雙可用區域，文件寫不會停機，但可能影響效能 |
| 3. 開始收費 | RDS db.t4g.small，雙可用區域 |
有人付錢，停機開始有實際損失 | 故障自動接手，通常 60～120 秒 | 改規格，文件說雙可用區域能減少中斷 |
| 4. 負載變大 | RDS db.t4g.medium，雙可用區域，50 GB。之後可再往上換 |
付費店家變多 | 更多記憶體和 CPU | 搬到 Aurora（第 6 節） |
| 5. 搬到 Aurora | 先固定規格，之後依需要換成 Serverless | 手動換規格太累、忙閒差很大，或需要多台讀取器 | 自動擴充、儲存按用量計費、有讀取器時故障通常不到 60 秒 | — |
跟上一則回覆不同的地方：上一則的表是先升到 t4g.medium 單機，再開雙可用區域。查完價格後，Claude 把順序改了：small 雙可用區域約 79 美元，跟 medium 單機約 81 美元幾乎一樣貴。開始收費時，「主機壞了會自動接手」通常比「多 2 GiB 記憶體」重要，尤其是 Jesse 要一個人 24 小時待命。如果到時候負載已經很緊，當然要先加大。
4. 各階段費用細項
單價
| 項目 | RDS PostgreSQL | Aurora PostgreSQL |
|---|---|---|
db.t4g.micro（1 GiB） | 單機 0.025／雙可用區域 0.050 美元／小時 | — |
db.t4g.small（2 GiB） | 單機 0.050／雙可用區域 0.101 美元／小時 | — |
db.t4g.medium（4 GiB） | 單機 0.101／雙可用區域 0.202 美元／小時 | 0.113 美元／小時 |
| Serverless | — | 每 ACU 0.15 美元／小時 |
| 儲存 | gp3 單機 0.138／雙可用區域 0.276 美元／GB／月，按配置量 | 0.12 美元／GB／月，按用量 |
| I/O | 基準（20～399 GiB 為 3,000 IOPS）內不另收 | 每 100 萬次 0.24 美元 |
| 超出保留範圍的備份 | 0.095 美元／GB／月 | 0.023 美元／GB／月 |
| 超過 CPU 基準 | 0.075 美元／vCPU 小時 | 0.09 美元／vCPU 小時 |
每月試算
| 配置 | 假設 | 運算 | 儲存 | I/O | 合計 |
|---|---|---|---|---|---|
RDS t4g.micro 單機 | 配置 20 GB | 18.25 | 2.76 | — | 21.01 |
RDS t4g.small 單機 | 配置 20 GB | 36.50 | 2.76 | — | 39.26 |
RDS t4g.small 雙可用區域 | 配置 20 GB | 73.73 | 5.52 | — | 79.25 |
RDS t4g.medium 單機（比較用） | 配置 50 GB | 73.73 | 6.90 | — | 80.63 |
RDS t4g.medium 雙可用區域 | 配置 50 GB | 147.46 | 13.80 | — | 161.26 |
Aurora t4g.medium 固定規格，一台 | 用量 50 GB，I/O 5,000 萬次 | 82.49 | 6.00 | 12.00 | 100.49 |
Aurora t4g.medium 固定規格，兩台 | 同上 | 164.98 | 6.00 | 12.00 | 182.98 |
| Aurora Serverless，平均 0.5 ACU | 用量 20 GB，I/O 另計 | 54.75 | 2.40 | — | 57.15 起 |
| Aurora Serverless，平均 1 ACU | 用量 50 GB，I/O 5,000 萬次 | 109.50 | 6.00 | 12.00 | 127.50 |
| Aurora Serverless，平均 2 ACU，兩台 | 同上 | 438.00 | 6.00 | 12.00 | 456.00 |
單位是美元。RDS 的 I/O 假設沒有超過 gp3 基準。Serverless 的數字假設全月平均就是這個容量，實際會隨負載變動。
第一年大概差多少
舉例：前 6 個月用 t4g.micro、後 6 個月用 t4g.small，約 362 美元。同一年全程用 Serverless 且平均 0.5 ACU，約 686 美元起；平均 1 ACU（20 GB）約 1,343 美元。兩者都還要另加 Aurora 的 I/O 費。這些只是假設情境，主要看資料庫實際多忙。
確定長期使用後：預留執行個體
負載穩定、確定一年內不會改規格時，可以買預留執行個體。下表是一年期不預付的價格：
| 規格 | 隨選 | 一年期不預付 | 省 |
|---|---|---|---|
RDS t4g.micro 單機 | 18.25 | 14.38 | 21% |
RDS t4g.small 單機 | 36.50 | 28.69 | 21% |
RDS t4g.small 雙可用區域 | 73.73 | 57.38 | 22% |
RDS t4g.medium 雙可用區域 | 147.46 | 114.76 | 22% |
Aurora t4g.medium | 82.49 | 70.66 | 14% |
Claude 的看法：前幾個階段不要買。階段變動快時，買了可能很快就用不上，省下的錢不值得綁住。
5. RDS 內怎麼升級
| 要做的事 | 怎麼做 | 會不會停機 | 要注意 |
|---|---|---|---|
| 換主機規格 例如 micro → small |
主控台改 DB instance class，可以立即套用，或等下次維護時段 | 會。文件寫這個變更會造成停機，時間長短沒有寫 | 排在店家不營業的時段。程式要能在連線斷開後重試 |
| 開雙可用區域 | 主控台選「Convert to Multi-AZ」 | 文件寫不會，但可能影響效能 | 新磁碟在背景初始化期間可能變慢。AWS 把在正式環境直接轉換列為不建議的做法，建議先建讀取副本轉換再升格；資料量小時可以評估直接轉換，並排在離峰時段 |
| 加儲存 | 打開儲存自動擴充，設定上限 | 這次沒查 | 只能加，不能減。自動擴充在剩餘空間 10% 以下、持續 5 分鐘時觸發 |
| 加讀取副本 | 建立 Read Replica，費用另計 | 不影響現有主機 | 雙可用區域的備援主機不能拿來讀，報表想分流要另外建副本 |
| 備份 | 建立時設定保留天數 | 從 0 改成非 0（或反過來）會造成中斷 | 主控台預設 7 天、API 預設 1 天，最多 35 天。天數屬於第 9 題 |
6. 從 RDS 搬到 Aurora
整條路線裡最需要規劃的一步。AWS 列了幾種做法：
| 做法 | 流程 | 停止寫入的時間 | 適合 |
|---|---|---|---|
| Aurora 唯讀副本（Claude 的看法：首選） | 建立副本，持續同步，追上後升格 | 只有最後切換那一小段 | 有真實店家在用 |
| 快照搬遷 | 拍快照，再從快照建立 Aurora 叢集 | 要避免資料遺失的話，從拍快照到切換都不能寫入 | 可以接受較長維護時間、資料很小 |
pg_dump／pg_restore |
匯出再匯入 | 整段都不能寫入 | 資料很小，或還沒有真實店家 |
用唯讀副本搬遷的流程
開始前要先確認
- 版本：Aurora 在東京要有相同或更高小版本，而且大版本相同。AWS 的例子是 RDS 11.14 要對應 Aurora 11.14 以上的 11 版。
- 同一個帳號、同一個地區：唯讀副本這條路只能在同帳號、同地區進行。
- 來源限制：來源已經有 Aurora 副本或跨地區副本時，不能再建立。
- 儲存空間：同步期間 WAL 會累積在 RDS 上，要盯
FreeStorageSpace和OldestReplicationSlotLag，避免磁碟滿了。 - 加密：來源有加密時，新叢集也要加密。Claude 的看法：第一天就開加密，之後比較單純。
- Unlogged 資料表：AWS 特別提醒要處理。耀達 Lite 不要用這種表。
如果切換後出問題
切換前都能放棄，RDS 一直是正式資料。切換後只要 Aurora 寫入過新資料，直接切回 RDS 就會遺失那些資料，所以驗收要放在恢復寫入之前，或先寫好反向同步的計畫。
要先演練
Claude 的看法：正式搬遷前，從 RDS 快照還原一台臨時主機，照流程完整跑一次，並量出每一步的時間。這條路線這次完全沒有實測，本機也測不到。
7. 從 Aurora 固定規格換成 Serverless
這一步比前一步簡單很多。AWS 文件的做法是修改既有主機，把主機類型改成 Serverless，第一次換時順便設定 ACU 範圍。
- 可以逐台換：同一個叢集可以混用固定規格和 Serverless。文件說，先把一台主機換成 Serverless，當作切換的第一步，可以減少停機。
- 版本要符合：叢集要達到 Serverless 要求的最低版本。要用到 384 ACU 或縮到 0，版本要求更高（
aurora-serverless.html第 4 節）。 - 可以換回去：文件也有從 Serverless 換回固定規格的流程。如果實際用量穩定、換回去比較便宜，可以再換回去。
- 程式不用改：連線用的 endpoint 不變。
8. 什麼時候該升級
不要依日期或店家數升級，要看資料庫實際的數字。下面的門檻都只是起始值，正式告警留給第 8 題。
| 訊號 | CloudWatch 指標 | 代表 | 通常的動作 |
|---|---|---|---|
| CPU 點數持續下降 | CPUCreditBalance、CPUUtilization | 長期超過基準，快要開始多收費 | 查有沒有慢查詢，再考慮加大規格 |
| 可用記憶體一直很低 | FreeableMemory、SwapUsage | 常用資料放不進記憶體 | 加大規格 |
| 讀取量明顯升高 | ReadIOPS、ReadLatency | 常要去磁碟讀資料 | 先查索引，再考慮加大 |
| 連線數接近上限 | DatabaseConnections | 連線池或容器數太多 | 先調小連線池，再考慮加大 |
| 磁碟快滿 | FreeStorageSpace | 資料或 WAL 累積 | 開自動擴充，檢查 VACUUM |
| 開始收費、停機有實際損失 | 不是指標，是營運決定 | 單機故障風險變得不可接受 | 開雙可用區域 |
| 每個月都要手動換規格，或尖峰離峰差很多 | 長期看 CPUUtilization 曲線 | 固定規格開始不划算或不好管 | 評估搬到 Aurora Serverless |
| 報表拖慢開單 | 資料庫負載、慢查詢紀錄 | 讀寫搶同一台主機 | 加讀取副本，或把報表改背景工作 |
先查再加大：一個缺索引的查詢就能吃掉整台主機的 CPU。升級前先看 pg_stat_statements（postgres-design-sql.html 第 15 節），否則只是花更多錢撐著同一個問題。
9. 便宜方案的限制與風險
9.1 CPU 只有基準，超過要加錢
db.t4g 平時只保證一部分 CPU，靠累積的點數短暫爆發。RDS 的 t4g 固定開 Unlimited 模式，所以用超過基準不會變慢，而是另外收費。
| 規格 | vCPU | 每顆 CPU 基準 | 主機費 | 整月滿載的額外費用（估算） |
|---|---|---|---|---|
t4g.micro | 2 | 10% | 18.25 | 約 98.55 |
t4g.small | 2 | 20% | 36.50 | 約 87.60 |
t4g.medium | 2 | 20% | 73.73 | 約 87.60 |
基準來自 EC2 的 t4g 文件，RDS 文件沒有另列。額外費用是「2 顆 × 730 小時 × 超出基準的比例 × 0.075 美元」的粗估。這只是最壞情況，代表「便宜的主機如果一直很忙，帳單會比規格價高很多」，要設帳單告警。
9.2 記憶體與連線數
RDS PostgreSQL 預設連線上限是 LEAST({DBInstanceClassMemory/9531392}, 5000)。1 GiB 的主機算出來最多約 112 條，實際可用記憶體比 1 GiB 少，所以會更低。
- Npgsql 預設每個容器最多 100 條，兩個容器就可能撞頂，第一天就要調小。Claude 的看法：
t4g.micro上每個容器先設 10 條。 - 記憶體小也代表常用資料放不下，查詢較常去磁碟讀。這對 1 GiB 特別明顯。
9.3 單機階段沒有備援
- 階段 1、2 是單機：主機或可用區域故障時不會自動接手。實際要停多久，這次沒查到官方數字。
- SLA 也不同：RDS 雙可用區域的補償門檻是月可用率 99.95%，單機是 99.5%。SLA 只是達不到時的補償標準，不是保證。99.5% 換算約每月 3.65 小時，99.95% 約 22 分鐘。
- 雙可用區域不是沒有中斷：故障接手通常 60～120 秒，大交易或復原較久時會更長。程式要能重試。寫入延遲也可能變高。
- 跟 24 小時待命的關係：單機階段半夜出事就是 Jesse 要處理。這是省錢的代價，開始收費時要重新評估。
9.4 儲存只能加不能減
RDS 按配置量收費，配置了就算沒用滿也要付，而且不能縮小。所以從 20 GB 開始，打開自動擴充並設好上限，不要一開始就配很大。Aurora 則按實際用量計費。
9.5 換規格有中斷
Serverless 變大變小不會中斷，固定規格每次換都會。階段 1～4 的每次升級都要找時間，而且 Jesse 要事先判斷「快不夠了」。
9.6 跟 Aurora 比少了什麼
| 項目 | RDS PostgreSQL 是怎樣 | Aurora PostgreSQL 是怎樣 |
|---|---|---|
| 容量 | 固定規格，手動換，有中斷 | Serverless 自動變大變小，不中斷 |
| 儲存 | 按配置量，不能縮 | 按用量，自動長大 |
| 資料副本 | 主機的磁碟；雙可用區域時另一區有同步備援 | 6 份，分散在 3 個可用區域，就算只開一台也一樣 |
| 故障接手 | 雙可用區域通常 60～120 秒 | 有讀取器時通常不到 60 秒；沒有讀取器時重建通常不到 10 分鐘 |
| I/O 費 | gp3 基準內不另收 | 標準方案按次收費 |
| 快速複製 | 沒查 | 有 fast clone，適合跑重報表或測試 |
| 縮到 0 | 沒有。可以手動停機，但最多 7 天後會自動開回來 | Serverless 可以自動暫停 |
10. 從第一天就要準備的事
只要守住下面這些，每一步升級都只是換主機，不用改程式。
- 只用 PostgreSQL 標準功能：RLS、複合外鍵、鍵集分頁、
set_config都是引擎本身的行為。postgres-design-sql.html的實測跑在 PostgreSQL 18.6 上，文件的設計規則在 RDS 上應該都適用。 - 不要依賴 Aurora 或 RDS 專屬功能：例如 Query Plan Management（
apg_plan_mgmt）只在 Aurora 有。 - 選 Aurora 也支援的版本：RDS 的小版本可能比 Aurora 先推出。Claude 的看法：大版本選定之後，注意自動小版本升級，免得 RDS 跑到 Aurora 還沒有的版本，暫時走不了唯讀副本這條路。
- 連線字串放設定檔，分寫入、讀取兩個：一開始都指向同一台，之後換主機或加讀取器不用改程式。
- 程式要能重試斷線：換規格、故障接手都會斷線。重試元件第一天就要做（
postgres-design-sql.html第 9 節）。 - 開加密與自動備份：開加密，備份天數依第 9 題決定。
- 每張表都有主鍵、不用 unlogged 表：搬遷和 Blue/Green 都會用到。
- 一開始就有監控：第 8 節的指標加上帳單告警。沒有數字就無法判斷該不該升級。
- 資料庫改動用遷移工具管理：環境換來換去時，結構才不會漂移。
主鍵與 RDS Proxy 的互動：第一版不用 Proxy 的話，bigint 序列沒有釘住問題，這也跟 postgres-design-sql.html 第 4 節的看法一致。
11. 其他起步方案比較
| 方案 | 每月約 | 好處 | 代價 |
|---|---|---|---|
RDS t4g.micro（Claude 的看法：推薦） |
21 美元 | 最便宜的正式代管選項之一，有官方路徑搬到 Aurora，帳單好預估 | 1 GiB 很小、單機沒有備援、要手動升級 |
RDS t4g.small |
39 美元 | 記憶體多一倍，比較不會一開始就卡住 | 試用期可能用不到，多花 18 美元 |
| Aurora Serverless，最小 0.5 ACU | 57 美元起 | 以後不用搬、不用手動換規格，會自動擴充 | 忙起來費用跟著升高，帳單難預估；還有 I/O 費 |
| Aurora Serverless，最小 0（自動暫停） | 依使用時數 | 沒人用時不付運算費，只付儲存；同樣不用搬 | 暫停後第一個連線要等約 15 秒，超過 24 小時可能 30 秒以上；閒置連線會擋住暫停；暫停時 VACUUM 不會跑。適合測試區，不適合店家正在用的正式環境 |
Aurora 固定規格 t4g.medium |
約 100 美元 | 一開始就在 Aurora，之後改主機類型就能換 Serverless，不用搬 | 是這張表最貴的；Aurora 沒有更小的 t4g 規格可選（這次的價目表只查到 medium 起） |
| Lightsail 資料庫 | 約 15 美元 | 最便宜，含 40 GB，方案簡單 | 只比 RDS 便宜約 6 美元。AWS 的 Aurora 搬遷文件沒有列這條路，之後可能要多搬一次 |
| 自己裝在 EC2 或 VPS | 更低 | 最便宜 | 作業系統、備份、修補都要自己顧，跟「一個人維運、不顧主機」的前提相反。第 3 題已經排除 |
12. 已拍板的事
第一階段從 Aurora Serverless 改成 RDS PostgreSQL db.t4g.micro，把 Aurora 改成之後的升級目標（Jesse 2026-11-02 選，Claude 推薦）。
理由：Jesse 的前提是固定月費越低越好、店家變多時升級要方便。店家數還不知道的時候，每月 21 美元起步、看數字才升級，比一開始就付 Serverless 的費用合理。原本選 Serverless 的主要理由是「一個人維運不想管規格」，這個理由等店家變多、真的開始累人時再兌現也不遲。
- 店家看到的差別：平常看不出來。少的是自動擴充和快速故障接手，負載變大要 Jesse 自己升級，單機階段故障時要等比較久。
- 接受的代價：要盯 CPU 點數和記憶體、找時間換規格，以及一次 RDS 到 Aurora 的搬遷（如果真的走到那一步）。
- 沒選的：一開始就用 Aurora Serverless，可以少一次搬遷、不用手動換規格，但每月至少多付約 36 美元（平均 0.5 ACU 時），帳單也比較難預估。其他方案見第 11 節。
這個決定改了第 3 題原本定的資料庫，也會影響第 7 題（環境）、第 8 題（監控）、第 9 題（備份）。各階段的順序與時機還沒拍板。
另外，資料庫不是唯一的固定費用：ALB 粗估每月約 38 美元，比階段 1 的資料庫還貴，Fargate、CloudFront、監控也都還沒合起來試算。如果整體預算是主要考量，下一步應該算一次整套月費，再決定哪裡值得省。
13. 還沒查證的事
- 整條搬遷路徑都沒有實測：RDS 到 Aurora 的切換時間、Aurora 固定規格換 Serverless 的實際中斷，都要到 AWS 上演練。
- 換規格會停多久：文件只寫會停機，沒有數字。
- 單機故障要停多久：沒查到官方數字。
t4g的 RDS 基準：10%、20% 來自 EC2 文件，RDS 文件沒有另外列出。- 東京目前 RDS 與 Aurora 各有哪些小版本：這次沒查，建置時用
describe-db-engine-versions確認。 - RDS 上的 RLS 與效能：引擎相同，應該跟本機實測一樣，但沒有實際在 RDS 上跑過。1 GiB 主機上的實際效能也還沒測。
- 免費方案與抵用金：AWS 的免費方案是否適用這個帳號，這次沒查。
- Aurora 的 SLA：這次只查了 RDS 的 SLA 頁面。
- 整套系統的月費：還沒有合起來算。
14. 名詞對照
| 名詞 | 白話 |
|---|---|
| RDS PostgreSQL | AWS 代管的標準 PostgreSQL，資料放在主機掛的磁碟，選固定規格 |
| Aurora PostgreSQL | AWS 重新設計儲存層、跟 PostgreSQL 相容的資料庫 |
| 固定規格（provisioned） | 自己選主機大小，整月同樣價錢 |
db.t4g | 可爆發型主機：平時只保證一部分 CPU，便宜，適合負載不高的情況 |
| CPU 基準、點數 | 平時保證的 CPU 比例；低於基準時累積點數，超過時消耗 |
| Unlimited 模式 | 點數用完還能繼續爆發，但超出的部分要付費 |
| 單機（Single-AZ） | 只有一台主機，放在一個可用區域 |
| 雙可用區域（Multi-AZ） | 另一個可用區域有一台同步的備援，故障時自動接手。備援平常不能讀，費用大約兩倍 |
| 讀取副本（Read Replica） | 可以讀的非同步副本，用來分擔查詢 |
| Aurora 唯讀副本搬遷 | 讓一個 Aurora 副本持續同步 RDS，追上後升格成獨立叢集 |
| 升格（promote） | 副本脫離同步，變成可以寫入的獨立資料庫 |
| WAL、LSN | 資料異動的日誌，以及日誌的位置編號。比對位置就知道副本有沒有追上 |
| SLA | 服務水準協議：可用率低於標準時，AWS 給的補償 |
| 預留執行個體 | 承諾使用一年或三年，換取較低單價 |
15. 來源
價格
- AWS 價目表 API：RDS 東京（2026-10-29 發布，含 RDS、Aurora、CPU 點數、預留價）
- AWS 價目表 API：Lightsail 東京
RDS
- DB instance class types（
t4g的 Unlimited 模式） - EC2 burstable credits and baseline（CPU 基準）
- Settings for DB instances（哪些變更會停機、儲存只能加）
- Storage autoscaling
- RDS storage（gp3 基準）
- Multi-AZ DB instance deployments
- Converting to Multi-AZ（不停機、效能影響、最佳做法）
- Failing over a Multi-AZ DB instance（60～120 秒）
- Backup retention period
- RDS quotas and constraints（
max_connections公式） - Stopping a DB instance（7 天後自動開回）
- Amazon RDS SLA
Aurora 與搬遷
- Migrating data to Aurora PostgreSQL（搬遷選項）
- Migrating using an Aurora read replica（版本要求、流程、指標、限制）
- Migrating using a snapshot
- Managing Aurora serverless（固定規格與 Serverless 互換）
- High availability for Aurora（故障接手時間）
- Scaling to Zero ACUs（自動暫停）