這些題目為學習目的而獨立製作，並非 AWS 官方考題、實際考題、外流題或考題庫。
SAA-040
在以 EC2 Auto Scaling 運作的 Web 應用程式中,每當發生縮減或執行個體故障時,部分使用者便會被登出。工作階段資訊儲存於各執行個體的本機磁碟。下列哪項改善措施最為合適?
選項
解析與正確答案
閱讀解析與正確答案（劇透：建議先自行作答）
正確答案：C. 將工作階段資訊移至 Amazon ElastiCache 或 Amazon DynamoDB 等外部資料存放區,使應用程式層無狀態化
解析
根本原因在於將狀態保存於執行個體這類生命週期短暫的資源上。若將工作階段資訊外部化至 ElastiCache 或 DynamoDB 等共用資料存放區並使應用程式層無狀態化,則無論哪台執行個體終止,工作階段皆不會遺失。
各選項解析
A. 啟用 Application Load Balancer 的黏性工作階段,將同一使用者恆定轉送至同一執行個體
黏性工作階段僅是持續轉送至同一執行個體,一旦該執行個體終止,工作階段仍會遺失。故障時的登出問題並未解決,還會衍生負載偏斜的另一個問題。
B. 為各執行個體掛載專用的 EBS 磁碟區,並將工作階段檔案儲存於其中
EBS 磁碟區掛載於單一執行個體,並固定於單一可用區域。一旦執行個體終止,其他執行個體便無法讀取該工作階段。
C. 將工作階段資訊移至 Amazon ElastiCache 或 Amazon DynamoDB 等外部資料存放區,使應用程式層無狀態化
正解。將狀態外部化後,即可將執行個體視為「隨時可丟棄」的用完即棄資源。
D. 提高 Auto Scaling 群組的最小台數,使縮減不會發生
即使提高最小台數,執行個體故障或健康檢查失敗導致的替換仍會發生,只會增加成本而無法根本解決。
實際使用情境
在以 Auto Scaling 為前提的架構中,執行個體必須設計為「隨時終止都無妨」。成為縮減對象、因健康檢查失敗而遭替換、因可用區域故障而消失等事件皆屬於正常流程的一部分,若每次發生都會對使用者造成影響,便不符合水平擴充的前提。不讓執行個體持有「僅存在於該台上的狀態」(例如工作階段資訊或上傳中的暫存檔),亦即使應用程式層無狀態化,即為基本設計。 工作階段外部化的常見目的地為 Amazon ElastiCache(Redis / Valkey / Memcached)與 Amazon DynamoDB。ElastiCache 為記憶體內運算,回應快速,並可自然地以 TTL 撰寫工作階段的期限管理。Redis 系列支援複寫與自動容錯移轉(Multi-AZ),因此快取層本身的可用性也能確保。DynamoDB 為無伺服器,不需要容量管理,支援以 TTL 屬性自動刪除,若使用全域資料表甚至可跨區域共用工作階段。另一方面,ALB 的黏性工作階段(工作階段親和性)雖可作為既有應用程式的暫行對策,但須理解其無法解決執行個體故障時的工作階段遺失,且有負載偏向特定執行個體的副作用。同樣地,需要共用的檔案應置於 Amazon EFS 或 S3 而非 EBS。 SAA-C03 中,以「每次縮減都會被登出」「執行個體替換後購物車內容就消失」等症狀,要求選出狀態外部化(ElastiCache / DynamoDB)的出題相當常見。誤答則排列出啟用黏性工作階段、提高最小台數、將工作階段儲存於 EBS 等。EBS 屬於綁定單一可用區域、單一執行個體的資源這項性質,即為此判斷的決定關鍵。