核心服務的部署順序由依賴方向決定（被依賴的先建），運算在這個四層依賴結構裡位於第三層：它引用底層的 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 混用

Fargate 計價模型

Fargate 按 task 的 vCPU 時數和記憶體時數分別計費，從 task 啟動（pull image 完成、進入 RUNNING）到停止。計費的最小粒度是一分鐘，不足一分鐘按一分鐘算。

以 ap-northeast-1（東京）為例的單價（截至撰寫時的量級參考，實際以 AWS 定價頁為準）：

一個 1 vCPU / 2 GB 的 task 持續運行一個月（730 小時）的費用約為 $0.05056 × 730 + $0.00553 × 2 × 730 ≈ $44.97。這個數字是所有後續比較的基線。

Fargate 的計費粒度還有一個常被忽略的面向：task 規格只能從 AWS 預定義的 vCPU/memory 組合中選。如果應用只需要 0.3 vCPU / 512 MB，最小可選的配置是 0.25 vCPU / 0.5 GB，但如果需要 0.3 vCPU / 1 GB，就得選 0.5 vCPU / 1 GB — 多付了 0.2 vCPU 的費用。這個「階梯式浪費」在小規格 task 上比例最高。

Fargate vs EC2 launch type 的成本比較

EC2 launch type 的成本結構不同：付的是 EC2 instance 的時數（不管上面跑幾個 task），加上 ECS 本身不收費。省的是 Fargate 的 markup，多的是 instance 管理（AMI 更新、capacity provider 設定、instance 閒置時仍計費）。

幾個判讀要點：

• task 數量少且持續運行時，Fargate 的溢價比例最高（+50% 到 +277%），但絕對金額小（$15-$80/月的差距），不值得為此承擔 instance 管理的維運負擔
• task 數量多且持續運行時，EC2 的絕對節省量開始可觀（$660/月），這時候切換的維運成本有回報
• 流量波動大時，Fargate 的優勢是按需計費 — 離峰時 task 數降下來就停止計費，EC2 instance 閒置時仍然計費。波動越大，Fargate 的成本效益越接近或超過 EC2

Fargate Spot

Fargate Spot 使用 AWS 的閒置容量，價格約為 on-demand 的 30%（折扣幅度 ~70%），代價是 AWS 可以隨時回收容量、task 會收到 SIGTERM 後被終止。

適用條件：task 能在 120 秒內優雅停止、應用有重試機制或上游有 load balancer 自動移除不健康的 target。批次處理、背景 worker、可中斷的佇列消費者是典型的 Spot 候選。對外直接服務的 API 通常混合部署 — 基線容量用 on-demand、彈性擴張部分用 Spot。

 1resource "aws_ecs_service" "api" {
 2  # ...
 3
 4  capacity_provider_strategy {
 5    capacity_provider = "FARGATE"
 6    weight            = 1
 7    base              = 2  # 至少 2 個 on-demand task 保底
 8  }
 9
10  capacity_provider_strategy {
11    capacity_provider = "FARGATE_SPOT"
12    weight            = 3  # 擴張時 3/4 的 task 用 Spot
13  }
14}

base = 2 確保至少有兩個 on-demand task 在線（不會被回收），weight 比例讓後續擴張的 task 優先使用 Spot。中斷發生時 ECS 會自動在 on-demand 上補充，但補充需要時間（task 啟動 + health check 通過），這段期間服務容量會短暫下降。

Compute Savings Plans

Compute Savings Plans 是對 Fargate（和 EC2、Lambda）的預付承諾折扣：承諾每小時固定消費 X 美元的運算量，換取 1 年或 3 年的折扣（1 年約 -20%、3 年約 -40%，視具體方案）。

關鍵判斷：承諾量（$/hr）設在實際用量的多少比例。保守做法是設在過去 3 個月最低用量的 80% — 這部分幾乎確定會用到，享受折扣；超過承諾量的部分自動按 on-demand 計費，不會浪費。

