使用 AWS 建立分散式雲端架構：完整實戰指南

小型網站：租用 1 台 t3.micro（每月約台幣 300 元）
中型電商：租用 5 台 m5.large（每月約台幣 15,000 元）
大型平台：租用 50 台 c5.xlarge（每月約台幣 150,000 元）

用戶請求 → ELB → 檢查各台 EC2 的負載狀況 → 選擇最不忙的那台 → 轉發請求

最小數量：2 台（確保基本服務）
最大數量：20 台（避免成本失控）
目標數量：根據 CPU 使用率自動調整

當 CPU > 70% 持續 5 分鐘 → 增加 2 台 EC2
當 CPU < 30% 持續 10 分鐘 → 減少 1 台 EC2

Master DB（主資料庫）
├── 處理所有寫入操作（新增、修改、刪除）
├── 確保資料一致性
└── 位於主要可用區

Read Replica（從資料庫）
├── 只處理讀取操作
├── 可以建立多個（2-5 個都很常見）
├── 可以分散在不同地區
└── 自動從 Master 同步資料

沒有 Read Replica：

- 100 個讀取請求 + 10 個寫入請求 = 主資料庫處理 110 個請求

有 3 個 Read Replica：

- 主資料庫只處理 10 個寫入請求
- 100 個讀取請求分散給 3 台 Read Replica
- 每台平均只需處理 33 個讀取請求

遊戲排行榜：每秒數千筆積分更新

購物車系統：大促期間瞬間流量

IoT 數據收集：數百萬設備同時傳送數據

用戶會話管理：數百萬用戶同時在線

選擇 RDS 當你需要：

✓ 複雜的 SQL 查詢
✓ 嚴格的資料一致性
✓ 現有的 MySQL/PostgreSQL 程式碼

選擇 DynamoDB 當你需要：

✓ 極高的讀寫效能
✓ 無限擴展能力
✓ 簡單的鍵值查詢

用戶查詢「熱門商品」

→ 查詢資料庫（300ms）
→ 計算排序（200ms）
→ 回傳結果（總共 500ms）

如果有 1000 人同時查詢，資料庫要處理 1000 次相同計算

第一個用戶查詢「熱門商品」

→ 查詢資料庫（300ms）
→ 計算排序（200ms）
→ 存入快取
→ 回傳結果（總共 500ms）

接下來 999 個用戶查詢

→ 直接從快取取得（5ms）
→ 回傳結果

資料庫壓力減少 99.9%！

應用程式 → 先查快取 → 沒有的話查資料庫 → 存入快取

資料更新時 → 同時更新資料庫和快取

商品價格：TTL = 1小時（價格不常變動）
庫存數量：TTL = 5分鐘（庫存變化頻繁）
用戶資料：TTL = 24小時（個人資料相對穩定）

實際情況：

你在台北上傳一張照片 → 照片存到 S3
美國用戶立即查詢這張照片 → 可能暫時找不到（幾秒後就會有）
歐洲用戶查詢同一張照片 → 可能看到的是舊版本（很快就會更新）

為什麼這樣設計？

- 如果要求所有地區完全同步，系統會很慢
- 實際使用中，幾秒的延遲通常不是問題
- 換來的是近乎無限的擴展能力

重要檔案被誤刪或覆蓋？不怕！

- 檔案的每次修改都會保留歷史版本
- 可以隨時回復到任何一個版本
- 像是檔案的「時光機」

根據檔案使用頻率自動調整儲存等級：

Standard：經常存取的檔案（成本較高）

↓ 30天後自動轉移

IA (Infrequent Access)：不常存取的檔案（成本中等）

↓ 90天後自動轉移  

Glacier：長期保存的檔案（成本很低，取回需要幾小時）

↓ 365天後自動轉移

Deep Archive：極少存取的檔案（成本最低，取回需要12小時）

電商網站的商品圖片：

- 新商品圖片：放在 Standard（快速載入）
- 3個月前的商品圖片：自動轉到 IA（節省50%成本）
- 1年前的過季商品圖片：自動轉到 Glacier（節省80%成本）

AWS 在全球有 200+ 個 CloudFront 節點：

- 台灣：台北
- 中國大陸：北京、上海、深圳等
- 日本：東京、大阪
- 韓國：首爾
- 美國：各大城市都有
- 歐洲：倫敦、法蘭克福、阿姆斯特丹等

台灣用戶看美國伺服器上的影片：

台北 → 海底電纜 → 美國西岸 → 下載影片
延遲：150-200ms，下載速度：5-10 MB/s

台灣用戶看影片：

台北 → 台北 CloudFront 節點 → 下載影片
延遲：5-10ms，下載速度：50-100 MB/s

第一個用戶請求時：CloudFront 從美國源伺服器下載
後續用戶請求：直接從台北節點提供，超快速！

不只是靜態檔案，連動態內容也能加速：

- API 請求透過最佳路由
- SSL 加密在邊緣節點處理
- 壓縮優化在邊緣節點完成

圖片、CSS、JS：快取 24 小時
HTML 頁面：快取 1 小時
API 回應：快取 5 分鐘
用戶個人資料：不快取

影片上傳處理流程：

1. 用戶上傳影片 → EC2 主機快速回應「上傳成功」
2. 主機把工作訊息丟進 SQS：「請處理影片 video123.mp4」
3. SQS 把訊息排隊等待處理
4. 後台工作程序從 SQS 取得訊息開始處理
5. 處理完成後，工作程序刪除 SQS 中的訊息

如果某個工作一直處理失敗：

嘗試處理 3 次 → 還是失敗 → 送到死信佇列

