Amazon DOP-C02: 容器與無伺服器維運 — 學習指南

By Laurynas Brazys · 4 August 2026 · #amazon #dop-c02 #certification #exam-prep #study-guide

屬於 AWS DevOps Engineer Professional DOP-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

容器與無伺服器改變了您在 AWS 上營運、擴展和發布應用程式的方式。本節將串連 Amazon ECS、AWS Fargate、Amazon EKS、Amazon ECR、AWS Lambda 和 Amazon API Gateway 的營運基元，讓您能夠設計安全的部署、實施映像檔治理、調整並行性，並在基於 EC2 和 Fargate 的容量之間做出一致的選擇。本節重點在於任務與 Pod 的排程模型、健康狀態檢查與部署控制、流量轉移、跨帳戶映像檔分發，以及 API 快取和 Lambda 佈建並行等效能特性。

Amazon ECS 與 AWS Fargate

ECS 任務定義宣告一或多個容器，以及排程器所需的所有執行期組態。關鍵元素包括 CPU/記憶體預留與限制、portMappings、環境變數與私密資料 (來自 AWS Secrets Manager 或 Systems Manager Parameter Store)、Linux 參數與 ulimits、logConfiguration (awslogs、firelens 等)、ephemeralStorage 大小 (對於 Fargate 為 20–200 GB)，以及磁碟區 (包括 EFS)。使用任務執行角色來拉取映像檔和處理日誌驅動程式；使用任務角色來讓應用程式存取 AWS API。容器的 healthCheck 定義了命令、間隔、逾時、重試次數和 startPeriod。結合 dependsOn (condition=HEALTHY)，健康狀態檢查可強制執行附屬容器 (sidecar) 的啟動順序。

ECS 服務會維護期望的任務數量，並可選擇性地將任務註冊到 ALB/NLB。服務的 deploymentConfiguration 透過 minimumHealthyPercent 和 maximumPercent 來控制滾動更新。部署熔斷器 (啟用/回滾) 可以在任務健康狀態檢查失敗時，自動還原失敗的部署。服務自動擴展與 Application Auto Scaling 整合，可進行基於 CPU/記憶體的目標追蹤或 ALB RequestCountPerTarget。服務探索 (AWS Cloud Map) 和 ECS Service Connect 簡化了服務對服務的流量。

叢集類型與容量：

• EC2 啟動類型在您自行管理的 EC2 執行個體上執行任務。可使用 Auto Scaling 群組、放置限制/策略，以及任何 networkMode (bridge/host/awsvpc)。支援 Daemon 任務和特殊化的 AMI (例如 Bottlerocket)。
• Fargate 啟動類型是容器的無伺服器運算。它僅使用 awsvpc 網路模式，為每個任務提供自己的 ENI 和安全群組。不支援 Daemon 任務；您需依賴附屬容器 (sidecar) 或服務原生整合 (例如 FireLens)。平台版本會決定支援的功能 (請查看版本資訊以了解 EFS、ephemeral storage 和 exec 的支援情況)。Fargate Spot 可為可中斷的任務降低成本。請選擇支援的 CPU/記憶體組合 (例如，從 0.25 vCPU/0.5–2 GB 到 16 vCPU/120 GB)。在私有子網路中執行時，需為 ECR (api 和 dkr)、CloudWatch Logs 新增 VPC 介面端點，並新增 S3 閘道端點，以便在沒有 NAT 的情況下拉取映像檔和傳送日誌。

Fargate 與 EFS：在任務定義中定義一個 EFS 磁碟區並使用 TLS 掛載；建議優先使用 EFS 存取點以實施最低權限和身分強制。這支援了有狀態的需求，例如共享組態、模型權重或中繼檔案，而無需將它們內建到映像檔中。

容器健康狀態檢查、滾動更新與藍/綠部署：

