Amazon SAP-C02: 部署、自動化與 DevOps — 學習指南

By Laurynas Brazys · 1 August 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

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

基礎設施即程式碼與環境管理

將基礎設施即程式碼 (IaC) 視為環境的唯一真實來源 (single source of truth)，將網路、IAM 和應用程式拓撲嵌入可重複使用、版本化的產物 (artifacts) 中。若要嚴格的宣告式控制與深度的 AWS 整合，請選擇 CloudFormation；當高階建構 (constructs) 和語言原生抽象化能提升開發者生產力時，則使用 AWS Cloud Development Kit (CDK)；務必強制 CI 將 CDK 合成為範本，並將產物儲存在加密且版本化的 S3 儲存貯體中。使用 CloudFormation StackSets 進行一致性的跨帳戶、跨區域堆疊實例化，並在偏移 (drift) 指出組態熵 (configuration entropy) 時，啟用偏移偵測並結合 Systems Manager 進行自動化修復。使用 EC2 Image Builder 或 Packer 來打造黃金映像檔 (golden images)，並透過自動化管道將 AMI 發佈到各帳戶與區域；這能支援不可變部署 (immutable deployments) 並減少啟動後的組態偏移。請謹慎使用 CloudFormation 變更集 (change sets)、終止保護 (termination protection) 和更新政策，以避免因無意的資源替換而導致資料遺失。常見的陷阱包括在範本中嵌入機密、依賴會破壞偏移偵測的便宜行事手動變更，或授予過於寬鬆的 CloudFormation 執行角色——應將執行角色限制在最小權限，並保留 CloudTrail 和 Config 的歷史記錄以供稽核。權衡取捨很直接：CDK 加速開發，但需要嚴謹的 CI/CD 以避免執行階段堆疊不同步；純 CloudFormation 較為僵固，但可立即稽核。

CI/CD 管道與部署策略

設計將建置、測試和部署階段分開的管道，並讓回滾決策自動化。AWS CodePipeline、CodeBuild 和 CodeDeploy 為從原始碼到生產環境的流程提供了一條完全託管的路徑，而第三方系統 (GitHub Actions、Jenkins、GitLab) 則與 AWS 服務整合，用於產物儲存 (S3)、容器登錄 (ECR) 和部署掛鉤 (deployment hooks)。對於執行階段策略，有狀態 (stateful) 或有會話 (sessionful) 的服務應優先採用不可變部署或藍/綠部署，以消除就地組態偏移；使用金絲雀部署 (canary deployments) 搭配流量轉移 (traffic shifting) 來逐步降低風險。對於 Lambda，使用別名 (aliases) 和加權流量轉移，並搭配 CloudWatch 警報或 CodeDeploy 進行自動化回滾。對於 ECS/EKS，結合部署控制器 (CodeDeploy、AWS App Mesh 或原生 Kubernetes 策略) 與 ALB 目標群組的流量排除 (draining) 和生命週期掛鉤 (lifecycle hooks)，以確保優雅關閉 (graceful shutdown)。注意資料庫結構描述 (schema) 的變更：設計向後相容的遷移，並使用功能旗標 (feature flags) (AWS AppConfig) 或暗啟動 (dark launches) 來將程式碼的推出與結構描述的演進解耦。成本與速度的考量很重要：金絲雀部署會減慢推出速度但能最小化爆炸半徑 (blast radius)，而平行的藍/綠部署則會在轉換期間使基礎設施成本加倍。務必將部署政策、健康狀態檢查和自動回滾納入管道中，以避免在事件發生時需要手動介入。

自動化、組態合規性與可觀測性

卓越營運取決於自動化修復、一致的組態和全面的可觀測性。AWS Systems Manager 提供用於組態的 Parameter Store、用於執行手冊 (runbooks) 的 Automation 文件、用於基準維護的 Patch Manager，以及用於無堡壘機 (bastionless) 故障排除的 Session Manager。使用 EventBridge 作為解耦自動化的中央事件匯流排——將 CloudTrail、Config 或應用程式事件路由到 Lambda 或 Step Functions 進行協調式修復。使用 AWS Config 規則和 Config Aggregator 來強制執行防護機制 (guardrails) 並稽核多個帳戶，並透過 Systems Manager 或 EventBridge 為不合規的資源實作自動化修復劇本 (playbooks)。在可觀測性方面，使用 CloudWatch 指標和日誌來檢測 (instrument) 服務，啟用 X-Ray 或 AWS Distro for OpenTelemetry 進行分散式追蹤，並使用 CloudWatch Logs 訂閱或 Kinesis Firehose 將日誌集中到一個中央化的 S3 資料湖和分析堆疊中。常見的陷阱包括無限制的日誌保留期導致成本飆升、高基數 (high-cardinality) 的自訂指標導致指標成本暴增、缺少關聯 ID (correlation IDs) 使追蹤變得無用，以及未在非生產環境中測試修復執行手冊。權衡取捨圍繞在遙測 (telemetry) 的精細度與擷取和儲存成本之間；抽樣追蹤和較短的保留期可以降低成本，但可能會掩蓋罕見的關鍵故障。設計針對可操作信號的警報和儀表板，以保持營運開銷在可控範圍內。

