本篇先確立依賴圖怎麼驅動部署順序，再展開核心服務裡最需要謹慎描述的一類 — 資料庫。資料庫持有無法重建的狀態，它的 IaC 描述比其他 stateless 資源多出保護策略、連線管理與讀寫分流三個維度。

核心服務的部署順序

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

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

四層依賴結構

依賴圖的典型展開順序呈現四層結構：

這四層不需要手動編排。只要程式碼裡的引用關係正確，Terraform 就會自動按這個順序 apply。當 plan 輸出的順序看起來不合直覺 — 例如 ALB 先於 ECS — 通常代表某個引用斷了、兩者之間沒有依賴邊。

順序失控的徵兆

順序失控的早期徵兆是：某個上層資源的定義裡寫了一串 hardcode 的 subnet ID 或 VPC ID。

1# 硬編碼 ID — 依賴圖斷裂，底層重建時上層不會跟上
2resource "aws_db_subnet_group" "private" {
3  subnet_ids = ["subnet-0abc123", "subnet-0def456"]
4}

這段 code 跟底層的 subnet 資源沒有引用關係。底層一旦重建、ID 改變，上層不會自動跟上，state 與雲端現實之間的不一致（即 drift）就此產生。修法是把硬編碼的 ID 換成對底層資源屬性的引用：

1# 引用資源屬性 — 依賴圖自動推導，底層重建時上層自動取得新 ID
2resource "aws_db_subnet_group" "private" {
3  subnet_ids = [for s in aws_subnet.private : s.id]
4}

跨 state 的情境（網路地基與核心服務分屬不同 state）則用 data source 取代直接引用 — 這個取捨在服務依賴與跨 state 引用展開。

隱性依賴與 depends_on

自動推導涵蓋的是「引用屬性時產生的邊」。少數情況下兩個資源之間有依賴卻沒有屬性引用 — 例如一個 IAM policy attachment 必須在某個 role 被 ECS task 使用之前完成，但 task 引用的是 role ARN 而非 attachment 的輸出。這時用 depends_on 顯式宣告邊：

1resource "aws_ecs_service" "api" {
2  # ...
3  depends_on = [aws_iam_role_policy_attachment.ecs_task_s3]
4}

depends_on 應該只出現在自動推導覆蓋不了的場景。如果一個 module 裡到處都是 depends_on，通常代表引用關係寫得不夠明確，該把隱性依賴改成屬性引用。

資料庫（RDS）

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

 1resource "aws_db_instance" "primary" {
 2  identifier             = "app-${var.env}-primary"
 3  engine                 = "postgres"
 4  engine_version         = "16.3"
 5  instance_class         = var.db_instance_class
 6  allocated_storage      = 100
 7  storage_encrypted      = true
 8
 9  db_subnet_group_name   = aws_db_subnet_group.private.name
10  vpc_security_group_ids = [aws_security_group.db.id]
11
12  multi_az                  = var.env == "prod" ? true : false
13  backup_retention_period   = var.env == "prod" ? 14 : 1
14  backup_window             = "03:00-04:00"
15  deletion_protection       = var.env == "prod" ? true : false
16  skip_final_snapshot       = var.env == "prod" ? false : true
17  final_snapshot_identifier = var.env == "prod" ? "app-prod-final-${formatdate("YYYYMMDD", timestamp())}" : null
18
19  tags = { service = "payments" }
20}
21
22output "db_endpoint" {
23  value = aws_db_instance.primary.endpoint
24}

加密的不可逆性

storage_encrypted = true 確保磁碟層級的加密在資源建立時就生效。RDS 不支援事後對既有 instance 開加密 — 漏了只能重建。補救路徑是匯出快照、用加密 KMS key 複製快照成加密版本、再用加密快照還原成新 instance。這個過程需要停機或切換端點，對已經承載流量的 production 資料庫代價很高。prod 的 RDS 若 storage_encrypted 為 false，這筆技術債越早處理越便宜。

parameter group 的角色

parameter group 定義資料庫引擎層級的行為參數（如 max_connections、work_mem、log_min_duration_statement），是 RDS instance 的設定骨架。IaC 描述 parameter group 的好處是讓這些參數進版本控制 — 有人改了 max_connections 會出現在 PR diff 裡，而不是某天在 Console 改了沒人知道。

 1resource "aws_db_parameter_group" "postgres16" {
 2  family = "postgres16"
 3  name   = "app-${var.env}-pg16"
 4
 5  parameter {
 6    name  = "log_min_duration_statement"
 7    value = "1000"
 8  }
 9
10  parameter {
11    name  = "shared_preload_libraries"
12    value = "pg_stat_statements"
13  }
14}

修改 parameter group 的某些參數需要重啟 RDS instance（稱為 apply_method = "pending-reboot"），修改前要先確認這個參數屬於「立即生效」還是「要重啟」。在 Terraform plan 裡不會明確標示重啟，要靠 AWS 文件交叉比對。

連線管理

運算到資料庫之間有一段常被略過的接線：連線管理。無狀態運算水平擴張時，每個實例各自開連線，容易把資料庫的連線數打滿。一個 ECS service 從 5 個 task 擴到 50 個、每個 task 開 10 條連線，就從 50 條跳到 500 條 — 而一台 db.r6g.large 的 max_connections 預設約在 1600 左右，500 條已經吃掉三分之一。

出現「擴運算反而拖垮 DB」的訊號時，解法是引入連線池或受管的連線代理。RDS Proxy 是 AWS 的受管方案：它在運算與 RDS 之間當一層連線池，把下游的數百條短連線收斂成對 RDS 的少量長連線。在 IaC 裡一併定義，輸出 proxy 端點給運算引用：

 1resource "aws_db_proxy" "app" {
 2  name                   = "app-${var.env}-proxy"
 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.db.id]
 7
 8  auth {
 9    auth_scheme = "SECRETS"
10    secret_arn  = aws_secretsmanager_secret.db_password.arn
11  }
12}
13
14output "db_proxy_endpoint" {
15  value = aws_db_proxy.app.endpoint
16}

運算端引用 db_proxy_endpoint 而非 db_endpoint，連線管理就從各 task 自己處理轉成由 proxy 統一收斂。RDS Proxy 同時提供 failover 的連線保持 — 主庫切換到 standby 時，proxy 維護的連線不會全部斷開重建，應用端感受到的是短暫延遲而非連線錯誤。

