容器架構：ECS、EKS 與 Fargate 大規模運行

ECS 與 EKS 上的容器化是 AWS 現代化工作負載的預設運算基礎，SAP-C02 考試從至少三個任務陳述（task statement）的 Pro 深度測試容器化 ECS EKS 知識——2.1 部署策略、2.5 效能，以及 4.3 全新架構遷移。本章預設你已具備 Associate 等級的 Docker、task definitions 與基本 Fargate 操作熟悉度，並進一步聚焦在解決方案架構師 Professional 等級真正需要回答的問題：何時 ECS 優於 EKS（面對 50 個微服務的多語言團隊）、Capacity Providers 如何在不犧牲可用性的前提下混合 Fargate 和 EC2 Spot、IRSA 與 Pod Identity 有何差異、Karpenter 在哪些情境下嚴格優於 Cluster Autoscaler、App Mesh 與 VPC Lattice 分別解決哪種服務網格問題，以及多帳號多 Region 的容器平台切換實際上如何運作。本指南的每個章節都對應一種 SAP-C02 情境模式，讓心智模型在整個考試中相互強化。

容器化 ECS EKS 在 SAP-C02 深度的意涵

SAP-C02 層級的容器化 ECS EKS 不是比較兩套 orchestrator——而是一個影響 IAM 設計、網路拓撲、CI/CD 策略、成本模型與組織能力的平台架構決策。Associate 認證停留在「ECS 用 tasks，EKS 用 pods」。Professional 考試要求你在下列限制條件下推理容器化 ECS EKS 的選擇：200 個帳號的 Organizations 架構、六個多語言團隊擁有的 50 個微服務、有映像簽章需求的受監管工作負載，以及仍有一半機器在地端的混合部署。因此，容器化 ECS EKS 涵蓋三個相互交織的層面：控制平面（ECS 服務排程器 vs Kubernetes API server）、資料平面（Fargate 無伺服器 vs 搭載 Bottlerocket 的 EC2，加上地端的 ECS Anywhere 或 EKS Hybrid Nodes），以及平台層（服務探索、服務網格、secrets、可觀測性、政策）。

SAP-C02 題幹使用容器化 ECS EKS 來測試你是否理解每個決策的總擁有成本與風險輪廓，而非測試你有沒有背下 CPU 和記憶體上限。預期會看到「全球團隊已在其他雲端執行 Kubernetes、法規要求映像簽章、成本必須下降 40%」這類情境，正確答案需要把 EKS、附簽章的 ECR、Karpenter on Spot，以及 Compute Savings Plans 組合成一個前後一致的目標架構。本章的每個章節都為這類多重限制的答案提供組合素材。

為什麼容器化 ECS EKS 在 SAP-C02 值得獨立成章

容器化 ECS EKS 在 SAP-C02 擁有獨立章節，因為它是任務 4.3 現代化工作的目標平台、主導任務 2.5 效能設計空間，並且是任務 2.1 部署策略討論的核心。在 Domain 2 分配的 2000 道題中，大約 200 道直接指向容器化 ECS EKS 的決策，另有 300 道在複合情境中涉及本主題。因此，掌握 SAP-C02 深度的容器化 ECS EKS 相當於整場考試約 10% 的分數槓桿。

白話文解釋 Containerization ECS EKS at Pro Scale

容器化 ECS EKS 的決策相當抽象，以下三個具體類比從不同面向讓責任劃分、可移植性與擴展軸變得清晰易懂。三個都讀一遍；重疊之處正是 SAP-C02 直覺的核心。

類比一：連鎖餐廳的中央廚房 vs 直營店

想像一家連鎖餐廳必須在多個城市供應 50 種菜色。

• ECS on Fargate = 食材備料齊全的直營門市 — 總部給每家門市一張食譜卡（task definition）和密封好的備料間（Fargate 佈建的 microVM）。員工只需加熱上菜；食材與爐具由總部集中管理。開店快、流程簡單，但每家門市都要照總部定好的廚房格局走。
• EKS 搭配 Managed Node Groups 與 Karpenter = 有共同廚房標準的加盟連鎖 — 每家門市說同一種語言（Kubernetes API），所以在東京受訓的廚師也能在台北的門市工作。加盟總部（EKS 控制平面）維持標準，但每個加盟主（node group）自己買冰箱（EC2 容量），自行決定何時開多一台爐子（Karpenter 即時佈建）。
• ECS Anywhere / EKS Hybrid Nodes = 把總部食譜送到獨立家庭餐廳 — 既有的家庭餐廳保留原來的廚房（地端硬體），但印出加盟品牌的食譜卡並回報總部。你延伸了品牌，而不需要逼著對方重建廚房。
• App Mesh / VPC Lattice = 外場傳菜系統 — 當廚房越來越多，你需要一套標準化的方式，讓菜餚無論從哪個廚房出品都能準確送達桌位。

50 個微服務的多語言情境直接對應這個類比：若六個團隊都以 Kubernetes 為母語，加盟模型獲勝；若只有兩個團隊碰容器，其他四個只想要一個 URL，直營 Fargate 門市獲勝。

類比二：工具箱裡的兩把不同扳手

容器化 ECS EKS 可以想成工具箱裡的兩把扳手，都能鎖螺絲，但各有用途。

• Amazon ECS = AWS 原廠扭力扳手 — 專門針對 AWS 的螺絲校準（IAM、ALB、CloudWatch、Secrets Manager）。用起來完全合手，不需要額外轉接頭，且扳手本身免費（ECS 控制平面不收費）。
• Amazon EKS = 國際規格活動扳手 — 因為 Kubernetes 是全球標準，所以能鎖任何地方的螺絲（AWS、地端、其他雲端），你的技師在任何工廠都能上工。但扳手本身要租金（每 cluster 每小時 $0.10，約每月 $73），因為它符合 CNCF 規範。
• Fargate = 裝在兩把扳手上的人體工學握把 — 消除手部疲勞（主機管理），但每秒計費，費用比較高。
• Karpenter = 智慧扭力感應器 — 夾在 EKS 扳手上，自動決定安裝哪個尺寸與數量的 EC2 螺絲，還能在同一個動作中混合 Spot 和 On-Demand。
• App Mesh 與 VPC Lattice = 組裝定位夾具 — 當你有很多扳手同時鎖很多螺絲，夾具讓一切保持對齊。

SAP-C02 若出現「公司想在 AWS 和地端 Kubernetes 之間保持可移植性」，就是國際規格活動扳手的情境——EKS 搭配 EKS Hybrid Nodes，而不是 ECS Anywhere。

