前言

當我們把電商系統的業務邏輯、資料層分工與交易鏈路大致拆清楚後，下一個無法迴避的問題就是：這些東西到底要怎麼在雲端上承接？對很多團隊來說，「上 AWS」常常被理解成選幾個服務把它串起來，但對超大型電商而言，真正的問題其實是故障域怎麼切、容量怎麼算、網路流量怎麼走、資料層怎麼隔離、成本怎麼控。

換句話說，這篇不是要列出一張 AWS 服務清單，而是要回答：當流量真的大、資料真的多、活動真的尖峰、平台真的不能停時，CloudFront、WAF、ALB、EKS、Aurora、ElastiCache、SQS、OpenSearch、S3 這些元件，應該怎麼放在同一張架構圖裡思考。

本篇會以超大型電商平台的常見需求為前提，討論 AWS 上的高層架構規劃、Multi-AZ 與 Multi-Region 取捨、容量預估、觀測與安全治理，以及很多團隊在雲端費用與高可用之間最容易踩到的平衡點。

系列文章導航

  1. 從商品瀏覽到訂單履約，超大型電商平台到底怎麼拆
  2. 商品目錄、搜尋、推薦、快取與 CDN，為什麼電商本質上是讀流量主導的系統
  3. 購物車、庫存預留、下單流程與超賣治理
  4. 支付、退款、帳務、對帳與交易一致性
  5. MySQL、PostgreSQL、DynamoDB、Redis、OpenSearch 與 S3，資料到底該放哪裡
  6. CloudFront、WAF、ALB、EKS、Aurora 與 Multi-Region，AWS 基礎設施如何規劃（本篇）
  7. 黑五與大促場景下的限流、降級、觀測、災難復原與成本控制

先講結論：超大型電商的 AWS 架構不是服務越多越好

很多架構圖會把 AWS 服務畫得很滿，彷彿只要堆足夠多元件，系統就自然會高可用。但真實世界裡，服務越多通常代表：

  • 更多網路跳數
  • 更多權限管理
  • 更多觀測與告警點
  • 更多故障模式
  • 更多費用

所以設計重點從來不是「把能用的服務全用上」，而是讓每一層都承接明確責任，並且知道失敗時該如何退化與隔離。

電商在 AWS 上的高層分層通常長什麼樣子

flowchart LR
    USER[Global Users] --> R53[Route 53]
    R53 --> CF[CloudFront]
    CF --> WAF[WAF / Shield]
    WAF --> ALB[ALB]
    ALB --> EKS[EKS / ECS / EC2 App Tier]
    EKS --> AUR[(Aurora)]
    EKS --> REDIS[(ElastiCache Redis)]
    EKS --> OS[(OpenSearch)]
    EKS --> MQ[SQS / SNS / Event Bus]
    EKS --> S3[(S3)]
    MQ --> WORKER[Async Workers]
    WORKER --> AUR
    WORKER --> S3

這張圖反映的是一個常見邏輯：

  • CloudFront 與邊緣層先吸收大量靜態與可快取請求。
  • WAF 與安全層先做第一層流量保護。
  • ALB 或入口層把流量送進應用計算層。
  • EKS、ECS 或 EC2 承接主要服務。
  • 資料層與非同步層各自分工，不讓所有請求都直接打到核心資料庫。

架構圖看起來很常見，但真正難的是每一層到底要承接多少責任，以及容量如何相互配合。

邊緣層是大型電商穩定性的第一道防線

如果你的商品圖片、靜態資源、首頁片段、可快取 API 響應沒有盡量在邊緣層被處理，後面的應用與資料層壓力會很快膨脹。

所以在 AWS 上，超大型電商通常會把下面幾件事優先做好：

  • CloudFront 承接靜態資源與可快取內容
  • 重要圖片與媒體內容進 S3 + CloudFront
  • WAF 規則保護入口 API 與 Web 流量
  • Shield 或 DDoS 防護能力保護高曝光活動頁

這一層的目標是讓大量重複請求不要每次都回到 origin，也讓惡意或異常流量在最外層就被攔下來。

EKS、ECS、EC2 沒有絕對標準答案，關鍵在控制面與操作模型

很多人會問：大型電商到底要用 EKS、ECS 還是直接 EC2？

比較務實的答案通常是：

  • 如果團隊已經成熟使用 Kubernetes，且需要大量服務治理、彈性擴展與一致的 deployment model，EKS 很常見。
  • 如果團隊偏向 AWS 原生託管體驗，希望降低 Kubernetes 控制面複雜度，ECS 也是合理選擇。
  • 如果有大量自管 middleware、特殊網路需求、既有 AMI 流程或 legacy workload，EC2 仍然可能存在。

真正要避免的是：團隊尚未準備好，就為了「看起來比較現代」而導入超出治理能力的控制面。