判讀是否需要 RDS Proxy 的訊號是連線數成長曲線：如果運算的擴縮範圍固定且連線數上限遠低於 max_connections，直連即可；如果運算會頻繁擴縮或連線數可能逼近上限，proxy 值得引入。proxy 本身有額外成本（按 vCPU 計費），不是所有環境都划算 — dev 環境通常直連就夠。

read replica

當讀流量遠大於寫、且能容忍副本的複寫延遲（通常是毫秒到秒級）時，read replica 是把讀請求導離主庫的下一步。replica 在 IaC 裡用獨立資源描述，引用主庫的 identifier：

 1resource "aws_db_instance" "read_replica" {
 2  identifier             = "app-${var.env}-replica"
 3  replicate_source_db    = aws_db_instance.primary.identifier
 4  instance_class         = var.db_replica_class
 5  vpc_security_group_ids = [aws_security_group.db.id]
 6}
 7
 8output "db_replica_endpoint" {
 9  value = aws_db_instance.read_replica.endpoint
10}

運算端依讀寫分流引用不同端點 — 寫走 db_endpoint（或 db_proxy_endpoint），讀走 db_replica_endpoint。這個分流邏輯屬於應用層的責任，infra 只負責把端點暴露出來。

read replica 的邊界要講清楚：它緩解讀流量對主庫的壓力，但它不是備份。replica 會同步複製主庫的所有變更 — 包括誤刪的資料。需要還原到某個時間點的保護由 backup retention 與 PITR（point-in-time recovery）提供，這兩者的 IaC 描述在 stateful 保護策略。

引擎版本升級的取捨

RDS 引擎版本（engine_version）寫進 IaC 後，版本升級就成為一個需要 PR review 的變更。升級分 minor 和 major：minor 升級（16.2 → 16.3）通常向後相容、可在維護視窗自動套用；major 升級（15 → 16）可能有 breaking change，需要先在 dev 環境驗證、備份、排維護窗口。

在 IaC 裡把 engine_version 寫死是刻意的選擇 — 它阻止 AWS 在背景自動升級 major 版本，讓版本變更必須走 PR。代價是需要定期檢查是否有 EOL 版本還在用。如果 engine_version 指向的版本已經超過 AWS 的支援期限，Terraform apply 會在某天失敗（AWS 會強制升級），這比主動升級更不可控。

資料庫在規模放大後的治理維度也會改變。Netflix 把分散的 Aurora 叢集整併後成本降了 28%——多個團隊各自開的 RDS instance 加起來的閒置容量遠超一個整併後的叢集。infra 層的教訓是 RDS 的 IaC 描述不只管單一 instance 的設定，長期還要管叢集的分布與合併策略。另一個維度是合規需求驅動的資料落地：Hard Rock Digital 因為 Wire Act 法規要求資料留在特定州，用 AWS Outposts 在地端跑運算——這類情境下 infra 的 region 與可用區選擇由法規約束驅動，而非純技術決策。

跨分類引用

• → 模組三：網路地基：資料庫的 subnet group 引用 private subnet
• → 模組二：身分與憑證地基：RDS Proxy 的 IAM role 與 secret 存取
• → 模組四：環境分離與模組化：prod / dev 用同一個 module、不同參數值
• → stateful 保護與跨 state 引用：backup retention、deletion protection、multi-AZ 的完整討論
• → 運算上 IaC：運算端怎麼引用資料庫端點
• → backend 模組一：資料庫：schema 設計、migration、query 層面的服務端討論

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

bucket 的四道安全防線

一個 S3 bucket 在 IaC 裡至少要描述四個獨立資源，各自對應一道防線。Terraform 把它們拆成獨立資源是設計選擇 — 每道防線可以單獨 review、單獨調整、單獨追蹤變更歷史。

 1resource "aws_s3_bucket" "assets" {
 2  bucket = "acme-${var.env}-assets"
 3
 4  tags = { service = "cdn-origin", env = var.env }
 5}
 6
 7resource "aws_s3_bucket_versioning" "assets" {
 8  bucket = aws_s3_bucket.assets.id
 9  versioning_configuration { status = "Enabled" }
10}
11
12resource "aws_s3_bucket_server_side_encryption_configuration" "assets" {
13  bucket = aws_s3_bucket.assets.id
14  rule {
15    apply_server_side_encryption_by_default {
16      sse_algorithm = "aws:kms"
17    }
18  }
19}
20
21resource "aws_s3_bucket_public_access_block" "assets" {
22  bucket                  = aws_s3_bucket.assets.id
23  block_public_acls       = true
24  block_public_policy     = true
25  ignore_public_acls      = true
26  restrict_public_buckets = true
27}

versioning

versioning 讓物件的每次覆寫都保留前一版。誤覆寫時可以從版本歷史回退到前一個正確版本，誤刪時物件只是被標記為 delete marker、前一版仍然存在。這道防線對承載正式資料的 bucket 是必要的 — 沒有 versioning 的 bucket，一次誤操作就是資料永久遺失。

versioning 開啟後會累積歷史版本的儲存量。搭配生命週期規則設定 noncurrent_version_expiration 可以控制保留多少天的舊版本，避免儲存成本無限成長。這個天數是「保留能力」跟「儲存成本」的取捨 — 保留 30 天通常足以涵蓋發現問題到回退的時間差，受合規要求的資料則依規定延長。

server-side encryption

server_side_encryption 確保物件在 S3 落地時加密。aws:kms 使用 KMS 管理的金鑰，加密操作對應用程式透明 — 寫入時自動加密、讀取時自動解密，不需要改應用程式碼。選 aws:kms 而非 AES256（SSE-S3）的判斷依據是存取控制粒度：KMS 金鑰可以獨立設定 key policy，讓「誰能解密」這件事跟「誰能讀 bucket」分開管理，適合跨帳號或跨團隊的場景。

使用 KMS 加密的 bucket 在跨帳號存取時，目標帳號除了要有 bucket 的讀取權限，還需要 KMS key 的 kms:Decrypt 權限 — 少了這一步會拿到 AccessDenied，錯誤訊息通常指向 S3 權限而非 KMS，排查時容易走錯方向。

public access block

public_access_block 的四個布林全設 true，等於從 bucket 層級封死對外公開的可能。即使有人之後誤加了一條公開的 bucket policy 或 ACL，這個 block 也會擋住。它是一道兜底機制 — 擋的是設定錯誤，不是正常操作。

靜態掃描工具（checkov / tfsec）會標記缺少 public access block 的 bucket。這正是模組七：infra 走 PR 流程裡自動化護欄的典型攔截對象 — 漏設的 bucket 會在 PR 階段被擋下，而非部署到線上才發現。