1# 查過去 90 天的 Fargate 用量趨勢
2aws ce get-cost-and-usage \
3  --time-period Start=2026-03-01,End=2026-06-01 \
4  --granularity MONTHLY \
5  --metrics "UnblendedCost" \
6  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Container Service"]}}'

Savings Plans 跟 Fargate Spot 可以疊加：Spot task 的費用也能用 Savings Plans 折抵。先用 Savings Plans 降低基線成本，再用 Spot 降低彈性擴張的成本，兩層折扣疊起來可以把 Fargate 的實際單價壓到接近 EC2 on-demand。

Task 規格的 rightsizing

Fargate task 的 vCPU 和記憶體配置如果設得過大，多出來的資源每小時都在計費。rightsizing 的目標是讓 task 規格貼合實際使用量，但留足安全餘裕。

量測實際使用量

開啟 CloudWatch Container Insights 後，每個 task 的 CPU 和記憶體使用量會自動上報。觀察 7-14 天的 p95 值：

1# 查 ECS service 過去 7 天的 CPU p95
2aws cloudwatch get-metric-statistics \
3  --namespace ECS/ContainerInsights \
4  --metric-name CpuUtilized \
5  --dimensions Name=ServiceName,Value=api Name=ClusterName,Value=prod \
6  --start-time 2026-06-19T00:00:00Z \
7  --end-time 2026-06-26T00:00:00Z \
8  --period 3600 \
9  --statistics p95

判斷調整方向

調整後觀察 3-5 天確認沒有效能退化再進入下一輪。每次只調一個維度（CPU 或 memory），避免同時改兩個變數無法歸因。

Fargate 可選的規格組合

Fargate 的 vCPU 和 memory 不能任意搭配。常用的組合：

選的時候從最小的「能跑」組合開始，用 Container Insights 量測後再調。常見的浪費是把所有 task 都設成 1 vCPU / 2 GB — 一個只用 0.1 vCPU / 256 MB 的 sidecar 也配了同樣的規格。

何時從 Fargate 切到 EC2

切換的判斷不只看成本差額，還要看維運能力。EC2 launch type 需要管理：AMI 更新（安全 patch）、instance draining（rolling update 時把 task 遷走再關 instance）、capacity provider 的擴縮邏輯、instance 的 security group 與 IAM role。

混合部署是常見的中間路線：基線容量用 EC2（成本低、啟動快），尖峰彈性用 Fargate Spot（按需、不需預留）。這需要同時維護兩種 capacity provider，複雜度較高。

成本監控

把 ECS 的成本歸因到服務層級需要兩個機制：task 層的 tag propagation 和 Cost Explorer 的 tag 維度。

 1resource "aws_ecs_service" "api" {
 2  # ...
 3  propagate_tags = "SERVICE"
 4
 5  tags = {
 6    service     = "payment-api"
 7    env         = "prod"
 8    cost-center = "cc-payments"
 9  }
10}

propagate_tags = "SERVICE" 讓 service 的 tag 自動傳播到每個 task，Cost Explorer 就能按 service 或 cost-center 維度拆分 Fargate 費用。這跟模組八：治理好習慣的 tagging 規範對齊 — tag 是成本可見性的地基。

定期（月初或月中）檢查 Cost Explorer 的 Fargate 費用趨勢：

1aws ce get-cost-and-usage \
2  --time-period Start=2026-06-01,End=2026-06-26 \
3  --granularity DAILY \
4  --metrics "UnblendedCost" \
5  --group-by Type=TAG,Key=service \
6  --filter '{"Dimensions":{"Key":"SERVICE","Values":["Amazon Elastic Container Service"]}}'

費用突然跳升時，先看是 task 數增加（auto-scaling 觸發）還是單價變化（Savings Plans 過期或 Spot 中斷後自動回補為 on-demand）。這兩者的處理方式不同：前者檢查 scaling policy、後者檢查 Savings Plans 到期日和 Spot 回收頻率。

跨分類引用

• → 運算平台上 IaC：ECS vs EKS 選型、Fargate 的定位
• → 模組八：治理好習慣：tagging 與成本可見性的地基
• → devops 模組八：成本管理：運行期的 RI / Spot / rightsizing 策略

概念位置

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