單點裸露架構的風險解析：DDoS 攻擊原理與 AWS CloudFront 的防禦角色
什麼是「單點裸露」？
- 應用服務直接部署於單台 EC2
- 公網 IP 對外開放
- DNS A Record 直接指向伺服器
- 無中間緩衝層（CDN / 反向代理 / WAF）
在這種架構下，所有流量會直接抵達源站伺服器，沒有分流、沒有快取層、沒有流量清洗機制。
一旦流量超過主機資源上限（CPU、記憶體、連線數），服務將立即降級或中斷。
DDoS 攻擊如何造成服務癱瘓？
DDoS（Distributed Denial of Service）攻擊的核心原理：透過大量請求耗盡目標系統資源，使其無法正常服務合法用戶。
常見影響層級包括：
- L3 / L4（網路層 / 傳輸層）：大量 TCP / SYN Flood
- L7（應用層）：大量 HTTP 請求
對於沒有緩衝層的單台 EC2 而言，只要併發請求數超過系統處理能力，即可導致：
- File descriptor 耗盡
- 連線排隊超時
- CPU 滿載
- 502 Bad Gateway 或 504 Gateway Timeout 錯誤
AWS CloudFront 在架構中的角色
Amazon CloudFront 是全球分散式內容傳遞網路（CDN），其核心價值不僅是加速，更包含：
- 全球邊緣節點分流：使用者請求優先由最近的 Edge Location 處理
- 快取吸收大量讀取請求：多數流量不會回源
- 預設整合 AWS Shield Standard：自動緩解常見 L3 / L4 層攻擊
- 源站隱藏機制：搭配 Security Group + AWS Managed Prefix List，且僅允許 CloudFront 存取源站
這使 CloudFront 不只是效能優化工具，更是架構中的第一層安全屏障。
接下來將透過實戰壓測演示，說明：
- 為何單台 EC2 會在高併發下快速崩潰
- CloudFront 如何吸收流量並保護源站
- 如何透過 Security Group + Prefix List 隱藏源站
- AWS Shield Standard 在其中扮演的角色
實戰驗證：單點裸露架構在高併發下的崩潰機制
本次壓測首先直接針對單台 EC2 發動高併發請求，以觀察在未經任何邊緣緩衝與防護下，單點架構的實際承載極限與失效模式。
直接攻擊單台 EC2
1. 測試環境
- 目標機：一台安裝 Nginx 的 EC2
- 攻擊機：安裝
oha壓測工具的終端或另一台 EC2 - 網站狀態：可透過 Public IP 正常看到 Nginx 預設頁面
若你還沒安裝網站伺服器，可先參考我們的教學：如何在 EC2 上安裝 Nginx
2. 發動壓測攻擊
使用 Rust 撰寫的現代 HTTP 壓測工具 oha 進行壓測
執行命令如下：
oha -c 1000000 -z 15s –latency-correction http://<目標EC2公網IP>
參數意義：
# -c 1000000：併發連線數 1000000（對於單台小型主機而言，足以造成系統失效）
# -z 15s：持續發送請求 15 秒
# –latency-correction：修正延遲統計，避免計算偏差
# http://<目標EC2公網IP>：目標主機的對外 IP 位址
3. 攻擊結果觀察
- 成功率僅 32.23%：接近七成的請求被丟棄
- 出現大量：
No file descriptors availableaborted due to deadline
- 目標機監控畫面 EC2 CPU 使用率直接滿載：Nginx 處理能力達到物理極限
從這些數據可以判斷，伺服器在短時間內已耗盡可用系統資源，包含 CPU 與可用連線描述符數量。
當新的連線請求無法建立時，系統開始拒絕或中止請求，導致用戶端接收到錯誤回應。
此時服務雖未完全關閉，但實際上已無法穩定對外提供正常服務，等同於發生業務中斷。
架構優化：導入 CloudFront 後的流量吸收與源站保護機制
我們進行以下架構調整：
- 建立 CloudFront Distribution，將 EC2 設為 Origin
- 啟用 HTTPS 強制導向
- 修改 EC2 Security Group
- 移除 0.0.0.0/0 開放規則
- 僅允許 AWS Managed Prefix List
com.amazonaws.global.cloudfront.origin-facing存取源站（此時源站已不再直接暴露於公網）
CloudFront 配置步驟
- 步驟一：登入 AWS 控制台，進入「CloudFront」服務，點擊「Create distribution」
- 步驟二：選擇一個方案（Plan），例如此處選擇「Free」後，輸入配置名稱，點擊「建立」
- 步驟三：Origin Type 選擇「Other」；Origin domain 輸入「EC2 Public DNS」；Protocol 選擇「HTTP and HTTPS」
- 步驟四：檢視器通訊協定政策（Viewer protocol policy） 選擇「Redirect HTTP to HTTPS」
- 步驟五：Web Application Firewall (WAF) 點擊「下一步」，再點擊「 Create distribution」
- 步驟六：等到狀態變為「已啟用」且「上次修改」顯示日期時即可
- 步驟七：回到 EC2 控制台選擇「安全群組」，選擇目標機的安全群組規則ID「編輯傳入規則」
- 步驟八：刪除舊規則，新增新規則輸入「pl」在列表中選擇 com.amazonaws.global.cloudfront.origin-facing（這是 AWS 維護的 CloudFront 所有IP地址列表）
- 步驟九：儲存規則後，僅能透過 CloudFront 訪問網站，無法再直接使用 EC2 的 IP 進入
壓測結果對比：可用性、負載與基礎防護能力差異
1. 目標改為 CloudFront 網域再次壓測
執行命令如下：
oha -c 1000000 -z 15s –latency-correction https://<CloudFront Domain>
2. 結果觀察
- oha報告：所有請求成功
- 平均延遲（Average Latency）顯著降低
- EC2 CPU 使用率維持在低負載區間
AWS CloudFront 架構優化成效差異
完成上述架構調整後，我們再次從可用性、負載表現與防護能力等面向進行對照分析。
透過相同條件下的壓測結果，可以清楚看出在導入 CloudFront 籤後，整體架構穩定性與抗壓能力出現明顯差異。以下為前後架構的重點比較：
| 項目 | 單台 EC2 | 導入 CloudFront |
|---|---|---|
| 源站是否暴露 | 是 | 否 |
| 是否具備流量緩衝 | 否 | 是 |
| 壓測成功率 | 32.23% | 100% |
| CPU 負載 | 滿載 | 低負載 |
| 基礎抗 DDoS 能力 | 幾乎無 | 具備 |
結論：將 CloudFront 納入基礎安全架構，而非單純效能優化工具
本次實戰壓測驗證了一個關鍵事實：當應用服務以單台 EC2 直接對外提供服務時，其可用性完全取決於單點資源上限。
一旦流量超出處理能力，服務便迅速降級，甚至實質中斷。
透過導入 CloudFront 並正確設定源站存取控制後，架構產生了本質變化：
- 使用者流量由全球邊緣節點分流處理
- 快取機制吸收大量重複請求
- 源站 IP 不再直接暴露於公網
- 基礎設施層流量由 Shield Standard 自動緩解
同樣的壓測條件下，系統從 32.23% 成功率與 CPU 滿載，轉變為請求全數成功且源站負載維持穩定。這並非單純的效能優化，而是架構層級的防禦能力提升。
因此，在公開 Web 服務場景中，CloudFront 的定位不應僅被視為 CDN 加速工具，而應納入基礎安全設計的一部分。
將邊緣防禦納入架構標準，才能避免單點風險成為服務可用性的限制因素。
勤英科技作為 AWS 認證代理商，長期協助企業規劃與導入雲端安全架構，涵蓋 CDN 防護、DDoS 防禦、WAF 規劃與整體雲端治理。
若您正在評估現有架構的抗壓能力，或希望建立更完整的邊緣防禦體系，歡迎與我們聯繫。