• 健康狀態檢查發生在多個層級：容器 (基於 CMD)、ECS 任務 (彙總的容器狀態)，以及負載平衡器目標健康狀態 (HTTP/TCP)。請對齊檢查間隔和閾值，以便 ECS 可以在 ALB 取消註冊目標之前，優雅地替換不健康的任務。
• 滾動更新是 ECS 的預設方式。調整 minHealthy/maxPercent 來控制突增量和容量安全性。
• 藍/綠部署使用 CodeDeploy 搭配 ECS (deploymentController 類型為 CODE_DEPLOY)。CodeDeploy 管理 ALB 後面的兩個目標群組，將測試流量轉移到綠色組 (AfterAllowTestTraffic)，執行自動化檢查 (例如透過 Lambda)，然後轉移生產流量。將 CloudWatch 警示與 5XX 錯誤突增、延遲或自訂指標綁定，以觸發回滾。此模式可隔離故障，並提供近乎零停機時間的快速還原。

使用 ECR 進行映像檔治理：

• 掃描：啟用推送時掃描 (scan-on-push) 並採用 Amazon Inspector 增強型掃描，以獲得持續的 CVE 涵蓋範圍和 SBOM。在 CI/CD 管線中使用檢查，根據漏洞嚴重性來決定是否放行部署。
• 生命週期政策可根據數量/存在時間和標籤前綴，來讓舊的映像檔標籤過期。結合標籤不變性 (tag immutability) 來阻止意外覆寫。
• 加密：使用 ECR 管理的加密或客戶管理的 KMS 金鑰搭配適當的金鑰政策。
• 跨帳戶：附加儲存庫資源政策，以授予其他帳戶或 CI 角色的拉取/推送權限。使用 ECR 複寫規則將映像檔複製到不同區域/帳戶，以實現本地性和縮小爆炸半徑。PrivateLink (VPC 端點) 允許在沒有網際網路的情況下拉取映像檔。

Amazon EKS 運算模型

EKS 將受管的控制平面與您的資料平面選項分開：

受管節點群組 (Managed node groups, MNGs) 會佈建並管理 EC2 工作節點的生命週期。它們與啟動範本整合，可用於選擇 AMI (Amazon Linux 2, Bottlerocket)、執行個體類型和啟動參數。MNGs 處理具備突增容量 (surge capacity) 的滾動更新，以及自動化的 cordon/drain，以將中斷降至最低。使用節點 taints/tolerations 來引導特定工作負載。與 Cluster Autoscaler (或 Karpenter) 結合，根據待處理的 pod 來適當調整節點容量。

自我管理的節點讓您對啟動程序和作業系統有完全的控制權，但增加了維運的負擔；它們通常保留給特殊核心或利基硬體使用。

EKS on Fargate 無需管理節點即可執行 pod。Fargate profiles 會將 namespaces/labels 對應到 Fargate。每個 pod 都會取得自己的 ENI (awsvpc)，簡化了網路隔離。限制包括不支援 DaemonSets、主機網路/磁碟區，以及對特權工作負載的限制。可觀測性代理程式 (例如 Fluent Bit) 必須以 sidecar 形式執行，或使用受管的日誌收集服務。此模型非常適合流量突增、佔用資源少或多租戶的工作負載，這些負載能從每個 pod 的隔離性和按 pod 付費的經濟效益中獲益。

維運附加元件：

• VPC CNI、CoreDNS 和 kube-proxy 是受管的附加元件；請鎖定與叢集版本相容的版本，並謹慎地進行升級。
• IAM Roles for Service Accounts (IRSA) 為每個 pod 強制執行最低權限的 AWS 存取，並取代了節點角色憑證共享的方式。
• 透過 AWS Load Balancer Controller 進行負載平衡，支援 Services 和 Ingress 使用 ALB/NLB；請確保適當的 IAM 和安全群組規則，尤其是在混合使用 MNG 和 Fargate 時。
• 透過 CSI 驅動程式提供持久性儲存 (EBS 用於每個 pod 的區塊儲存，EFS 用於共享的 POSIX 檔案系統)。對於 Fargate，EFS 是共享狀態的典型選項。

AWS Lambda 維運與並行

封裝與組態：

• 部署套件可以是 ZIP 壓縮檔 (包含語言執行環境) 或最大 10 GB 的容器映像檔。ZIP 對於小型程式碼較為輕量；映像檔則統一了基於容器建置的工具鏈。
• Layers 封裝了跨函數共享的函式庫；應保持其精簡並進行版本控制。一個函數最多可以包含五個 Layers。
• Versions 是不可變的快照；aliases 是指向版本的穩定指標，並可帶有權重以進行流量轉移。
• 臨時儲存空間預設為 512 MB，可提高至 10,240 MB，用於建置、暫存檔或機器學習推論快取。選擇 x86_64 或 arm64 以在成本/效能之間進行權衡。使用環境變數進行組態設定，並與 Secrets Manager 或 Parameter Store 整合。