類比三：電網與發電廠

多 Region 規模的容器化 ECS EKS 是一個電網問題。

• ECS tasks / EKS pods = 個別用電設備 — 它們消耗 CPU 和記憶體，就像家電消耗瓦特。
• Fargate = 共用公共電網 — 插上就用，按度收費，永遠不必管發電廠。
• EC2 Capacity Providers = 自建廠內發電機組 — 穩定負載下更便宜，尤其搭配 Savings Plans（長期合約）或 Spot（以七折買到公用電廠的剩餘容量）。
• Karpenter = 動態電力調度員 — 按照當前負載啟動恰好適合的發電機（機型），需求下降就關機，能在一分鐘以內混合切換 Spot 和 On-Demand。
• Cluster Autoscaler = 舊式燃煤電廠操作員 — 按預設的機組擴張，對穩定需求夠用，但對突發流量反應較慢。
• 多 Region EKS = 互聯的跨區域電網 — 每個 Region 有自己的控制平面和節點；DNS/流量管理層（Route 53、Global Accelerator）決定哪個電網服務哪個用戶，資料層複寫則在幕後持續運作（Aurora Global Database、DynamoDB Global Tables）。
• App Mesh / VPC Lattice = 高壓輸電標準 — 確保電力在不同電廠之間安全傳輸，不管是誰建的。

多 Region 切換情境的解法是：在兩個電網（Region）都保持資料平面運作，在輸電層（Route 53 加權或 failover 路由）切換流量，直到負載穩定後才拆除舊電網——絕對不能同時切掉兩個電網。

ECS vs EKS — Pro 決策框架

SAP-C02 深度的容器化 ECS EKS 選擇是一個六維決策，而不是 Associate 等級那兩條規則。針對情境逐一檢視每個維度，讓多數信號指引你找到答案。

維度一 — 團隊技能與生態系適配

若情境提到現有 Kubernetes 操作員、Helm charts、Argo CD、Flux、Istio，或廠商以 Kubernetes manifests 形式交付的軟體，容器化 ECS EKS 傾向 EKS。若團隊以 AWS 原生為主，偏好用 CloudFormation 或 Terraform 撰寫 task definitions，ECS 是更快的路徑。

維度二 — 可移植性需求

若工作負載今天必須跑在 EKS 上，明天可能要跑在地端 Kubernetes、其他雲端的 Kubernetes 或紅隊實驗室，答案就是 EKS。ECS 只能在 AWS 上運行，ECS Anywhere 是唯一例外（它是把 AWS 原語推送出去，而不是讓工作負載自由移動）。

維度三 — 控制平面成本

ECS 控制平面免費。EKS 控制平面每個 cluster 每小時 $0.10（每月約 $73）。在 Pro 規模下——平台團隊為 50 個業務單位各跑一個 cluster——光是控制平面費用每年就高達 $44,000。對成本敏感的全新架構情境，除非明確要求 Kubernetes，通常選 ECS。

維度四 — 穩定狀態的營運負擔

ECS 沒有控制平面需要修補，也沒有 CoreDNS / VPC CNI / kube-proxy 等 add-ons 需要版本鎖定，更沒有可能導致工作負載中斷的 node group 次版本升級。EKS 需要持續管理控制平面版本（每個版本支援約 14 個月）、add-ons 與節點的生命週期。Professional 考試嘉許那些能權衡持續維護成本與生態系優勢的答案。

維度五 — 無法替換的生態系依賴

服務網格（Istio、Linkerd）、政策引擎（OPA Gatekeeper、Kyverno）、GitOps 工具（Argo CD、Flux）、資料庫 Operator（Zalando Postgres Operator），以及可觀測性技術堆疊（叢集內的 Prometheus、Grafana）往往需要 Kubernetes APIs。若情境的關鍵點涉及上述任一項，EKS 獲勝。

維度六 — AWS 原生整合深度

ECS 與 IAM task roles、ALB target groups、CloudWatch Container Insights、task definitions 中的 Secrets Manager 引用、AppConfig 以及 CodeDeploy 藍/綠部署都有緊密整合。EKS 需要額外的轉接層（IAM 用 IRSA 或 Pod Identity、ALB 用 AWS Load Balancer Controller、Secrets Manager 用 External Secrets Operator）。若情境重視最快速的整合路徑，ECS 獲勝。

ECS Pro 主題 — Capacity Providers、服務探索、Exec、Anywhere

SAP-C02 深度的容器化 ECS EKS 需要掌握 Associate 考試略過的 ECS 功能。本節涵蓋在真實情境中出現的五個 Pro 等級 ECS 能力。

ECS Capacity Providers — 混合 Fargate、EC2 與 Spot

Capacity providers 把支撐 ECS 服務的運算資源抽象化，讓你能以每個服務為單位混合 Fargate、Fargate Spot 與 EC2 Auto Scaling Groups。Capacity provider 策略是一個有序清單，每個 provider 有 base（第一個 provider 上的最低任務數）和 weight（超過 base 後各 provider 的相對分配比例）。

典型的容器化 ECS EKS Capacity Provider 模式：

• Fargate 100% — 最簡單，按秒計費，適合流量不規律的微服務。
• Fargate + Fargate Spot（base=2, weight=1:4） — 保留 2 個 On-Demand 以確保最低可用性，其餘任務約 20% 走 On-Demand、80% 走 Spot，混合折扣約 55%。
• EC2 ASG 為主 + Fargate 負責高峰 — 穩定負載跑 Reserved Instances 或 Savings Plans，高峰流量走 Fargate，避免 EC2 過度佈建。
• EC2 On-Demand + EC2 Spot 混合 ASG — 適用於只有 EC2 叢集且需要成本優化的情境；ASG 本身處理混合機型政策。

ECS 服務探索 via AWS Cloud Map

ECS 透過 AWS Cloud Map 的服務探索，為 tasks 提供穩定的 DNS 名稱，不受副本輪替影響。當你將 ECS 服務註冊到 Cloud Map，ECS 會建立並更新一個私有 namespace（例如 orders.internal），為每個 task IP 新增 A 記錄（awsvpc 網路模式）或 SRV 記錄（bridge 網路模式），並將每個 task IP 登錄為後端。客戶端服務查詢 orders.orders.internal 就能取得最新的 IP，無需任何服務網格的額外負荷。

容器化 ECS EKS 中 Cloud Map vs Application Load Balancer 的比較：

• Cloud Map DNS 服務探索 — 輕量，無 ALB 費用，適合使用 gRPC 或自訂協定的內部微服務，不支援請求層級路由。
• ALB target groups — 功能更豐富（路徑路由、主機路由、黏性 session、加權 target groups、TLS 終止），但增加成本。