定期用 CLI 掃一遍帳號內所有 bucket 的公開狀態，命中的每個 bucket 都要能回答「這個公開是故意的、理由是什麼」：

1aws s3api list-buckets --query 'Buckets[].Name' --output text | tr '\t' '\n' | \
2  while read b; do
3    status=$(aws s3api get-public-access-block --bucket "$b" 2>/dev/null | \
4      jq -r '.PublicAccessBlockConfiguration | to_entries[] | select(.value==false) | .key')
5    [ -n "$status" ] && echo "$b: $status"
6  done

生命週期規則

儲存成本隨物件數量與保留時間線性成長。生命週期規則讓 IaC 描述「某類物件多久後搬到更便宜的儲存層、再多久後刪掉」，把成本控制變成可版本控制的設定。

 1resource "aws_s3_bucket_lifecycle_configuration" "assets" {
 2  bucket = aws_s3_bucket.assets.id
 3
 4  rule {
 5    id     = "archive-old-logs"
 6    status = "Enabled"
 7    filter { prefix = "logs/" }
 8
 9    transition {
10      days          = 30
11      storage_class = "GLACIER_IR"
12    }
13    expiration { days = 365 }
14  }
15
16  rule {
17    id     = "cleanup-old-versions"
18    status = "Enabled"
19    filter {}
20
21    noncurrent_version_expiration {
22      noncurrent_days = 30
23    }
24  }
25}

儲存層的取捨

S3 提供多個儲存層，各自在存取延遲與儲存單價之間取捨：

transition 規則的日數設定要回推自業務需求：log 在除錯期間需要即時讀取（Standard），超過 30 天後幾乎只在事故回顧時才翻（Glacier Instant Retrieval 或 Standard-IA），超過一年可以淘汰或移到更深的歸檔層。把這些規則寫進 IaC，「為什麼 logs 只留一年」就是一個能在 PR 上被討論的決定，而非某人在 Console 點了不知道大家知不知道的設定。

bucket policy 與跨帳號存取

bucket policy 描述誰能對這個 bucket 做什麼操作，是 bucket 層級的存取控制。它跟 IAM policy 的差別在施力點：IAM policy 貼在身分上、定義「這個身分能做什麼」；bucket policy 貼在資源上、定義「這個 bucket 允許誰來」。兩者同時生效 — 一個請求要同時被身分端和資源端允許才會放行（除非有顯式 deny）。

跨帳號存取是 bucket policy 最常見的使用場景。一個帳號的 S3 bucket 要讓另一個帳號的 IAM role 讀取，需要兩端同時授權：bucket policy 允許那個 role 的 ARN，對方帳號的 IAM policy 也允許對這個 bucket 操作。

 1resource "aws_s3_bucket_policy" "cross_account_read" {
 2  bucket = aws_s3_bucket.assets.id
 3
 4  policy = jsonencode({
 5    Version = "2012-10-17"
 6    Statement = [{
 7      Sid       = "AllowCrossAccountRead"
 8      Effect    = "Allow"
 9      Principal = { AWS = "arn:aws:iam::111222333444:role/data-reader" }
10      Action    = ["s3:GetObject", "s3:ListBucket"]
11      Resource = [
12        aws_s3_bucket.assets.arn,
13        "${aws_s3_bucket.assets.arn}/*"
14      ]
15    }]
16  })
17}

bucket policy 的常見陷阱是 Principal: "*" — 允許任何人存取。這跟 security group 的 0.0.0.0/0 是同一類風險。除了做為 CloudFront Origin Access Control（OAC）的配合設定，幾乎沒有合理場景需要把 Principal 設成 wildcard。checkov 的 CKV_AWS_70 規則專門攔這個。

把 bucket policy 寫進 IaC 的好處是每一條授權都有 PR 紀錄 — 誰在什麼時候加了一條跨帳號存取、為什麼加、reviewer 同意了沒有。散落在 Console 的 bucket policy 沒有這些追蹤，某天發現一條不認得的授權時，只能去翻 CloudTrail 猜它是什麼時候加的。

事件通知

S3 事件通知讓 bucket 在物件被建立、刪除或還原時，自動觸發下游處理 — 寫入後自動縮圖、上傳後自動掃毒、刪除後自動通知。這些觸發關係寫進 IaC，讓「這個 bucket 會觸發什麼」成為可查詢的事實，而非散落在 Console 的隱性接線。

 1resource "aws_s3_bucket_notification" "assets" {
 2  bucket = aws_s3_bucket.assets.id
 3
 4  lambda_function {
 5    lambda_function_arn = aws_lambda_function.thumbnail.arn
 6    events              = ["s3:ObjectCreated:*"]
 7    filter_prefix       = "uploads/"
 8    filter_suffix       = ".jpg"
 9  }
10}
11
12resource "aws_lambda_permission" "allow_s3" {
13  statement_id  = "AllowS3Invoke"
14  action        = "lambda:InvokeFunction"
15  function_name = aws_lambda_function.thumbnail.function_name
16  principal     = "s3.amazonaws.com"
17  source_arn    = aws_s3_bucket.assets.arn
18}

事件通知的兩個配置常被忽略。第一是權限：S3 要觸發 Lambda，Lambda 的 resource-based policy 必須允許 S3 呼叫它（上面的 aws_lambda_permission），少了這段 apply 會成功但事件不會觸發，除錯時不容易發現。第二是 filter：不設 prefix / suffix 的通知會對 bucket 裡每一個物件操作都觸發，包括生命週期搬遷產生的物件變動 — 流量遠超預期。用 filter 把觸發範圍收斂到需要處理的路徑與檔案類型。

事件通知也可以導向 SQS 或 SNS，適合需要非同步佇列處理或 fan-out 到多個消費者的場景。選擇依據是下游的消費模式：Lambda 適合輕量即時處理（毫秒級回應），SQS 適合需要 backpressure 和重試的批次處理，SNS 適合同一事件需要同時通知多個服務。

跨分類引用

• → 模組七：infra 走 PR 流程：checkov / tfsec 攔截缺少 public access block 或加密的 bucket
• → 模組八：治理好習慣：bucket 的 tagging 與成本歸因
• → 模組二：身分與憑證地基：bucket policy 與 IAM policy 的權限模型交集

