情境:
公司原本在地端架設了一套 Web 服務，但隨著業務量大增，使用者開始抱怨：
- 網站速度變慢
- 資料庫回應時間變長
- 高峰流量容易造成延遲甚至當機
IT 團隊被迫面對一個現實：「地端效能升級太慢、太貴，而且無法彈性擴展」。
為了改善使用者體驗並支援未來的快速成長，公司決定把整套應用搬到 AWS，並期望：
- 各層都能自動擴展
- 前端流量能平均分散
- 資料庫能高可用、可讀寫分離
- 使用者在擴展過程中不會被登出或遭遇中斷
解決方案將採用 Amazon Aurora PostgreSQL、Amazon EC2 Auto Scaling、Elastic Load Balancing。
接著，他們便開始評估實際的架構與服務搭配組合……
核心知識點:
Amazon Aurora PostgreSQL 是什麼?
Amazon Aurora PostgreSQL 是與 PostgreSQL 相容的完全受管且符合 ACID 規範的關聯式資料庫引擎，結合了 Amazon Aurora 的速度、可靠性和可管理性，以及開源資料庫的簡易性和成本效益。
※Aurora 是 AWS 研發出來的資料庫引擎，在雲端建構的 MySQL 和 PostgreSQL 相容關聯式資料庫服務
Writer 只有一個（Primary Instance）
Aurora 的寫入節點稱為 Writer，整個 Aurora Cluster 中 同時間永遠只有一個 Writer。
用途：
- 提供 讀寫 功能
- 負責交易（Insert、Update、Delete）
- 任何寫入都必須經過 Writer
- Aurora 不支援多 Writer（除非使用 Aurora Multi-Master，但目前不是主流且限制多）
多個 Reader 用於讀取擴展（Read Replicas）
Aurora 支援建立多個副本讀取節點（Reader），這些副本執行：
- 唯讀查詢（SELECT）
- 分散大量查詢壓力
- 提高整體讀取吞吐量
Aurora Reader 適合：
- 報表查詢
- API 查詢量大
- 高併發read-heavy workloads
Auto Scaling 只會擴展 Replicas，不會自動建立 Writer
Aurora Auto Scaling 的運作方式：
| 節點類型 | Auto Scaling 支援？ | 說明 |
| Writer | ❌ 不支援 | 不會新增額外 Writer |
| Replicas | ✅ 支援 | 可依讀取負載自動新增/刪除 Reader 節點 |
也就是說，Aurora 的 Auto Scaling 絕對不是「多 Writer 自動擴展」，而是針對讀取節點的自動擴展。
Elastic Load Balancing (ELB) 是什麼?
Elastic Load Balancing 會自動將傳入流量分配到一或多個可用區域中的多個目標，例如 EC2 執行個體、容器和 IP 地址。其會監控已註冊目標的運作狀態，並且僅將流量路由至運作狀態良好的目標。Elastic Load Balancing 會根據傳入流量的變化自動擴展負載平衡器的容量。
AWS 有兩種常見的 Load Balancer：
| Application Load Balancer（ALB） 工作在 第 7 層（Application Layer） 能解析 HTTP/HTTPS支援進階路由（URL path、Host-based routing） 支援 Cookie-based Sticky Sessions 適合 Web App、API、需要 session 的應用。 | Network Load Balancer（NLB） 工作在 第 4 層（Transport Layer） 超高速，低延遲大量 TCP/UDP 連線不支援 HTTP Cookie Stickiness 但支援 TCP 連線層面的 Source IP Stickiness 適合高吞吐、固定 IP、非 HTTP 流量。 |
Stateful App 需要 Sticky Sessions → 必須用 ALB
- NLB 沒有 Cookie
- Stateful 應用如果 session 不一致 → 使用者會被登出或錯亂
Stateful 的意思是，伺服器會記住使用者的登入狀態、購物車、瀏覽進度等資訊。
因此在流量導向時，要保證使用者的所有請求，必須導向同一台 EC2，這就是 Sticky Sessions（Session Affinity）
ALB 透過 Application Cookie 或 Load Balancer Cookie 維持使用者請求落到同一台後端。
常用場景：
- 登入系統
電商購物車 - 後台管理系統
- 存在 session 的 PHP / Java / Python Flask / Ruby on Rails
ALB 預設使用 Round Robin（輪詢） 進行流量分配
Round Robin 的優點：
- 平均流量到所有 EC2
- 簡單且穩定
- 適合大多數 Web 應用
- 無需分析負載或延遲
當 Sticky Sessions 開啟後：
- Round Robin 只會在新 session 開始後執行一次
後續會維持同一使用者落到同一台 EC2
Auto Scaling 與 Load Balancing 的最佳搭配
Amazon EC2 Auto Scaling 能確保您有數量正確的 Amazon EC2 執行個體來處理應用程式的負載。您可以建立 EC2 執行個體的集合，此集合稱為「Auto Scaling 群組」。
Auto Scaling 主要組成
- Launch Template（定義 EC2 規格）
- Auto Scaling Group（決定最小/最大/期望數量）
- 伸縮策略 Scaling Policy（依 CPU、記憶體、流量等自動增加或減少）
EC2 Auto Scaling 主要功能：
- 自動新增 EC2
- 自動移除 EC2
- 健康檢查、替換失效 EC2
ALB 主要功能：
- 自動註冊/解除註冊 Auto Scaling 的 EC2
- 健康檢查
- 將 HTTP/HTTPS 流量分散到所有 EC2
結論:
1.Aurora Replicas 能負責讀取擴展，提高資料庫效能
2.ALB 可安全處理 HTTP/HTTPS，並支援 sticky sessions
3.Round Robin 是 ALB 預設、安全且常用的流量分配策略
4.EC2 Auto Scaling + ALB + sticky sessions 能確保 stateful app 一致使用者體驗
以分層架構組合思路來說
Web 層：EC2 Auto Scaling + ALB（sticky sessions）
DB 層：Aurora Writer + Reader Auto Scaling
最終可提供彈性、可擴展、高可用且一致的使用者體驗
參考連結:
Aurora Auto Scaling
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-auto-scaling.html
Aurora PostgreSQL 架構
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.html
Application Load Balancer Stickiness
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/sticky-sessions.html
Elastic Load Balancing – Routing Algorithms
EC2 Auto Scaling 與 ALB 整合
https://docs.aws.amazon.com/autoscaling/ec2/userguide/autoscaling-load-balancer.html
