Cloud Architecture — 架構完善的框架五大支柱、可靠性與高可用性、Trusted Advisor。針對 AWS Certified Cloud Practitioner 考試整理重點與常見誤區。
# 9.1 AWS 架構完善的框架 Well-Architected Framework
生活比喻
蓋房子有「建築規範」: 結構要安全、水電要能維修、要住得舒適、要省電、預算要控制。AWS Well-Architected Framework 就是雲端版的建築規範 —— 一套讓你自我檢查「我這個架構蓋得好不好」的標準清單。
定義
這個框架由五大支柱 (Pillars) 組成，提供設計原則與檢核問題，幫助你在雲上建立安全、高效、有韌性且划算的系統。
| 支柱 | 英文 | 核心問題 |
|---|---|---|
| 卓越營運 | Operational Excellence | 能不能順利運行、監控、持續改進？ |
| 安全性 | Security | 資料與系統受到保護了嗎？ |
| 可靠性 | Reliability | 出事了能不能自動復原？ |
| 效能效率 | Performance Efficiency | 資源用得有效率嗎？能隨需求調整嗎？ |
| 成本優化 | Cost Optimization | 有沒有花不必要的錢？ |
補充說明
你們課程列的是五大支柱 (第 2–6 部分), 這是課程知識檢查的答案依據。不過 AWS 後來新增了第六個支柱永續性 (Sustainability), 關注減少雲端使用的環境影響。實際考 Cloud Practitioner 時，若選項出現六個支柱也不要意外 —— 以課程作業為準答五個，考證照時知道有第六個。
# 9.2 卓越營運 Operational Excellence
重點是「把日常維運變成可重複、可自動化、可持續改進的流程」。
- 以程式碼執行營運：用 CloudFormation 等工具把基礎設施寫成程式碼，避免手動點擊造成的不一致
- 頻繁進行小幅、可逆的變更：小改動出錯容易回退，大改動一次爆炸難救
- 預期並演練失敗：定期模擬故障，確認復原流程真的有效
- 從所有營運失敗中學習：事故後檢討並改進流程
相關服務: CloudFormation (基礎設施即程式碼)、 CloudWatch (監控)、 CloudTrail (稽核)、 AWS Config (設定追蹤)。
# 9.3 安全性 Security
這根支柱和 Module 4 的內容高度重疊，設計原則包含:
- 實施強大的身分基礎：最小權限原則，使用 IAM 集中管理
- 啟用可追溯性：記錄與監控所有動作 (CloudTrail、CloudWatch)
- 在所有層級套用安全性：縱深防禦 ——VPC、子網路、安全群組、執行個體、應用程式層層設防
- 自動化安全最佳實務：讓安全控制以程式碼形式自動套用
- 保護傳輸中與靜態資料：加密 (KMS、ACM)
- 為安全事件做好準備：事先規劃事件回應流程
# 9.4 可靠性 Reliability
核心是「系統能否從故障中自動復原，並隨需求正確擴展」。
- 自動從故障中復原：監控關鍵指標，超過門檻自動觸發修復
- 測試復原程序：不只測功能，要真的測失敗情境
- 水平擴展以提高可用性：多台小機器比一台大機器可靠
- 停止臆測容量：用 Auto Scaling 讓容量自動跟著需求走
- 透過自動化管理變更
# 9.5 效能效率 Performance Efficiency
核心是「用最合適的資源達成需求，並隨技術演進持續調整」。
- 將先進技術大眾化：用受管服務，不必自己養專家 (例如用 RDS 而非自架資料庫)
- 幾分鐘內即可全球部署：善用多區域與 CloudFront
- 使用無伺服器架構：免除管理實體伺服器的負擔
- 更頻繁地進行實驗：雲端測試成本低，多試幾種配置
- 考量機械同感：選擇最符合工作特性的技術方案
# 9.6 成本優化 Cost Optimization
呼應 Module 6 的 EC2 成本優化，原則包含:
- 採用消費模式：用多少付多少，不要為了尖峰而長期養著閒置資源
- 衡量整體效率：用 Cost Explorer 等工具追蹤成本與產出的比例
- 停止在資料中心營運上花錢：讓 AWS 處理機房與硬體
- 分析並歸屬支出：用標籤 (Tags) 區分不同專案 / 部門的花費
- 使用受管服務降低擁有成本
# 9.7 可靠性與高可用性
定義
可靠性 (Reliability): 系統在需要時能正確執行預期功能的能力。高可用性 (High Availability, HA): 系統盡可能維持可運作狀態、把停機時間降到最低。容錯 (Fault Tolerance): 某個元件壞掉時，系統仍能不受影響地繼續運作。
生活比喻
高可用像餐廳有備援廚師 —— 主廚請假，備援上場，客人可能等久一點但還是吃得到飯。容錯則像雙引擎飛機 —— 一顆引擎熄火，飛機照樣穩穩地飛，乘客完全感覺不到。
# 提升可用性的常見做法
- 跨多個可用區域 (AZ) 部署：單一 AZ 出事不會全掛，這是最基本的高可用手段
- 使用 Elastic Load Balancing: 自動把流量導向健康的執行個體
- 使用 Auto Scaling: 執行個體不健康時自動汰換、負載上升時自動增加
- 消除單點故障 (SPOF): 任何只有一台的關鍵元件都是風險
- 使用 Route 53 健康檢查與 Failover 路由：區域級的容錯移轉
考試重點
「跨多個可用區域部署」幾乎是所有「如何提高可用性」題目的正解。要注意區分：多個 AZ = 高可用；多個區域 (Region)= 災難復原 / 降低全球延遲。另外「可用性」常以百分比表示 (如 99.99%), 數字越多個 9, 允許的停機時間越短。
# 9.8 AWS Trusted Advisor
生活比喻
Trusted Advisor 像一個會自動巡邏的顧問：他繞你的房子一圈，回來告訴你「後門沒鎖」「這盞燈整天開著在浪費電」「你的保險快到期了」。他不會幫你動手修，但會主動指出問題。
Trusted Advisor 會依照最佳實務自動檢查你的 AWS 環境，並提出建議。檢查分為五個類別 —— 這五個類別是高頻考點:
| 類別 | 檢查什麼 |
|---|---|
| 成本優化 Cost Optimization | 閒置的執行個體、未使用的 EBS 磁碟、可改用預留方案的資源 |
| 效能 Performance | 使用率過高的執行個體、可最佳化的設定 |
| 安全性 Security | 對外全開的安全群組、Root 帳號未啟用 MFA、公開的 S3 貯體 |
| 容錯 Fault Tolerance | 缺少備份、未跨 AZ 部署、沒有啟用 Multi-AZ |
| 服務限制 Service Limits | 資源用量是否接近帳戶配額上限 |
考試重點
記憶口訣可用五個字頭: 成本、效能、安全、容錯、限制。另外要知道檢查項目的完整度取決於你的支援方案等級 —— 基本方案只提供部分核心檢查，Business 與 Enterprise 支援方案才有完整的全部檢查項目。
# 重點回顧
- Well-Architected Framework 五大支柱：卓越營運、安全性、可靠性、效能效率、成本優化 (後增第六支柱永續性)。
- 可靠性關鍵字是「自動從故障復原」; 高可用的標準做法是「跨多個可用區域部署」。
- 多個 AZ = 高可用；多個 Region = 災難復原與全球延遲優化。
- 消除單點故障 (SPOF) 是架構設計的核心原則，搭配 ELB 與 Auto Scaling 實現。
- Trusted Advisor 五大檢查類別：成本、效能、安全、容錯、服務限制；完整檢查需 Business 以上支援方案。
# 自我測驗
AWS Well-Architected Framework 的五大支柱是哪些?
答：卓越營運、安全性、可靠性、效能效率、成本優化。(AWS 後續新增第六支柱「永續性」。)
AWS Trusted Advisor 的五大檢查類別是什麼?
答：成本優化、效能、安全性、容錯、服務限制。 完整的檢查項目需要 Business 或 Enterprise 支援方案。
要提高應用程式的可用性,最基本的架構做法是什麼?
答：跨多個可用區域 (AZ) 部署。 這樣單一 AZ 發生故障時，其他 AZ 的資源仍能繼續服務。
「高可用性」和「容錯」有什麼不同?
答：高可用性是盡量縮短停機時間 (可能有短暫中斷但快速恢復); 容錯是元件故障時系統完全不受影響地持續運作。 容錯的要求比高可用更嚴格。
「以程式碼執行營運」屬於哪一根支柱的設計原則?
答：卓越營運 (Operational Excellence)。 用 CloudFormation 等工具把基礎設施寫成程式碼，避免手動操作造成不一致。
