核心服務的部署順序由依賴方向決定（被依賴的先建），運算在這個四層依賴結構裡位於第三層：它引用底層的 subnet、security group 與 IAM role，同時被上層的 load balancer target group 引用。所以運算資源的 IaC 定義裡，subnet ID、security group ID、IAM role ARN 都應該是引用而非硬編碼 — 底層重建時上層才會自動跟上。

ECS vs EKS 選型

ECS 與 EKS 都能跑容器，差異在控制平面的維運模型與生態適配。選型看的是團隊能力與業務需求，而非功能多寡 — 兩者都能達成「容器跑在私有 subnet、用 IAM role 存取資源、掛到 ALB 接收流量」這個基本目標。

ECS 的控制平面由 AWS 代管，service、task definition、target group 都是 AWS 原生資源，Terraform 的 provider 直接描述，心智負擔低。它的 Fargate 啟動類型更進一步 — 連 EC2 instance 都不用管，只描述 task 要多少 CPU 和記憶體，AWS 負責排程到底層主機。

EKS 的控制平面是受管的 Kubernetes，IaC 描述的是 cluster 本身與 node group，workload（Deployment、Service）則走 Kubernetes manifest 或 Helm chart。這代表 infra 工具鏈跨越了 Terraform 與 Kubernetes 兩套系統 — Terraform 負責 cluster 基礎設施，kubectl / Helm 負責工作負載，兩者的 state 與變更流程是分開的。

團隊已有 Kubernetes 能力或需要其生態（service mesh、自訂排程器、多雲部署、社群的 operator 生態）時，EKS 的複雜度才值得承擔。否則 ECS 的低負擔是預設起點。一個自測方式：團隊選了 EKS 但只用到最基本的 Deployment + Service，沒有碰 service mesh、CRD 或跨雲，那等於承擔了 Kubernetes 的維運成本卻沒用到它的回報——退回 ECS 通常更合理。

Fargate vs EC2 launch type

ECS 的執行模式再分 EC2 launch type 和 Fargate launch type。EC2 launch type 需要自己管理 EC2 instance 組成的 capacity provider — AMI 更新、instance 擴縮、OS 層安全修補都是團隊的責任。Fargate 由 AWS 代管運算實例，不需要配 capacity provider、不需要管 AMI，進一步降低運維面。

Fargate 的代價是三個面向：單位成本較高（同規格的 vCPU/記憶體比 EC2 貴約 20-40%）、不支援 GPU workload、啟動延遲稍長（cold start 約 30-60 秒，EC2 已有 instance 時近乎即時）。多數 web API 和非 GPU 的背景工作的初始選擇是 Fargate — 省掉的運維時間通常抵得過溢價。流量穩定且需要成本最佳化時再切回 EC2 launch type，屆時增加的是 capacity provider 的設定與 instance 管理。量級參考：一個持續運行 2 vCPU / 4GB 的 Fargate task 月費約 $70，同規格 EC2 t3.medium 約 $30。月費差距在服務數量少時不顯著，當 task 數量超過 10-20 個且流量穩定時，切回 EC2 launch type 的節省量才值得投入切換工程。

後續 HCL 範例以 ECS Fargate 示意，EKS 的接線骨架（subnet、IAM、target group）相近，差異落在編排層的資源類型。

Task definition：描述容器規格與接線

Task definition 是 ECS 描述「一個工作單元長什麼樣」的宣告：要跑哪個容器映像、給多少 CPU 和記憶體、開哪些 port、用哪個 IAM role、log 送到哪裡。它是運算 IaC 的核心資源。

 1resource "aws_ecs_task_definition" "api" {
 2  family                   = "api-${var.env}"
 3  requires_compatibilities = ["FARGATE"]
 4  network_mode             = "awsvpc"
 5  cpu                      = var.task_cpu
 6  memory                   = var.task_memory
 7  execution_role_arn       = aws_iam_role.ecs_execution.arn
 8  task_role_arn            = aws_iam_role.api_task.arn
 9
10  container_definitions = jsonencode([{
11    name  = "api"
12    image = "${var.ecr_repo_url}:${var.image_tag}"
13    portMappings = [{ containerPort = 8080, protocol = "tcp" }]
14    logConfiguration = {
15      logDriver = "awslogs"
16      options = {
17        "awslogs-group"         = aws_cloudwatch_log_group.api.name
18        "awslogs-region"        = var.region
19        "awslogs-stream-prefix" = "api"
20      }
21    }
22  }])
23}

這段定義裡有三個刻意的設計：

映像版本解耦：var.image_tag 在 infra 的 tfvars 裡給一個穩定的預設值（如 latest 或某個基線版本），部署管線覆寫這個值推新版本。infra apply 不會因此改動映像、部署 pipeline 不會因此改動 subnet — 兩者的變更頻率與審查強度不同，混在一起會讓快的等慢的。如果每次部署新版本都要改 infra 的 Terraform code 並跑 apply，代表映像版本跟 infra 沒有解耦——應該讓部署管線直接用 aws ecs update-service 或修改 task definition 的 image tag，不走 Terraform。

兩個 IAM role 的分工：execution_role_arn 是 ECS 代理用來拉映像和寫 log 的身分 — 它的權限是 ECS 平台層級的，跟業務邏輯無關。task_role_arn 是容器內的應用程式碼在執行期取得的身分 — 它的權限對應業務需求，例如讀寫某個 S3 bucket 或呼叫某個 SQS queue。兩者混在同一個 role 上，就是把平台權限跟業務權限混在一起，違反最小權限（見模組二：身分與憑證地基）。

 1resource "aws_iam_role" "api_task" {
 2  name               = "api-task-${var.env}"
 3  assume_role_policy = data.aws_iam_policy_document.ecs_assume.json
 4}
 5
 6resource "aws_iam_role_policy" "api_task" {
 7  role   = aws_iam_role.api_task.id
 8  policy = data.aws_iam_policy_document.api_permissions.json
 9}
10
11data "aws_iam_policy_document" "api_permissions" {
12  statement {
13    actions   = ["s3:GetObject", "s3:PutObject"]
14    resources = ["${aws_s3_bucket.uploads.arn}/*"]
15  }
16  statement {
17    actions   = ["sqs:SendMessage"]
18    resources = [aws_sqs_queue.notifications.arn]
19  }
20}

