💡 先搞懂問題
虛構的「晴空食品」把網購訂單放在一台 Amazon RDS for MySQL 的 DB 執行個體上，部署在單一可用區域（Availability Zone, AZ）。上線半年遇到三件事：一次例行的作業系統修補讓資料庫重新啟動，網站下單停了好幾分鐘；每到月底，財務的報表查詢把 CPU 吃滿，顧客結帳變得很慢；還有一次，工程師在正式環境誤下了 DROP TABLE。會議上有人說「開 Multi-AZ 就都解決了」，結果開了之後，修補時的中斷確實縮短了，但月底報表照樣拖慢結帳，而誤刪的資料表也還是救不回來。
原因是這三件事各有各的解法。Multi-AZ 在另一個可用區域放一台待命執行個體（standby），用同步複寫（synchronous replication）保持一致，主要執行個體出事時自動容錯移轉（failover），解決的是可用性。讀取複本（read replica）用非同步複寫（asynchronous replication）複製一份可以讀的資料庫，讓報表查詢去讀它，解決的是讀取擴充。誤刪資料則兩者都救不了，因為刪除動作會被忠實地複寫過去，要靠自動備份（automated backups）做時間點還原（point-in-time recovery, PITR）。Amazon Aurora 把這幾件事重新設計過：資料放在跨可用區域的共用儲存，讀取複本同時就是容錯移轉的目標。
生活比喻：總店主廚、備位主廚與分店
想像晴空食品其實是一家餐廳。總店主廚是唯一能改菜單、能做新菜的人。為了怕主廚突然倒下，老闆在隔壁棟的廚房請了一位備位主廚：總店每做一道菜，備位主廚就同步做一模一樣的一份，而且要等兩邊都做好，這道菜才算完成；但備位主廚做的菜不出給客人，他存在的唯一目的，就是主廚倒下時馬上接手。客人不用知道換了人，門口的招牌和訂位電話都沒變，只是交接那一兩分鐘，正在點的單要重新點一次。
月底常有大批團體客只是來看菜單、問價錢，把主廚忙到沒空炒菜。老闆的辦法是開分店：分店照總店的食譜出菜，只負責接待這些「只看不點」的客人，但食譜是事後一份份寄過去的，所以分店的菜單可能比總店晚一點更新。總店真的關門時，分店不會自動變成總店，要老闆正式宣布升格，從此分店獨立營業，客人得改打分店的電話。至於主廚把一道菜的配方寫錯、整鍋倒掉，備位主廚和分店也會照著做錯，這時只能翻出昨晚存檔的食譜、照白天的點單紀錄重做到出錯前一刻，而且是在一間新的廚房裡重做。
這個比喻有幾個地方要修正。第一，備位主廚「完全不出菜」是真的：Multi-AZ DB 執行個體部署的待命機不能接任何讀取流量，要分擔讀取得靠讀取複本或改用 Multi-AZ DB 叢集。第二，交接不是零中斷：容錯移轉時 RDS 會把端點的 DNS 記錄改指向新的主要執行個體，既有連線會斷掉，應用程式要能自動重新連線。第三，分店晚多少不是固定的，複本延遲隨寫入量與複本的負載變化，可以從 CloudWatch 的 ReplicaLag 指標看到。第四，時間點還原不會把原本的資料庫倒轉，而是建立一個新的 DB 執行個體，端點也是新的。
🎮 互動實驗室一：故障與讀寫模擬器
先選一種部署，下方會畫出每個可用區域裡有哪些執行個體（深紫是寫入者、虛線灰是不可讀的待命機、淡紫是可讀的待命或 Aurora 複本、黃色是讀取複本）。接著觸發一個事件：主要執行個體故障、主要執行個體所在的可用區域故障、月底大量報表查詢，或工程師誤刪資料表。開著「先猜再看」時，會先請你回答一個是非題，答完才公布四格結果：會不會自動容錯移轉、大約多久、讀取能不能分擔、需不需要時間點還原。
同一個區域內的三個可用區域 ap-northeast-1（示意）
時間依官方文件與產品頁的典型值（查證時間 2026 年 10 月）：Multi-AZ DB 執行個體部署的容錯移轉通常 60～120 秒（使用者指南），產品頁寫「最快約 60 秒」；Multi-AZ DB 叢集通常 35 秒內（產品頁）；Aurora 有 Aurora 複本時通常 60 秒內、常在 30 秒內，沒有複本時重建主要執行個體通常 10 分鐘內（Aurora 使用者指南）。單一 AZ 的自動復原時間官方沒有承諾。實際時間會受交易量與復原工作影響。
🎮 互動實驗室二：情境分診台
十張虛構公司的情境卡，一次出現一張。讀完需求後，從八個選項裡挑出最適合的一個：Multi-AZ、讀取複本、跨區域讀取複本、Aurora Global Database、RDS Proxy、ElastiCache、手動快照、AWS Backup。選完立刻告訴你對錯，並說明為什麼是它、為什麼不是最容易混淆的那一個。全部做完會顯示分數，可以重來再練一次。
🛠️ 操作教學：建立 Multi-AZ 資料庫與讀取複本
不用登入 AWS，也能先把流程走一遍。左邊是簡化的管理主控台，照步驟填表、按按鈕；右邊同步顯示等效的 AWS CLI 與 CloudFormation，黃色底的那幾行就是目前這一步對應的指令。可以故意把資料庫執行個體識別碼打錯、把備份保留期設成 0，或改選 Multi-AZ DB 叢集，看驗證訊息與指令怎麼變。整個流程都不會出現密碼：主要使用者的密碼交給 AWS Secrets Manager 產生與保管。
DeletionPolicy: Snapshot 讓 CloudFormation 在刪除資料庫前先留一份最終快照（沒寫的話，獨立的 DB 執行個體與 DB 叢集預設也是 Snapshot），而 DeletionProtection: true 會讓刪除直接失敗，要先在範本裡改成 false 並更新堆疊。
自己動手時要注意
權限方面，建立時需要 rds:CreateDBSubnetGroup、rds:CreateDBInstance（Multi-AZ DB 叢集是 rds:CreateDBCluster）、rds:CreateDBInstanceReadReplica、測試容錯移轉的 rds:RebootDBInstance，以及讀取 VPC、子網路、安全群組的 EC2 描述權限；讓 RDS 在 Secrets Manager 管理主要使用者密碼時，執行者還需要建立機密的權限（例如 secretsmanager:CreateSecret）。
費用方面，RDS 依執行個體時數、配置的儲存與佈建 IOPS、超出額度的備份儲存與資料傳輸計費；Multi-AZ 的待命機、Multi-AZ DB 叢集的另外兩台、每一個讀取複本都各自計費，跨區域讀取複本另有跨區域資料傳輸費；Secrets Manager 依機密數量與 API 呼叫計費。2025-07-15 以後建立的帳戶採抵用金制度的 Free Tier，建立 RDS 資料庫是可以多拿抵用金的活動之一；選「免費方案」的帳戶在 6 個月到期或抵用金用完時會自動關閉，練習前先確認帳戶方案。練習完依序刪除讀取複本、關閉刪除保護、刪除主要執行個體與子網路群組：
# 1. 先刪讀取複本（複本不需要最終快照）
aws rds delete-db-instance --db-instance-identifier qingkong-orders-replica-1 --skip-final-snapshot --region ap-northeast-1
# 2. 關閉刪除保護，再刪除主要執行個體（保留一份最終快照）
aws rds modify-db-instance --db-instance-identifier qingkong-orders --no-deletion-protection --apply-immediately --region ap-northeast-1
aws rds delete-db-instance --db-instance-identifier qingkong-orders --final-db-snapshot-identifier qingkong-orders-final --region ap-northeast-1
# 3. 資料庫刪除完成後，刪除子網路群組
aws rds delete-db-subnet-group --db-subnet-group-name qingkong-orders-subnets --region ap-northeast-1
# 用 CloudFormation 建立的：先把 DeletionProtection 改成 false 並更新堆疊，再刪除堆疊
aws cloudformation delete-stack --stack-name rds-multiaz-lab --region ap-northeast-1最終快照與手動快照會一直保留並計費，確定不需要時記得刪除。範例裡的名稱、子網路與安全群組 ID 都是示意；不要把資料庫密碼、存取金鑰寫進腳本、範本或截圖，需要帳戶 ID 時用 111122223333 或 <your-account-id> 這類佔位字。應用程式要連資料庫時，從 Secrets Manager 讀取主要使用者的機密，或改用 IAM 資料庫驗證。
📘 原理補完
五種「多一台資料庫」的正式定義
判斷時先問：要解決的是可用性（主機或可用區域壞了要自動接手）、讀取擴充（讀取查詢太多），還是災難復原（整個區域出事）？下表依 Amazon RDS 與 Aurora 使用者指南、RDS Multi-AZ 產品頁整理（查證時間 2026 年 10 月）。
| 機制 | 主要目的 | 複寫方式 | 平常能讀嗎 | 自動容錯移轉 | 典型切換時間 | 支援範圍與數量 |
|---|---|---|---|---|---|---|
| Multi-AZ DB 執行個體部署 | 可用性 | 同步，另一個 AZ 一台待命 | 不能 | 會，端點不變 | 通常 60～120 秒 | RDS 所有引擎 |
| Multi-AZ DB 叢集 | 可用性＋讀取 | 半同步，三個 AZ：1 寫入＋2 可讀待命 | 能（讀取端點） | 會 | 通常 35 秒內 | RDS for MySQL、PostgreSQL；特定執行個體類別 |
| 讀取複本 | 讀取擴充 | 非同步，可同 AZ、跨 AZ、跨區域 | 能（自己的端點） | 不會，要手動升級 | 依你的處理流程 | MySQL、PostgreSQL、MariaDB、SQL Server 每個來源最多 15 個，Oracle 最多 5 個 |
| Aurora 複本 | 讀取＋可用性 | 共用叢集磁碟區（6 個儲存節點跨 AZ） | 能（讀取端點） | 會，依優先順序升格 | 通常 60 秒內，常在 30 秒內 | 每個叢集最多 15 個 |
| Aurora Global Database | 跨區域災難復原＋就近讀取 | 專用基礎設施跨區域複寫，延遲通常 1 秒內 | 次要區域能讀 | 計畫性切換或非計畫性容錯移轉由你發動 | 依切換方式 | 最多 10 個次要叢集 |
「典型切換時間」是官方文件寫的典型值，大交易或長時間的復原會讓時間變長。Aurora 叢集沒有 Aurora 複本時，主要執行個體故障會在同一個 AZ 重建，通常 10 分鐘內恢復。
容錯移轉時到底發生什麼事
以 Multi-AZ DB 執行個體部署為例，官方列出的觸發條件包括：作業系統離線修補、主要主機不健康、網路無法連到主要主機、你修改了執行個體、主要執行個體忙到沒有回應、底層儲存磁碟區故障，以及你自己選了「重新開機並容錯移轉」。RDS 偵測到之後，把端點的 DNS 記錄改指向待命機，待命機升格為新的主要執行個體。因為是同步複寫，已提交的交易不會遺失；但既有連線會中斷，應用程式要能重新連線，而且不要把 DNS 解析結果快取太久。Multi-AZ DB 叢集的容錯移轉時間取決於另外兩台讀取執行個體的複寫延遲，要先套用完尚未套用的交易才能升格。
讀取複本：分擔讀取，不是自動備援
建立讀取複本時，RDS 先替來源執行個體做快照、用快照建立複本，之後用引擎原生的非同步複寫持續追上。複本有自己的端點，應用程式要自己決定哪些查詢送去複本，例如把報表、搜尋、匯出導過去。來源執行個體必須開啟自動備份（備份保留期大於 0），否則不能建立讀取複本。讀取複本可以放在同一個 AZ、另一個 AZ，甚至另一個區域；跨區域讀取複本常用來讓遠地使用者就近讀取，或當作區域災難時的備案：出事時把它升級（promote）成獨立的執行個體，但升級是單向的，升級後就不再接收來源的變更，應用程式也要改連新端點，非同步複寫中還沒送到的交易會遺失。
Aurora：儲存與運算分開
Aurora 把資料放在叢集磁碟區（cluster volume），寫入主要執行個體的資料會同步複寫到跨可用區域的 6 個儲存節點；所有執行個體都讀同一份磁碟區，所以新增 Aurora 複本不必複製整份資料，複本延遲通常很低。Aurora 複本同時是讀取擴充與容錯移轉目標：主要執行個體故障時，Aurora 依你設定的升格優先順序（0 最高、15 最低）挑一個複本升為寫入者，叢集端點（cluster endpoint）自動指向新的寫入者，讀取端點（reader endpoint）則在複本之間分散讀取連線。跨區域需求用 Aurora Global Database：一個主要叢集加最多 10 個次要區域叢集，複寫延遲通常在 1 秒內，計畫性切換（switchover）不遺失資料。
誤刪資料：Multi-AZ 與複本都救不了
不論同步還是非同步，被複寫的是「每一個變更」，DROP TABLE 也是變更，會被忠實地送到待命機與每一個複本。能救回資料的是備份：RDS 的自動備份每天在備份時段替儲存磁碟區做快照，並持續把交易日誌上傳到 S3；保留期間 DB 執行個體可設 0～35 天（0 代表停用），Multi-AZ DB 叢集為 1～35 天，主控台建立時預設 7 天、API 與 CLI 沒指定時預設 1 天。時間點還原可以回到保留期內的任一秒，最新可還原時間通常只比現在早幾分鐘；但它一定是建立新的 DB 執行個體，原本的不會被覆蓋。要保存超過 35 天，用手動快照（保存到你刪除為止，可複製到其他區域）；要用同一套政策集中管理多種服務的備份、跨帳戶複製或不可變保存，用 AWS Backup。Aurora MySQL 另有 Backtrack，可以把同一個叢集原地倒轉到較早的時間。
判斷步驟
- 主機或可用區域故障時要自動接手、端點不變：開 Multi-AZ。只要可用性、引擎是 Oracle、SQL Server 等，選 Multi-AZ DB 執行個體部署。
- 引擎是 MySQL 或 PostgreSQL，希望待命機也能分擔讀取、切換更快：選 Multi-AZ DB 叢集。
- 讀取查詢太多：加讀取複本，讓報表或搜尋改連複本端點；能接受資料稍舊才行。
- 同一批查詢重複太多、要微秒回應：在資料庫前面加 ElastiCache。連線數太多（例如大量 Lambda）：加 RDS Proxy。
- 要防整個區域的災難或讓遠地就近讀取：RDS 用跨區域讀取複本；Aurora 用 Aurora Global Database。
- 要防誤刪與資料錯誤：靠自動備份的時間點還原；超過 35 天用手動快照；集中治理、跨帳戶保存用 AWS Backup。
- 需求同時有高可用、大量讀取與快速切換，又是 MySQL／PostgreSQL 相容：評估 Aurora。
容易考錯的地方
Multi-AZ 可以分擔讀取：Multi-AZ DB 執行個體部署的待命機不能接讀取流量。題目說「提高讀取效能」要選讀取複本；題目同時要「待命機也能讀、容錯移轉 35 秒內」，而且是 MySQL 或 PostgreSQL，才是 Multi-AZ DB 叢集。
讀取複本會自動接手：RDS 讀取複本不會自動容錯移轉，要手動升級，升級後端點不同、也不再同步。會自動升格的是 Aurora 複本。
Multi-AZ 等於備份：同步複寫連誤刪也一起複寫。防誤刪看自動備份的時間點還原、手動快照或 AWS Backup。
時間點還原會覆蓋原本的資料庫：不會，一定建立新的執行個體，應用程式要改連新端點。原地倒轉只有 Aurora MySQL 的 Backtrack。
跨區域讀取複本與 Aurora Global Database 一樣：兩者都能做跨區域讀取與災難復原，但 Global Database 用專用基礎設施複寫、延遲通常 1 秒內，最多 10 個次要區域；RDS 的跨區域讀取複本是引擎原生的非同步複寫，災難時要手動升級。
RDS Proxy 能讓查詢變快：它解決的是連線數與容錯移轉時的連線中斷，查詢本身慢還是慢；要減少重複查詢的負擔是 ElastiCache。
相關考試：CLF-C02、SAA-C03、SOA-C03、DEA-C01 等的 in-scope 服務清單都列出 Amazon RDS 與 Amazon Aurora；SOA-C03 另外點名 Amazon RDS Proxy，SAA-C03 與 SOA-C03 也列出 AWS Backup 與 AWS Secrets Manager。
✅ 自我檢測
6 題原創題，選完立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6