ALB 掛在 public subnet、引用專屬的 security group，security group 的入站通常只開 80 和 443 對 0.0.0.0/0（這是少數合理出現全開的位置，因為 ALB 的工作本來就是接收公開流量）。後端運算節點住在 private subnet，它們的 security group 入站只允許來自 ALB security group 的流量 — 這個 group-to-group 引用讓規則跟著成員身分走，不跟著 IP 走（見模組三：網路地基）。

ALB 與 listener 設定

ALB 資源本身描述的是它掛在哪些 subnet、用哪個 security group、是對外（internal = false）還是內部。Listener 則是掛在 ALB 上的監聽端點，每個 listener 綁定一個 port + protocol 的組合。

1resource "aws_lb" "api" {
2  name               = "api-${var.env}"
3  internal           = false
4  load_balancer_type = "application"
5  security_groups    = [aws_security_group.alb.id]
6  subnets            = [for s in aws_subnet.public : s.id]
7}

HTTP 到 HTTPS 的強制跳轉

正式服務通常同時建兩個 listener：port 443 接受 HTTPS 流量並轉發到後端，port 80 接收 HTTP 流量後直接回一個 301 redirect 到 HTTPS — 確保使用者即使用 http:// 開頭訪問也會被導到加密連線。

 1resource "aws_lb_listener" "https" {
 2  load_balancer_arn = aws_lb.api.arn
 3  port              = 443
 4  protocol          = "HTTPS"
 5  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
 6  certificate_arn   = aws_acm_certificate.api.arn
 7
 8  default_action {
 9    type             = "forward"
10    target_group_arn = aws_lb_target_group.api.arn
11  }
12}
13
14resource "aws_lb_listener" "http_redirect" {
15  load_balancer_arn = aws_lb.api.arn
16  port              = 80
17  protocol          = "HTTP"
18
19  default_action {
20    type = "redirect"
21    redirect {
22      port        = "443"
23      protocol    = "HTTPS"
24      status_code = "HTTP_301"
25    }
26  }
27}

ssl_policy 決定 ALB 接受哪些 TLS 版本與密碼套件。選擇以安全與相容性為取捨 — ELBSecurityPolicy-TLS13-1-2-2021-06 只接受 TLS 1.2 和 1.3，能阻擋過時協定的降級攻擊，但會拒絕仍在使用 TLS 1.0/1.1 的極舊用戶端。對面向公眾的 API 或網站，TLS 1.2 以上是合理的底線；如果有明確的舊用戶端需求（例如嵌入式設備），再往下調但要知道代價。

多服務共用 ALB

一個 ALB 可以掛多個 listener rule，用 host header 或 path 把流量分到不同的 target group。這讓多個微服務共用一個 ALB（省成本），而不需要每個服務各開一個：

 1resource "aws_lb_listener_rule" "auth" {
 2  listener_arn = aws_lb_listener.https.arn
 3  priority     = 10
 4
 5  condition {
 6    path_pattern { values = ["/auth/*"] }
 7  }
 8
 9  action {
10    type             = "forward"
11    target_group_arn = aws_lb_target_group.auth.arn
12  }
13}

一個常見的收斂機會：如果每個服務都各自開了一個 ALB，但流量都從同一個入口進來、只是路徑不同，可以收斂成一個 ALB 加 listener rule。每個 ALB 有固定的小時費，少開幾個月費就少幾筆。反過來，當不同服務的安全等級或流量特性差異大到需要獨立的 security group 和 WAF 規則時，分開 ALB 才合理。

target group 與健康檢查

Target group 定義一組接收流量的後端（ECS task、EC2 instance 或 IP），以及判斷這些後端是否健康的檢查邏輯。它是 ALB 和實際運算之間的橋樑。

 1resource "aws_lb_target_group" "api" {
 2  name        = "api-${var.env}-tg"
 3  port        = 8080
 4  protocol    = "HTTP"
 5  vpc_id      = aws_vpc.main.id
 6  target_type = "ip"
 7
 8  health_check {
 9    path                = "/healthz"
10    interval            = 15
11    healthy_threshold   = 2
12    unhealthy_threshold = 3
13    timeout             = 5
14    matcher             = "200"
15  }
16}

健康檢查的閾值設計

健康檢查的路徑與閾值是最常被忽略的判讀點。各參數之間的交互作用決定了兩個時間窗口：新後端多久後開始接流量、壞後端多久後被移出。

healthy_threshold = 2 配 interval = 15 代表一個新啟動的後端要等 30 秒（兩次通過）才開始接流量。unhealthy_threshold = 3 代表連續三次失敗（45 秒）才被移出。閾值太寬鬆會把壞掉的後端留在輪替裡，讓部分使用者持續收到錯誤；太嚴格會在部署瞬間 — 新容器啟動、應用還在初始化 — 就判定不健康，反覆移出移入，使用者看到間歇性失敗。

健康檢查路徑的選擇

path 指向的端點應該能反映應用是否確實能服務請求，而不只是 process 還活著。一個只回 200 的空端點（所謂 liveness check）證明 HTTP server 在跑，但不代表它能連到資料庫、能讀到必要的 config。較合理的做法是讓 /healthz 至少檢查核心依賴的連線（例如 ping 一下 DB），失敗時回 503。代價是健康檢查會跟著核心依賴一起報不健康 — 如果 DB 暫時斷了，所有後端都會被判定不健康，ALB 會回 503 給使用者。這是正確的行為：如果應用確實無法服務請求，把它標成不健康比假裝健康好。

判讀方式：部署後觀察 target group 裡的 healthy / unhealthy 轉換次數。如果每次部署都看到新 target 在 healthy 與 unhealthy 之間跳動，代表初始等待不夠 — 應用的啟動時間超出 healthy_threshold * interval，考慮加大 healthy_threshold 或設定 ECS 的 startPeriod（啟動寬限期）讓健康檢查在應用初始化期間暫停。

TLS 憑證：ACM 簽發、DNS 驗證與自動續期

HTTPS listener 引用的 TLS 憑證也屬於 ALB 的接線。用 ACM（AWS Certificate Manager）簽發的憑證在 IaC 裡完整描述 — 涵蓋網域與 DNS 驗證方式 — 讓「憑證存在、驗證、掛載」整條鏈都進版本控制，而非在 Console 手動上傳一份會過期沒人盯的憑證。