Log 接線：logConfiguration 把容器的 stdout/stderr 導向 CloudWatch Logs，log group 名稱引用的是同一份 IaC 裡宣告的資源 — 這正是模組六：可觀測性與 log 說的「監控跟資源同生命週期」。

ECS service：部署模式與網路接線

ECS service 控制「要跑幾個 task、怎麼部署新版本、掛到哪個 target group」。它是 task definition 的執行實例管理者。

 1resource "aws_ecs_service" "api" {
 2  name            = "api-${var.env}"
 3  cluster         = aws_ecs_cluster.main.id
 4  task_definition = aws_ecs_task_definition.api.arn
 5  desired_count   = var.api_desired_count
 6  launch_type     = "FARGATE"
 7
 8  network_configuration {
 9    subnets          = [for s in aws_subnet.private : s.id]
10    security_groups  = [aws_security_group.api.id]
11    assign_public_ip = false
12  }
13
14  load_balancer {
15    target_group_arn = aws_lb_target_group.api.arn
16    container_name   = "api"
17    container_port   = 8080
18  }
19
20  deployment_circuit_breaker {
21    enable   = true
22    rollback = true
23  }
24}

network_configuration 把 task 放進 private subnet 並套用 security group — 它決定了這些容器在網路拓撲裡的位置（見模組三：網路地基）。assign_public_ip = false 讓容器不拿公網 IP，對外流量經由 NAT 出去、入站流量經由 ALB 進來。

deployment_circuit_breaker 是 ECS 的內建保護：部署新版本時如果 task 持續啟動失敗（health check 不過、容器 crash），ECS 會自動回滾到上一版。這個行為需要明確開啟、預設是關的 — 關著的話，壞版本的 task 會反覆啟動失敗，新版始終上不來但舊版也不會回來，服務陷入降級狀態。

連線管理：運算到資料庫的接線

運算到資料庫之間有一段常被略過的接線：連線管理。無狀態運算水平擴張時，每個 task 各自開連線到 RDS，容易把資料庫的連線數打滿。RDS 的連線上限由 instance class 決定（例如 db.r6g.large 約 1000 個連線），而一個跑了 50 個 task 的 ECS service，每個 task 開 20 個連線就到上限了。

出現「擴運算反而拖垮 DB」的訊號時，要引入連線池或受管的連線代理。RDS Proxy 在運算與 RDS 之間代理連線，把運算端的大量短命連線收斂成少量長期連線再進資料庫。它也可以寫進 IaC 並輸出端點給運算引用：

 1resource "aws_db_proxy" "main" {
 2  name                   = "api-proxy-${var.env}"
 3  engine_family          = "POSTGRESQL"
 4  role_arn               = aws_iam_role.rds_proxy.arn
 5  vpc_subnet_ids         = [for s in aws_subnet.private : s.id]
 6  vpc_security_group_ids = [aws_security_group.rds_proxy.id]
 7
 8  auth {
 9    auth_scheme = "SECRETS"
10    secret_arn  = aws_secretsmanager_secret.db_password.arn
11  }
12}
13
14output "db_endpoint" {
15  value = aws_db_proxy.main.endpoint
16}

運算端的連線字串指向 proxy 端點而非 RDS 端點。proxy 的 security group 允許來自運算 security group 的流量，proxy 到 RDS 的流量則由 proxy 自己的 security group 對 RDS security group 的規則控制 — 安全邊界多了一層但更清晰。

Auto-scaling：容量隨負載擴縮

ECS service 的 desired_count 是靜態的起始容量。要讓容量隨負載動態調整，需要加上 Application Auto Scaling。它的責任是在負載上升時長出更多 task、負載下降時縮回去省錢。

auto-scaling 的核心決策是「用什麼指標觸發擴縮」。常見的指標分兩類：

CPU utilization 是最直覺的指標，但它在 I/O 密集型服務上會失準 — 一個等待外部 API 回應的 task，CPU 很低但已經沒有多餘的能力處理新請求。這時用 ALB 的 request count per target（每個 task 平均處理幾個請求）更能反映真實負載。

 1resource "aws_appautoscaling_target" "api" {
 2  max_capacity       = var.api_max_count
 3  min_capacity       = var.api_min_count
 4  resource_id        = "service/${aws_ecs_cluster.main.name}/${aws_ecs_service.api.name}"
 5  scalable_dimension = "ecs:service:DesiredCount"
 6  service_namespace  = "ecs"
 7}
 8
 9resource "aws_appautoscaling_policy" "api_cpu" {
10  name               = "api-cpu-${var.env}"
11  policy_type        = "TargetTrackingScaling"
12  resource_id        = aws_appautoscaling_target.api.resource_id
13  scalable_dimension = aws_appautoscaling_target.api.scalable_dimension
14  service_namespace  = aws_appautoscaling_target.api.service_namespace
15
16  target_tracking_scaling_policy_configuration {
17    target_value       = 60
18    predefined_metric_specification {
19      predefined_metric_type = "ECSServiceAverageCPUUtilization"
20    }
21    scale_in_cooldown  = 300
22    scale_out_cooldown = 60
23  }
24}

target_value = 60 表示目標 CPU 平均維持在 60% — 留 40% 的餘裕應對突發。scale_out_cooldown 設短（60 秒），讓擴張反應快；scale_in_cooldown 設長（300 秒），避免負載短暫下降就立刻縮容、結果下一波流量來了又要重新擴張。

設了 auto-scaling 後要定期看 scaling activity log 確認它在正確的時機擴縮。從來沒觸發過有兩種可能：min_capacity 已經高於實際需求（資源浪費），或 target value 設太高（來不及擴）。

max_capacity 是成本護欄 — 設一個你能接受的上限，避免異常流量（爬蟲、攻擊、上游重試風暴）把 task 數推到遠超預期的帳單。運行期的成本優化在 devops 模組八：成本管理 展開。

規模放大後，auto-scaling 的行為模式會改變。Pokémon GO 上線時實際流量達預估的 50 倍，這類突發不是 auto-scaling 能事前規劃的——50 倍的 headroom 會讓平日成本不合理。Niantic 的 infra 層前提是 GKE 把容器啟動時間降到秒級，讓 surge 反應成為可能；同時依賴 Google CRE 即時補 node 容量。Zoom COVID 期間的 30 倍突發 則是結構性成長——日活從 1000 萬升到 3 億後不會回落，容量規劃的 baseline 需要永久重新校準。兩個案例的共同教訓是：auto-scaling 的 max_capacity 設定要預留突發空間，但極端突發的處理靠的是平台能力（容器化的快速啟動）和 vendor 支援（managed service 的彈性），不是 IaC 配置能獨立解決的。