在 50 個微服務的情境中，常見模式是：外部 HTTP 流量在平台邊緣使用 ALB，內部服務間探索使用 Cloud Map。Cloud Map 也透過 External DNS 專案與 EKS 整合，並與 AWS App Mesh 整合。

ECS Exec — 不需 SSH 的安全 Shell

ECS Exec 讓你在不使用 SSH、跳板機或主機層存取的情況下，在運行中的 ECS task 內執行互動式 shell 或單一指令。它使用 SSM Session Manager 基礎架構，因此稽核紀錄會落入 CloudWatch Logs 或 S3，IAM 控制誰能對哪個 task 執行 exec。

ECS Exec 的 SAP-C02 相關細節：

• 需要 task role 包含 ssmmessages 權限，且 task definition 要設定 enableExecuteCommand=true。
• 同時支援 Fargate 和 EC2 launch type；Fargate tasks 使用 ECS Exec 時仍無法 SSH 登入主機。
• 指令會連同 IAM principal、task ID 和時間戳記一起記錄——滿足大多數合規要求。
• 取代了舊有的 SSH sidecar 或在 Fargate 映像中植入 SSM agent 等做法。

ECS Anywhere — 將 ECS 延伸至地端硬體

ECS Anywhere 讓你將外部實例（地端裸機、VM、其他雲端）登錄為 ECS cluster 的容量。外部實例運行 ECS agent 和 SSM agent，透過 SSM activation 完成註冊，ECS 就像 EC2 launch type 一樣將 tasks 排程到它上面。

ECS Anywhere 對 SAP-C02 容器化 ECS EKS 情境的意義，在於那些說「因法規要求必須繼續在地端資料中心運行工作負載，同時統一使用 AWS 工具」的情境。計費方式為每個外部實例每小時固定費率，與實例大小無關。必須記住的限制：外部實例沒有 load balancer 整合（需自行部署），沒有 EBS volumes，也沒有 Auto Scaling Group 語意。

ECS Task Definition Pro 細節 — CPU、記憶體、網路模式

Pro 等級的 task definitions 開放了 Associate 考試不測試的調整選項。

• Task CPU / 記憶體組合 — Fargate 強制使用矩陣（例如 0.25 vCPU 搭配 0.5-2 GB、1 vCPU 搭配 2-8 GB，最高 16 vCPU 搭配 120 GB）。EC2 launch type 允許 task 預留量加總低於實例容量（超額訂閱）。
• 網路模式 — awsvpc（task 擁有獨立 ENI；Fargate 必用）、bridge（Docker bridge 網路，僅 EC2）、host（共用主機網路堆疊，僅 EC2，無每 task security group）、none（無外部網路）。
• 臨時儲存 — Fargate 預設 20 GB，可設定至 200 GB；EC2 tasks 使用主機的 docker 儲存。
• Volumes — bind mounts、Docker volumes、EFS volumes、FSx for Windows File Server volumes。
• Secrets — secrets 欄位引用 Secrets Manager 或 Parameter Store ARN；值在 task 啟動時注入為環境變數，無需修改程式碼。
• Task role vs Execution role — task role 授予應用程式的 AWS SDK 權限（讀取 S3 bucket）；execution role 授予 Fargate 或 ECS agent 在容器啟動前代表你執行動作的權限（拉取 ECR 映像、寫入日誌、取得 secrets）。

EKS Pro 主題 — 控制平面、節點選項、IRSA vs Pod Identity

容器化 ECS EKS 在 EKS 側有其深厚的 Pro 知識面。本節涵蓋控制平面 HA 與日誌、三種節點選項、透過 IRSA 和 Pod Identity 的 IAM 整合，以及 EKS add-ons。

EKS 控制平面 HA 與日誌

EKS 控制平面預設為多 AZ——Kubernetes API server、etcd、scheduler 與 controller manager 副本跨至少兩個 AZ 運行，完全由 AWS 管理。你看不到這些節點，無法 SSH 登入，並以每 cluster 每小時 $0.10 的費用換取這項 HA 保證。

EKS 控制平面日誌在啟用後會串流五種日誌類型至 CloudWatch Logs：api、audit、authenticator、controllerManager、scheduler。啟用 audit 是 SAP-C02 中需要完整記錄誰對 Kubernetes API 做了什麼的情境常見正確答案——對合規審查與鑑識時間軸很有幫助。

控制平面 endpoint 存取模式對容器化 ECS EKS 安全性至關重要：

• 公開 endpoint（預設）— 從網際網路可連線；仍受 AWS IAM 驗證和 RBAC 保護。
• 公開 + 私有 — 從網際網路和 VPC 內部都可連線。
• 僅私有 — 只能從 VPC 或透過 Transit Gateway / VPN 存取；適合受監管工作負載的正確答案。

EKS 運算選項 — Managed Node Groups vs Self-Managed vs Fargate Profiles

EKS 提供三種運行 pods 的方式。

• Managed node groups — EKS 佈建並管理 EC2 Auto Scaling Group 的工作節點生命週期，處理 AMI 和 Kubernetes 版本的滾動更新，並與 Capacity Providers 整合。大多數 SAP-C02 全新架構答案的預設選擇。
• Self-managed nodes — 你自己佈建 EC2 實例（或自訂 ASG），並用 EKS bootstrap script 加入叢集。需要自訂 AMI、Managed 模式不支援的 Windows 節點，或特殊硬體時才使用。
• Fargate profiles — 以選擇器（namespace + labels）為基礎的規則，將符合條件的 pods 路由至 Fargate microVMs。每個 pod 在各自獨立的隔離邊界中執行。情境若說「不需要節點管理」，這是常見答案。

在 SAP-C02 中會出現的限制：

• Fargate pods 不支援 DaemonSets、hostNetwork、hostPort、privileged containers、GPU 或 EBS volumes（只能透過 CSI 使用 EFS）。
• Fargate pods 每個 pod 有最低規格（0.25 vCPU / 0.5 GB），無法低於此下限。
• DaemonSets（CNI 外掛程式、log forwarders、安全性 agents）需要 managed 或 self-managed 節點，因此許多真實叢集在大多數 pods 跑在 Fargate 的同時，仍保留一個小型 managed node group。

IRSA 與 EKS Pod Identity — Pod 層級的 IAM

在不暴露節點層級憑證的情況下授予 pod AWS IAM 權限，是容器化 ECS EKS 中的核心 IAM 問題。AWS 提供兩種解法。