ACM 簽發的憑證使用 DNS 驗證時，ACM 要求在指定的 DNS 記錄上放一段驗證值。Terraform 可以自動建立這段記錄並等待驗證通過：

 1resource "aws_acm_certificate" "api" {
 2  domain_name       = "api.${var.domain}"
 3  validation_method = "DNS"
 4
 5  lifecycle { create_before_destroy = true }
 6}
 7
 8resource "aws_route53_record" "cert_validation" {
 9  for_each = {
10    for dvo in aws_acm_certificate.api.domain_validation_options : dvo.domain_name => dvo
11  }
12  zone_id = data.aws_route53_zone.main.zone_id
13  name    = each.value.resource_record_name
14  type    = each.value.resource_record_type
15  records = [each.value.resource_record_value]
16  ttl     = 60
17}
18
19resource "aws_acm_certificate_validation" "api" {
20  certificate_arn         = aws_acm_certificate.api.arn
21  validation_record_fqdns = [for r in aws_route53_record.cert_validation : r.fqdn]
22}

create_before_destroy 的必要性

create_before_destroy = true 確保憑證更新（例如加 SAN 或續期觸發重建）時先建新的再刪舊的，避免 listener 在交接期間沒有可用憑證。Terraform 預設行為是先刪後建，會造成一個短暫的 HTTPS 中斷窗口 — listener 找不到憑證、所有 HTTPS 連線失敗直到新憑證簽發並驗證完畢。

ACM 簽發的憑證自動續期：只要 DNS 驗證記錄還在（由 Terraform 管理，所以會一直在），ACM 在到期前 60 天自動續期。這是把憑證管理成本降到接近零的做法 — 不需要排程提醒、不需要手動下載上傳。判讀訊號：如果 CloudWatch 出現 DaysToExpiry 降到 30 以下的 alarm，代表自動續期失敗，通常是 DNS 驗證記錄被手動刪了或 Route 53 zone 變了。

多網域憑證（SAN）

一張 ACM 憑證可以涵蓋多個網域（Subject Alternative Names），例如 api.example.com 和 admin.example.com 共用一張。在 IaC 裡用 subject_alternative_names 列舉：

1resource "aws_acm_certificate" "multi" {
2  domain_name               = "api.${var.domain}"
3  subject_alternative_names = ["admin.${var.domain}", "*.internal.${var.domain}"]
4  validation_method         = "DNS"
5
6  lifecycle { create_before_destroy = true }
7}

共用一張還是分開簽取決於生命週期：如果這幾個網域總是一起上下線、一起變更，共用一張省維護；如果各自獨立演進，分開簽讓變更範圍更小。

DNS zone 管理與 ALB 的銜接

Hosted zone：DNS 記錄的容器

Route 53 的 hosted zone 是一個網域下所有 DNS 記錄的容器。public hosted zone 管理對外可見的網域（如 example.com），private hosted zone 管理只在 VPC 內可解析的內部網域（如 internal.example.com），讓服務之間用 DNS 名稱互連而不靠 IP。

多環境的 DNS 管理常用子網域 delegation：production 用 example.com（主 zone），dev 和 staging 各用 dev.example.com 和 staging.example.com（子 zone）。子 zone 可以放在不同帳號、由不同團隊管理，主 zone 只需要一組 NS 記錄指向子 zone。這讓環境之間的 DNS 邊界跟帳號邊界對齊。

 1resource "aws_route53_zone" "main" {
 2  name = var.domain
 3}
 4
 5resource "aws_route53_zone" "staging" {
 6  name = "staging.${var.domain}"
 7}
 8
 9resource "aws_route53_record" "staging_ns" {
10  zone_id = aws_route53_zone.main.zone_id
11  name    = "staging.${var.domain}"
12  type    = "NS"
13  ttl     = 300
14  records = aws_route53_zone.staging.name_servers
15}

hosted zone 也是 ACM 憑證 DNS 驗證的依賴 — ACM 簽發憑證時需要在對應的 zone 寫入一條驗證記錄，zone 不存在或不在同帳號就接不上。把 zone 的建立排在 ACM 之前，讓依賴圖自然正確。

ALB 的穩定 DNS 記錄

ALB 重建後 DNS 名稱會改變。穩定對外的方式是在 Route 53 建一條 alias 記錄指向 ALB，使用者連的是 api.example.com，DNS 自動解析到 ALB 目前的位址：

 1resource "aws_route53_record" "api" {
 2  zone_id = data.aws_route53_zone.main.zone_id
 3  name    = "api.${var.domain}"
 4  type    = "A"
 5
 6  alias {
 7    name                   = aws_lb.api.dns_name
 8    zone_id                = aws_lb.api.zone_id
 9    evaluate_target_health = true
10  }
11}

evaluate_target_health = true 讓 Route 53 在 ALB 所有 target 都不健康時把這條記錄標為不健康。如果有多個 region 的 ALB 做了 failover routing，這個設定能讓 DNS 層自動切換到健康的 region — 屬於跨區域容災的地基，在 devops 模組展開。

WAF 與下一步

ALB 支援掛載 AWS WAF（Web Application Firewall），在流量進到應用之前先過一層規則 — 擋已知惡意 IP、防 SQL injection / XSS 的常見模式、限制單一 IP 的請求速率。WAF 的規則也可以寫進 IaC，讓「哪些流量被擋」成為可審查的程式碼而非 Console 上的設定。WAF 的詳細設計屬於安全層的範圍（見 backend 模組七：資安與資料保護），這裡只確認它的掛載點是 ALB。

四類核心服務的 IaC 描述到此完成。下一步是讓這些服務可被觀測——log、metric、alarm 跟資源同生命週期建立，見模組六：可觀測性與 log。

跨分類引用

• → 模組三：網路地基：ALB 的 security group 設計，group-to-group 引用
• → 模組五：stateful 資源的保護策略：ALB 是 stateless，但它引用的 ACM 憑證和 DNS 記錄有自己的生命週期考量
• → devops 模組一：負載平衡：ALB 的運行期調校 — 跨 AZ 流量分配、connection draining、sticky session
• → backend 模組七：資安與資料保護：WAF 規則設計

本篇同時處理服務之間依賴的表達方式 — output 與 data source — 因為依賴表達直接影響 stateful 資源的爆炸半徑：同一份 state 裡的資料庫跟運算綁在一起 apply，還是拆成獨立 state 各自演進，決定了一次 apply 失敗會波及多少資源。

stateful 資源的保護策略

stateful 資源的 IaC 描述要把「保護狀態」當成第一類需求，而非事後補上的選項。保護的三個面向 — 可用性、可還原性、防誤刪 — 各自對應不同的機制，混在一起談會讓判斷失焦。

multi-AZ 的職責邊界