多叢集治理是另一個規模維度。Riot Games 用 246 個 EKS cluster 跨多遊戲多地區，每個遊戲一個獨立叢集（避免跨遊戲互相影響），搭配 Terraform 做 IaC、Karpenter 做 node lifecycle，年省 1000 萬美金。infra 層的教訓是：當運算叢集數量從個位數長到數十甚至數百，叢集本身變成需要 IaC 治理的資源——叢集的建立、版本升級、安全基線都要標準化。Condé Nast 的 EKS 平台整併也印證了同樣的模式：多團隊各自維護異質 K8s 叢集會造成安全基線不一致，整併到統一平台後把 kube2iam（有 race condition 風險）換成 IRSA（OIDC federation），消除了 node-level 的 credential 共用。

跨分類引用

• → 模組二：身分與憑證地基：execution role 與 task role 的最小權限設計
• → 模組三：網路地基：運算放在 private subnet、security group 接線
• → 模組六：可觀測性與 log：log group 與 task definition 同生命週期
• → devops 模組八：成本管理：auto-scaling 的成本護欄與 spot/Fargate Spot 混用

上核心服務的順序

核心服務的部署順序由依賴方向決定：被依賴的先建，依賴別人的後建。網路與身分是幾乎所有上層服務的共同前置 — 資料庫要放進私有 subnet、運算要套用 IAM role 才能讀 S3、load balancer 要掛在公開 subnet 並引用 security group。這些底層平面若還沒成形，上層資源會在 apply 時因為找不到 subnet ID 或 role ARN 而失敗，或更糟，建在預設 VPC 裡繞過了所有隔離設計。

把順序交給 IaC 工具的依賴圖自動推導，比人工排序可靠。當運算資源的定義引用了 subnet 與 security group 的資源屬性，Terraform 會解析出「subnet 先於運算」的邊，apply 時自動排程。人工維護一份「先做 A 再做 B」的清單會隨資源增加而失準，依賴圖則隨程式碼本身演進。

順序失控的早期徵兆是：某個上層資源的定義裡寫了一串 hardcode 的 subnet ID 或 VPC ID，代表它沒有透過依賴圖連到底層平面。底層一旦重建、ID 改變，上層不會自動跟上，state 與雲端現實之間的不一致（即 drift）就此產生。把硬編碼的 ID 換成對底層資源屬性或 data source 的引用，順序才會回到工具掌控之內。

各類服務怎麼描述

四類核心服務承擔不同責任，IaC 描述它們時關注的屬性也不同。共通原則是：描述服務的「身分與接線」，而非把每個執行期參數都塞進程式碼。

資料庫（RDS） 是這層裡最需要謹慎描述的資源，因為它持有無法重建的狀態。IaC 定義它的 instance class、引擎版本、所在的 subnet group（決定它落在哪些私有 subnet）、套用的 parameter group 與 security group。連線端點不要硬編碼，改用資源 output 暴露給上層運算引用。

1resource "aws_db_instance" "primary" {
2  identifier             = "app-prod-primary"
3  engine                 = "postgres"
4  engine_version         = "16.3"
5  instance_class         = "db.r6g.large"
6  db_subnet_group_name   = aws_db_subnet_group.private.name
7  vpc_security_group_ids = [aws_security_group.db.id]
8}

運算（ECS / EKS） 描述的是業務程式碼的執行載體。重點屬性是它跑在哪些 subnet、套用哪個 task / pod 的 IAM role、掛到哪個 load balancer 的 target group，以及與容器映像版本解耦 — 映像 tag 通常由 CI/CD 在部署期注入，不寫死在 infra 程式碼裡。這層只描述「運算容量與接線」，實際跑什麼版本由部署流程決定，這個邊界讓 infra 變更與應用發布各走各的節奏。

ECS 與 EKS 在這裡被併寫，但兩者的維運模型不同、存在實際選型：ECS 是受管的容器編排，控制平面由雲商代管、心智負擔低，接線概念貼近 AWS 原生資源；EKS 是受管的 Kubernetes，換來跨雲可攜的生態與更細的編排控制，代價是要承擔 Kubernetes 自身的運維面（升級、附加元件、RBAC）。團隊已有 Kubernetes 能力或需要其生態時 EKS 的成本才划算，否則 ECS 的低負擔通常是預設起點。IaC 描述的接線骨架相近，差異主要落在編排層的資源類型。

運算到資料庫之間還有一段常被略過的接線：連線管理。無狀態運算水平擴張時，每個實例各自開連線，容易把資料庫的連線數打滿 — 出現「擴運算反而拖垮 DB」的訊號時，要引入連線池或受管的連線代理（如 RDS Proxy），把連線收斂後再進資料庫，這層也可寫進 IaC 並輸出端點給運算引用。當讀流量遠大於寫、且能容忍副本的複寫延遲時，read replica 是把讀請求導離主庫的下一步，運算端依讀寫分流引用不同端點。

儲存（S3） 描述的是 bucket 的存在、命名、加密設定、版本控制與存取政策。bucket 本身幾乎沒有重建代價意義上的狀態問題 — 困難在它「裝的東西」。空 bucket 可隨時重建，裝了正式資料的 bucket 與 RDS 一樣不可隨意 destroy。描述時把加密、public access block、生命週期規則寫進去，這些是安全與成本的預設防線。

入口（ALB） 描述流量進入系統的第一站。它定義 listener（監聽哪些 port 與協定）、target group（流量導向哪些運算後端）、health check 條件與 TLS 憑證。ALB 本身是 stateless 的 — 重建一個 load balancer 不會遺失資料，但會換掉它的 DNS 名稱，所以對外服務通常在它前面再掛一層穩定的 DNS 記錄。健康檢查的路徑與閾值是這裡最常被忽略的判讀點：閾值太寬鬆會把壞掉的後端留在輪替裡，太嚴格會在部署瞬間誤判健康的新實例。HTTPS listener 引用的 TLS 憑證也屬於這層的接線 — 憑證由 ACM 簽發與自動續期，IaC 用憑證資源描述它（涵蓋網域與驗證方式），再把憑證 ARN 接到 listener 上，讓「憑證存在、續期、掛載」整條鏈都進版本控制，而非在 Console 手動上傳一份會過期沒人盯的憑證。