• IAM Roles for Service Accounts (IRSA) — cluster 有已登錄的 OIDC identity provider；Kubernetes service account 上標注 IAM role ARN；pod 內的 AWS SDK 透過 AssumeRoleWithWebIdentity 將 projected ServiceAccount token 換成 STS 憑證。可在 EKS 運行的任何地方使用，但每個 cluster 需要設定 OIDC provider，且 trust policy 設定較為複雜。
• EKS Pod Identity — 更新的機制（2023 年），以 EKS add-on 為基礎，無需為每個 cluster 管理 OIDC provider。你建立一個 Pod Identity Association，將 namespace + service account 對應到 IAM role；節點上的 Pod Identity Agent DaemonSet 透過 AWS Pod Identity Token 提供憑證。Trust model 更簡單，且在跨帳號情境下效果更好，因為 trust policy 只需要一個簡單的 service principal。

在 SAP-C02 深度如何選擇：

• 複雜 trust 的跨帳號 role chaining，或僅使用 Fargate 的工作負載 → IRSA（Pod Identity Agent 是 DaemonSet，無法在 Fargate 上執行）。
• 全新 cluster 搭配 managed nodes、簡單的每 cluster IAM 模型、更少繁瑣設定 → Pod Identity。
• 正在遷移？兩種機制可共存；pods 可以使用任一種。

EKS Add-ons

EKS add-ons 是 AWS 管理的、經過測試的叢集軟體套件：VPC CNI、kube-proxy、CoreDNS、EBS CSI driver、EFS CSI driver、Pod Identity Agent、Mountpoint for S3 CSI、Snapshot Controller 與 AWS Distro for OpenTelemetry。使用 add-ons 可將版本相容性與修補工作卸載給 AWS，並在 EKS 主控台顯示狀態。

Add-ons 在 SAP-C02 中的意義，在於情境要求跨機隊規模對核心叢集元件進行生命週期自動化——手動管理 50 個 cluster 的 VPC CNI 版本不是可持續的答案；在平台 pipeline 中以 add-ons 搭配版本鎖定才是。

EKS Hybrid Nodes — EKS 的地端工作節點

EKS Hybrid Nodes（2024 年 GA）讓你將地端 Linux 伺服器登錄為 EKS 工作節點，同時控制平面仍運行在 AWS。地端節點透過 AWS Direct Connect 或 Site-to-Site VPN 與 EKS 控制平面通訊，並與 EC2 和 Fargate 節點並排出現在同一個 cluster 中。

SAP-C02 容器化 ECS EKS 情境選擇 EKS Hybrid Nodes 的時機：

• 資料主權法規要求資料平面在地端，但平台工具要統一在 EKS。
• 製造業或零售業的邊緣站點需要與雲端 cluster 一致的 Kubernetes 體驗。
• 混合容量高峰——地端跑基礎量，需求爆增時擴展至 EC2。

與 ECS Anywhere 的對比：ECS Anywhere 把 ECS 延伸到地端；EKS Hybrid Nodes 把地端伺服器納入 EKS cluster。兩者都不能取代 Outposts 在需要 AWS 管理硬體的情境中的角色。

Karpenter vs Cluster Autoscaler — 正確的節點自動擴展

節點自動擴展是容器化 ECS EKS 成本與敏捷性相乘或崩潰的地方。SAP-C02 測試 Karpenter vs Cluster Autoscaler 的差異，因為兩種機制並不可互換。

Cluster Autoscaler — 舊有的預設選擇

Cluster Autoscaler（CA）監看無法排程的 pods，並對現有 node groups 進行擴充或縮減。它感知 node group，因此你需要預先定義各工作負載形狀的 node groups（例如一組 CPU 密集、一組記憶體密集、一組 GPU），CA 擴展符合需求的那個 group。CA 的反應時間是分鐘級而非秒級，因為它要驅動 ASG desired count 並等待 EC2 啟動。

在 SAP-C02 深度重要的限制：

• 需要預先定義 node groups；除非存在一個 4xlarge 的 group，否則無法為單一大型 pod 取得 4xlarge 實例。
• 單一 AZ 的 ASG 是常見陷阱——CA 假設 node group 可在任何 AZ 啟動。
• 縮減時遵守 PodDisruptionBudget，但仍可能很慢。

Karpenter — 即時佈建的接班人

Karpenter 是 AWS 發起的開源節點佈建器，用 NodePool 和 EC2NodeClass 資源取代 node groups，描述允許的機型系列、容量類型（On-Demand / Spot）、可用區域和 taints。當出現無法排程的 pod，Karpenter 評估 pod 的需求並啟動最便宜的適配 EC2 實例——通常在一分鐘內，通常是完美尺寸的實例而非 node group 預設的規格。

Karpenter 在容器化 ECS EKS 成本與敏捷性上勝出的理由：

• 尺寸適配 — 為等待中的 pods 佈建恰好合適的實例，減少 CA 固定 node group 形狀帶來的資源浪費。
• Spot 感知 — 一流的 Spot 支援，透過 EventBridge 通知處理中斷，自動回退至 On-Demand。
• 整合 — Karpenter 可以主動釋放利用率低的節點，並自動將 pods 重排到更便宜或更少的節點上。
• 無需 node groups — 縮減了維運複雜度。

SAP-C02 情境若出現「Spot 上的即時容量」或「混合機型」或「積極的 Spot 使用」，答案指向 Karpenter；情境若說「簡單、少量工作負載形狀、團隊已熟悉 Cluster Autoscaler」，仍可合理選擇 CA。

App Mesh 與 VPC Lattice — 容器的服務網格

一旦容器化 ECS EKS 上有 50 個微服務，你就需要解決服務間探索、mTLS、流量整形、重試和可觀測性。AWS 有兩個服務應對此問題：App Mesh（已棄用，見說明）和 VPC Lattice（較新）。

AWS App Mesh

App Mesh 是 AWS 基於 Envoy 的服務網格。每個 ECS task 或 EKS pod 運行一個 Envoy sidecar，以 App Mesh 控制平面集中管理的政策處理東西向流量。功能包括重試、逾時、金絲雀部署的流量分割、透過 ACM Private CA 的 mTLS，以及與 X-Ray、CloudWatch 和 Prometheus 的可觀測性整合。

SAP-C02 注意事項：AWS 已宣布 App Mesh 不再接受新功能，處於維護模式；新設計應優先使用 VPC Lattice 或客戶自行操作的網格（Istio、Linkerd）。但 App Mesh 仍會出現在舊有現代化情境中，考試仍可能引用它。

Amazon VPC Lattice