multi-AZ 用一個布林屬性開啟，背後是 RDS 在另一個可用區維護同步副本。它承擔的是可用性：主庫所在的可用區故障時，RDS 自動 failover 到 standby，服務在秒級到一兩分鐘的窗口後恢復。

multi-AZ 的邊界要明確界定，因為把它當成超出職責的工具會在事故裡踩空：

• standby 是熱備不可讀。multi-AZ 的 standby 不接受任何查詢流量，所以它不提供讀取擴展。要分攤讀流量得另開 read replica，這是另一個資源、另一個端點、另一套複寫延遲要管。
• failover 有切換窗口。切換期間應用的資料庫連線會中斷、需要重連。應用層如果沒有處理連線中斷的重試邏輯，failover 就會變成一段可見的服務中斷，而非透明切換。
• 它不防邏輯損壞。誤刪一張 table、一筆錯誤的批次 UPDATE、一段有 bug 的 migration script — 這些操作會同步複製到 standby。multi-AZ 防的是硬體與可用區故障，邏輯損壞的防線是備份與時間點還原（PITR）。

這三條邊界說明 multi-AZ 和 backup 的職責正交：前者解可用性，後者解可還原性。兩者要分別配置、分別驗證。成本參考：multi-AZ RDS 的費用約為 single-AZ 的兩倍（standby instance 按相同規格計費）。這筆費用對應的能力是可用區故障時的分鐘級自動 failover——判斷值不值得時，用主庫所承載的服務停機每小時的商業代價來衡量。

備份保留與時間點還原

backup 用保留天數與備份視窗描述。RDS 依此每日自動快照並保留交易日誌，以支援還原到任意時間點（PITR）。自動備份的保留上限是 35 天，更長的留存要靠手動快照或匯出到 S3 自行管理。

backup_retention_period 取多少天，以 RPO（Recovery Point Objective）與合規要求反推。RPO 問的是「出事時最多能接受遺失多久的資料」— PITR 能還原到最近 5 分鐘內的時間點，但前提是自動備份有開、交易日誌有保留。保留天數決定的是「能回溯多遠」：14 天是 AWS RDS 自動備份 35 天上限的保守折衷，足以涵蓋多數營運場景下「發現問題到決定還原」的時間差；受監理的服務往 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-${formatdate("YYYYMMDD", timestamp())}"
8}

備份視窗選在流量低谷（如 UTC 凌晨），避免快照 IO 跟尖峰流量競爭。手動快照用獨立資源描述，常見用途是重大變更前的保險點 — 大版本升級、schema migration、或任何會改變資料結構的操作。

刪除保護與 final snapshot

deletion_protection = true 讓 terraform destroy 無法直接刪除這個 instance — 要先用另一次 apply 把保護關掉，這一步本身就會出現在 plan 裡、被 review 攔住。skip_final_snapshot = false 確保即使確實要刪，也會先拍一份最終快照。兩者搭配是正式資料庫的硬性下限。

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

S3 bucket 的保護同理但機制不同。versioning 讓覆寫或刪除的物件可以回到先前版本；MFA delete 要求刪除前提供第二因素驗證；lifecycle rule 控制舊版本的保留時間 — 這三者分別對應「可還原」「防誤刪」「控成本」三個職責，見儲存（S3）。

跨 region 災難復原的邊界

multi-AZ 解的是可用區級故障 — 單一資料中心出問題時，同 region 的另一個可用區接手。跨 region 的災難復原（cross-region read replica、S3 cross-region replication、Route 53 failover routing）屬於更高級的可用性投資，解的是整個 region 不可用的極端情境。它的成本與複雜度顯著上升：跨 region 複寫有延遲、failover routing 需要健康檢查與 DNS TTL 配合、兩個 region 的 infra 要各自維護。多數服務在單 region 的 multi-AZ + 備份做完之後再評估是否需要跨 region，依據是業務的 RTO（Recovery Time Objective）對 region 級故障的容忍度。

跨 region 的 infra 投資在 B2B SaaS 的合約義務下更容易成立。Genesys 的客服平台跨 15 個 region 用 DynamoDB 達成 99.999% 可用性——年停機只有 5 分鐘。對 B2B SaaS 來說，客戶服務中斷等於客戶的終端使用者打不通電話，可用性是合約義務而非行銷敘述。infra 層的判斷依據是：multi-AZ 不夠用（業務需要跨 region failover）的情況通常由合約 SLA 驅動，而非技術判斷驅動。

stateful 與 stateless 的操作差異

stateful 與 stateless 資源的根本差別在重建代價。這個差別傳導到三個操作後果，每一個都影響日常的 PR review 與 apply 流程。

刪除保護的必要性

stateless 資源（ECS service、ALB、無狀態運算）重建只是換一組新實例，幾分鐘內恢復、沒有資料損失，所以它們可以被頻繁地 destroy 與 recreate — 這是 IaC 最擅長的對象。stateful 資源重建意味著資料遺失或漫長的還原，代價可能是數小時的停機與不可逆的損失。開啟 deletion protection 讓「不小心 destroy」需要先顯式關閉保護這一步，多一道人為確認。

drift 容忍度

stateless 資源的 drift 可以靠重建抹平 — apply 一次就回到程式碼的狀態，副作用只是新實例的短暫滾動更新。stateful 資源的 drift 要謹慎處理，因為 IaC 的「修正回程式碼狀態」動作可能觸發重啟甚至重建。

一個常見的情境：某人手動改了 RDS 的 parameter group，Terraform plan 顯示要把它改回程式碼的版本。這個改回動作是 update in-place（改設定、不重建）還是 replace（先刪後建），取決於哪個參數被改了 — 某些 parameter 的修改需要重啟，而某些需要整個 instance 重建。判讀方式是先跑 plan、看 drift 修正的結果，update in-place 通常安全（可能觸發重啟），replace 對資料庫意味著先刪後建，在 prod 上需要額外的確認。

變更審查強度

改動 stateful 資源的 plan 輸出要逐行看，特別警惕任何顯示為 replace（-/+）或標記 forces replacement 的項目。某些欄位的改動看似無害但會觸發 replace：

Review 時看到 stateful 資源出現 forces replacement，在 prod 路徑上幾乎都該先暫停、確認回退路徑（手動快照是否已拍）再決定是否繼續。常見做法是把這個差別寫進流程：stateful 資源的變更走更嚴格的 PR review 與分階段套用（先在 dev apply 驗證、確認是 in-place 後再推 prod），自動化護欄在模組七：infra 走 PR 流程展開。

服務之間的依賴怎麼表達