效能、有狀態服務、安全性與跨區域考量

根據存取模式、延遲需求和一致性要求來選擇有狀態服務與儲存服務。記憶體內快取 (In-memory caches) 提供亞毫秒級的讀取；ElastiCache (Redis) 支援有序集合 (ordered sets)，非常適合排行榜 (leaderboards) 這類應用，並提供複寫 (replication)、持久性 (persistence) 以及用於跨區域讀取本地性 (read locality) 的 Global Datastore。DynamoDB 非常適合大規模、持久化的儲存，且可與 DAX 搭配以加速讀取，不過 DAX 最適用於可快取的項目級 (item-level) 存取，且有效能上的最終一致性 (eventual consistency) 取捨。對於基於檔案的舊有應用程式，可考慮使用 Amazon FSx for NetApp ONTAP 或 Amazon EFS 搭配 DataSync 以達成直接遷移 (lift-and-shift) 的相容性；若需要 SMB/NFS 語意，FSx 通常是風險最低的選項。加密和複寫存在一些細微的陷阱：AWS KMS 金鑰是區域性的 (regional)，對於跨區域的 S3 複寫，必須按區域管理，或者使用多區域金鑰 (multi‑Region keys) 來簡化存取模式；請小心處理金鑰政策 (key policies) 和跨帳戶授權。在 VPC 中的 Lambda 會因 ENI 的建立而遭受冷啟動 (cold-starts) 之苦——可透過 VPC 端點 (VPC endpoints)、較小的套件大小、預置並行 (provisioned concurrency) 或在 VPC 外使用 Lambda 搭配 RDS Proxy 來緩解此問題。權衡成本與彈性：Global tables 和跨區域複寫能改善 RTO/RPO，但成本會增加；預置並行能減少延遲，但會提高基礎支出。在選擇架構時，請考量資料持久性需求、災難復原 (DR) 時間表以及每個帳戶的資源限制。

實務問題：使用案例情境

情境：SkyForge Games 公司在兩個區域營運現有的 AWS 環境，其中包含生產和預備 (staging) 帳戶。目前的排行榜是透過 DynamoDB 實作，並由經 CodePipeline 部署的 Lambda API 提供服務；玩家期望在頻繁的功能發布期間，能有微秒級的讀取延遲和近乎零的停機時間。

挑戰：提供微秒級的排行榜讀取效能，同時維持持久性，並建立一個安全的自動化 CI/CD 管線，以支援跨帳戶和區域的快速、可回滾的部署。

建議方法：

在主要區域為排行榜的熱路徑 (hot-path) 佈建一個啟用叢集模式 (Cluster Mode Enabled) 的 ElastiCache for Redis，並在多個 AZ 之間設定複本 (replicas)，同時啟用 Redis 持久性 (AOF)；在次要區域設定 Global Datastore 以提供讀取本地性。
將 DynamoDB 作為資料的真實來源 (source of truth)；使用 DynamoDB Streams + Lambda (或 Kinesis Data Streams) 以非同步方式更新 Redis，確保最終一致性以及用於復原的可重放性 (replayability)。
實作一個基於 CDK 的管線 (CDK Pipelines 或由 Git 觸發的 CodePipeline)，該管線能合成範本、將產出物 (artifacts) 建置到加密的 S3/ECR 中，並透過 CloudFormation StackSets 將基礎設施 (infra) 部署到目標帳戶/區域；納入自動化的煙霧測試 (smoke tests) 和核准閘門 (approval gates)。
使用金絲雀/藍綠 (canary/blue-green) 策略部署應用程式變更：使用加權的 Lambda 別名 (aliases) 或 ALB 目標群組切換，搭配 CloudWatch 警報和自動回滾；使用 CloudWatch、X-Ray 和綜合性的金絲雀檢查 (synthetic canary checks) 進行檢測 (instrument)。

理由：使用 Redis 以實現真正的亞毫秒級讀取，同時保留 DynamoDB 的持久性和可重放性；使用 CDK 和 StackSets 的 CI/CD 提供了一致、可稽核的多帳戶部署，而流量轉移加上可觀測性 (observability) 則能實現具備快速回滾能力的安全迭代發布。

← 成本優化與治理 · 所有領域

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