VPC Lattice 是 AWS 較新的應用層網路服務，無需 sidecar 即可跨 VPCs 和帳號提供服務探索、連線、安全性和可觀測性。它運作在第 7 層，處理 HTTP、HTTPS 和 gRPC 流量。

容器化 ECS EKS 的 VPC Lattice 關鍵概念：

• Service network — 將服務分組的邏輯邊界；VPCs 關聯至 service network 以取得存取權。
• Service — 在 network 中登錄的 HTTP 或 gRPC endpoint。
• Target group — 支撐 service 的運算資源；可以是 ECS tasks、EKS pods、Lambda、EC2 或 IP 位址。
• Auth policy — IAM policy，控制哪些 VPCs 中的哪些 principals 可以呼叫哪些 services。

VPC Lattice 對跨多個 VPC 和多個帳號的 50 個微服務情境極具吸引力。它以單一 service network 取代 N×(N-1)/2 的 VPC peering，並提供一致的 IAM 驗證授權。

何時選 App Mesh、VPC Lattice 還是 Istio

• Istio / Linkerd on EKS — 你已投資 Kubernetes 原生網格，且需要 AWS 尚未提供的功能（故障注入、WASM 擴充）。
• VPC Lattice — 跨帳號、跨 VPC、多種服務類型混合（ECS、EKS、Lambda、EC2），以 IAM 驗證授權為主要控制平面。
• App Mesh — 僅用於已選擇它的既有部署；不要在新設計中使用 App Mesh。

容器映像安全 — ECR 掃描、Inspector、簽章

容器化 ECS EKS 的映像安全是 SAP-C02 的獨立主題。你需要了解 ECR 掃描層級、Inspector 整合與簽章。

ECR Basic vs Enhanced 掃描

Amazon ECR 提供兩種掃描模式：

• Basic scanning — 由 Clair（開源）驅動，免費，推送時掃描，回傳 CVE 發現。對大多數非受監管工作負載足夠。
• Enhanced scanning — 由 Amazon Inspector v2 驅動，與 Inspector 儀表板整合，包括對現有映像的持續掃描（不只在推送時），偵測 OS 和語言套件的漏洞，並產生可路由至 Security Hub 的 EventBridge 發現。

針對受監管的 SAP-C02 情境（「PCI-DSS 容器合規」、「持續漏洞可視性」），正確答案是 ECR Enhanced Scanning 搭配 Inspector v2。

Amazon Inspector 用於容器

Inspector v2 持續掃描 ECR 映像、運行中的 EC2 實例和 Lambda functions 的漏洞。對容器而言，Inspector 在推送時深度掃描映像層，並在有新 CVE 發布時持續重新評估現有映像——即使映像首次推送時漏洞尚不存在，也能後來察覺。發現結果流向 AWS Security Hub 和 EventBridge 以進行自動化回應。

容器映像簽章

對於高保證的供應鏈，使用 AWS Signer 簽署映像並在部署時驗證簽章，可防止部署不受信任的映像。標準模式是使用 AWS Signer 搭配 Notation 或 Cosign 簽章存放於 ECR；EKS 上的 Kyverno 或類似的 policy engine 在允許 pod 准入前驗證簽章；ECS 則透過 task definition 檢查或 CI/CD 閘門進行驗證。

多帳號與多 Region 的容器策略

組織規模的容器化 ECS EKS 意味著多個帳號、多個 Region，以及共用的平台服務。SAP-C02 複合題幾乎都跨越至少兩個邊界。

多帳號容器平台模式

大多數平台團隊為容器化 ECS EKS 確立了三層帳號架構：

• 共用服務帳號 — 中央 ECR、中央 Route 53 私有 hosted zones、中央 VPC Lattice service network、中央 CI/CD 工具。
• 工作負載帳號 — 每個團隊或每個環境一個；運行 ECS 或 EKS cluster。
• 安全帳號 — 集中的 GuardDuty、Security Hub、Inspector 發現結果與日誌聚合。

跨帳號 ECR 拉取透過 ECR registry policies 和 repository policies 啟用；工作負載帳號中的 EKS 節點扮演可從共用服務 ECR 拉取映像的角色。對 ECS on Fargate 而言，工作負載帳號中的 execution role 需要明確的跨帳號 ECR 拉取權限。

多 Region 容器策略

多 Region 容器化 ECS EKS 設計分為三個 RTO/RPO 等級。

• Pilot light — 映像和 manifests 透過 ECR 複寫規則和 GitOps 複寫；cluster 預先建立但縮放至零；故障切換時按需擴展。成本最低，RTO 為數十分鐘。
• Warm standby — 次要 Region 中運行縮小版的相同 cluster；Route 53 failover 路由切換流量；資料層持續複寫（Aurora Global Database、DynamoDB Global Tables）。RTO 為數分鐘。
• Active/active — 兩個 Region 都有等規模的 cluster，位於 Global Accelerator 或 Route 53 延遲路由後面；流量以 Region 為單位服務，寫入透過 Global Database 或應用層協調。RTO 接近零，成本最高。

Route 53 健康檢查必須探測能反映實際 cluster 健康狀況的 endpoint——不只是 ALB，而是能驗證資料層的深度健康端點，否則 failover 路由仍會持續將流量送往故障的 Region。

典型的 50 個微服務多語言多 Region 切換情境

考慮這個複合 SAP-C02 情境：50 個微服務由六個多語言團隊擁有，目前在單一 Region 的 EC2 上運行，需要遷移至容器並實現多 Region active/active，同時達成 40% 的成本降低目標。

此容器化 ECS EKS 情境的 Pro 等級目標架構：

1. Orchestrator — EKS，因為六個多語言團隊通常包含 Java Spring、Python FastAPI、Go、Node.js，以及至少一個已在使用 Helm 的團隊。可移植性和生態系是決定因素。
2. 運算組合 — Karpenter 在 Bottlerocket AMI 上管理 20/80 比例的 On-Demand 和 Spot EC2（專為容器設計的 OS，原子更新，縮小攻擊面）；小型 managed node group 用於 DaemonSets；Fargate profiles 用於批次工作和不受信任的工作負載。
3. 映像供應鏈 — 共用服務帳號中的中央 ECR，透過 ECR 複寫複製到次要 Region，Inspector Enhanced Scanning，AWS Signer 用於簽章，EKS 上的 Kyverno policy 用於簽章驗證。
4. 網路 — VPC Lattice service network 跨兩個 Region 用於跨服務流量，每個 Region 邊緣使用 ALB，Route 53 延遲路由跨 Region 並搭配深度健康檢查。
5. 資料層 — 關聯式資料用 Aurora Global Database，鍵值資料用 DynamoDB Global Tables，物件用 S3 Cross-Region Replication。
6. IAM — 新工作負載使用 EKS Pod Identity；ECR 使用跨帳號拉取角色。
7. CI/CD — 每個微服務的 CodePipeline 觸發，透過 Argo CD 或 Flux GitOps 部署到各 cluster；Argo Rollouts 漸進式交付搭配 Karpenter 整合。
8. 成本 — Compute Savings Plans 涵蓋 Karpenter On-Demand 基礎容量（約 40% 折扣），Spot 涵蓋突發容量（約 70% 折扣），批次 profiles 使用 Fargate Spot。混合後的運算節省超過 40% 目標。
9. 切換 — 並行部署新架構，透過加權 Route 53 在兩週內以 10% / 25% / 50% / 100% 漸進轉移流量，再保留舊架構熱備一週作為回滾緩衝，然後下線。