服務間依賴用 output 與 data source 表達，讓引用關係成為程式碼裡可追蹤的邊，而非靠人記憶的隱性約定。引用方式的選擇直接影響 state 的大小與爆炸半徑。

同 state 內的引用

同一個 state 內，直接引用資源屬性即可建立依賴。運算資源引用資料庫的端點，IaC 自動推導出「資料庫先於運算」的邊，也讓端點變更時上層自動取得新值：

1resource "aws_ecs_task_definition" "api" {
2  container_definitions = jsonencode([{
3    environment = [
4      { name = "DB_HOST", value = aws_db_instance.primary.endpoint }
5    ]
6  }])
7}

同 state 引用的好處是依賴圖最完整 — apply 一次就把所有引用解析到正確的值。代價是 state 越大、單次 apply 的爆炸半徑越大。一份包含網路、資料庫、運算、LB 的 state，一次 apply 失敗可能讓所有資源處於半完成狀態。

跨 state 的 data source

跨 state（例如網路地基與核心服務分屬不同 Terraform state，呼應模組四：環境分離與模組化的拆分）時，下游用 data source 唯讀地讀取上游已建立的資源：

 1data "aws_vpc" "main" {
 2  tags = { Name = "app-${var.env}" }
 3}
 4
 5data "aws_subnets" "private" {
 6  filter {
 7    name   = "vpc-id"
 8    values = [data.aws_vpc.main.id]
 9  }
10  tags = { tier = "private" }
11}

下游查詢上游的 VPC 與 subnet，取得 ID 來放置自己的資源，而不複製貼上硬編碼的值。

同 state vs 跨 state 的取捨

兩種方式的取捨在耦合與隔離之間：

用 grep 搜一遍核心服務的 HCL：如果出現大量寫死的 subnet ID 或 VPC ID，代表該用 data source 而沒用。這些硬編碼是日後上游重建時 drift 與 broken reference 的來源。把它們換成 data source，依賴關係才會在程式碼裡顯性化、可被工具與 review 看見。

data source 查詢的可靠性取決於查詢條件的穩定度。用 tags 查比用 Name 查更穩 — tag 是自己定義的、可控的值，而某些資源的 Name 可能在重建時改變。用 terraform_remote_state data source 直接讀上游的 state output 是最精確的方式，但它把兩份 state 的 backend 設定耦合在一起，上游搬 state 時下游也要跟著改。在團隊規模小、state 拆分不多的階段，terraform_remote_state 的耦合代價通常可接受；團隊變大後，用 tag-based data source 或 SSM Parameter Store 當中間層，能讓上下游各自獨立演進。

跨分類引用

• → 模組三：網路地基：核心服務落在哪些 subnet、security group 怎麼引用
• → 模組四：環境分離與模組化：跨 state 的拆分策略
• → 模組七：infra 走 PR 流程：stateful 變更的自動化護欄

Route 53 Hosted Zone

Hosted zone 是 Route 53 用來管理某個網域的 DNS 記錄集合。建立 zone 後，Route 53 會分配一組 NS（Name Server）記錄，網域的 DNS 解析就由這組 NS 負責。

Public vs Private Zone

Public hosted zone 對應的是可從網際網路解析的網域（如 example.com），用於對外服務的 A / CNAME / MX 記錄。Private hosted zone 只在指定的 VPC 內可解析，用於內部服務發現（如 db.internal.example.com 解析到 RDS 的 private IP）。多數專案兩者都需要：public zone 給對外流量、private zone 給內部服務互連。

 1resource "aws_route53_zone" "public" {
 2  name = "example.com"
 3  tags = { Environment = "production" }
 4}
 5
 6resource "aws_route53_zone" "private" {
 7  name = "internal.example.com"
 8
 9  vpc {
10    vpc_id = aws_vpc.main.id
11  }
12
13  tags = { Environment = "production" }
14}

子網域 delegation

當 dev / staging / prod 各用獨立帳號時，每個帳號建自己的 hosted zone 管理子網域（如 dev.example.com）。父網域的 zone 需要加一組 NS 記錄指向子網域的 zone，這個動作叫 delegation。

1resource "aws_route53_record" "dev_ns" {
2  zone_id = aws_route53_zone.public.zone_id
3  name    = "dev.example.com"
4  type    = "NS"
5  ttl     = 300
6  records = aws_route53_zone.dev.name_servers
7}

delegation 的 NS 記錄指向子帳號 zone 的 name server。子帳號內的所有 DNS 記錄（如 api.dev.example.com）由子帳號的 zone 管理，父帳號不需要逐條設定。跨帳號 delegation 需要兩邊的 Terraform 各自管理自己的 zone，NS 記錄在父帳號的 state 裡。

判讀設定是否正確：用 dig dev.example.com NS 查回的 name server 應該是子帳號 zone 的 NS，不是父帳號的。如果查回父帳號的 NS，代表 delegation 沒生效，子網域的 DNS 記錄不會被解析。

ACM 憑證申請與 DNS 驗證

AWS Certificate Manager（ACM）提供免費的 TLS 憑證，條件是透過 DNS 或 email 驗證網域所有權。DNS 驗證是 IaC 友善的方式——ACM 要求在指定網域下建一條 CNAME 記錄，記錄值由 ACM 提供，驗證通過後憑證自動簽發。

 1resource "aws_acm_certificate" "main" {
 2  domain_name               = "example.com"
 3  subject_alternative_names = ["*.example.com"]
 4  validation_method         = "DNS"
 5
 6  lifecycle {
 7    create_before_destroy = true
 8  }
 9
10  tags = { Environment = "production" }
11}

subject_alternative_names 加 *.example.com 讓同一張憑證涵蓋所有子網域（如 api.example.com、admin.example.com），省去為每個子網域各申請一張。

DNS 驗證記錄

ACM 簽發後會產出一組驗證用的 CNAME 記錄。用 Terraform 自動在 Route 53 建立這些記錄，讓驗證流程不需要手動操作：

 1resource "aws_route53_record" "cert_validation" {
 2  for_each = {
 3    for dvo in aws_acm_certificate.main.domain_validation_options : dvo.domain_name => {
 4      name   = dvo.resource_record_name
 5      record = dvo.resource_record_value
 6      type   = dvo.resource_record_type
 7    }
 8  }
 9
10  zone_id = aws_route53_zone.public.zone_id
11  name    = each.value.name
12  type    = each.value.type
13  ttl     = 300
14  records = [each.value.record]
15
16  allow_overwrite = true
17}
18
19resource "aws_acm_certificate_validation" "main" {
20  certificate_arn         = aws_acm_certificate.main.arn
21  validation_record_fqdns = [for record in aws_route53_record.cert_validation : record.fqdn]
22}