stateful 資源的特殊處理

stateful 資源的 IaC 描述要把「保護狀態」當成第一類需求，而非事後補上的選項。RDS 是典型 — 它的高可用、備份與還原能力全都能、也應該用程式碼描述，這樣保護策略本身就進入版本控制與審查流程，而非散落在某人手動點過的 Console 設定裡。

multi-AZ 用一個布林屬性開啟，背後是 RDS 在另一個可用區維護同步副本。它解的是可用性：主庫故障時 failover 到 standby，但這個切換有秒級到一兩分鐘的窗口而非零停機，期間連線會中斷重連。要先界定它的邊界，才不會把它當成超出職責的工具。standby 副本是熱備不可讀，所以 multi-AZ 不提供讀取擴展 — 要分攤讀流量得另開 read replica 或改用 multi-AZ cluster 形態。它也不防邏輯損壞：誤刪一張表或一筆錯誤的批次更新會同步複製到 standby，這類風險由 backup 與時間點還原（PITR）負責，與 multi-AZ 的可用性職責正交，兩者要分別配置。

backup 用保留天數與備份視窗描述，RDS 依此每日自動快照並保留交易日誌以支援還原到任意時間點。自動備份的保留上限是 35 天，更長的留存要靠手動快照或匯出到 S3 自行管理。下方 backup_retention_period 取 14 是以 RPO 與合規要求反推的結果 — 一般營運場景 14 天足以涵蓋「發現問題到決定還原」的時間差，受監理或需要更長追溯窗口的服務則往 30 天甚至接上手動快照保險。手動快照用獨立資源描述，常見於重大變更前的保險點。

1resource "aws_db_instance" "primary" {
2  multi_az                   = true
3  backup_retention_period    = 14
4  backup_window              = "03:00-04:00"
5  deletion_protection        = true
6  skip_final_snapshot        = false
7  final_snapshot_identifier  = "app-prod-final"
8}

該在 review 攔下的訊號是：正式環境的 stateful 資源若 backup_retention_period 為 0 或 deletion_protection 為 false，代表狀態保護沒有寫進程式碼。把這些屬性視為正式資料庫的硬性下限，而非可調的偏好。

stateful 與 stateless 的差異怎麼影響操作

stateful 與 stateless 資源的根本差別在重建代價，這個差別會傳導到刪除保護與 drift 風險的處理方式。stateless 資源（ECS service、ALB、無狀態運算）重建只是換一組新實例，幾分鐘內恢復、沒有資料損失，所以它們可以被頻繁地 destroy 與 recreate，是 IaC 最擅長的對象。

stateful 資源（RDS、裝了資料的 S3、持久化 volume）重建意味著資料遺失或漫長的還原，代價可能是數小時的停機與不可逆的損失。這個差別帶來三個操作後果。第一，刪除保護是必要的：stateful 資源開啟 deletion protection，讓「不小心 destroy」需要先顯式關閉保護這一步，多一道人為確認。第二，state drift 的容忍度不同：stateless 資源的 drift 可以靠重建抹平，stateful 資源的 drift（例如有人手動改了 parameter group）要謹慎處理，因為 IaC 的「修正回程式碼狀態」動作可能觸發重啟或重建。第三，變更的審查強度不同：改動 stateful 資源的 plan 輸出要逐行看，特別警惕任何顯示為 replace（先刪後建）而非 update in-place 的項目 — 對資料庫而言這通常代表資料會被丟棄。

實務上把這個差別寫進流程：stateful 資源的變更走更嚴格的 PR review 與分階段套用，這部分的自動化護欄在「模組七：infra 走 PR 流程與自動化護欄」展開。

服務之間的依賴怎麼表達

服務間依賴用 output 與 data source 表達，讓引用關係成為程式碼裡可追蹤的邊，而非靠人記憶的隱性約定。同一個 state 內，直接引用資源屬性即可建立依賴 — 運算資源引用資料庫的端點 output，IaC 自動推導出「資料庫先於運算」，也讓端點變更時上層自動取得新值。

1output "db_endpoint" {
2  value = aws_db_instance.primary.endpoint
3}

跨 state（例如網路地基與核心服務分屬不同 Terraform state，呼應「模組四：環境分離與模組化」的拆分）時，下游用 data source 唯讀地讀取上游已建立的資源。下游查詢上游的 VPC 與 subnet，取得 ID 來放置自己的資源，而不複製貼上硬編碼的值。

1data "aws_vpc" "main" {
2  tags = { Name = "app-prod" }
3}

兩種方式的取捨在耦合與隔離之間。同 state 引用最直接、依賴圖最完整，但 state 越大、單次 apply 的爆炸半徑越大。跨 state 的 data source 把爆炸半徑切小、讓網路地基能獨立演進，代價是依賴關係跨越了 state 邊界、需要約定上游一定先 apply。判讀訊號是：若一份核心服務程式碼裡出現大量寫死的 ID，通常代表該用 data source 而沒用 — 這是日後上游重建時 drift 與 broken reference 的來源。把硬編碼的引用換成 data source，依賴關係才會在程式碼裡顯性化、可被工具與 review 看見。

服務都接上後，下一個關注點是讓它們可被觀測 — log 與 metric 與服務同生命週期建立，這部分在「模組六：可觀測性與 log 同生命週期」展開。

章節文章

跨分類引用

• → backend 模組五：部署平台：PaaS / container 平台跑在這層之上
• → devops 實務指南：這些服務上線後的運行期維運

觀察

Lyft 在 AWS 的關鍵數字（引自 Lyft case study）：

服務組合：Amazon DynamoDB（搭乘追蹤、GPS 座標）、Amazon Redshift（客戶洞察）、Amazon Kinesis（即時事件串流）、AWS Auto Scaling、Amazon EC2 Container Registry。

判讀

Lyft 的工程做法揭露三個微服務容量治理重點。

1. 微服務不是「全部 8x」、是「特定服務 8x」：8x 是 某些核心服務 在週末爆量時刻的擴容比、不是 100 個服務全部 8x。對應 9.5 瓶頸定位流程 必須先做「哪個服務是熱點」的層次定位。
2. 微服務粒度 = 擴容粒度：把 ride matching、payment、driver tracking、notification 切成獨立服務、每個服務的 autoscaling policy 可以獨立設計。對應 03 訊息佇列模組 跟 05 部署平台模組 的服務邊界。
3. GPS 座標寫入 DynamoDB 是高頻 sustained workload：每個 driver 每秒寫 1-2 次位置、200+ 城市 × 每個城市數萬司機 = 巨量持續寫入、跟峰值無關。對應 9.C5 Amazon Ads 的 KV 高吞吐設計同類。