Multi-AZ 幾乎是基本盤，Multi-Region 則是成本與複雜度的重大決策

對超大型電商來說，單一可用區故障不是不可想像的風險，所以 Multi-AZ 通常是基本要求。應用節點、快取、資料庫、訊息佇列與入口服務都應該至少有跨可用區考量。

但 Multi-Region 就不是「能做就做」這麼簡單。因為一旦進入跨區域：

  • 資料同步複雜度大幅上升
  • 寫入一致性與衝突處理更困難
  • 網路延遲更高
  • 成本明顯增加
  • 故障演練與切換程序變得更複雜

所以更常見也更務實的做法通常是：

  • 前台內容與靜態資產全球分發
  • 核心交易主區域 active
  • 次區域 warm standby 或 active-passive
  • 少數真的需要就近存取的能力做 region-local optimization

不是所有系統都適合 active-active，尤其是牽涉訂單、支付與庫存真相的核心交易鏈路。

容量規劃不能只看 QPS，還要看尖峰型態與下游承受能力

大型電商最危險的地方在於，入口流量大不代表每一層壓力等比例增加。真正需要關注的通常包括：

  • CloudFront 命中率
  • ALB 新連線與並發連線數
  • 應用層 p95 / p99 latency
  • Redis hit ratio 與 hot key
  • Aurora CPU、IOPS、connections、replica lag
  • SQS 或 queue backlog
  • OpenSearch 查詢延遲與索引延遲

也就是說，容量規劃不能只問「一天有多少流量」，而要問：

  • 高峰會集中在哪一個時間窗
  • 熱門活動是否會打到單一商品或單一 API
  • 哪些請求可以被快取
  • 哪些請求一定會穿透到資料層
  • 背景 worker 在高峰時能不能消化後續事件

如果沒有把這些問題算清楚，自動擴縮也救不了真正的瓶頸。

資料層與計算層的隔離，是 AWS 上最值錢的基本功

對大型電商來說，一個很常見的錯誤是讓所有服務共用同一套資料庫與同一個網路路徑，結果任何一個服務暴衝都會連帶影響其他服務。

比較穩健的做法通常包括：

  • 交易核心與查詢投影分開
  • 熱門前台查詢盡量走快取與搜尋層
  • 背景工作用 queue 與 worker 隔離
  • 報表與分析工作負載不要直接撞交易主庫
  • 不同環境、不同系統邊界有清楚的 VPC、subnet 與 IAM 權限治理

換句話說，AWS 架構的價值不只是把機器開出來，而是讓不同 workload 不會互相拖垮。

安全治理與成本治理不能等平台做大才補

超大型電商在 AWS 上除了效能與可用性，還會面對兩個常被晚點才想到、但其實應該早點進場的主題：安全與成本。

安全側常見重點

  • IAM 最小權限
  • Secrets Manager 或同類機制管理機密
  • WAF 規則治理
  • 審計與存取紀錄
  • PCI DSS 類型要求下的資料隔離

成本側常見重點

  • 跨 AZ 與跨 Region 流量費
  • OpenSearch 叢集過度放大
  • Redis 節點規模過大但命中率不佳
  • Aurora replica 開太多卻沒有對應讀流量
  • 大促過後沒有有效縮容

真正成熟的架構不是「絕不省錢」，而是知道哪裡該花、哪裡不該浪費。

2026 年看 AWS 上的超大型電商架構，最容易踩的坑

到了 2026 年，很多團隊已經熟悉雲端名詞，但仍然容易在下面幾件事上翻車：

  1. 把 Kubernetes 當答案本身，而不是操作模型的一部分。
  2. 高估自動擴縮的威力，低估資料層與快取層的熱點。
  3. 過早追求 Multi-Region active-active，卻沒有準備好狀態衝突與營運流程。
  4. 忽略跨 AZ / 跨 Region 流量成本與架構連鎖效應。
  5. 把觀測、安全與故障演練留到上線後才處理。

這些問題都不是 AWS 特有，而是雲端把系統彈性放大後，工程判斷錯誤也會一起被放大。

總結

AWS 上的超大型電商架構，真正重要的不是堆出一張看起來很完整的服務拓樸圖，而是知道每一層的責任、流量如何進出、故障會停在哪裡、擴縮是否真的能解決問題，以及成本是否與價值相稱。

CloudFront、WAF、ALB、EKS、Aurora、Redis、OpenSearch、SQS 與 S3 都是重要元件，但沒有任何一個服務本身能保證成功。真正保證平台可持續運作的，是你是否清楚切分邊界、理解故障域、預估容量、安排退化策略，並讓安全與成本治理從一開始就進入架構決策。

下一篇也是這個系列的收尾，我們會進入真正的實戰壓力場景：黑五與大促期間，系統如何限流、降級、觀測、災難復原與控制成本。