aws_acm_certificate_validation 資源會等到 ACM 確認驗證通過才算 apply 成功。如果 DNS 記錄設錯或 zone 的 NS delegation 有問題，這個資源會卡住直到 timeout——排查方向是先確認驗證 CNAME 記錄能被公網 DNS 解析。

create_before_destroy

lifecycle { create_before_destroy = true } 在憑證需要替換時（如增加 SAN、更換網域），讓 Terraform 先建新憑證、再刪舊憑證。沒有這個設定，預設行為是先刪後建——刪除的瞬間 ALB listener 失去憑證，HTTPS 連線全部中斷直到新憑證驗證通過（可能要幾分鐘到幾十分鐘）。

ALB HTTPS Listener

憑證驗證通過後，把它掛到 ALB 的 HTTPS listener：

 1resource "aws_lb_listener" "https" {
 2  load_balancer_arn = aws_lb.main.arn
 3  port              = 443
 4  protocol          = "HTTPS"
 5  ssl_policy        = "ELBSecurityPolicy-TLS13-1-2-2021-06"
 6  certificate_arn   = aws_acm_certificate_validation.main.certificate_arn
 7
 8  default_action {
 9    type             = "forward"
10    target_group_arn = aws_lb_target_group.app.arn
11  }
12}

ssl_policy 決定 TLS 版本與加密套件。ELBSecurityPolicy-TLS13-1-2-2021-06 支援 TLS 1.2 和 1.3、停用已知不安全的舊版協定。選型判準是相容性與安全性的平衡——TLS 1.3-only policy 最安全但可能排除舊版客戶端，多數場景用 1.2+1.3 的組合。

certificate_arn 引用的是 aws_acm_certificate_validation 而非直接引用 aws_acm_certificate，確保 listener 只在憑證驗證通過後才建立。

HTTP → HTTPS 重導

同時建立一個 HTTP listener，把所有 80 埠流量重導到 443：

 1resource "aws_lb_listener" "http_redirect" {
 2  load_balancer_arn = aws_lb.main.arn
 3  port              = 80
 4  protocol          = "HTTP"
 5
 6  default_action {
 7    type = "redirect"
 8    redirect {
 9      port        = "443"
10      protocol    = "HTTPS"
11      status_code = "HTTP_301"
12    }
13  }
14}

301 永久重導讓瀏覽器記住後續直接走 HTTPS。security group 仍然需要開放 80 埠入站，否則重導不會發生——client 連 80 埠被擋、收到的是連線失敗而非重導回應。

多網域與 SAN 憑證

一張 ACM 憑證最多支援 10 個 SAN（Subject Alternative Name）。多數場景用主網域 + wildcard（example.com + *.example.com）就夠用。如果有多個不同根網域（如 example.com 和 example-app.com），可以加進同一張憑證：

 1resource "aws_acm_certificate" "multi_domain" {
 2  domain_name               = "example.com"
 3  subject_alternative_names = [
 4    "*.example.com",
 5    "example-app.com",
 6    "*.example-app.com",
 7  ]
 8  validation_method = "DNS"
 9
10  lifecycle {
11    create_before_destroy = true
12  }
13}

每個 SAN 網域都需要獨立的 DNS 驗證記錄。如果不同網域在不同的 hosted zone 裡，驗證記錄的建立要分別指向各自的 zone。

當 SAN 數量超過 10、或不同網域的憑證需要獨立管理（不同 team 負責不同網域），改用 aws_lb_listener_certificate 額外掛載：

1resource "aws_lb_listener_certificate" "additional" {
2  listener_arn    = aws_lb_listener.https.arn
3  certificate_arn = aws_acm_certificate.other_domain.arn
4}

ALB 會根據 SNI（Server Name Indication）自動選擇匹配的憑證。

穩定的 DNS 別名記錄

ALB 重建後 DNS 名稱會改變，對外服務不應該直接用 ALB 的 DNS 名稱。用 Route 53 的 alias record 把穩定的網域名指向 ALB：

 1resource "aws_route53_record" "app" {
 2  zone_id = aws_route53_zone.public.zone_id
 3  name    = "api.example.com"
 4  type    = "A"
 5
 6  alias {
 7    name                   = aws_lb.main.dns_name
 8    zone_id                = aws_lb.main.zone_id
 9    evaluate_target_health = true
10  }
11}

alias record 不收費（一般的 A/CNAME 記錄每百萬次查詢 $0.40，alias 到 AWS 資源免費），且支援 zone apex（如 example.com，一般 CNAME 不支援 zone apex）。evaluate_target_health = true 讓 Route 53 在 ALB 不健康時停止回應該記錄，配合 failover routing 使用。

憑證續期監控

ACM 的 DNS 驗證憑證會自動續期——條件是驗證用的 CNAME 記錄仍然存在且可解析。只要那條記錄沒被刪掉，憑證到期前 60 天 ACM 會自動續期。

自動續期失敗的常見原因：驗證 CNAME 記錄被手動刪除、hosted zone 的 NS delegation 失效、或 zone 本身被刪除重建導致 NS 改變。用 CloudWatch alarm 監控憑證到期日，在自動續期失敗時提前收到通知：

 1resource "aws_cloudwatch_metric_alarm" "cert_expiry" {
 2  alarm_name          = "acm-cert-expiry-${aws_acm_certificate.main.domain_name}"
 3  comparison_operator = "LessThanThreshold"
 4  evaluation_periods  = 1
 5  metric_name         = "DaysToExpiry"
 6  namespace           = "AWS/CertificateManager"
 7  period              = 86400
 8  statistic           = "Minimum"
 9  threshold           = 30
10  alarm_actions       = [aws_sns_topic.oncall.arn]
11
12  dimensions = {
13    CertificateArn = aws_acm_certificate.main.arn
14  }
15}

這個 alarm 在憑證距離到期不足 30 天時觸發。正常情況下 ACM 在到期前 60 天就會完成續期，收到 30 天警報代表自動續期失敗了、需要人工介入確認驗證記錄。

跨分類引用

• → 入口上 IaC — ALB：ALB listener、target group、健康檢查的完整設定
• → 模組三：網路地基：ALB 所在的 public subnet 與 security group 設計
• → 模組七：infra 走 PR 流程：憑證與 DNS 變更走 PR review

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 策略