需要警惕：「8x 峰值」是 峰值倍數、不是 尖峰持續時間。週末晚間的尖峰可能持續 3-4 小時、機場特殊事件可能持續 30 分鐘、演唱會結束可能只有 10 分鐘瞬間。容量策略要按持續時間區分。

策略

可重用的工程做法：

1. 微服務粒度切到「同性質擴容單位」：同步 vs async、stateful vs stateless、CPU-bound vs I/O-bound 不該混在同一服務、否則擴容邏輯互相衝突。對應 05 部署平台模組 的 service decomposition。
2. 預測式 + 反應式擴容混用：可預測（早晚通勤）用 scheduled scaling、不可預測（演唱會散場）用 reactive autoscaling、兩者組合。
3. GPS 類持續寫入適合 KV / time-series store：不適合放 OLTP DB、會佔用 transaction 資源。對應 01 資料庫模組 的 storage choice。

跨平台等效：GCP GKE + HPA / VPA / Karpenter、Azure AKS + KEDA、自建 Kubernetes + Cluster Autoscaler 都可以實作對等架構。

下一步路由

• 想做微服務容量治理 → 05 部署平台模組 + 9.6 容量規劃模型
• 想規劃事件型峰值 → 9.11 高峰事件準備 + 9.C2 GR8 Tech
• 想設計高頻 sustained workload → 01 資料庫模組 + 9.C5 Amazon Ads

引用源

• Lyft Case Study
• DynamoDB Customers

觀察

Niantic Pokémon GO 在 GCP 上的關鍵敘述（引自 Bringing Pokémon GO to life on Google Cloud）：

關鍵敘述：「Niantic chose GKE for its ability to orchestrate container clusters at planetary-scale」「Google CRE seamlessly provisioned extra capacity on behalf of Niantic to stay ahead of their record-setting growth」。

判讀

這個案例最重要的判讀是「surge load 跟可預測峰值是不同問題」。

1. 50x surge 沒辦法事前規劃：任何合理的 capacity planning 都不會預留 50x headroom — 那會讓平日成本爆炸。surge 的工程做法不是「事前撐住」、是「事中快速補上」。對應 9.11 高峰事件準備 跟 08 事故處理模組 的事件管理。
2. CRE 不是技術、是 vendor 關係：Google Customer Reliability Engineering 是 GCP 提供給戰略客戶的 24/7 工程支援團隊。能即時為 Niantic 補容量靠的是 人 + 流程 + 工具 的組合、不是純技術。對應 00.6 操作控制服務選型 的廠商支援能力評估。
3. Kubernetes 是 surge 的前置條件：如果 Niantic 用 VM-based 架構、即使 CRE 想補容量也來不及 boot up。Container orchestrator 把 provisioning 時間從分鐘級降到秒級、才讓 surge 反應變得可能。對應 05 部署平台模組 的 platform 選型。

需要警惕：「Google CRE 即時補容量」這種敘述對中小客戶不適用。一般客戶在 surge 下能依賴的是 自己的 autoscaler、不是 vendor 工程師。設計 surge 對應策略時要假設「沒有 vendor 救援」。

策略

可重用的工程做法：

1. 接受 surge 不可避免、設計快速 onboard 流程：核心問題不是「會不會 surge」、是「surge 之後 24 小時內能不能撐住」。對應 9.11 高峰事件準備 跟 08.8 incident communication。
2. 降級機制作為 surge 救命稻草：當容量不足時、優先保住核心功能、暫時關閉非核心。對應 02.3 cache stampede 跟 01.6 high concurrency access 的降級設計。
3. 預先談好 vendor 緊急支援條款：戰略服務在簽約時就要談好 surge 期間的容量配額、限流豁免、CRE / TAM 支援、不要等出事才談。對應 00 服務選型模組 的 vendor relationship 設計。
4. container-first 是 surge 反應的前置：VM-based 架構在 surge 下擴容速度比 container 慢一個量級、會直接成為 bottleneck。

跨平台等效：AWS Enterprise Support + TAM、Azure Premier Support + CSAM 都有對等服務、但能即時動用工程師補容量的程度跟客戶等級綁定。

下一步路由

• 想對應 surge load → 9.11 高峰事件準備 + 08.6 incident severity trigger
• 想設計降級策略 → 01.6 high concurrency access + 02 快取模組
• 想評估 vendor 支援 → 00.6 operations control service selection
• 對照可預測峰值案例 → 9.C1 AWS Prime Day

引用源

• Bringing Pokémon GO to life on Google Cloud
• Google Customer Reliability Engineering

概念位置

ECS 在核心服務層裡的角色是「應用程式的執行載體」。它跑在 VPC 的 private subnet 裡，用 IAM task role 存取其他 AWS 資源，前面掛 ALB 接收流量。IaC 描述 ECS 時，重點在「接線」（subnet、security group、IAM role、target group）而非容器映像版本 — 映像版本由 CI/CD 在部署期注入。

ECS 的執行模式分 EC2 launch type（自己管運算實例、要管 AMI 更新與 capacity provider）和 Fargate launch type（AWS 代管運算、不需管實例）。Fargate 進一步降低運維面，代價是單位成本較高（同規格約多 20-40%）且不支援 GPU workload。

可觀察訊號

以下狀況指向 ECS 相關問題：

• Task 頻繁被 kill 後重啟 — 健康檢查失敗或 OOM，先看 task 的 stopped reason 和 CloudWatch log
• 部署後新版本遲遲不上線 — rolling update 的 minimum healthy percent 設太高，新 task 啟動空間不足
• Task 無法拉到 ECR image — 通常是 private subnet 沒有 NAT 或 VPC Endpoint 到 ECR

設計責任

使用 ECS 時要決定：

• Launch type：Fargate（低運維、較高成本）還是 EC2（低成本、要管實例）。多數 web API 的初始選擇是 Fargate，流量穩定後再評估 EC2
• Task IAM role：task execution role（拉 image 和寫 log 用）和 task role（應用程式存取其他 AWS 資源用）是兩個不同的 role，不要混用
• 映像版本解耦：task definition 裡的 image tag 由 CI/CD 部署期注入，infra code 不寫死版本號
• Auto-scaling 指標：用 CPU / memory 還是 ALB request count，取決於服務是計算密集還是 IO 密集