流量轉移與安全性：

• 使用 CodeDeploy 進行 canary/linear (金絲雀/線性) 轉移，並在 CloudWatch 警報觸發時 (例如 5XX 錯誤、延遲或自訂應用程式指標) 自動回滾。或者，直接設定 alias 的權重以進行簡單的 A/B 路由。
• 使用結構化日誌記錄到 CloudWatch Logs，並建立指標篩選器，以便在不更改指標埋點的情況下，衍生出按操作/版本/程式碼維度的指標。啟用 X-Ray 以進行端到端的延遲追蹤。

並行控制：

• 未預留的並行數量會從帳戶的區域共用池中提取。突增的流量可能會耗盡其他函數的資源。
• 預留並行數量會限制一個函數的最大並行數，並透過從區域共用池中劃分出來以保證其容量；這提供了與「吵雜鄰居」的隔離。
• Provisioned concurrency (預置並行) 會為特定版本/別名保持執行環境的初始化，幾乎消除了冷啟動並穩定延遲。使用 Application Auto Scaling 根據一天中的時間或指標來擴展預置並行數量。
• 當函數達到其並行限制時會發生節流 (Throttling)；同步呼叫者會收到 429 錯誤，而異步調用會以指數退避進行重試，並在達到設定的嘗試次數後進入死信佇列。對於像 SQS 這樣基於輪詢的來源，Lambda 會隨著佇列深度增加並行數；請確保預留/預置的並行數量以及下游容量與最大處理中訊息數相匹配，以避免積壓增長。

API Gateway 設計與 ECR 跨帳戶存取

API Gateway REST API vs. HTTP API：

• REST API 提供最豐富的功能集：請求/回應對應 (VTL)、用量計畫與 API 金鑰、授權方、WAF 及階段層級快取。當您需要進階轉換、帶有配額的 API 金鑰或成熟的生態系整合時，請選擇 REST API。
• HTTP API 的延遲較低、成本也較低，路由到 Lambda 和 HTTP 後端（包括 ALB/NLB/私有整合）也更簡單。它們支援 JWT 授權方和 IAM，但缺乏許多 REST 的功能，包括階段層級快取和 VTL 轉換。若要進行直接的代理且開銷最小，請選擇 HTTP API。

階段與調節 (Throttling)：

• 階段會將特定的部署綁定到一個 URL 路徑。在階段層級設定階段變數、日誌記錄和調節。套用用量計畫 (REST) 來強制執行每個 API 金鑰的調節和配額。調節設定包括速率 (rate) 和高載 (burst)；它們會與帳戶層級的限制結合，因此請確保總流量不超過區域配額。啟用結構化 JSON 格式的存取日誌，並整合 WAF 來檢查和封鎖惡意請求。

快取 (僅限 REST API)：

• 階段層級快取可減少後端負載和延遲；為每個方法設定 TTL、啟用加密，並考慮快取金鑰的參數/標頭以確保正確性。在會改變回應形式或行為的部署之後，請將快取失效。

私有連線：

• 選擇端點類型：邊緣優化 (edge-optimized) (REST，透過 CloudFront 全域提供)、區域性 (regional) 或私有 (private) (VPC 端點)。使用 VPC Link 的私有整合可連接到 VPC 中的 NLB/ALB 後端，無需對外公開。

ECR 跨帳戶存取：

• 使用儲存庫資源策略，將 pull/push 權限授予其他帳戶中的主體 (principal) (CI/CD 或執行期角色)。如果使用客戶管理的 KMS 金鑰，請相應地擴展金鑰策略。對於多帳戶分發，請定義 ECR 複寫規則以指定目標帳戶/區域，並在部署中使用標籤不可變性 (tag immutability) 和摘要鎖定 (digest pinning) 來驗證映像檔的完整性。

實務問題情境

Spotify 正在現代化一個播放清單微服務堆疊，以減少在發行高峰期間的延遲變異，並加強其跨多個 AWS 帳戶的映像檔供應鏈。

