Aurora PostgreSQL Serverless v2 說明書
寫給耀達 Lite 雲端進銷存的部署討論（2026-11-02）。接續 db-scaling.html、cache.html、alb.html。
前提：AWS 東京、ECS Fargate、ASP.NET Core，租戶隔離用共用資料表＋RLS。價格來自 AWS 東京價目表（2026-10-29 發布），一律是美元、未稅。標示「Claude 的看法」的內容都還沒拍板。
1. 先講結論
- 它是什麼：AWS 代管的 PostgreSQL 資料庫，CPU 和記憶體會跟著負載自動增減，不用事先挑主機大小，也不用自己顧主機。
- 怎麼算錢：東京每 ACU 每小時 0.15 美元（1 ACU 約 2 GiB 記憶體），按秒計費；資料另外按實際用量收，每 GB 每月 0.12 美元。
- 資料很安全：每筆資料自動存 6 份、分散在 3 個可用區域，就算只開一台主機也一樣。
- 只開一台不等於高可用：主機故障時，沒有讀取器要重建主機，通常不到 10 分鐘；有讀取器則通常不到 60 秒，但運算費大約變兩倍。
- 不一定比較便宜：負載全天穩定時，固定規格的主機常常更划算（第 12 節）。它贏在忙閒差很大、人力少的情況。
- 這次查到一個要小心的衝突：RLS 常用的
SET、set_config會讓 RDS Proxy 的連線共用失效（第 9 節）。第一版可能要改用程式內建的連線池，建置前要實測。
2. 把名字拆開看
| 名字的部分 | 意思 |
|---|---|
| Amazon Aurora | AWS 重新設計儲存層的關聯式資料庫服務。程式碼和工具用起來跟一般資料庫一樣，資料卻不是存在主機自己的硬碟上（第 3 節）。 |
| PostgreSQL | 資料庫引擎的種類。AWS 寫明 Aurora PostgreSQL 相容 PostgreSQL，可以用一般驅動程式連線，也能用 pg_dump、pg_restore 搬進搬出。 |
| Serverless | 不是沒有伺服器，也不是沒人用就一定不收錢，而是不用自己挑、自己換主機大小，容量由 AWS 在你設定的範圍內調整。 |
| v2 | 第二代。第一代（v1）架構不同，AWS 文件已標示為淘汰的產品，不要參考 v1 的資料。 |
查資料時會遇到的名稱差異：AWS 最新文件已經改叫「Aurora serverless」，不再寫 v2；價目表、API（ServerlessV2ScalingConfiguration）、主機類型（db.serverless）還留著舊名字。價目表裡每 ACU 每小時 0.10 美元那一筆是第一代，不要拿來試算。
用店面來比喻：傳統資料庫像是簽約租一間固定坪數的店面，生意再淡也付一樣的租金，生意變好要搬家才能換大間。Serverless 像是牆壁會動的店面，人多就自動變大，人少就縮小，按當下的坪數算錢，但你要先決定最小和最大能到多少。
3. 核心設計：運算和儲存分開
這是理解 Aurora 的關鍵。一般資料庫的資料放在主機自己的硬碟裡；Aurora 的主機只負責運算，所有資料都放在一個共用的「叢集磁碟區」。
這樣分開帶來三個直接的好處：
- 資料和主機大小無關：資料可以有好幾 TB，主機同時縮到很小。
- 加讀取器很快：新主機直接接上共用資料，不用複製一份。
- 主機壞了資料還在：刪掉主機也不會刪資料，只有刪除整個叢集才會。
4. ACU：容量的單位
ACU（Aurora Capacity Unit）代表一份約 2 GiB 的記憶體，加上相對應的 CPU 和網路。AWS 每秒量一次目前用了多少，容量可以是 1.5、3.5 這種帶小數的數字。
叢集要設定最小和最大 ACU。範圍對叢集裡的每台主機都一樣，但每台主機的容量各自變動。
| ACU | 約略記憶體 | 每小時（標準方案） | 整個月都停在這裡（730 小時） |
|---|---|---|---|
| 0.5 | 1 GiB | 0.075 美元 | 54.75 美元 |
| 1 | 2 GiB | 0.15 美元 | 109.50 美元 |
| 2 | 4 GiB | 0.30 美元 | 219.00 美元 |
| 4 | 8 GiB | 0.60 美元 | 438.00 美元 |
| 8 | 16 GiB | 1.20 美元 | 876.00 美元 |
| 16 | 32 GiB | 2.40 美元 | 1,752.00 美元 |
| 32 | 64 GiB | 4.80 美元 | 3,504.00 美元 |
| 384 | 768 GiB | 57.60 美元 | 42,048.00 美元 |
表內是單一台主機的運算費，還沒算儲存和 I/O。
可以設定的範圍
| 範圍 | Aurora PostgreSQL 版本要求 |
|---|---|
| 0.5～128 | 13.6、14.3、15.2、16.1 以上 |
| 0.5～256 | 13.13、14.10、15.5、16.1 以上 |
| 0～256 | 13.15、14.12、15.7、16.3 以上 |
| 0～384 | 14.23、15.18、16.14、17.10、18.4 以上，而且平台版本要是 4 |
東京支援到 PostgreSQL 18，平台版本 4 也有。新建的叢集會直接用最新的平台版本。
更正舊文件：db-scaling.html 與 deployment.md 原本寫 Serverless v2 最大 256 ACU（約 512 GiB），這是舊資料。現在 PostgreSQL 版本夠新時，最大是 384 ACU（約 768 GiB）。兩份文件已在 2026-11-02 更正。
5. 怎麼自動變大變小
Aurora 持續觀察每台主機的 CPU、記憶體、網路用量。不夠用就加大，用不完就縮小，每台主機各自決定。
店家感覺得到嗎
- 調整時不用停機：文件寫明，連線開著、交易進行中、資料表鎖著的時候都可以調整，不會中斷正在跑的工作。
- 大部分在同一台實體主機上完成：少數要換主機時，AWS 會處理連線，連線字串不用改。
- 最小一步 0.5 ACU：目前容量越大，每一步越大，所以升得越快。AWS 沒有公開固定的秒數。
最小值不能只看省錢
| 最小值設太低的代價 | 說明 |
|---|---|
| 升得比較慢 | 從很小的容量起跳，每一步小；早上第一波尖峰可能要等一下才撐起來。 |
| 快取被清掉 | 縮小時常用資料會被擠出記憶體，變大後要重新從儲存層讀回來，這段時間會比較慢，也會多產生 I/O 費。 |
| 連線數上限變低 | 最小值設 0 或 0.5 時，PostgreSQL 的連線上限最多 2,000（第 9 節）。 |
| 部分功能不建議 | AWS 建議開 Performance Insights 時最小 2 ACU，光一台主機每月下限就是 219 美元。 |
最大值就是預算保險絲
整個叢集最多可能花到「主機台數 × 最大 ACU」。例如兩台主機、最大 16 ACU，全力跑一整個月的運算費上限是 3,504 美元。設太高，寫壞的查詢可能燒很多錢；設太低，主機撞頂、記憶體不夠時會一直重開。
長時間撞頂、因記憶體不足頻繁重開時，主機狀態會變成 incompatible-parameters，這段期間引擎升級等操作會被擋住。AWS 文件也提到，資料庫物件（metadata）很多會增加記憶體負擔。Claude 由此推論，共用資料表在這點上比「一家一個 schema」輕，但這沒有實測過。
6. 縮到 0：自動暫停
最小值設 0，主機閒置一段時間後就會暫停。暫停期間不收運算費，但儲存費照收。
| 項目 | 行為 |
|---|---|
| 閒置多久才暫停 | 可設 5 分鐘到 1 天，預設 5 分鐘 |
| 醒來要多久 | 通常約 15 秒；暫停超過 24 小時，可能要 30 秒以上 |
| 什麼會叫醒它 | 任何連線嘗試，就算密碼打錯也會；改設定、引擎升級、查看記錄檔也會 |
| 剛醒來時 | 從比較小的容量開始往上升，不會回到暫停前的大小 |
| 大量連線同時擠進來 | 部分可能失敗，程式要有重試機制 |
| 進行中的背景工作 | 暫停時，autovacuum（資料庫的清理工作）和 pg_cron 排程會被取消，暫停期間到點的排程會直接跳過 |
不會暫停的情況：只要有任何使用者連線開著就不會暫停。RDS Proxy 會一直開著連線，所以有接 Proxy 的叢集永遠不會暫停。ASP.NET Core 的連線池如果留著閒置連線，一樣會擋住暫停（這點是推論，要實測）。
AWS 把這個功能定位給開發、測試區和內部系統。正式環境店家早上第一個操作要等 15 秒，體驗很差，所以只適合測試區。
7. 儲存層：資料放在哪裡
- 寫入時：同步複製到 6 個儲存節點，分散在 3 個可用區域，帳單只算一份。
- 不用先買容量：會自動長大，最多 256 TiB（依版本），用多少算多少。
- 一個可用區域整個掛掉：叢集設計上可以承受，不會遺失資料，只有短暫中斷。不過主機也要另一區有才接得上（第 8 節）。
刪資料不一定讓帳單變少，這點跟租戶隔離有關
刪掉資料後空間能自動還回去的，只有 DROP TABLE、TRUNCATE TABLE、ALTER TABLE ... DROP PARTITION 這類操作，一般的 DELETE 不算。
耀達 Lite 選了共用資料表，要刪一家沒付費的店只能用 DELETE。這些空間之後可以給新資料重複使用，但帳單不會馬上下降；要真的縮小，還得事後用 pg_repack 重整資料表。這是選 A 時記下的「刪大店要分批慢慢刪」之外，新查到的代價。
兩種儲存方案
| 標準（Standard） | I/O 最佳化（I/O-Optimized） | |
|---|---|---|
| 運算（每 ACU 每小時） | 0.15 美元 | 0.20 美元 |
| 儲存（每 GB 每月） | 0.12 美元 | 0.27 美元 |
| I/O（每 100 萬次） | 0.24 美元 | 不收費 |
| 適合 | I/O 費低於資料庫總費用 25% | I/O 費達到總費用 25% 以上 |
I/O 是資料庫跟儲存層之間的讀寫次數。從標準換成 I/O 最佳化每 30 天可以一次；反過來隨時可以換。Serverless 的主機切換時不用停機、不用重開。所以第一版可以先選標準，看帳單再決定。
8. 寫入器、讀取器與故障接手
寫入器只有一台，負責所有新增和修改。讀取器可以加到 15 台，只能查詢。兩者的差別只在角色，它們讀的是同一份資料。
程式連線時有兩個固定的網址：叢集端點永遠指向目前的寫入器；讀取端點會分散到讀取器。主機換手時，叢集端點的網址不用改。
主機故障時會怎樣
| 配置 | 故障時的動作 | 中斷多久 | 月費影響 |
|---|---|---|---|
| 只有寫入器 | 在同一個可用區域重建主機 | 通常不到 10 分鐘 | 最低 |
| 寫入器＋順位 0、1 的讀取器 | 讀取器升格成寫入器 | 通常不到 60 秒，常常不到 30 秒 | 運算費約兩倍 |
| 只有寫入器，而且整個可用區域掛掉 | 不會自動接手，要手動在別區建新主機 | 看人多快處理 | 最低 |
讀取器的順位決定它的行為
| 順位 | 容量 | 適合用來 |
|---|---|---|
| 0、1 | 跟著寫入器：至少跟寫入器一樣大，接手時立刻撐得住，閒的時候也一起縮小 | 高可用備援 |
| 2～15 | 各自獨立，在叢集範圍內自己伸縮，可以單獨暫停 | 跑報表、全站統計。接手時可能要先變大；最小值太低時複寫可能跟不上 |
讀取器有一點點延遲：文件說通常遠低於 100 毫秒，但不是零。店員剛開完銷貨單，馬上去讀取器查庫存，可能還看到舊的數字。庫存、金額、剛寫入的單據一律讀寫入器，只有報表這類能接受些微延遲的查詢才放讀取器。
讀取器不一定要第一天就開。AWS 文件說，隨時可以替現有叢集加一台其他可用區域的讀取器，轉成多可用區域配置。
整個東京區域掛掉的話要靠 Aurora Global Database（跨區域），AWS 建議此時最小 8 ACU，第一版不需要考慮。
9. 連線數與 RDS Proxy：跟 RLS 的衝突
連線數上限
上限看的是最大 ACU，不是目前容量，所以主機縮小時連線不會被切斷。它是靜態參數，改了最大 ACU 要重開主機才會更新。
| 最大 ACU | 預設連線上限（PostgreSQL，平台版本 4） |
|---|---|
| 1 | 194 |
| 4 | 844 |
| 8 | 1,710 |
| 16 | 3,443 |
| 32 以上 | 5,000 |
最小值設 0 或 0.5 時，上限最多 2,000。
RDS Proxy 想解決的問題
RDS Proxy 擋在程式和資料庫中間，讓很多程式連線共用少量資料庫連線。一筆交易結束就把連線還回去，給別人用，這叫多工（multiplexing）。它也能讓主機換手更快，AWS 寫的是故障接手時間最多減少 66%。
RLS 怎麼知道現在是哪一家店
AWS 的多租戶指引建議由程式在執行時設定一個變數，例如 app.current_tenant，RLS 規則再用 current_setting() 讀它來過濾資料。問題就出在這裡。
文件怎麼寫
RDS Proxy 文件列出，在 Aurora PostgreSQL 上會造成釘住的操作包括：SET 指令、用 set_config 設定參數、PREPARE 等預備陳述式、暫存資料表、宣告游標、DISCARD、nextval 這類序列函式，以及文字超過 16 KB 的陳述式。PostgreSQL 也不支援用來略過釘住的過濾器。
「SET LOCAL 不會釘住」這句話，文件只寫在 MySQL 那一節；PostgreSQL 那一節沒有這個例外。交易範圍內的 set_config(..., true) 或 SET LOCAL 實際會不會釘住，文件看不出來，要實測。
可能的處理方式：
| 做法 | 好處 | 代價 |
|---|---|---|
| 甲、第一版不用 Proxy，用 Npgsql 內建連線池（Claude 的看法） | 少一個零件和一筆費用；容器數量不多時連線數算得出來；縮到 0 也不會被 Proxy 擋住 | 每個容器各有一池，預設每池最多 100 條，容器變多時要把池子調小；故障接手少了 Proxy 的加速 |
| 乙、用 Proxy，先實測交易範圍的設定會不會釘住 | 沒釘住的話可以兩邊都要：RLS 加連線共用 | 若會釘住就白付費，每 ACU 每小時多 0.025 美元 |
| 丙、用 Proxy，把店家編號放進查詢條件，不靠變數 | 不用 SET | RLS 的規則就拿不到店家編號，等於放棄資料庫這一層保護，違反第 5 題的決定，不建議 |
這修正了 db-scaling.html 的說法：那份文件把 RDS Proxy 當成可以直接加上去的一招，當時沒有考慮它跟 RLS 的互動。主鍵如果用 nextval，一樣可能造成釘住，這也跟「主鍵不依賴全庫共用流水號」的方向相符。
10. 備份與還原
- 自動備份不能關：連續、增量，寫入時對效能沒有影響。
- 保留天數：可設 1～35 天，預設只有 1 天，建立時一定要改。
- 還原到任一時間點：可以回到保留期內任何時刻，最新可還原時間通常在 5 分鐘內。
- 手動快照：不會過期，想留超過 35 天就用它。
- 複製（Clone）：用寫入時才複製的方式，建立很快，一開始幾乎不佔空間，一個來源最多 15 個。適合拿正式資料做測試。
- 備份費：不超過叢集大小的部分免費，超過每 GB 每月 0.023 美元。叢集刪掉後留下的快照要收費。
還原一定是建立一個新叢集，不是把舊資料蓋回原本的叢集，也沒有「只還原某一家店」的按鈕。這正是共用資料表的弱點，也是第 9 題要提對策的原因。
可用的機制是：把備份還原或複製成另一個叢集，連進去只查那家店的資料，再寫回正式資料庫。怎麼做、誰有權限、要花多久，留到第 9 題討論。
11. 費用（東京）
| 項目 | 標準方案 | 備註 |
|---|---|---|
| 運算 | 每 ACU 每小時 0.15 美元 | 每台主機各算，按秒計費 |
| 儲存 | 每 GB 每月 0.12 美元 | 按實際用量，6 份只算 1 份 |
| I/O | 每 100 萬次 0.24 美元 | 沒實測前最難估的一項 |
| 備份 | 每 GB 每月 0.023 美元 | 不超過叢集大小的部分免費 |
| RDS Proxy（若使用） | 每 ACU 每小時 0.025 美元 | 依底層主機的 ACU 計費 |
三個試算情境
以下是試算，不是報價。使用量都是假設，I/O 只是舉例，要等壓力測試或上線後才知道。一個月算 730 小時，備份假設都在免費額度內，資料傳輸費沒有算進去。
| 情境 | 假設 | 運算 | 儲存 | I/O | 合計（每月） |
|---|---|---|---|---|---|
| 測試區 最小 0，會暫停 | 每月使用 176 小時（8 小時 × 22 天），平均 1 ACU；資料 5 GB；I/O 200 萬次 | 26.40 | 0.60 | 0.48 | 27.48 美元 |
| 第一版單機 只有寫入器 | 每天 12 小時平均 2 ACU、12 小時 0.5 ACU；資料 50 GB；I/O 5,000 萬次 | 136.88 | 6.00 | 12.00 | 154.88 美元 |
| 有備援 寫入器＋順位 1 的讀取器 | 同上，讀取器跟著寫入器一樣大 | 273.75 | 6.00 | 12.00 | 291.75 美元 |
如果接上 RDS Proxy，第一版單機約多 22.8 美元，有備援約多 45.6 美元。「第一版單機」的 I/O 費只佔 7.7%，遠低於 25%，所以選標準方案；同一個情境改用 I/O 最佳化會變成 196.00 美元。
12. 跟固定規格的資料庫比
Serverless 不一定比較便宜，要看平均用量。下面只比運算費（單機、全月 730 小時、隨選價）：
| 選項 | 規格 | 每小時 | 每月 |
|---|---|---|---|
| Aurora Serverless 平均 0.5 ACU | 約 1 GiB | 0.075 美元 | 54.75 美元 |
| Aurora Serverless 平均 1 ACU | 約 2 GiB | 0.15 美元 | 109.50 美元 |
| Aurora Serverless 平均 2 ACU | 約 4 GiB | 0.30 美元 | 219.00 美元 |
Aurora 固定規格 db.t4g.medium | 2 vCPU／4 GiB（可爆發） | 0.113 美元 | 82.49 美元 |
Aurora 固定規格 db.r6g.large | 2 vCPU／16 GiB | 0.313 美元 | 228.49 美元 |
RDS PostgreSQL db.t4g.micro | 2 vCPU／1 GiB（可爆發） | 0.025 美元 | 18.25 美元 |
RDS PostgreSQL db.t4g.medium（雙可用區域） | 2 vCPU／4 GiB（可爆發） | 0.202 美元 | 147.46 美元 |
RDS PostgreSQL db.r6g.large（雙可用區域） | 2 vCPU／16 GiB | 0.540 美元 | 394.20 美元 |
- 損益平衡點：平均用量低於約 0.75 ACU 時，Serverless 比
db.t4g.medium便宜；低於約 2.1 ACU 時，比db.r6g.large便宜。 - 比較的限制：記憶體相同不代表 CPU 相同。
t4g靠 CPU 點數爆發，用超過要另外付費（東京每 vCPU 小時 0.09 美元）。RDS 的儲存費另計，這張表沒有算進去，儲存架構也不同。 - 什麼時候贏：半夜和假日真的會縮下來，而且不想預先猜主機大小、也不想手動換規格。固定規格換大小時會有短暫中斷，Serverless 不用。
- 同一個叢集可以混用：寫入器固定規格、讀取器 Serverless，或反過來都可以。負載穩定後也能把 Serverless 主機換成固定規格，程式不用改，所以這個選擇不是一次定終身。
Claude 的看法：這裡不是建議換方案。第 3 題選 Serverless 的理由是一個人維運、店家數未知，這點沒有變。只是「Serverless 一定省錢」這句話不成立，等有真實用量後要回來比一次。長期穩定時也可以看預留執行個體或 Savings Plans，這次沒有查。
13. 要監控什麼
表格前四項每秒計算一次，這些都可以設 CloudWatch 告警。門檻留給第 8 題「監控與告警」討論。
| 指標 | 意思 | 要注意的情況 |
|---|---|---|
ServerlessDatabaseCapacity | 目前用了幾 ACU | 費用直接跟它有關，看它是否真的會在半夜縮下來 |
ACUUtilization | 目前容量 ÷ 最大 ACU | 接近 100 表示快撞頂，要加大最大值或加讀取器 |
CPUUtilization | CPU 用量 ÷ 最大 ACU 的 CPU | 跟一般主機算法不同；接近 100 表示撞頂 |
FreeableMemory | 以最大容量來算還有多少可用記憶體 | 接近 0 表示已經撐到最大，又快沒記憶體 |
DatabaseConnections | 目前連線數 | 接近連線上限 |
VolumeBytesUsed | 帳單算的儲存量 | 長期趨勢，也是分割、分片門檻的參考 |
主機狀態 incompatible-parameters | 長期撞頂、因記憶體不足頻繁重開 | 應該立刻通知值班的人 |
14. 對耀達 Lite 的意義
以下都是 Claude 目前的看法，還沒討論，分別屬於第 7、8、9 題。列在這裡是讓這些設定值有個可以討論的起點。
| 階段 | 配置 | 運算費下限（每月） | 理由 |
|---|---|---|---|
| 開發、測試區 | 單台，最小 0，暫停 5 分鐘 | 0 美元 | 沒人用不付運算費；等 15 秒可以接受 |
| 開放試用、還沒有付費店家 | 單台寫入器，最小 1、最大 16 | 109.50 美元 | 不暫停，店家不用等；故障不到 10 分鐘可接受 |
| 開始有付費店家 | 加一台順位 1 的讀取器，放在另一個可用區域 | 219.00 美元 | 故障約 1 分鐘內自動接手，半夜不用人起來處理；一區掛掉也不會全停 |
- 最小值為什麼不是 0.5：先前的討論寫「正式環境建議留 0.5 ACU」，但那句沒有來源。AWS 文件其實是列出考量因素，要看常用資料放不放得下、需要升多快。1 ACU 每月每台多約 55 美元，這是要討論的取捨，上線後看曲線再調。
- 最大值 16：單台全月上限 1,752 美元，當作預算保險絲；連線上限 3,443 條（最小值設 1 時）也夠用。改最大值要重開主機才會更新連線上限。
- 儲存方案：先選標準，I/O 費超過 25% 再換。
- 備份：保留天數建立時就改成 35 天，不要用預設的 1 天。天數屬於第 9 題。
- 連線：第一版不用 RDS Proxy，先用 Npgsql 連線池，並實測 RLS 的設定方式。
- 讀寫分離：程式預留兩個入口；庫存、金額、剛寫入的資料讀寫入器，報表讀讀取器。
- 刪店：退訂店家的資料用夜間分批
DELETE，不急著要回空間。之後如果做了分割，大量資料才能用DROP PARTITION還回去。
15. 還沒查證的事
- RLS × RDS Proxy：
SET LOCAL、set_config(..., true)在 Aurora PostgreSQL 上會不會釘住，文件沒有明講。要用DatabaseConnectionsCurrentlySessionPinned指標實測。 - Npgsql 歸還連線的重設方式：如果歸還時會送
DISCARD ALL，AWS 文件說這會造成釘住。Npgsql 文件這次只查到有No Reset On Close參數，沒有確認預設送什麼。 - 閒置的連線池會不會擋住自動暫停：依文件規則推論會，沒有實測。
- 真實的 ACU 用量、I/O 次數：要等程式寫出來做壓力測試。第 11 節的數字都只是假設。
- 台灣到東京的延遲、個資法對資料放境外的限制、長期預約折扣、免費方案的適用條件：都還沒查。
- 每區各 2 份副本：這次讀到的文件只寫 6 個儲存節點、3 個可用區域，沒有寫每區幾份，第 3 節的圖只是示意。
16. 名詞對照
| 名詞 | 白話 |
|---|---|
| 叢集（Cluster） | 一組主機加上共用的資料 |
| 寫入器（Writer） | 唯一能改資料的主機 |
| 讀取器（Reader／Aurora Replica） | 只能查詢的主機，也是故障時的接班人 |
| ACU | 容量單位，約 2 GiB 記憶體加相對應的 CPU |
| 固定規格（Provisioned） | 事先選好主機大小，不會自動變動 |
| 自動暫停（Auto-pause） | 閒置後縮到 0 ACU，不收運算費 |
| 緩衝快取（Buffer cache） | 放在記憶體裡的常用資料，縮小時會被清掉一部分 |
| 故障接手（Failover） | 寫入器壞掉時，換另一台當寫入器 |
| 順位（Promotion tier） | 0 到 15，數字越小越優先接手 |
| 可用區域（Availability Zone，AZ） | 同一個地區裡彼此獨立的機房群 |
| 釘住（Pinning） | 程式連線綁死一條資料庫連線，無法共用 |
| RLS（Row-Level Security） | 由資料庫依規則過濾每一列，每家店只看得到自己的資料 |
| 時間點還原（PITR） | 把資料還原到保留期內某個時刻，會建立新叢集 |
| 複製（Clone） | 快速建立一份共用底層資料的新叢集，改動時才分開存 |
17. 來源
都在 2026-11-02 查閱。價格來自 AWS 價目表 API，東京區域，發布日期 2026-10-29。
- AWS：How Aurora serverless works（ACU、範圍、伸縮、順位、平台版本）
- AWS：Performance and scaling for Aurora serverless（最小最大值的考量、連線上限、記憶體不足、監控指標）
- AWS：Scaling to Zero ACUs（自動暫停）
- AWS：Supported Regions and Aurora DB engines for Aurora serverless（東京支援的版本）
- AWS：Amazon Aurora storage（叢集磁碟區、儲存方案）
- AWS：Managing performance and scaling（空間回收、
DELETE與pg_repack、副本延遲） - AWS：High availability for Amazon Aurora（故障接手時間、可用區域故障、RDS Proxy 減少 66%）
- AWS：Amazon RDS Proxy for Aurora
- AWS：Avoiding pinning an RDS Proxy（釘住的條件）
- AWS：Row-level security recommendations（用執行時變數設定店家）
- AWS：Overview of backing up and restoring an Aurora DB cluster
- AWS：Cloning a volume for an Amazon Aurora DB cluster
- AWS：Amazon Aurora FAQ（PostgreSQL 相容性、256 TiB）
- AWS：Amazon Aurora pricing（按秒計費、25% 法則、備份免費額度）
- AWS：Amazon RDS Proxy pricing
- AWS 價目表 API：RDS 東京（所有東京價格）
- Npgsql：Connection string parameters（連線池預設值）