鄰卡

• Subnet — ECS task 跑在 private subnet 裡
• Security Group — ECS service 套用 security group 控制入站
• IAM — task role 與 execution role 是 ECS 的兩個身分接線
• ALB — 流量透過 ALB target group 導入 ECS task

觀察

Riot Games 遷移到 EKS 的關鍵數字（引自 Riot Games case study）：

服務組合：Amazon EKS（主要）、AWS Local Zones（低延遲就近部署）、AWS Outposts（on-prem edge）、Karpenter（node lifecycle）、Terraform（IaC）。

關鍵架構決策：從 multi-tenant cluster 模型改成 single-tenant per game — 每個遊戲一個獨立 cluster、避免跨遊戲互相影響。

判讀

Riot Games 案例揭露三個多 cluster K8s 容量治理重點。

1. Cluster 隔離是容量規劃的單位：246 個 cluster 看似很多、但 每個 cluster 是獨立容量單位、不互相影響。一個遊戲的擴容不會吃掉另一個遊戲的容量。對應 05 部署平台模組 的 multi-tenant vs single-tenant 取捨。
2. 延遲門檻反推 region 部署：35ms 是競技遊戲（VALORANT、League）的可接受上限、超過會「卡」。從這個門檻反推：玩家所在 region 不能跨洲、需要區域 cluster。對應 9.12 SLO 與 Performance Budget 的 latency budget。Local Zones / Outposts 是這個門檻的工程回應。
3. Karpenter + Terraform = cluster 容量自動化：246 個 cluster 手動管理會崩。Karpenter（node 動態 lifecycle）+ Terraform（IaC）讓 cluster 級操作可重複、可審查。對應 9.9 Performance Improvement Loop 的自動化迴圈。

需要警惕：「年省 1000 萬」是 vs 自管 Mesos、不是 vs 沒上雲。EKS 仍有 vendor cost、只是比自管便宜。讀案例時要看 baseline 是什麼。另外、單一 cluster 的容量上限（pod 數、node 數）仍是工程現實、超過時要做 cluster sharding（這正是 Riot 走 246 個 cluster 的部分原因）。

策略

可重用的工程做法：

1. single-tenant cluster per workload：每個高敏感度工作負載（每個遊戲、每個關鍵服務）一個獨立 cluster、避免 noisy neighbor。對應 05 部署平台模組。
2. 延遲門檻反推 region 部署數量：先訂 latency budget、再算 玩家分布 × region cluster 數量。region 增加會線性增加 ops 成本、要在 latency 跟 cost 之間找平衡。對應 9.7 成本邊界與 efficiency。
3. cluster 級 IaC + 自動化是 multi-cluster 治理前置：Terraform / Pulumi / Crossplane + Karpenter / Cluster Autoscaler 是基本工具。

跨平台等效：GCP GKE Fleet management（multi-cluster）、Azure Fleet Manager、自建 Cluster API + ArgoCD 都可以做 multi-cluster 治理。差異是 vendor 整合度跟政策。

下一步路由

• 想設計 multi-cluster K8s → 05 部署平台模組 + 9.6 容量規劃模型
• 想做延遲門檻反推部署 → 9.12 SLO 與 Performance Budget + 9.C3 Coinbase
• 想對照微服務 vs multi-cluster → 9.C7 Lyft

引用源

• Riot Games Cuts $10M Annual Infrastructure Costs by Migrating to Amazon EKS
• Riot Games on Using AWS to Improve Gaming

觀察

SeatGeek Virtual Waiting Room 架構（引自 AWS Architecture Blog）：

業務動機：取代「第三方 waiting room 服務」、原因是缺乏客製化（VIP 規則、優先級）跟 metrics 可見度。

關鍵機制：

1. Token = 庫存單位：access token 總數 = 可售票數量。沒拿到 token 的用戶被導到 waiting room 頁面、看到排隊位置與預估等待時間。
2. FIFO 或 priority queue：可以按進入順序、也可以對 VIP 客戶優先發 token。
3. Token 失效機制：用戶完成購票 / 主動退出時、token 釋放回 pool、給下一位等候用戶。

判讀

SeatGeek 案例揭露三個明確限流設計重點。

1. 隱性緩衝 vs 明確排隊是兩種架構取捨：Tixcraft 模式「全部塞進 DynamoDB」、用戶以為下單成功、實際處理排隊。SeatGeek 模式「明確告訴你排隊位置」、用戶看得到等待時間。前者犧牲透明度換流量吸收、後者犧牲流量吸收換體驗。對應 9.10 Production-Side 驗證 的用戶體驗 vs 系統行為取捨。
2. WebSocket connection 是 stateful 容量單位：100 萬個 active waiting room 用戶 = 100 萬個 WebSocket connection、每個 connection 都吃記憶體跟 file descriptor。Lambda 沒辦法保持 WebSocket、需要 API Gateway WebSocket API 或 AppSync 配合。對應 05 部署平台模組 的 stateful service 容量規劃。
3. 限流粒度 = 業務粒度：「每分鐘發 N 個 token」這個參數直接決定「每分鐘成交 N 張票」。N 太小、賣不完；N 太大、後端撐不住。N 不是技術參數、是業務 × 後端容量的協商結果。對應 9.6 容量規劃模型 把容量規劃跟業務 KPI 對接。

需要警惕的判讀盲點：

• AWS Architecture Blog 沒提具體流量數字（concurrent users、queue depth、throughput）。讀者無法直接套用到自家容量規劃、必須自己壓測。
• DynamoDB 4 張表的設計 看似簡單、實際上每張表的 partition key / sort key 設計都要仔細想。複製這個架構不等於拿到 SeatGeek 的吞吐能力。
• 「token expiration」機制如果設計不好（例如用戶關閉瀏覽器、token 沒回收）、會導致「排隊很長但實際空著」、影響轉換率。

策略

可重用的工程做法：

