AWS Well-Architected Framework筆記

不要只是把地端系統搬到雲端，而是要用雲端思維重新設計架構。

雲端的價值在於彈性、自動化、受管服務、快速重建與持續演進。 好的 AWS 架構，不只是能跑，而是要穩定、可擴展、容易維護、成本合理。

一、不要猜容量，交給 Auto Scaling

傳統機房常常要先預估容量，買太多浪費，買太少又撐不住。 在 AWS 上，應該根據實際流量自動擴展。

流量變大就自動增加資源，流量變小就自動減少資源。 這就是雲端彈性的價值。

二、用正式環境規模測試系統

在雲端中，可以快速建立大量資源。 所以在需要時，可以用接近正式環境的規模來做壓力測試。

這樣可以提前知道系統是否能承受大量使用者、尖峰流量或特殊活動。

三、架構要自動化

使用 CloudFormation 可以把基礎架構寫成程式碼。 這樣就能快速建立、修改、複製與重建環境。

如果架構都靠人工點選建立，一旦環境壞掉或需要複製，就會很難管理。

四、架構要能持續演進

剛上雲時，可能會先把地端系統搬到 EC2。 但後續應該思考如何使用更多 AWS 受管服務。

例如資料庫可以考慮 RDS，事件處理可以考慮 EventBridge， 非同步處理可以考慮 SQS，短任務可以考慮 Lambda。

五、用資料決定架構

架構設計不要靠猜。 應該觀察實際流量、查詢模式、錯誤情況、使用者行為與系統瓶頸。

根據數據選服務，才不會過度設計，也不會選錯架構。

六、做故障演練

好的系統不是假設不會壞，而是壞了也能繼續服務。 所以需要定期模擬故障、流量暴增或服務中斷。

Netflix 的 Chaos Monkey 就是典型例子： 它會隨機終止正式環境中的 EC2 instance，用來測試系統是否真的能承受故障。

七、雲端設計原則

設計原則	口語化說明
可擴展性	系統要能依照需求增加或減少資源。
可拋棄式資源	伺服器壞掉就重建，不要把重要設定只放在單一主機上。
自動化	用程式碼與工具管理架構，減少人工操作。
鬆耦合	系統元件不要綁太死，避免一個服務壞掉拖垮全部。
思考服務，不是伺服器	不要只想 EC2，要多使用 RDS、Lambda、SQS、SNS 等受管服務。

八、從單體架構走向鬆耦合

傳統單體架構： 使用者 ↓ 大型應用程式 ↓ 資料庫 問題： 一個功能壞掉，可能影響整個系統。 應用程式越來越大，越難維護、部署與擴展。 雲端鬆耦合架構： 使用者 ↓ 前端服務 ↓ API / Lambda / ECS ↓ SQS / SNS / EventBridge ↓ 後端服務 / 資料庫 / 儲存服務 優點： 每個元件可以獨立擴展、獨立維護。 某個元件故障，不一定會拖垮整個系統。

九、AWS Well-Architected Framework 六大支柱

支柱	重點說明
Operational Excellence 營運卓越	讓系統容易管理、監控、自動化與持續改善。
Security 安全性	保護資料、權限、系統與網路存取。
Reliability 可靠性	系統要能承受故障，並且快速恢復。
Performance Efficiency 效能效率	選擇合適服務與資源，讓系統有效率地運作。
Cost Optimization 成本最佳化	避免浪費資源，用合理成本達到需求。
Sustainability 永續性	減少不必要的資源使用，提高整體效率。

一句話總結：AWS 架構設計的重點，不是把地端機房原封不動搬到雲端， 而是利用雲端的自動化、彈性、受管服務與鬆耦合能力， 讓系統更穩、更容易擴展、更好維護。