1. 標準化映像檔建置與治理

• 實作 ECR 儲存庫，啟用推送時掃描 (scan-on-push) 和 Amazon Inspector 增強型掃描。新增標籤不可變性與生命週期策略，以保留每個分支最新的 N 個版本並清除過時的版本。設定從建置帳戶到生產 (prod) 和預備 (staging) 帳戶的跨區域/跨帳戶複寫。 原因：Inspector 確保了持續的 CVE 涵蓋，標籤不可變性防止了標籤劫持，而複寫則將拉取操作本地化，以減少部署延遲和爆炸半徑。

2. 在 ECS 上使用 Fargate 提供無狀態 API

• 定義 ECS 任務定義，使用 awslogs 和 FireLens 來處理結構化日誌和指標。啟用容器的 healthCheck，並使其與 ALB 目標群組的健康檢查對齊。透過存取點掛載一個 EFS 磁碟區，用於共享的唯讀設定。在 Fargate 上執行服務，並採用混合 Fargate 和 Fargate Spot 的容量提供者策略，以實現成本效益。 原因：Fargate 免除了節點管理，並為每個任務以 ENI 進行隔離；EFS 避免將設定檔寫死在映像檔中，並支援設定的原子性回滾。

3. 透過藍/綠部署與自動化測試實現安全部署

• 將 ECS 服務切換到 CodeDeploy 部署控制器。在 ALB 上設定兩個目標群組。使用金絲雀轉移 (canary shift) 搭配 AfterAllowTestTraffic 來呼叫一個 Lambda 測試執行器，在 5 分鐘內對關鍵端點進行測試。附加 CloudWatch 警報到 5XX 錯誤和 p90 延遲上，以觸發回滾。 原因：CodeDeploy 的藍/綠部署隔離了風險，測試掛鉤 (test hook) 在完全切換前驗證了綠色環境，而警報則提供了自動化、客觀的回滾機制。

4. 在 Lambda 上處理對延遲敏感的操作，並穩定冷啟動問題

• 對於一個權杖化 (tokenization) 的輔助 API，將函數打包成一個僅包含精簡依賴項的 ZIP 檔。建立一個版本/別名，並啟用根據峰值調整大小的預置並行 (provisioned concurrency)。透過 Application Auto Scaling，使用追蹤發行時程的每日排程來驅動預置並行。使用 CodeDeploy 金絲雀部署 (10%/15 分鐘) 進行基於別名的流量轉移，並與 CloudWatch 警報綁定。 原因：預置並行消除了流量高峰期間的冷啟動；別名金絲雀部署實現了逐步的流量暴露，並能快速回滾。

5. 透過 API Gateway 公開外部 API 並保護私有後端

• 使用 API Gateway 作為 Lambda 和 ECS ALB 的前端。對 Lambda 代理使用 HTTP API，以最小化成本/延遲。對於需要請求/回應對應和階段快取的重度讀取端點的 ECS ALB 路徑，使用 REST API。套用 WAF Web ACL 和階段調節；啟用結構化存取日誌。 原因：根據需求選擇 API 類型可以優化成本和功能；快取減少了負載；WAF 和調節在事件高峰期間提供了保護。

6. 無需網際網路的跨帳戶執行期拉取

• 在執行期的 VPC 中，為 ECR (api, dkr) 和 CloudWatch Logs 新增介面端點 (interface endpoint)，並為 S3 新增閘道端點 (gateway endpoint)。附加 ECR 儲存庫資源策略，以允許生產帳戶的任務執行角色進行拉取。使用帶有跨帳戶金鑰策略的客戶管理 KMS 金鑰，對靜態映像檔進行加密。 原因：私有映像檔拉取避免了 NAT 成本和出口風險；明確的資源/金鑰策略強制執行了最小權限的跨帳戶存取。

此設計減少了維運負擔 (無需管理節點)，透過預置並行和與 ALB 健康檢查對齊的部署提供了可預測的延遲，並透過 ECR 掃描、複寫和不可變性來強制執行端到端的映像檔來源追溯。

← 安全、合規性與治理 · 所有領域 · 高可用性、韌性與災難復原 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Amazon →