1. 明確 vs 隱性限流的選擇：高價值門票（演唱會、限量周邊）適合明確排隊（用戶願意等）；高頻低價值商品（FCFS 折扣）適合隱性緩衝（讓用戶快速完成）。
2. Virtual Waiting Room 是 stateful service、要規劃連線容量：不是 stateless Lambda 一招到底、需要 WebSocket gateway + DynamoDB state store。對應 05 部署平台模組 的混合架構。
3. token 過期策略要寫進設計初稿：用戶離開、付款超時、瀏覽器當掉 — 三種狀況的 token 回收邏輯都不一樣、要明確設計。
4. 可觀測性是「自建 waiting room」勝過「第三方」的關鍵：SeatGeek 換掉第三方就是要 metrics 可見、知道每分鐘 token issue rate、queue depth distribution、token expiration rate、conversion funnel。對應 04 可觀測性模組。

跨平台等效：GCP Cloud Functions + Firestore + Pub/Sub；Azure Functions + Cosmos DB + SignalR；自建 Redis（INCR / TTL）+ WebSocket gateway（Soketi / Socket.IO + Redis adapter）都可以實作對等架構。AWS 還推出官方 Virtual Waiting Room on AWS Solutions、是 SeatGeek 模式的可重用版本。

下一步路由

• 想設計明確排隊限流 → 05 部署平台模組 + 9.11 高峰事件準備
• 對照隱性緩衝模式 → 9.C15 Tixcraft
• 想做 conversion funnel 可觀測性 → 04 可觀測性模組 + 04.16 SLI / SLO 訊號
• 想了解 stateful service 容量規劃 → 05 部署平台模組 + 9.5 瓶頸定位流程

引用源

• Build a Virtual Waiting Room with Amazon DynamoDB and AWS Lambda at SeatGeek
• Virtual Waiting Room on AWS (Solutions)
• How to manage peak traffic on AWS using Queue-it’s virtual waiting room

觀察

FanDuel 在 AWS 的關鍵敘述（引自 FanDuel Case Study）：

關鍵敘述：「seamlessly scale capacity 5–10 times as required for large sporting events, such as the NFL Super Bowl」。

判讀

FanDuel 案例揭露三個雙重峰值對齊的工程重點。

1. 直播跟投注是兩種完全不同 SLO：直播容忍秒級延遲（用 CDN + ABR 串流）、投注必須毫秒級成交（Super Bowl 進球瞬間、賠率變動、用戶投注必須在賠率變化前完成）。兩個服務必須各自獨立擴容、各自獨立 SLO。對應 9.12 SLO 與 Performance Budget 的多 SLO 對齊。
2. AWS Local Zones / Wavelength / Outposts 是地理 + 監管雙重需求：美國博彩受各州監管、資料必須留在州內 → 用 Local Zones 在每個州就近部署；4G/5G 用戶投注延遲敏感 → 用 Wavelength 在電信商機房內運算；on-prem 需求 → 用 Outposts。對應 9.C14 Standard Chartered 的受監管雙重需求、跟 9.C12 Riot Games 的延遲反推 region。
3. 5-10x 是「同類事件中的最高倍率」：Super Bowl 是 NFL 賽季最大事件、不是常態。平日 baseline → 季後賽 2-3x → 季冠軍賽 4-5x → Super Bowl 5-10x。容量規劃要按事件級別分段、不是一律 10x。對應 9.6 容量規劃模型 的事件型容量分級。

需要警惕：

• AWS 案例 沒有 提具體 betting transaction TPS、concurrent streams、延遲分布。讀者要對 策略 學習、不要套用具體數字。
• 「5-10x」是 峰值倍數、不是 peak 持續時間。Super Bowl 的關鍵 30 分鐘可能 8-10x、其他 3 小時可能 3-5x。

策略

可重用的工程做法：

1. 不同 SLO 的工作負載分開部署、不要混在同一 service：betting 跟 streaming 在 FanDuel 必然是兩個獨立微服務、各自有 dedicated infrastructure。對應 05 部署平台模組 的 service decomposition、跟 9.C7 Lyft 同思維。
2. 多層 edge（Local Zone / Wavelength / Outposts）服務不同延遲需求：Local Zone 服務「州內合規」需求、Wavelength 服務「電信網內超低延遲」、Outposts 服務「on-prem 監管」需求。三者組合對應跨州博彩業務。
3. 事件型容量規劃分級：建立 event tier 體系（regular game / playoff / championship / super bowl），每 tier 對應不同 pre-scale 倍數。對應 9.11 高峰事件準備 的容量分級。

跨平台等效：Azure 提供類似 stack（Stack Edge + Edge Zones + Azure for Operators）、GCP 有 Network Edge + Distributed Cloud。差異是各家 edge 覆蓋深度跟電信商合作。

下一步路由

• 對照其他事件型峰值 → 9.C2 GR8 Tech（賽事高潮 AI 預測）/ 9.C4 DraftKings
• 想設計多 SLO 對齊 → 9.12 SLO 與 Performance Budget
• 想做受監管多地區部署 → 9.C14 Standard Chartered + 9.C12 Riot Games
• 想做 edge / Local Zone 規劃 → 05 部署平台模組
• 想理解雙峰下 Aurora storage / replica scaling → Aurora 儲存層架構 + Aurora read replica scaling
• 想評估 distributed SQL 在 betting 場景的 fit → Aurora DSQL / Spanner / CockroachDB 決策樹

引用源

• FanDuel Case Study
• FanDuel CloudFront Case Study

觀察

Maersk + Bosch 在 Azure AKS 的關鍵敘述（引自 AKS Customer Stories）：

其他常見 AKS 大客戶：Siemens Healthineers（醫療設備）、Finastra（金融軟體）、Hafslund（能源）。

判讀

Maersk 跟 Bosch 案例揭露三個傳統產業 K8s 治理的工程重點。

1. 傳統產業上 K8s 的動機是「治理一致性」、不是「成長彈性」：
   • 雲原生公司（Riot、Netflix）上 K8s 是為了 快速擴容 跟 跨 region 部署
   • 傳統產業上 K8s 是為了 統一 50+ 個應用團隊的部署流程、降低 ops 複雜度
   • 訴求不同、配置不同 — 傳統產業可能用 較大 node、較少 cluster、不是 9.C12 Riot 246 cluster 那種多 cluster 策略