這是具代表性的 SAP-C02 答案結構：跨多個領域、以具體服務搭配理由引用、明確處理成本與風險。

容器化 ECS EKS 的成本優化

容器成本優化是 Pro 等級技能，因為各項槓桿會相互疊加。以下是容器化 ECS EKS 的成本操作手冊。

Fargate Spot 用於無狀態與批次工作

Fargate Spot 對 ECS Fargate tasks 和 EKS Fargate pods 提供最高 70% 的折扣，並透過 SIGTERM 提供 2 分鐘中斷預警。非常適合 load balancer 後面的無狀態微服務（load balancer 在任務中斷時繞過它）、批次工作（中斷後重啟），以及開發 / CI 環境。

Compute Savings Plans 用於穩定容量

Compute Savings Plans 對 Fargate、Lambda 和 EC2 的每小時支出承諾 1 或 3 年，可獲得高達 66% 的 On-Demand 折扣（3 年全額預付更高）。Compute Savings Plans 自動應用於 Fargate、Lambda 和 EC2，因此是混合運算機隊的正確答案。不要對容器化 ECS EKS 使用 EC2 Instance Savings Plans，除非你已承諾特定機型系列。

Bottlerocket — 專為容器設計的 OS

Bottlerocket 是 AWS 的容器優化 Linux 發行版。它只包含運行容器所需的套件，支援原子更新和自動回滾，相較通用用途 AMI 縮小攻擊面，並且容器化 ECS EKS 工作負載的開機速度比 Amazon Linux 2 / 2023 更快。Bottlerocket 可作為 managed node group 的 AMI 選項，是 EKS Auto Mode 和許多 Karpenter 設定的預設選擇。

選擇 Bottlerocket 的 SAP-C02 理由：

• 需要最少已安裝套件的合規情境。
• 快速節點輪替 / 修補——原子更新可向前或向後滾動。
• 更快的擴展速度——Karpenter 啟動節點時開機時間縮短。

右型和整合

AWS Compute Optimizer 現在為 Fargate 上的 ECS 服務和 EKS 容器提供右型建議。Karpenter 的整合（consolidation）功能在利用率低時自動將 pods 整合到更少的節點。CloudWatch 上的 Container Insights 提供每個 task 和每個 pod 的 CPU 與記憶體指標，可以回饋到 task definitions 和 pod 資源請求中。

Graviton 用於容器

AWS Graviton（ARM64）實例為許多容器工作負載提供高達 40% 的價效比提升。ECS 和 EKS 都透過 task definition 的 runtimePlatform 欄位支援 Graviton 支撐的 Fargate，以及 Graviton EC2 實例。提到「進一步降低無狀態微服務成本」的情境，往往以 Graviton 作為最後一哩的答案。

容器化 ECS EKS 的常見考試陷阱

以下這些容器化 ECS EKS 陷阱在 SAP-C02 考試中反覆出現。

陷阱一 — 只要提到容器就選 EKS

只有在情境有 Kubernetes 特定需求的證據時才選 EKS。否則 ECS on Fargate 更便宜、更快。

陷阱二 — 把 IRSA 和 Pod Identity 視為可互換

它們以不同方式解決同一個問題。Pod Identity 不在 Fargate 上執行；IRSA 可以。跨帳號設定 Pod Identity 更容易。兩者都要熟悉。

陷阱三 — 假設 Fargate 支援所有 Pod 形狀

Fargate pods 不支援 DaemonSets、hostNetwork、hostPort、privileged、GPU 或 EBS。任何需要上述功能的題目都排除了 Fargate-only 設計。

陷阱四 — 在全新設計中推薦 App Mesh

App Mesh 處於維護模式。新設計請使用 VPC Lattice 或開源網格。

陷阱五 — 假設 ECR Basic Scanning 會持續掃描

Basic scanning 只在推送時執行一次。持續重新掃描需要 Enhanced Scanning / Inspector v2。

陷阱六 — 情境明確有 Karpenter 時仍選 Cluster Autoscaler

若情境提到「即時容量」、「混合機型」或「積極的 Spot 使用」，Karpenter 是目標答案。

陷阱七 — 把 Capacity Providers 和 Auto Scaling Groups 混淆

Capacity providers 是 ECS 的抽象層；它們可以包覆 Fargate 容量來源或 EC2 ASG。Auto Scaling Groups 單獨存在對 ECS cluster 自動擴展是不夠的；你需要一個綁定到 ASG 的 Capacity Provider。

陷阱八 — 搞混 ECS Anywhere 和 EKS Hybrid Nodes

ECS Anywhere 把 ECS tasks 推送到地端硬體。EKS Hybrid Nodes 把地端伺服器納入 EKS cluster。它們解決不同問題；情境若指定地端需要 Kubernetes API 相容性，需要的是 EKS Hybrid Nodes。

容器化 ECS EKS vs SAP-C02 相鄰主題

清楚劃定與相鄰主題的邊界，避免考試時的跨主題混淆。

• containerization-ecs-eks vs event-driven-serverless-architecture — 本章負責容器；serverless 負責 Lambda、EventBridge、Step Functions。複合情境透過 EventBridge → Fargate 或 SQS → Fargate worker pools 將事件路由至容器。
• containerization-ecs-eks vs modernization-app-target-architecture — 現代化涵蓋遷移劇本和 6-Rs（重構、重新平台化）；本章涵蓋一旦決定重新平台化至容器後的目標平台。
• containerization-ecs-eks vs cicd-iac-deployment-strategy — CI/CD 涵蓋 pipeline、藍/綠、金絲雀；本章涵蓋容器特定的執行期問題。
• containerization-ecs-eks vs new-solutions-reliability — 可靠性通用地涵蓋多 AZ、重試、熔斷器；本章涵蓋容器特定的 HA（Fargate AZ 分散、Pod Anti-Affinity、PDBs）。
• containerization-ecs-eks vs new-solutions-cost-design — 成本設計涵蓋所有服務的定價框架（RI、Savings Plans）；本章將它們具體應用於容器。