管理員可以檢查死信佇列找出問題

工作程序取得訊息後，其他程序暫時看不到這個訊息

如果工作程序當機，超時後訊息會重新出現讓其他程序處理

傳統方式：

- 你要租用 EC2 當工作伺服器
- 24小時都在跑，即使沒有工作也要付錢
- 要自己管理伺服器系統更新、安全設定

Lambda 方式：

- 不用租伺服器
- 只有在執行工作時才計費（以毫秒計算）
- AWS 幫你管理所有基礎設施

影片處理工作：每個影片處理需要 5 分鐘

EC2 方式：
- 租用 m5.large：每月台幣 3,000 元
- 一個月處理 1000 個影片 = 台幣 3,000 元

Lambda 方式：
- 每次執行收費：台幣 0.5 元
- 處理 1000 個影片 = 台幣 500 元
- 節省 83% 成本！

平常：沒有工作，Lambda 函數休眠，不花錢

突然來了 100 個影片要處理：

- SQS 接收 100 個訊息
- AWS 自動啟動 100 個 Lambda 函數同時處理
- 全部處理完後，Lambda 函數自動關閉

電商網站的訂單處理：

用戶下單 → EC2 快速回應「訂單成功」
        → SQS 接收「處理訂單 #12345」
        → Lambda 函數處理：
           ├── 檢查庫存
           ├── 發送確認郵件
           ├── 通知倉庫出貨
           ├── 更新會員積分
           └── 發送簡訊通知

EC2 指標：

- CPU 使用率
- 記憶體使用量
- 網路流量
- 磁碟 I/O

RDS 指標：

- 資料庫連線數
- 查詢執行時間
- 讀寫 IOPS
- 磁碟空間使用率

ELB 指標：

- 請求數量
- 錯誤率
- 回應時間
- 健康的目標數量

業務指標監控：

- 每分鐘訂單數量
- 用戶註冊數
- 付款成功率
- 庫存告急商品數

CPU 警報：

當 EC2 CPU > 80% 持續 5 分鐘
→ 觸發 Auto Scaling 增加機器
→ 發送 Email 通知管理員

資料庫警報：

當 RDS 連線數 > 100
→ 發送緊急簡訊給 DBA
→ 自動觸發資料庫效能調整

錯誤率警報：  

當 API 錯誤率 > 5%
→ 立即通知開發團隊
→ 啟動緊急應變程序

所有服務的日誌都送到 CloudWatch Logs：

EC2 應用程式日誌：

[2025-08-10 14:30:25] INFO: User 12345 logged in
[2025-08-10 14:30:26] ERROR: Payment failed for order 67890

Lambda 函數日誌：

[2025-08-10 14:31:00] START RequestId: abc123
[2025-08-10 14:31:05] INFO: Processing video upload
[2025-08-10 14:31:10] END RequestId: abc123

ELB 存取日誌：

2025-08-10T14:30:25.000Z elb-name 1.2.3.4:80 10.0.0.1:32768 0.001 0.002 200 0 234 345

CloudWatch Insights 查詢語言：

找出所有錯誤：

fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc

分析 API 回應時間：

fields @timestamp, @duration
| filter @type = "REPORT"
| stats avg(@duration), max(@duration) by bin(5m)

追蹤特定用戶的操作：

fields @timestamp, @message  
| filter @message like /User 12345/
| sort @timestamp asc

Email：發送詳細的警報郵件
SMS：緊急事件立即簡訊通知
Slack：發送到開發團隊群組
HTTP/HTTPS：觸發其他系統的自動回應
行動推播：發送到管理 App

系統偵測到問題：

1. CloudWatch 觸發 Alarm
2. Alarm 發送訊息到 SNS
3. SNS 同時發送：
   ├── Email 給所有管理員
   ├── 簡訊給值班工程師
   ├── Slack 訊息給開發團隊
   └── 觸發自動修復程序

用戶請求

    ↓
    
CloudFront (全球 CDN)

    ↓
    
ELB (負載均衡器)

    ↓
    
EC2 Auto Scaling Group (運算叢集)
    ├─→ ElastiCache (快取層)
    ├─→ RDS Master + Read Replicas (資料庫層)
    ├─→ S3 (檔案存儲)
    └─→ SQS + Lambda (非同步處理)

監控層：

CloudWatch (指標收集)
CloudWatch Logs (日誌管理)  
SNS (警報通知)

1. 建立 1-2 台 EC2 + ELB
2. 設定 RDS 資料庫
3. 基本 CloudWatch 監控
4. 估計成本：每月台幣 5,000-15,000 元

1. 加入 ElastiCache 快取層
2. 設定 Auto Scaling Group
3. 導入 S3 + CloudFront
4. 估計成本：每月台幣 15,000-50,000 元

1. 多 AZ 部署，提高可用性
2. 導入 Lambda + SQS 非同步處理
3. 完整監控警報系統
4. 多地區部署
5. 估計成本：每月台幣 50,000 元以上

新用戶第一年免費額度：

- EC2：750 小時 t2.micro
- RDS：750 小時 db.t2.micro  
- S3：5GB 存儲空間
- CloudFront：50GB 流量
- Lambda：100 萬次免費執行

1. 使用 Reserved Instances（預留實例）
   - 1年期：節省 30-40%
   - 3年期：節省 50-60%

2. 使用 Spot Instances（競價實例）
   - 適合非關鍵工作負載
   - 可節省 50-90% 成本

3. 定期檢查資源使用率
   - 關閉不必要的服務
   - 調整過大的實例規格

4. 使用 AWS Cost Explorer
   - 分析成本趨勢
   - 找出優化機會