2. 微服務 release cycle 多元化是傳統產業上 K8s 的核心需求：Bosch Connected Building 有「樓宇感測 daily release、能源計費 weekly release、設備運維 monthly release」、每個 release cycle 不同。K8s + GitOps（Argo CD、Flux）讓不同 cycle 共存於同一 cluster。對應 05 部署平台模組 的 release governance。
3. 「focus on business impact」是 managed K8s 的真正價值：Maersk 不是科技公司、是航運公司。工程資源從 維持 K8s 運維 釋放到 貨櫃追蹤演算法、港口物流優化、是商業 ROI 的關鍵。對應 9.C29 Lemino 90% 工程工時下降 的同類訴求、跟 9.7 成本邊界與 efficiency 的人力成本工程化。

需要警惕：Azure 官方對 Maersk / Bosch 的描述偏行銷、缺具體 throughput / latency 數字。讀此類案例要對 策略 學習、不要套用數字。

策略

可重用的工程做法：

1. 傳統產業 K8s 採用先做「單一 cluster 多 namespace」、再考慮多 cluster：管理 1 個大 cluster 比管理 246 個小 cluster 容易。除非有 9.C12 Riot Games 的隔離需求、否則 single-cluster-multi-namespace 是 sane default。
2. 不同 release cycle 用 GitOps + namespace 隔離：每個團隊 own 自己的 namespace、配合 Argo CD / Flux 各自 release。對應 05 部署平台模組。
3. AKS / EKS / GKE 的差異對傳統產業不關鍵：選哪家通常取決於企業已用哪家 cloud、不是 K8s feature 本身。重點是 managed K8s ops 比自管划算、不是哪家 managed 最好。
4. 監控訊號設計按業務 cycle：每天 release 的服務跟每月 release 的服務 monitoring 策略不同、alert 敏感度不同。對應 04 可觀測性模組。

跨平台等效：AWS EKS、GCP GKE、自管 Kubernetes + Rancher 都可實作對等架構。Azure 在 enterprise 整合（Active Directory、Azure DevOps）有優勢、特別適合 Microsoft 生態企業。

下一步路由

• 對照雲原生 K8s 策略 → 9.C12 Riot Games 246 cluster
• 對照其他 managed 服務釋放工程資源 → 9.C29 Lemino / 9.C19 Capcom
• 想設計 K8s 治理 → 05 部署平台模組 + 9.6 容量規劃模型

引用源

• Azure Kubernetes Service customer stories
• Maersk Azure case
• Bosch Software Innovations
• Kubernetes on Azure - Enterprise Expertise

觀察

GCP 130K-node GKE cluster 實驗（引自 How we built a 130,000-node GKE cluster）：

工作負載類型：AI / ML 平台、三個 priority class：

• Low：preemptible batch（data prep）
• Medium：core model training（tolerant to queuing）
• High：latency-sensitive inference

關鍵 control plane 設計：

• Consistent Reads from Cache（KEP-2340）— 強一致 read 從 in-memory cache、不打 storage
• Snapshottable API Server Cache（KEP-4988）— B-tree snapshot 處理 LIST 請求
• Spanner-based key-value store 作為 K8s storage backend（撐 13K QPS lease 更新）

判讀

130K-node 案例揭露三個 hyperscale K8s 設計的工程重點。

1. 單一 control plane 的極限取決於 storage backend、不是 nodes：130K node 不是「機器跑不動」、是「API server 跟 etcd 撐不撐住」。GCP 用 Spanner 替換 etcd、配上 cache-first read 設計、把 storage 從瓶頸變成「showed no signs of not being able to support higher scales」。對應 9.5 瓶頸定位流程 的「真實 bottleneck 在哪一層」。
2. AI workload 顛覆了 K8s 容量規劃：傳統 web workload 的 K8s 多在 1K-10K node、節點生命週期長。AI workload 短時間爆量創建跟銷毀 Pods（13 萬個 in 3 分 40 秒）、preempt 跟 schedule 頻繁、對 control plane 是完全不同壓力模式。對應 9.2 Workload Modeling — workload 形狀完全不同、容量規劃也完全不同。
3. 「power constraint > chip supply」是新瓶頸：單顆 NVIDIA GB200 GPU 吃 2700W、萬卡叢集 = 27MW 用電量。未來 mega cluster 必須跨多個 data center（一個 DC 電力撐不住）、需要 robust multi-cluster solutions。這層瓶頸跟 9.7 成本邊界 對接 — 電力成本變成主要 cost driver。

需要警惕：

• 130K-node 是 Google 內部實驗、不是 客戶能用的 production 配置。目前 GKE 官方支援 65K node、客戶用到 100K+ 還很遠。
• AI workload 跟 web workload 完全不同、把 AI 經驗套用到 web service 容量規劃是錯誤類比。

策略

可重用的工程做法：

1. K8s control plane 跟 data plane 分開規劃容量：data plane（worker nodes）擴容容易、control plane（API server、etcd / storage）擴容難。瓶頸通常在 control plane、不是 worker。
2. storage backend 是 K8s 規模極限的關鍵：etcd 撐 5K-10K node 後開始吃力、要用 PostgreSQL / Spanner / 自家 KV 替換、才能擴到萬級節點。一般客戶用不到、但要知道「為什麼到某個規模 etcd 不夠」。
3. AI workload 用 specialized scheduler（Kueue、Volcano）：默認 K8s scheduler 為 web workload 設計、AI 的 gang scheduling、fair-sharing、preemption 都不太適合。對應 05 部署平台模組 的 scheduler 選型。
4. power-aware capacity planning 是未來方向：傳統按 CPU / RAM 規劃容量、未來要加上 power budget。data center 用電量是硬上限、不是錢的問題。
5. multi-cluster 是萬卡訓練的必然：單一 cluster 撐不住、要 MultiKueue 等跨 cluster 排程方案。對應 9.C12 Riot Games multi-cluster 但目的完全不同。

跨平台等效：AWS EKS 官方支援單 cluster 多至 100K pod / cluster、Azure AKS 支援 5K node / cluster。GCP 用 Spanner 替換 etcd 是最深的工程投資、目前其他兩家還沒到這個規模。

下一步路由

• 對照其他大規模 K8s → 9.C12 Riot Games 246 cluster（多 cluster 策略）
• 對照 AI workload → 9.C8 Pokemon GO 50x surge（非 AI 但同 GCP K8s）
• 想理解 control plane vs data plane → 9.C18 Zoom + 9.5 瓶頸定位流程
• 想設計 K8s 容量上限 → 9.6 容量規劃模型 + 05 部署平台模組

引用源

• How we built a 130,000-node GKE cluster
• GKE and Kubernetes at KubeCon 2025
• What’s new in GKE at Next 26