容器化 ECS EKS 必背關鍵數字

• ECS 控制平面：免費。
• EKS 控制平面：每 cluster 每小時 $0.10（每月約 $73）。
• Fargate Spot 折扣：最高 70%，透過 SIGTERM 提供 2 分鐘中斷預警。
• Compute Savings Plans：3 年全額預付最高 66% 折扣；適用於 Fargate、Lambda、EC2。
• Fargate task 規格：0.25 vCPU（0.5-2 GB）至 16 vCPU（30-120 GB）。
• Fargate 臨時儲存：預設 20 GB，最高 200 GB。
• EKS Pod Identity 推出：2023 年 GA；不適用於 Fargate。
• IRSA：每個 cluster 需要 OIDC provider；跨帳號需要 trust policy federation。
• Karpenter：節點佈建不到一分鐘；跨 node pools 整合。
• ECR Enhanced Scanning：由 Inspector v2 驅動的持續重新掃描。
• ECS Anywhere：每個外部實例每小時固定費率；外部實例無 ALB / EBS。
• EKS Hybrid Nodes：透過 Direct Connect 或 VPN 加入 EKS 控制平面的地端 Linux 伺服器。

FAQ — 容器化 ECS EKS Pro 規模

Q1. SAP-C02 Pro 等級中 ECS 何時優於 EKS，EKS 何時優於 ECS？

ECS 在以下情況優於 EKS：AWS 原生全新工作負載、團隊尚未運行 Kubernetes、深度 ALB / IAM / CloudWatch / Secrets Manager 整合比可移植性更重要，以及多個 cluster 乘上約 $73/月的 EKS 控制平面費用是重要考量。EKS 在以下情況優於 ECS：需要可移植性（今天或未來有多雲或地端 Kubernetes 需求）、使用 Kubernetes 原生工具生態系（Helm charts、operators、service meshes、GitOps）、團隊是多語言且已標準化在 Kubernetes API 上，或廠商軟體只以 Kubernetes manifests 形式交付。在 SAP-C02 深度，始終掃描情境尋找明確的 EKS 證據——「團隊在地端運行 Kubernetes」、「使用 Helm」、「需要多雲 manifests」——再選擇 EKS 優於 ECS。

Q2. ECS Capacity Providers 如何混合 Fargate、Fargate Spot 和 EC2 進行成本優化？

ECS Capacity Providers 是一個抽象層，讓服務以加權策略針對多個運算後端。你將 Capacity Provider 策略定義為有序清單，每個 provider 有 base（該 provider 上的最低任務數）和 weight（超過 base 後的相對份額）。無狀態服務的典型成本優化模式是：Fargate On-Demand 設 base=2 weight=1，Fargate Spot 設 weight=4，保留兩個任務在可靠容量上，其餘以約 20% On-Demand 和 80% Spot 分配。對 EC2 支撐的 cluster，Capacity Providers 包覆 Auto Scaling Group，capacity provider 上的 managed scaling 自動擴展 ASG 以吸收等待中的任務。當 EC2 上已有 Reserved Instances 或 Savings Plans 承諾時，混合 Fargate 用於高峰、EC2 ASG Capacity Provider 用於穩定容量是常見的混合模式。

Q3. IRSA 和 EKS Pod Identity 的實際差異是什麼，各自何時選擇？

IRSA（IAM Roles for Service Accounts）使用 OIDC federation：EKS cluster 發布一個 OIDC issuer URL，你將該 URL 登錄為 IAM identity provider，pod 內的 AWS SDK 透過 AssumeRoleWithWebIdentity 將 projected ServiceAccount token 換成 STS 憑證。EKS Pod Identity 使用 service principal（pods.eks.amazonaws.com）加上 Pod Identity Association 資源，將 namespace + service account 對應到 IAM role，憑證透過 Pod Identity Agent DaemonSet 傳遞。在需要更簡單的 trust policies、更容易的跨帳號設定、且不需要管理 OIDC provider 的新 cluster 上選 Pod Identity——但注意 Pod Identity 不在 Fargate 上執行，因為它依賴 DaemonSet agent。在工作負載跑在 Fargate、cluster 是既有且已標準化在 IRSA 上，或需要可跨非 AWS Kubernetes cluster 移植的 trust model 時選 IRSA。同一個 cluster 支援共存，對從 IRSA 遷移到 Pod Identity 的過程很有幫助。

Q4. Karpenter 和 Cluster Autoscaler 有何差異，何時選擇 Karpenter？

Cluster Autoscaler（CA）根據等待中的 pods 對預先定義的 EC2 Auto Scaling Groups（node groups）進行擴充或縮減；你必須提前設計 node group 形狀，CA 在幾分鐘內反應。Karpenter 以 NodePool 和 EC2NodeClass 自訂資源取代 node groups，描述允許的機型系列、容量類型和可用區域；出現等待中的 pods 時，Karpenter 評估資源需求並啟動最便宜的適配 EC2 實例，通常在一分鐘內。Karpenter 還有一流的 Spot 處理（優雅響應中斷通知並回退至 On-Demand）和整合（consolidation）功能，在利用率下降時主動將 pods 移到更少、更便宜的節點上。對成本敏感、異質工作負載、需要即時容量和混合 Spot / On-Demand 的情境選 Karpenter。對均質、node group 設計已經穩固、且操作熟悉度比最後那點成本節省更重要的情境選 Cluster Autoscaler。大多數 SAP-C02 全新 EKS 答案現在預設使用 Karpenter。

Q5. 在 50 個微服務平台上何時用 VPC Lattice、何時用 Istio 等叢集內服務網格？

當服務跨越多個 VPCs 和多個 AWS 帳號、混合多種運算類型（ECS、EKS、Lambda、EC2），且主要控制面是 IAM 驗證授權和管理式 L7 連線時——全部不需要 sidecar——VPC Lattice 是正確答案。你可以用單一 AWS 管理的控制平面獲得服務探索、IAM auth policies、HTTP / gRPC 路由和跨帳號存取。Istio 等叢集內服務網格是正確答案，當你需要 VPC Lattice 尚未提供的 Kubernetes 原生功能——細粒度流量切換、用於混沌測試的故障注入、WASM 擴充、Envoy 設定調整，或開源生態系整合（Kiali 儀表板、SPIFFE/SPIRE 身份識別）。在 50 個微服務的 SAP-C02 情境中，常見的混合模式是在平台邊界使用 VPC Lattice（跨帳號、跨 VPC 的服務呼叫搭配 IAM 驗證），在每個 EKS cluster 內使用 Istio 或 Linkerd（用於叢集內的重試、mTLS 和流量分割）。新設計請避免使用 App Mesh，因為它處於維護模式。

