這些題目為學習目的而獨立製作，並非 AWS 官方考題、實際考題、外流題或考題庫。
SAA-009
目前有一個於單一可用區域運作的 RDS for MySQL。希望即使在可用區域故障時,亦能提高 DB 的可用性。將應用程式端的變更降至最低的組態為何?
選項
解析與正確答案
閱讀解析與正確答案（劇透：建議先自行作答）
正確答案：B. 將 RDS 改為 Multi-AZ 組態
解析
RDS Multi-AZ 透過同步複寫與自動容錯移轉,可提高可用區域故障時的可用性。
各選項解析
A. 將 RDS 的儲存類型變更為 gp3
錯誤。雖與儲存效能或成本有關,但無法作為可用區域故障對策。
B. 將 RDS 改為 Multi-AZ 組態
正確。為高可用性的代表性 RDS 組態。
C. 停用 RDS 的自動備份
錯誤。停用備份會降低復原性。
D. 將 RDS 執行個體移至公有子網路
錯誤。移至公有子網路並非提升可用性,反而會增加資安風險。
實際使用情境
RDS Multi-AZ 配置是於同一區域內的不同可用區域中自動建構待命 DB,並與主要 DB 之間進行同步複寫的組態。在主要可用區域故障時將自動發生容錯移轉,DB 端點(DNS 名稱)的參照位置會切換至待命端,因此應用程式無需變更連線字串即可復原。容錯移轉大致於 60〜120 秒左右完成,相較於單一可用區域的組態,RTO 可大幅縮短。 Multi-AZ 與 Read Replica 的區分使用,為 SAA-C03 的常見考點。Multi-AZ 是為提升可用性而設置的待命組態,待命 DB 通常無法用於讀取(部分例外為 Multi-AZ DB Cluster 選項,可擁有 2 個可讀取的待命)。Read Replica 則是為提升讀取效能而設置的非同步副本,並非以提升可用性為主要目的,作為容錯移轉的目的地則需要手動升格。將兩者組合,以 Multi-AZ 保護寫入系統、以 Read Replica 擴展讀取系統,即為大規模 RDS 組態的標準形態。 Multi-AZ 在成本方面也有取捨。由於會額外啟動待命 DB 執行個體,因此相較於單一可用區域,大致會產生 2 倍的運算費用。即使如此,因其具備無需變更應用程式連線即可進行容錯移轉的優點,於有可用性要求的工作負載中,標準上會被選擇。SAA-C03 中,在「可用區域故障時亦維持可用性」「應用程式變更最少」的要求下,Multi-AZ 為正解;誤答則排列出儲存類型變更、停用備份、移至公有子網路等與可用性不同軸線的操作。