Q6. 必須零停機切換的容器化 ECS EKS 平台應採用什麼多 Region 策略？

零停機多 Region 切換的做法是：在兩個 Region 都運行規模相等或接近的 cluster，透過 ECR 複寫規則複製容器映像，透過 GitOps（Argo CD / Flux 指向兩個 cluster）複製設定，在資料層複寫狀態（Aurora Global Database、DynamoDB Global Tables、S3 Cross-Region Replication），以 Route 53 延遲或加權路由（或用 Global Accelerator 的 anycast）作為平台前端，並使用能探測完整請求路徑（應用程式 + 資料庫）而非只探測 ALB 的深度健康檢查。切換時採用加權流量轉移：10% 到新 Region，監控錯誤率和延遲，逐步調整至 25%、50%、100%，再保留舊 Region 熱備一段回滾緩衝期，然後下線。這是 active/active 或 warm-standby 模式；pilot-light 模式不符合「零停機」要求，因為從零擴展需要數分鐘。考試嘉許引用這些具體服務和分段推出節奏的情境答案。

Q7. ECR Basic scanning、ECR Enhanced scanning 和 Amazon Inspector v2 對容器映像安全有何關係？

ECR Basic scanning（免費，由 Clair 驅動）在映像推送時執行一次，回報該映像快照的 CVEs。ECR Enhanced scanning 由 Amazon Inspector v2 驅動，啟用持續掃描：Inspector 在有新 CVE 發布時重新評估已推送的映像，即使漏洞在映像首次推送後才出現也能顯示為發現結果。Inspector v2 對容器的支援也延伸到 Lambda 和 EC2，發現結果流向 AWS Security Hub 和 EventBridge 以進行自動化回應（例如，EventBridge 規則可在出現嚴重發現時通知 SNS 並開立 Jira 工單）。對 SAP-C02 要求持續可視性或 PCI-DSS 等級合規的情境，正確答案是 ECR Enhanced scanning 搭配 Inspector v2 加上 Security Hub 聚合。搭配 AWS Signer 或 Cosign 進行映像簽章，以及 EKS 上的 Kyverno 或 OPA Gatekeeper policy（或 ECS 上的 CI 閘門）拒絕未簽署的映像，即可完成供應鏈安全的完整故事。

Q8. 如何為 50 個微服務的容器化 ECS EKS 平台進行成本優化以達到 40% 降低目標？

疊加各項成本槓桿：首先，透過 Compute Optimizer 建議和 Karpenter 整合對 pod 資源請求和 task CPU / 記憶體進行右型——光這一步通常就能釋放 10-20% 的容量。第二，對語言執行時期支援的微服務採用 Graviton（ARM64）；每個工作負載預計提升 20-40% 的價效比。第三，用 Compute Savings Plans 涵蓋基礎容量（3 年全額預付最高 66%，適用於 Fargate、Lambda、EC2）。第四，透過 Karpenter 將突發和批次工作負載移至 Fargate Spot 或 EC2 Spot（最高 70% 折扣）。第五，將 managed nodes 切換至 Bottlerocket 以獲得更快的開機時間和更小的攻擊面。第六，將 ECR 集中在共用服務帳號，並複寫到工作負載 Region，避免各帳號各自的資料傳輸費用。第七，對 AWS 到 AWS 的流量使用 VPC endpoints 而非 NAT Gateway。以混合單位成本（每請求成本）而非月帳單衡量結果，讓效益衰退提早浮現。一旦這些層次組合起來，對大多數 SAP-C02 全新架構情境而言，達到 40% 是切實可行的。

總結 — 容器化 ECS EKS 一覽

• SAP-C02 深度的容器化 ECS EKS 是六維決策：團隊技能、可移植性、控制平面成本、營運負擔、生態系、AWS 原生整合。
• ECS Pro 主題：Capacity Providers（Fargate + Spot + EC2）、Cloud Map 服務探索、可稽核除錯的 ECS Exec、地端用的 ECS Anywhere、task definitions 中 task role vs execution role 的差異。
• EKS Pro 主題：控制平面 HA + 稽核日誌 + 私有 endpoint、Managed Node Groups vs Self-Managed vs Fargate Profiles、IRSA vs Pod Identity（Pod Identity 更簡單但不在 Fargate 上）、EKS Add-ons、地端 Kubernetes 用的 EKS Hybrid Nodes。
• Karpenter 對成本敏感、異質、Spot 密集的工作負載優於 Cluster Autoscaler；CA 對均質、穩定 node group 形狀的機隊仍然有效。
• 服務網格：跨 VPC、跨帳號、跨運算類型用 VPC Lattice；Kubernetes 原生進階功能用 Istio / Linkerd；App Mesh 僅用於舊有部署（維護模式）。
• 映像安全：Inspector v2 配合 ECR Enhanced scanning 實現持續可視性，AWS Signer + Kyverno / OPA 實現簽署映像准入。
• 多帳號：共用服務 ECR 搭配跨帳號拉取、VPC Lattice 用於跨帳號服務網路、Organizations + SCPs 用於護欄。
• 多 Region：active/active 實現接近零 RTO，warm standby 實現分鐘級 RTO，pilot light 實現數十分鐘 RTO；Route 53 延遲或加權路由搭配深度健康檢查；資料層透過 Aurora Global Database、DynamoDB Global Tables、S3 CRR。
• 成本：Compute Savings Plans 用於基礎容量，Fargate Spot 用於無狀態，Graviton 用於適合的執行時期，Bottlerocket 用於節點效率，Compute Optimizer 和 Karpenter 整合用於右型。
• 典型的 50 個微服務多語言多 Region 情境解法：EKS + Karpenter on Spot + Bottlerocket + VPC Lattice + Aurora Global Database + Route 53 延遲路由 + GitOps + Compute Savings Plans，搭配分段加權流量切換。

在 Pro 深度掌握容器化 ECS EKS，SAP-C02 Domain 2 的容器切面以及 Domain 4 的現代化重疊部分就會成為模式辨識而非死記硬背。這套框架在考試之外，也能延伸應用到真實的平台架構決策中。