CI/CD Pipeline 與 IaC 部署策略

CI/CD pipeline 與基礎設施即程式碼（IaC）部署策略，在 SAP-C02 中位於可靠性、安全性與速度三者的交叉點。每道題目只要出現「公司必須以最短停機時間部署新版本」、「將基準配置推送至 40 個帳號」，或「錯誤率飆升時自動回滾」，本質上都是在考部署策略。在 Professional 等級，AWS 期望你選出正確的部署模式、正確的 IaC 工作單元，以及正確的多帳號分發機制——並且清楚知道每種選擇的失敗模式。

本指南假設你已具備 Associate 等級的基礎知識：CloudFormation stack 是什麼、CodeBuild 做什麼、Lambda function alias 是什麼。它聚焦在 Pro 等級的決策：StackSets vs 巢狀 stacks vs CDK Pipelines、CodeDeploy canary vs linear vs all-at-once、ECS blue/green 機制、Lambda alias-based 流量切換、AppConfig feature flags、Service Catalog 受管自助服務，以及何時該用 Terraform。目標是讓 SAP-C02 每一道部署策略題都變成 30 秒的快速辨識，而非 3 分鐘的逐項排除。

為什麼部署策略在 SAP-C02 如此重要

在 Professional 等級，AWS 幾乎不問「CloudFormation 是什麼」，而是問：「團隊有 20 個 AWS 帳號，組織層級的 IAM 基準必須可部署、可稽核、且能偵測 drift——你會組合哪些服務？」這道題同時牽涉 AWS Organizations、CloudFormation StackSets 服務管理權限、委派管理員、drift detection、change sets，以及 CodePipeline 的核准動作。少掌握任何一個環節，就會選到技術上可行但在維運上較差的答案。

考試也喜歡讓部署選項彼此對立：all-at-once vs rolling vs blue/green vs canary、CloudFormation vs CDK vs SAM vs Terraform、StackSets 服務管理 vs 自管理、CodeDeploy ECS blue/green vs rolling、Lambda canary vs linear vs all-at-once、AppConfig vs 環境變數作為 feature flag、Service Catalog vs 直接 CloudFormation 權限給開發者。最快的應對方式，就是把每個工具的最佳使用場景及其特定失敗模式背得滾瓜爛熟。

白話文解釋 CI/CD and IaC Deployment

部署策略是一個機制看起來相似、但後果卻大相逕庭的主題。以下三個來自不同領域的類比，能讓各種取捨清晰易記。

類比一：便利商店新品上架

把一家 24 小時連鎖便利商店的新品上架流程想像成部署。All-at-once 部署是在最忙碌的午餐尖峰，把所有貨架一口氣換成新品——如果新款飯糰口味有問題，所有顧客同時踩雷。Rolling 部署是一次換一個貨架，其餘繼續賣舊品——每個時段只有少數顧客受影響，但整體轉換時間拉長。Blue/green 是最謹慎的做法：你在旁邊架設一個全新的陳列區，擺好新品試賣幾個品項，確認沒問題後，讓門市人員把所有顧客導引到新陳列區，舊陳列區則完成現有訂單後關閉。如果新品大翻車，門市立刻開回舊陳列區——不會有任何浪費。Canary 部署是先讓前 10% 的顧客試吃新飯糰，觀察 10 分鐘的反應，再逐步擴大到接下來的 20%，依此類推。Linear 是同樣的概念，但以固定節奏推進（每 10 分鐘增加 10%，不管回饋如何）。

CloudFormation 是店長手冊上的標準作業流程——宣告式、版本控制、冪等；同一套 SOP，得到同樣的結果。CDK 是能讀懂你的需求草稿並自動寫出完整 SOP 的資深主管——你說「幫我規劃一個可服務 200 人的早餐菜單」，他把完整流程整理出來。SAM 是專門給鮮食部門用的 SOP 格式——針對生鮮快取商品最佳化，比 CloudFormation 更精簡。Terraform 是能跨品牌使用的通用 SOP 格式——你的門市（AWS）、隔壁的咖啡廳（Azure）、樓下的麵館（GCP）都能用同一套。StackSets 是把你的 SOP 一次加盟授權給 40 家門市，並派遣督導（drift detection）定期巡店，確保沒有門市偷偷改配方。

類比二：航空公司機隊升級

航空公司汰換客艙設備的情境，能讓你用高風險場景直覺感受部署策略的差異。All-at-once 是週六深夜讓全機隊停飛、週一早上前全部改裝完畢——最快、風險最高。Rolling 是每週改裝一架，其餘繼續飛——每一步的爆炸半徑小，但整體推進耗時一季。Blue/green 是買一批新飛機，停在第二候機廊橋，空機試飛後，在切換日把所有新班次分配到新機隊，舊機隊完成既有排班後退役。如果新機娛樂系統當機，一小時內重啟舊機隊服務。Canary 是挑五架塗裝新塗裝的飛機載正常旅客，觀察一週的評價，評價良好才再擴展到二十架。Linear 是排程版本——每週五固定增加五架，不管評價如何。

AWS CodeDeploy 扮演航班調度員的角色：決定哪些飛機（或 ECS tasks、Lambda 版本）上有旅客。CloudWatch alarms 是接到調度員指令的安全感測器；一旦偵測到異常（錯誤率攀升、p99 延遲超標），調度員自動中止剩餘換裝程序，把旅客導回舊機隊。CodePipeline 是地勤排班系統，將整個工作流程串接起來：從倉庫領取零件（source）、在機棚組裝（build）、進行地面測試（test）、協調調度員（deploy）、通知機組人員（notify）。具備核准動作的多帳號 CodePipeline 是航空公司董事會——生產部署必須取得副總裁簽核，調度員才能放行旅客登機。

類比三：醫院新術式導入

醫院在引進新手術術式時採用的分段推行機制，與部署策略幾乎完美對應。All-at-once 是一夜之間讓所有手術室全面改用新術式——在真實醫療場景中絕對不可能這樣做。Rolling 是每個月訓練一位外科醫師；風險隨時間分散。Blue/green 是先在模擬手術室（staging 環境）練到熟練，再開設一間設備完整的第二手術室（green 環境）進行新術式，新排刀安排在此；若第一台手術出現意外，醫院立刻回到舊手術室——完全不需要重新排程。Canary 是倫理委員會核准的試驗：先做前十位病患，觀察兩週的術後成效，情況穩定才擴展到下一批一百位。Linear 是標準化推進——每月增加 10%，持續十個月。

Change sets 是術前確認清單——CloudFormation 在你動刀前告訴你「這次更新將取代 RDS 執行個體」；你可以喊停。Drift detection 是術後稽核——有人在正式流程之外偷偷更換了設備嗎？AppConfig feature flags 是每間手術室的獨立開關——你可以在不重新部署整間醫院的情況下，瞬間關閉新麻醉方案。Service Catalog 是核准術式手冊——外科醫師從通過審查的術式列表中自助挑選，而不是自己發明新做法。

部署策略選擇——All-at-Once、Rolling、Blue/Green、Canary、Linear

在討論 IaC 工具之前，先選定流量切換模式。SAP-C02 的題目幾乎都會暗示一個線索：「零停機」、「快速回滾」、「漸進流量轉移」、「成本敏感的開發環境」。把線索對應到正確策略。

All-at-once（原地全量部署）

• 模式：停止所有主機上的舊版本，將新版本部署到同一批主機，啟動新版本。
• 停機時間：有，時間等於停止-部署-啟動的週期。
• 回滾速度：慢——需要再執行一次部署才能還原。
• 成本：最低（無需複製機隊）。
• 使用場景：開發/測試環境、非客戶端的批次作業、可接受維護視窗的環境。
• CodeDeploy 組態：CodeDeployDefault.AllAtOnce（EC2/on-prem）或 CodeDeployDefault.LambdaAllAtOnce / CodeDeployDefault.ECSAllAtOnce。

Rolling（原地分批部署）

• 模式：分波次替換執行個體或 tasks。常見波次：一次一個（OneAtATime）、一次一半（HalfAtATime）、自訂百分比。
• 停機時間：每個執行個體幾乎無停機；推進期間整體吞吐量略降。
• 回滾速度：慢——需要以舊版本向前部署。
• 成本：與原地部署相同（無需複製機隊）。
• 使用場景：EC2 Auto Scaling groups、具有足夠容量餘裕的 ECS 服務、內部工具。
• CodeDeploy 組態：CodeDeployDefault.OneAtATime、CodeDeployDefault.HalfAtATime。

Blue/Green

• 模式：佈建平行的「green」機隊，在此部署新版本，透過 ELB 監聽器交換或 Route 53 加權記錄切換流量，排乾後退役「blue」。
• 停機時間：切換為原子操作時為零。
• 回滾速度：極快——將監聽器切回 blue；blue 仍處於熱機狀態。
• 成本：切換期間較高（兩套完整機隊同時運行）。
• 使用場景：面向客戶的生產環境、原地升級有風險的有狀態工作負載、ELB 後方的 ECS 服務與 EC2。
• AWS 服務：CodeDeploy ECS blue/green、CodeDeploy EC2 blue/green（搭配 Auto Scaling）、Elastic Beanstalk 環境 URL 交換。

Canary

• 模式：將一小部分流量（通常 10%）切換至新版本，經過一段觀察期後再切換其餘流量。
• 停機時間：零。
• 回滾速度：快——幾秒內將流量從 canary 切走。
• 成本：增量極低（只有小部分 canary 機隊需複製，Lambda 使用加權流量時甚至無需複製）。
• 使用場景：公開 API、Lambda functions、任何能透過 CloudWatch 警報偵測錯誤率回歸的場景。
• CodeDeploy 組態：CodeDeployDefault.LambdaCanary10Percent5Minutes、LambdaCanary10Percent10Minutes、LambdaCanary10Percent15Minutes、LambdaCanary10Percent30Minutes。

Linear

• 模式：按固定排程以相等增量移轉流量（例如每分鐘增加 10%）。
• 停機時間：零。
• 回滾速度：推進期間快；完成後需重新部署才能還原。
• 成本：低。
• 使用場景：希望平滑推進而非突然跳躍時；適合遙測延遲已知的場景。
• CodeDeploy 組態：CodeDeployDefault.LambdaLinear10PercentEvery1Minute、LambdaLinear10PercentEvery2Minutes、LambdaLinear10PercentEvery3Minutes、LambdaLinear10PercentEvery10Minutes。

自訂部署組態

對於 EC2/on-prem（非 Lambda、非 ECS），你可以建立自訂部署組態，指定最小健康主機數（百分比或絕對數量）。對 Lambda 和 ECS，則可使用上述內建的 canary 和 linear 變體——自訂 ECS blue/green 流量切換可透過 appspec Hooks 和自訂 CodeDeploy 組態支援。

CloudFormation Pro 深度——Stacks、Nested Stacks、Cross-Stack References

CloudFormation 是 AWS 原生的 IaC 骨幹。SAP-C02 中凡是說「使用 IaC」的答案，除非明確點名 Terraform，否則本質上都是 CloudFormation 或 CDK 的答案。

Stack 組織模式

你可以把整個架構塞進一個巨型 stack，但在 Pro 規模下這會出問題：

• 爆炸半徑：一次失敗的更新會回滾整個 stack。
• 變更頻率不一致：VPC 一年改一次，Lambda 每天改；單一 stack 強迫它們使用相同的節奏。
• 所有權：網路團隊負責 VPC，應用團隊負責 Lambda；同一個 stack 造成所有權混淆。
• 服務限制：每個 stack 最多 500 個資源（軟性限制，可申請調高）、200 個參數/輸出/映射。

AWS 的標準做法是依變更頻率和所有權拆分：基礎 stacks（VPC、IAM roles、共用 KMS keys）、平台 stacks（ECS cluster、EKS cluster）、應用 stacks（services、Lambdas）。再透過巢狀 stacks 或跨 stack 參照將它們串接。

巢狀 stacks

巢狀 stack 是一個 AWS::CloudFormation::Stack 資源，其 TemplateURL 指向 S3 中的子範本。父 stack 的生命週期管理所有子 stack 的建立、更新與刪除。

• 優點：單一生命週期——更新父 stack，所有子 stack 以一次交易完成更新；失敗時一起回滾。
• 優點：可重複使用的模組——將同一份子範本帶入不同父 stack，搭配不同參數。
• 缺點：緊耦合——無法在不經過父 stack 的情況下獨立更新子 stack。
• 缺點：當許多子 stack 彼此參照時，範本規模可能急遽膨脹。
• 適用場景：VPC 模組 + 子網路模組 + 安全群組模組作為同一應用 stack 的兄弟子項目。

跨 stack 參照

跨 stack 參照使用一個 stack Outputs 區段的 Export，以及另一個 stack 的 Fn::ImportValue，在 stack 邊界之間共享值。

• 優點：鬆耦合——各 stack 擁有獨立的生命週期與所有者。
• 優點：清晰的契約——export 名稱就是契約。
• 缺點：匯出 stack 在匯入者存在期間無法刪除或重新命名 export（你會收到相依性錯誤）。這是著名的 Day-2 痛點：必須先刪除匯入者，再更新匯出者。
• 缺點：僅限同帳號同區域——跨 stack 參照無法跨帳號或區域。如需跨帳號共享，請使用 SSM Parameter Store 或透過 CDK Pipelines context 傳遞值。
• 適用場景：VPC stack 匯出子網路 ID，多個獨立應用 stack 匯入使用。

選擇巢狀 stacks vs 跨 stack 參照 vs 單一大型 stack

Change sets

Change set 在執行前預覽 CloudFormation 將套用的資源層級差異。關鍵特性：

• 列出每個被新增、修改、移除或取代的資源（取代代表銷毀並重新建立——可能造成停機）。
• 可由人工或程式化方式審查（CodePipeline 有 CloudFormationCreateReplaceChangeSet + CloudFormationExecuteChangeSet 動作拆分，這是 Pro pipeline 的標準模式）。
• 生產 pipeline 必備：絕對不直接更新 stack；一律透過 change set 加核准閘門。

Drift detection 與補救

Drift 是 stack 預期的範本狀態與實際存活資源之間的任何偏差。例如：有人手動編輯了安全群組規則、有人刪除了 IAM 政策附加、某個外部腳本更改了 S3 bucket 的版本控制設定。

CloudFormation drift detection：

• 隨選觸發：呼叫 DetectStackDrift（單 stack）或 DetectStackSetDrift（整個 stack set）取得快照。
• Stack set 定期掃描：StackSets 支援透過 EventBridge 排程規則或 AWS Config 規則（cloudformation-stack-drift-detection-check）執行週期性 drift detection。
• 補救路徑：(a) 手動或透過 Systems Manager Automation runbook 將資源恢復到範本期望狀態；(b) 更新範本以反映新的目標狀態後重新部署；(c) 透過循環 stack 替換已 drift 的資源。

Drift detection 不會自動補救。Pro 規模的完整模式是：drift detection → EventBridge 事件 → Lambda 或 SSM runbook，針對「已知安全的 drift」（如新增安全群組規則）自動補救，或針對「未知 drift」通知資安維運人員。

StackSets 大規模使用——自管理 vs 服務管理

CloudFormation StackSets 是多帳號、多區域的分發層。兩種權限模型：

• 自管理權限（Self-managed）：你在管理員帳號預先建立 AWSCloudFormationStackSetAdministrationRole，並在每個目標帳號建立 AWSCloudFormationStackSetExecutionRole。以帳號 ID 為目標。適用於組織未使用 AWS Organizations，或目標帳號位於組織外部的情境。
• 服務管理權限（Service-managed）：AWS 為你建立服務連結角色。以 OU 為目標。加入 OU 的新帳號透過自動部署自動收到 stack。這幾乎是 SAP-C02 組織範圍部署的標準答案。

每次 StackSet 操作的管控參數：

• 最大並發帳號數（數量或百分比）——同時部署的帳號數。
• 失敗容許度（數量或百分比）——在暫停前允許的失敗數。
• 區域順序——明確的列表；跨區域依序推進，同一區域內跨帳號平行。
• 每個 stack instance 的參數與標籤覆寫——帳號或區域可在不更改範本的情況下覆寫值。
• 離開 OU 時的刪除行為——當帳號離開 OU 時，保留或刪除 stack instance。

委派管理員模式在此很重要：從管理帳號指定一個成員帳號（通常是 Shared Services 或 Deployments 帳號）作為 StackSets 的委派管理員；日常操作便可在管理帳號之外進行。SAP-C02 幾乎不接受讓日常工作在管理帳號執行 StackSets 的答案。

標準模式：20 個帳號、組織層級基準、可部署 + 可稽核 + 可偵測 drift

這是 SAP-C02 最愛出的情境。正確架構如下：

1. 啟用所有功能的 AWS Organizations，OU 按政策對齊（Security、Infrastructure、Workloads/Prod、Workloads/Non-Prod、Sandbox）。
2. 已加入 AWS Control Tower 的 Security OU 基準（Log Archive、Audit、CloudTrail、Config）。
3. 在 Shared Services / Deployments 帳號設定 CloudFormation StackSets 的委派管理員。
4. **CodeCommit（或透過 connection 連接的 GitHub）**儲存基準範本，透過 pull request 進行同儕審查。
5. Deployments 帳號的 CodePipeline：source → build/lint（CodeBuild + cfn-lint + cfn-nag）→ 在 StackSet 上建立 change set → 人工核准 → 執行 StackSet 操作，以服務管理權限並啟用自動部署，針對特定 OU 推進。
6. 每個帳號和區域的 Stack instance 隨即佈建；加入 OU 的新帳號在第一天自動加入。
7. Drift detection 透過 EventBridge 每 24 小時排程一次對 StackSet；drift 事件流入 Security Hub 並透過 SNS 通知資安維運人員。
8. AWS Config 規則（cloudformation-stack-drift-detection-check、cloudformation-stack-notification-check）在偵測層補強相同的安全態勢。
9. Root 層級 SCP 拒絕對基準 stack 名稱模式執行 cloudformation:DeleteStack 和 cloudformation:UpdateStack，除非 principal 是 CodePipeline 執行角色——這讓開發者無法篡改。
10. CloudTrail 組織 trail（已由 Control Tower 啟用）記錄每一次 StackSet 操作；稽核人員透過 Athena 審查。

這個架構讓你具備可部署（一條 pipeline 同時推送基準到 20 個帳號）、可稽核（CloudTrail + change set 差異 + 核准簽名），以及可偵測 drift（CloudFormation + Config + EventBridge）。任何 SAP-C02 答案只要重用這個骨架，幾乎都是正確的。

AWS CDK——L1、L2、L3 Constructs 與 CDK Pipelines

AWS Cloud Development Kit（CDK）是程式化的 IaC 層，能從 TypeScript、Python、Java、C# 或 Go 程式碼合成 CloudFormation 範本。CDK 已成為 AWS 推薦的新工作負載撰寫體驗；SAP-C02 期望你識別出何時 CDK 是正確答案。

CDK 存在的理由

CloudFormation 是宣告式 YAML/JSON。在規模化時會遇到：

• 冗長——一個簡單的「Lambda 搭配 IAM role、log group 和 X-Ray 追蹤」需要幾十行。
• 重複——相同的 IAM 樣板複製貼上到每個範本。
• 脆弱——參數和映射取代了真正的程式設計（無迴圈、條件式薄弱）。

CDK 以 constructs 取代範本——可組合的程式語言類別，在部署時合成為 CloudFormation。

Construct 等級——L1、L2、L3

• *L1（Cfn constructs）**：與 CloudFormation 資源一對一對應。CfnFunction、CfnBucket、CfnTable。你能精確控制 CloudFormation 暴露的每個屬性。當你需要精細控制，或某個新 AWS 功能尚未抽象到 L2 時使用 L1。
• L2（精選 constructs）：具有合理預設和更高層級輔助工具的固執包裝。lambda.Function 自動建立 IAM role 和 log group，s3.Bucket 預設設定加密並封鎖公開存取。L2 是日常 CDK 程式碼的主體。
• L3（模式）：解決端到端使用案例的多資源模式。aws-ecs-patterns.ApplicationLoadBalancedFargateService 用一行程式碼建立 VPC、ECS cluster、Fargate service、ALB、安全群組、log groups 和 IAM roles。L3 constructs 內建 AWS 最佳實踐架構，是最快出貨的方式。

SAP-C02 期望你區分 L1（原始控制力、更多樣板）、L2（合理預設）、L3（整套模式）。情境說「團隊希望用最少的程式碼部署生產等級的 Fargate web 應用」，就指向 L3 模式。

環境、Bootstrapping 與 context

CDK 部署到環境（帳號 + 區域的組合）。部署前，每個帳號-區域需執行一次 cdk bootstrap aws://ACCOUNT/REGION——這會佈建一個 bootstrap stack，包含：

• 放置範本資產和 Lambda 程式碼 zip 的 S3 bucket。
• 放置容器映像資產的 ECR 儲存庫。
• CDK Toolkit 在部署期間承擔的 IAM roles（cfn-exec、deploy、lookup、publish-file、publish-image）。

Bootstrapping 是 SAP-C02 中最容易被忽略的操作步驟；「CDK 部署失敗，出現 bucket not found 錯誤」的答案，通常都指向缺少 bootstrap。

CDK Pipelines——自我變更的 CI/CD

CDK Pipelines（aws-cdk-lib.pipelines）是一個 construct 程式庫，定義一個 CodePipeline，其第一個階段是「建構並更新 pipeline 本身」，之後是每個環境的 build+synth+deploy 階段。特性：

• 自我變更（Self-mutating）：當你在程式碼中新增一個階段並推送，pipeline 會先更新自身以包含新階段，然後執行新階段。無需手動編輯 pipeline。
• 多帳號：每個階段可以針對不同的 AWS 帳號（透過跨帳號 CDK bootstrap roles）；適用於 dev→staging→prod 的晉升流程。
• 安全預設：工件 bucket 以 KMS 加密，roles 遵循最小權限，secrets 從 Secrets Manager 或 SSM Parameter Store 讀取。
• Waves：wave 中的平行階段可同時部署到多個區域或帳號。

當 SAP-C02 問「團隊希望有一條 pipeline，能在 dev、staging、prod 帳號之間晉升應用程式，且無需人工維護 pipeline」，CDK Pipelines 是標準答案。

CDK vs SAM vs CloudFormation——決策依據

AWS SAM 與 Serverless Application Repository

**AWS Serverless Application Model（SAM）**是專為無伺服器工作負載特化的 CloudFormation 擴充。

SAM 簡介

• 範本：使用 Transform: AWS::Serverless-2016-10-31 的 YAML。速記資源（AWS::Serverless::Function、AWS::Serverless::Api、AWS::Serverless::StateMachine、AWS::Serverless::HttpApi、AWS::Serverless::LayerVersion）在部署時展開為底層 CloudFormation。
• SAM CLI：sam build 打包 function 程式碼，sam deploy 包裝 aws cloudformation deploy，sam local invoke 在 Docker 容器中針對本地事件執行 function，sam local start-api 執行本地 HTTP 模擬器。
• 漸進式部署：AWS::Serverless::Function 上的 DeploymentPreference 屬性，將 CodeDeploy application + deployment group 與 pre-traffic Lambda hook、post-traffic Lambda hook，以及自動回滾的 CloudWatch 警報列表串接起來。設定 Type: Canary10Percent10Minutes 或 Linear10PercentEvery2Minutes，即可開箱即用地取得 alias-based 流量切換。
• Policy templates：預建的 IAM 政策捷徑（DynamoDBCrudPolicy、S3ReadPolicy、SQSSendMessagePolicy）減少 IAM 撰寫工作。

SAM 相較於 CloudFormation 的獨特價值：無伺服器友好的速記 + 本地開發 + 內建 CodeDeploy canary 串接。相較於 CDK 的獨特價值：更少的移動部件，無合成步驟，pipeline 中不需要程式語言執行時期。

Serverless Application Repository（SAR）

AWS Serverless Application Repository 是用於發布和探索 SAM 應用程式的受管儲存庫。使用案例：

• 組織內部重複使用——平台團隊發布一個部署標準日誌 Lambda + SQS DLQ 模式的 SAM app；每個應用團隊用幾個參數部署一份副本。
• 公開重複使用——AWS 發布參考應用程式（警報處理器、Slack 通知器、CSV 轉 DynamoDB 載入器），你可以兩次點擊部署到自己的帳號。
• 分發——廠商打包他們的無伺服器整合，客戶訂閱。

SAR 應用程式透過 AWS::Serverless::Application 資源部署，該資源參照應用程式 ARN 和 semver 版本。發布的範本存放在 SAR 的受管儲存空間；當你部署時，SAR 在你的帳號中合成一個巢狀 CloudFormation stack。

AWS CodePipeline——多帳號與多區域部署

CodePipeline 是將 source、build、test 和 deploy 動作串接成具有多個階段的 pipeline 的協調層。在 Professional 規模，有趣的形狀是多帳號、多區域——這是大多數真實企業的運行方式。

跨帳號動作模式

標準的跨帳號 CodePipeline 具備：

• Pipeline 帳號（通常是 Deployments 帳號）：承載 CodePipeline、CodeBuild 和工件 S3 bucket。
• 目標帳號（dev、staging、prod）：承載實際被部署的資源。
• Pipeline 帳號中的工件 bucket 以客戶自管 KMS key 加密；key 政策授予目標帳號 IAM roles 解密權限。
• 每個目標帳號有一個 pipeline 執行角色（例如 CodePipelineCrossAccountRole），其信任政策信任 pipeline 帳號的 CodePipeline 服務角色，並附帶 external ID 條件。
• 針對遠端帳號的 pipeline 階段，在動作的 RoleArn 欄位使用此角色以承擔目標帳號角色。

關鍵啟用因素：

• 工件 bucket KMS key 必須允許目標帳號 principals（或透過 aws:PrincipalOrgID 允許組織中的任何人）使用 kms:Decrypt 和 kms:GenerateDataKey。
• 工件 bucket 的 S3 bucket policy 必須允許目標帳號執行 s3:GetObject / s3:GetObjectVersion。
• 跨帳號目標階段的 CloudFormation deploy 動作 必須包含 DeploymentRoleArn（CloudFormation 在目標帳號中承擔的角色）——這與 pipeline 動作的 RoleArn 是不同的角色。

多區域考量

CodePipeline pipeline 是區域性的；支援跨區域動作，但需要在 pipeline 跨越的每個區域各有一個工件 bucket。當 pipeline 階段針對另一個區域時，CodePipeline 將工件複製到區域 bucket，然後在該處執行動作。

Pro 模式：

• 區域扇出：使用單一 pipeline，在 us-east-1、eu-west-1、ap-northeast-1 各有平行動作——每個動作部署相同的範本或映像。
• 區域排序：對於漸進式區域推進（先區域 A，A 健康後再 B），串接依序的階段，並以 CloudWatch 指標檢查閘控每個階段。
• 控制平面 vs 資料平面：在區域 1 部署後加入核准，不要等警報轉綠就自動推進到區域 2。

Source 動作選項

• CodeCommit（原生 AWS Git）。
• GitHub / GitLab / Bitbucket Cloud 透過 AWS CodeStar Connections——目前推薦的第三方 Git 機制（取代舊的 GitHub 動作）。
• S3 object——放在 S3 的壓縮包。
• ECR image——新推送的容器映像。
• AWS CodeArtifact package——新的 NPM/PyPI/Maven 套件版本。

與部署策略相關的動作提供者

• CloudFormation — CREATE_UPDATE、DELETE_ONLY、CHANGE_SET_REPLACE、CHANGE_SET_EXECUTE、REPLACE_ON_FAILURE。Pro pipelines 一律將 CHANGE_SET_REPLACE + 核准 + CHANGE_SET_EXECUTE 拆開。
• CloudFormation StackSets — 建立或更新 stack set，建立針對特定 OU 的 stack instances。
• CodeDeploy — 呼叫 EC2/on-prem 或 Lambda 或 ECS CodeDeploy 部署。
• CodeBuild — 執行建構（測試、linting、安全掃描）。
• Manual approval — 暫停 pipeline 等待人工簽核；支援 SNS 通知和審查者留言。
• Lambda invoke — 自訂部署前或部署後邏輯（資料庫遷移、煙霧測試、整合呼叫）。
• Step Functions invoke — 長時間執行或複雜的協調流程。
• Service Catalog — 部署一個產品。

AWS CodeDeploy——深入部署組態

CodeDeploy 是 AWS 針對 EC2/on-prem 執行個體、Lambda functions 和 ECS 服務的部署引擎。**部署組態（Deployment configuration）**是管控部署期間流量或執行個體如何移轉的策略。

EC2 / on-premises 部署組態

適用於 EC2 執行個體或安裝 CodeDeploy agent 的 on-prem 伺服器上的原地和 blue/green 部署。

• CodeDeployDefault.AllAtOnce — 同時更新所有執行個體。快速、高風險、低成本。僅限開發使用。
• CodeDeployDefault.HalfAtATime — 分波次更新一半，需機隊規模 ≥ 2。平衡速度與風險。
• CodeDeployDefault.OneAtATime — 每次更新一個執行個體。最慢但最安全，需機隊規模 ≥ 2。
• 自訂部署組態 — 你定義 MinimumHealthyHosts 為數量或百分比；CodeDeploy 確保部署期間至少有那麼多執行個體保持健康。

Lambda 部署組態

Lambda 部署從不原地執行；CodeDeploy 發布新 Lambda 版本並移轉 alias 流量。

• CodeDeployDefault.LambdaAllAtOnce — 立即切換 alias。開發使用。
• CodeDeployDefault.LambdaCanary10Percent5Minutes — 10% 流量觀察 5 分鐘，再切換至 100%。
• CodeDeployDefault.LambdaCanary10Percent10Minutes — 10% 觀察 10 分鐘，再切換。
• CodeDeployDefault.LambdaCanary10Percent15Minutes — 10% 觀察 15 分鐘，再切換。
• CodeDeployDefault.LambdaCanary10Percent30Minutes — 10% 觀察 30 分鐘，再切換。
• CodeDeployDefault.LambdaLinear10PercentEvery1Minute — 每 1 分鐘增加 10%（共約 10 分鐘）。
• CodeDeployDefault.LambdaLinear10PercentEvery2Minutes — 每 2 分鐘增加 10%。
• CodeDeployDefault.LambdaLinear10PercentEvery3Minutes — 每 3 分鐘增加 10%。
• CodeDeployDefault.LambdaLinear10PercentEvery10Minutes — 每 10 分鐘增加 10%（共約 100 分鐘）。

ECS 部署組態

透過 CodeDeploy 的 ECS 部署僅使用 blue/green——CodeDeploy 在 ALB/NLB 的測試監聽器後方佈建新的 task set，再移轉生產監聽器。

• CodeDeployDefault.ECSAllAtOnce — 測試流量驗證後立即將所有流量切至新 task set。
• CodeDeployDefault.ECSCanary10Percent5Minutes 到 ECSCanary10Percent15Minutes — 帶有指定觀察期的 canary。
• CodeDeployDefault.ECSLinear10PercentEvery1Minute 到 ECSLinear10PercentEvery3Minutes — Linear 推進。

自動回滾與警報

每個 CodeDeploy deployment group 都可以串接 CloudWatch 警報。屬性：

• Alarms：CloudWatch 警報列表；部署期間任何警報進入 ALARM 狀態，CodeDeploy 自動回滾。
• 自動回滾事件：DEPLOYMENT_FAILURE、DEPLOYMENT_STOP_ON_ALARM、DEPLOYMENT_STOP_ON_REQUEST。
• 生命週期 hooks：pre-traffic 和 post-traffic hooks 呼叫 Lambda functions 進行整合測試；hook 失敗觸發回滾。

Pro 模式：定義 p99Latency CloudWatch 警報和 Error5xxRate 警報；將兩者附加到每個 deployment group。對 Lambda，使用內建 CloudWatch 指標 Errors、Duration，以及透過 embedded metric format 發出的自訂應用指標。

Lambda Alias-Based Canary 與版本管理

Lambda 原生的版本控制和 alias 支援，是 CodeDeploy canary 部署的基礎。

Lambda 版本與 aliases

• Lambda function 版本：發布時 function 程式碼 + config + 環境變數的不可變快照。版本以數字標記（1、2、3...），$LATEST 是可變的工作副本。
• Lambda alias：指向特定版本的命名指標（prod → 7、staging → 8）。Aliases 可被呼叫（其 ARN 是穩定的），因此客戶端呼叫 alias ARN 而非版本 ARN。

Alias 流量切換

一個 alias 可以同時指向一或兩個版本，搭配 RoutingConfig 權重。範例：

alias: prod
FunctionVersion: 7  (主要，90% 的呼叫)
RoutingConfig:
  AdditionalVersionWeights:
    "8": 0.10  (10% 的呼叫路由至版本 8)

CodeDeploy 依部署排程（canary 或 linear）驅動這個 alias 流量切換。應用程式不知道有兩個版本；Lambda 服務處理每次呼叫的路由。

SAM vs 直接 CodeDeploy 串接

相同的 alias-canary 模式有三種撰寫風格：

• SAM — AutoPublishAlias: live + DeploymentPreference.Type: Canary10Percent10Minutes + DeploymentPreference.Alarms。最簡短。
• CDK — LambdaDeploymentGroup construct 搭配 deploymentConfig 和 alarms。CDK 資產的慣用做法。
• 直接 CloudFormation / CodeDeploy — AWS::CodeDeploy::Application、AWS::CodeDeploy::DeploymentGroup、AWS::Lambda::Alias。完全控制，最冗長。

Provisioned concurrency 與 aliases

Provisioned concurrency 分配給 alias（或特定版本）。當你執行 canary 時，舊版本（主要）和新版本（canary）都需要足夠的 provisioned concurrency 以避免流量切換期間的冷啟動。常見的 Pro 錯誤是在 alias 上佈建 concurrency（在 canary 模式下是分流的），卻未考慮 canary 百分比——canary 版本會冷啟動。修正方式：在 canary 開始前將 concurrency 佈建在即將推出的版本上，而非 alias 上。

AWS AppConfig——執行期 Feature Flags 與配置

部署策略不只是關於出貨程式碼——也關於在不部署程式碼的情況下出貨配置和 feature flags。AWS AppConfig 是這方面的受管服務。

核心元件

• Application：邏輯分組（例如「checkout-service」）。
• Environment：邏輯部署目標（例如「prod-us-east-1」、「staging-eu-west-1」）。環境可設定 CloudWatch 警報以自動回滾。
• Configuration profile：配置的單元——自由形式 JSON/YAML/文字、feature-flag profile（結構化 feature-flag JSON），或 hosted configuration。來源包含 AppConfig-hosted、SSM Parameter Store、S3 和 Systems Manager documents。
• Deployment strategy：管控推進的命名策略——AppConfig.AllAtOnce、AppConfig.Linear50PercentEvery30Seconds、AppConfig.Canary10Percent20Minutes，或自訂。
• Validator：可選的 Lambda 或 JSON Schema，在部署時驗證新配置。

部署流程

1. 操作員以新版本更新 configuration profile（feature flag 切換、閾值調整）。
2. 操作員以選定的部署策略開始部署到某個環境。
3. AppConfig 驗證配置（語法 + JSON Schema + 自訂 Lambda）。
4. AppConfig 依策略的推進節奏推出配置。
5. 客戶端（透過 AppConfig Agent sidecar 或 SDK）在下次輪詢間隔時拉取並套用新配置。
6. 如果環境的 CloudWatch 警報在部署期間進入 ALARM 狀態，AppConfig 內建回滾並還原。

為什麼選 AppConfig 而非環境變數

• 更改 Lambda 環境變數需要完整的部署和 alias 切換。
• 更改 ECS task definition 環境變數需要更新 task definition + service 部署。
• AppConfig 讓你在幾秒內更改行為 flag，無需部署，且具備與程式碼部署相同的回滾護欄。

Feature flags vs 配置

AppConfig 有一流的 feature flag profile 類型，具有結構化 flags（布林值、值、約束）。執行期 SDK 暴露 getFlag("newCheckoutFlow")，並有合理的預設值；UI 讓你按環境啟用/停用。當 SAP-C02 說「逐步為 10% 的使用者啟用新功能，並提供緊急關閉開關」，這個服務就是答案。

AWS Service Catalog——開發者的受管自助服務

當開發者需要自行建立資源，但組織需要護欄時，AWS Service Catalog 將 CloudFormation 範本包裝成版本化的、可啟動的產品，讓終端使用者透過受控的產品組合使用。

核心元件

• Product（產品）：代表可重複使用架構的版本化 CloudFormation 範本（例如「標準三層 web stack」、「附備份策略的 Aurora Postgres」）。
• Portfolio（產品組合）：共享給特定 IAM principals 或帳號的產品分組。
• Launch constraint（啟動約束）：Service Catalog 在啟動產品時承擔的 IAM role。終端使用者不需要 CloudFormation 權限——他們只需要啟動產品的權限，launch constraint role 負責佈建資源。
• Template constraint（範本約束）：限制終端使用者可選擇的參數值的規則（例如，執行個體類型必須來自允許清單）。
• TagOption library：受管的標籤鍵值允許清單；產品繼承 TagOptions，使所有已啟動的資源獲得一致的標籤。

多帳號模式

在多帳號組織中：

• Hub 帳號（通常是 Shared Services）：承載 portfolio 和 products。
• Spoke 帳號：透過 Service Catalog portfolio share 機制，或透過 AWS RAM 進行組織範圍共享，接收 portfolio 分享。
• Spoke 帳號的開發者從本地共享的 portfolio 啟動產品；使用 launch constraint role 在 spoke 帳號中啟動。
• 產品更新自動傳播到共享的 portfolios；spoke 管理員可看到新版本並套用到現有的已佈建產品。

Service Catalog vs 直接 CloudFormation 權限

SAP-C02 答案信號：「開發者應在不需廣泛 IAM 權限的情況下自助使用標準架構」→ Service Catalog。「平台團隊部署組織層級基準」→ StackSets。

AWS 上的 Terraform 考量

Terraform 不是 AWS 原生服務，但許多企業在 AWS 上大規模運行 Terraform。SAP-C02 偶爾會問 Terraform 如何與 AWS 原生 IaC 並存。

AWS 支援的整合點

• AWS Provider for Terraform：涵蓋幾乎每個 AWS 服務的標準 Terraform provider。由 HashiCorp 和 AWS 共同維護，版本化管理。
• AWS Cloud Control Provider：透過 Cloud Control API 提供 Terraform 對 CloudFormation 支援資源的存取——適用於 AWS Provider 尚未支援的資源。
• AWS Control Tower Account Factory for Terraform（AFT）：AWS 提供的基於 Terraform 的帳號自動佈建參考實作，搭配 Control Tower。使用每個帳號的 CodeCommit 儲存庫進行基準配置 + 全域自訂。
• Terraform Cloud / Terraform Enterprise 整合：CodePipeline 支援呼叫 Terraform Cloud 執行；私有模組登錄可參照 AWS 原生工件。

AWS 上的狀態管理

Terraform 在 Pro 規模需要遠端狀態：

• 狀態檔案使用 S3 backend，搭配 DynamoDB table 進行狀態鎖定（防止並發寫入）。
• 狀態 bucket 的 S3 bucket 版本控制，用於稽核和回滾。
• 靜態加密使用 KMS CMK。
• 每個環境使用獨立狀態檔案以限制爆炸半徑（dev、staging、prod 各自擁有）。

Terraform vs CloudFormation——Pro 等級的選擇

SAP-C02 通常偏好 CloudFormation/CDK 答案，除非情境明確提到現有的 Terraform 資產或多雲需求。當 Terraform 出現時，AFT 模式是 AWS 推薦的多帳號方式。

Systems Manager Automation 與變更管理

Pro 規模的部署策略也涵蓋作業變更——修補程式推進、配置基準、一次性 runbook 執行。AWS Systems Manager Automation 是處理這些的服務。

Automation documents（runbooks）

• AWS 受管 documents（數百個）：AWS-RestartEC2Instance、AWS-PatchInstanceWithRollback、AWS-EnableExplorer、AWSSupport-TroubleshootRDP 等。
• 自訂 documents：YAML 或 JSON 定義的步驟（aws:runCommand、aws:invokeLambdaFunction、aws:approve、aws:waitForAwsResourceProperty、aws:branch）。
• 多帳號、多區域 automation：runbooks 可以針對 Organizations OU，在一次執行中跨帳號和區域。

Patch Manager

• 每個 OS 和合規等級的Patch baselines 定義哪些修補程式獲批准。
• Patch groups 以標籤將 EC2 執行個體與它們遵循的 baseline 關聯。
• Maintenance windows 排程修補，遵守業務時間和維護核准。
• 組織範圍推進：Systems Manager Quick Setup + Patch Manager baselines 跨 OU 套用。

Change Manager

• Change templates 定義特定變更類型的審查工作流程和核准者。
• Change requests 是繫結到 runbook 的提案；核准者審查並核准或拒絕。
• Calendar 整合：防止在封鎖視窗期間進行變更。
• CloudTrail 可稽核性：每個步驟都有記錄。

SAP-C02 答案信號：「跨 40 個帳號進行可核准且可稽核的作業變更」→ Systems Manager Change Manager + Automation。「以合規報告排程整個機隊的 OS 修補」→ Patch Manager 搭配 maintenance windows。

情境模式——SAP-C02 中的 CI/CD 與 IaC

以下模式將考題描述對應到架構。

情境模式 1：「將組織層級基準部署到 20 個帳號，可稽核且可偵測 drift」

這是上面已詳細介紹的標準模式。摘要：

• AWS Organizations + Control Tower：提供 OU 結構和基準護欄。
• 服務管理權限的 CloudFormation StackSets：針對特定 OU，新帳號啟用自動部署。
• StackSets 的委派管理員設在 Deployments 帳號。
• CodePipeline：CHANGE_SET_REPLACE → 人工核准 → CHANGE_SET_EXECUTE 動作。
• Drift detection：透過排程 EventBridge 規則加上 AWS Config 規則 cloudformation-stack-drift-detection-check。
• Root 層級 SCP：拒絕篡改基準 stacks，但 pipeline role 除外。
• CloudTrail 組織 trail：稽核用途。

情境模式 2：「Lambda 必須在 p99 延遲回歸時自動回滾部署」

• 以 SAM AutoPublishAlias 或 CDK LambdaDeploymentGroup 發布新版本。
• CodeDeploy 部署組態 = CodeDeployDefault.LambdaCanary10Percent10Minutes。
• Lambda Duration p99 超過閾值的 CloudWatch 警報，以及 Errors 率警報。
• DeploymentPreference.Alarms 參照兩個警報。
• 警報觸發時，CodeDeploy 自動回滾 alias 權重。

情境模式 3：「ECS 服務零停機部署，搭配自動回滾」

• ECS service deploymentController = CODE_DEPLOY。
• ALB 有兩個監聽器（生產 + 測試）和兩個 target groups（blue + green）。
• CodeDeploy application + deployment group 搭配 ECSCanary10Percent5Minutes 或通過 hook 驗證後的 ECSAllAtOnce。
• Pre-traffic Lambda hook 對測試監聽器呼叫 /health；失敗則回滾。
• Post-traffic Lambda hook 執行整合測試；失敗則回滾。
• ALB 5xx、target group 健康主機數的 CloudWatch 警報。

情境模式 4：「具備治理的開發者自助服務」

• Shared Services 帳號中的 AWS Service Catalog hub。
• 透過原生 share 機制將 portfolio 共享至工作負載 OU。
• Launch constraint role 代表開發者在 spoke 帳號中佈建資源。
• Template constraints 限制執行個體類型、區域、AZ。
• TagOption library 強制必要標籤。
• 開發者從 Service Catalog 主控台，或透過 CloudFormation AWS::ServiceCatalog::CloudFormationProvisionedProduct 呼叫。

情境模式 5：「帶有緊急關閉開關的 feature flag 推進」

• AWS AppConfig application + environment + feature-flag profile。
• AppConfig deployment strategy = AppConfig.Linear50PercentEvery30Seconds。
• 業務指標的環境警報（例如轉換率）。
• 應用程式使用 AppConfig Agent Lambda extension 以零延遲取得配置。
• 緊急關閉：操作員將 flag 切換為 false 並啟動部署——幾秒內全面生效。

情境模式 6：「多帳號 CodePipeline——dev → staging → prod」

• Pipeline 帳號：承載 CodePipeline、CodeBuild、附客戶自管 KMS key 的工件 S3。
• Dev / staging / prod 帳號：各有一個信任 pipeline CodePipeline 服務角色的 CloudFormation 部署角色。
• KMS key policy 允許每個目標帳號角色解密。
• S3 bucket policy 允許目標帳號角色使用 s3:GetObject。
• Pipeline 階段在動作的 RoleArn 欄位使用目標角色，在 CloudFormation 動作的 DeploymentRoleArn 指定部署角色。
• Staging 和 prod 之間設有人工核准。

情境模式 7：「帶有漸進驗證的多區域推進」

• 單一 pipeline 搭配依序的區域階段：us-east-1 → eu-west-1 → ap-northeast-1。
• 每個區域有各自的工件 bucket（區域要求）。
• 各區域之間設有 CloudWatch 警報檢查動作（自訂 Lambda），驗證沒有指標處於 ALARM 狀態。
• 第一個生產區域要求人工核准；警報清除後後續區域自動晉升。

決策矩陣——哪個 IaC 和部署工具適合哪個目標

常見陷阱——CI/CD 與 IaC 部署策略

每次 SAP-C02 考試都可能出現以下多個干擾項。

陷阱 1：當 Organizations 存在時使用「自管理 StackSets 權限」

如果組織正在使用 AWS Organizations（且情境提到 OU），服務管理權限才是正確答案。自管理僅在目標位於組織外部或未啟用 Organizations 時才正確。

陷阱 2：從管理帳號執行 StackSets

日常 StackSet 操作應在委派管理員帳號執行，而非管理帳號。讓 StackSets 留在管理帳號的答案是治理反模式。

陷阱 3：跨帳號的跨 stack 參照

Fn::ImportValue 僅限同帳號同區域。如需跨帳號共享值，使用 SSM Parameter Store 搭配 RAM 共享，或透過 pipeline 參數或 CDK Pipelines context 明確傳遞。

陷阱 4：忘記 CDK bootstrap

CDK 部署需要每個帳號-區域有一個 bootstrap stack。缺少 bootstrap 是 CDK pipelines 出現「bucket not found」錯誤的第一大原因。修正方式：每個環境執行一次 cdk bootstrap。

陷阱 5：ECS CodeDeploy 缺少兩個監聽器或兩個 target groups

ECS blue/green 需要生產和測試兩個監聽器，以及兩個 target groups。單監聽器/單 target group 情境預設使用 ECS rolling update 控制器，而非 CodeDeploy blue/green。

陷阱 6：AppConfig vs 環境變數

要求「不需部署即可快速可回滾地變更配置」的情境，答案是 AppConfig，而非環境變數。環境變數需要完整的 function/task 更新才能變更。

陷阱 7：Canary 期間 Lambda provisioned concurrency 分配錯誤

在 canary 推進期間，在新版本上佈建 concurrency，而非在 alias 上（alias 是分流的）。否則 canary 流量會冷啟動。

陷阱 8：CloudFormation 適用時選擇 Terraform

除非情境明確提到多雲或現有 Terraform 資產，AWS 原生答案（CloudFormation、CDK、SAM、StackSets）在 SAP-C02 上更受青睞。Terraform 不是錯的，但在純 AWS 情境中很少是「最佳」答案。

陷阱 9：對 Tag policy 強制執行的誤解

Organizations tag policies 預設報告不合規；它們不會阻止資源建立。如要阻止，結合 tag policies 和使用 aws:RequestTag 條件的 SCP，或在 Service Catalog 產品層級用 TagOptions 強制執行。

陷阱 10：跨帳號 pipelines 缺少 KMS key policy

跨帳號 CodePipeline 工件需要客戶自管 KMS key 的 key policy 授予目標帳號 principals 解密權限。目標端的 IAM allow 是不夠的——KMS 主要依賴資源型權限。

陷阱 11：假設 CodeDeploy 對 ECS 執行原地 rolling update

CodeDeploy 的 ECS 部署控制器僅限 blue/green。如果你需要 ECS 原地 rolling update，使用 ECS 原生的 rolling update 控制器（而非 CodeDeploy）。考試有時會以「CodeDeploy rolling for ECS」作為干擾項——這個功能不存在。

陷阱 12：生產環境跳過 change sets

任何在生產 pipeline 中直接使用 CREATE_UPDATE 的答案都值得懷疑。Pro pipelines 一律使用 CHANGE_SET_REPLACE + 核准 + CHANGE_SET_EXECUTE。

診斷入口——「為什麼這個部署失敗？」

當情境說「部署失敗，團隊預期 X 但看到 Y」，請沿著診斷梯逐步排查：

1. Pipeline role 和跨帳號信任 — pipeline 的服務角色是否對目標帳號角色有 sts:AssumeRole？目標角色的信任政策是否以正確的 external ID 信任 pipeline 服務角色？
2. KMS CMK key policy — 對於工件 bucket 加密的 pipelines，KMS key 是否允許目標帳號的 kms:Decrypt 和 kms:GenerateDataKey？
3. 工件 bucket 的 S3 bucket policy — 是否允許目標帳號角色的 s3:GetObject / s3:GetObjectVersion？
4. CloudFormation 部署角色 — 對於跨帳號 CloudFormation 動作，DeploymentRoleArn 是 CloudFormation 在目標帳號中承擔的角色；它需要範本涉及的每種資源類型的權限。這是與 pipeline role 不同的角色。
5. 目標帳號路徑上的 SCP — 是否有拒絕 SCP 阻擋 CloudFormation 動作或某種資源類型？
6. 服務配額 — CloudFormation 500 資源限制、StackSet 100 stack-instance 操作限制、pipeline 動作逾時（預設 1 小時）。
7. Change set 有效性 — 過期的 change set 必須重新建立；參照不再存在的資源的 change set 執行失敗。
8. CloudFormation Hooks 或主動性護欄 — Control Tower 主動性控制可能在 hook 評估時阻擋變更；在 CloudFormation events 中查看 hook 結果。
9. CodeDeploy 部署的 CloudWatch 警報狀態 — 部署開始前某個警報是否已處於 ALARM 狀態（立即觸發自動回滾）？
10. Lambda function 限制 — 並發限制、程式碼大小、部署套件大小、保留並發衝突。

Log Archive 帳號中的 CloudTrail（透過組織 trail）加上 pipeline 執行歷史記錄以及 CloudFormation stack events，提供完整的鑑識軌跡。

費用模型說明

大多數 CI/CD 服務依具體使用單位收費：

• CodePipeline：第一條 pipeline 免費；額外的活躍 pipeline 按月計費。V2 pipelines 依執行分鐘計費。
• CodeBuild：依每個建構主機的每分鐘計費（general1.small 到 large）。
• CodeDeploy：EC2/on-prem/Lambda/ECS 部署本身不收費；你支付底層運算費用。
• CloudFormation StackSets：不收服務費；你支付已佈建資源的費用。
• CDK：免費；你支付已佈建資源以及 bootstrap 資產（S3 + ECR 儲存）的費用。
• SAM CLI：本地使用免費。
• Serverless Application Repository：發布和使用免費。
• AWS AppConfig：按每次配置呼叫 + 每次取得的配置計費（極小的單位成本；透過 agent/extension 快取）。
• Service Catalog：免費；你支付已佈建資源的費用。
• Systems Manager：大多數功能免費；Automation 跨大量執行個體執行時按步驟執行次數收費。

在 Pro 規模，主要成本是已佈建的基礎設施本身和大型 pipelines 的 CodeBuild 分鐘數；CI/CD 控制平面費用低廉。

FAQ——CI/CD 與 IaC 部署策略高頻問題

Q1：何時應使用 CloudFormation StackSets vs 巢狀 stacks vs 跨 stack 參照？

當單一團隊擁有所有資源，並希望它們以一次交易完成部署、更新和回滾時，使用巢狀 stacks——父 stack 驅動每個子 stack。當不同團隊在同帳號同區域擁有不同的部件，需要獨立的生命週期（VPC 團隊、IAM 團隊、應用團隊），但仍需共享子網路 ID 等輸出時，使用跨 stack 參照。當你必須將相同範本部署到多個帳號或區域時，使用 CloudFormation StackSets——巢狀 stacks 和跨 stack 參照都無法跨越帳號邊界。對 SAP-C02 而言，「組織層級基準」始終對應到帶服務管理權限的 StackSets；「由子網路模組組成的模組化 VPC」對應到巢狀 stacks；「被多個應用共享的基礎 IAM」對應到透過 SSM Parameter Store 的跨帳號跨 stack 參照。

Q2：對於新工作負載，如何在 CloudFormation、CDK 和 SAM 之間選擇？

對於純無伺服器工作負載（Lambda、API Gateway、DynamoDB、Step Functions、EventBridge），且團隊重視短範本和一流本地開發體驗時，選 SAM。對於混合工作負載（無伺服器 + 容器 + VM + RDS），或團隊希望程式化重複使用、具型別的基礎設施以及跨所有內容使用單一語言時，選 CDK。當資產已大量使用 CloudFormation、你希望最簡單的撰寫方式且無需建構步驟，或你正在發布 Service Catalog 或 StackSets 使用的可重複使用範本時，選純 CloudFormation YAML。三者最終都合成為 CloudFormation——你可以混用（CDK 用於新服務、CloudFormation 範本透過 CfnInclude 使用、SAM 用於無伺服器子系統）。

Q3：使用可稽核 pipeline 部署到 20 個 AWS 帳號的標準模式是什麼？

從管理帳號啟用所有功能的 Organizations，並將 Deployments 帳號指定為 CloudFormation StackSets 委派管理員。在 Deployments 帳號，執行一個 CodePipeline：從 CodeCommit 或透過 CodeStar Connections 連接的 GitHub 拉取範本，執行 CodeBuild 進行 linting（cfn-lint、cfn-nag、Terraform 的 tfsec）和單元測試，在帶服務管理權限的 StackSet 上針對特定 OU 建立 change set，在帶 SNS 通知到資安維運人員的人工核准動作上暫停，然後執行 change set，以設定好的並發數和失敗容許度平行部署到所有目標帳號。啟用自動部署，使加入 OU 的新帳號在第一天就收到 stack。透過 EventBridge 排程 drift detection。用 root SCP 鎖定一切，拒絕除 pipeline role 以外的任何人對基準 stack 名稱模式執行 cloudformation:*。每個步驟都記錄在 CloudTrail 組織 trail 中，提供完整稽核。

Q4：Lambda 部署應使用 canary 還是 linear？

當你希望有明確的兩步驟切換，並帶有人工觀察或警報監控的觀察期時，使用 canary——經典模式是 LambdaCanary10Percent10Minutes，在全面切換前提供 10 分鐘的 canary 流量。當你有信心 10 分鐘的資料足以捕捉回歸時（良好的遙測、高流量），canary 很合適。當你希望更平滑的推進時，使用 linear——每分鐘增加 10%，持續 10 分鐘——減少 canary 階段結束時的「跳躍」。當警報需要更多資料點且流量穩定時，linear 更合適；漸進推進讓每個步驟的警報評估能輸入下一個步驟。兩者都在 CloudWatch 警報時自動回滾。對於低流量 Lambda，10% 的數據量太少時，考慮延長觀察時間（LambdaCanary10Percent30Minutes）或在生產部署前傾向使用 blue/green 式的 staging 測試。

Q5：ECS blue/green 搭配 CodeDeploy 的端到端運作方式？

ECS service 配置 deploymentController: CODE_DEPLOY。你有一個 ALB，帶有兩個監聽器——生產監聽器（port 80/443）和測試監聽器（例如 port 8080）——以及兩個 target groups（blue 和 green）。CodeDeploy deployment group 參照 cluster、service、兩個 target groups、兩個監聽器和一個部署組態。當部署開始時，CodeDeploy 建立一個新的 ECS task set，註冊到 green target group。你可以選擇透過測試監聽器路由測試流量進行預生產驗證；pre-traffic Lambda hook 對測試監聽器執行整合測試。如果 hook 通過，CodeDeploy 依部署組態（all-at-once、canary 或 linear）將生產監聽器從 blue 切換到 green。post-traffic hook 在切換後執行煙霧測試。如果 deployment group 警報列表中的任何 CloudWatch 警報觸發，CodeDeploy 自動回滾——生產監聽器切回 blue，green task set 被終止。這讓你在不需要第二次部署的情況下，在幾秒內完成回滾。

Q6：何時應使用 AWS AppConfig 而非重新部署？

對於必須在執行期間不進行程式碼部署即可變更的配置和 feature flags，使用 AppConfig。典型用途：為特定比例的使用者開啟/關閉功能、調高速率限制閾值、切換演算法、啟用維護模式橫幅、推進區域功能。AppConfig 給你與程式碼部署相同的護欄——驗證（Lambda 或 JSON Schema）、分段推進（linear、canary、all-at-once），以及 CloudWatch 警報自動回滾——但推進以秒為單位，因為不需要重新部署，只需在下一個輪詢間隔取得。SAP-C02 情境中「幾秒內回滾配置變更」、「feature flag 推進」或「緊急關閉開關」都指向 AppConfig。不要用 AppConfig 存放 secrets（使用 Secrets Manager）或大型靜態資產（使用 S3）。可用於 1 MiB 以內的 JSON/YAML 配置 blob 和 feature-flag profiles。

Q7：如何跨多個 AWS 帳號部署 CodePipeline？

將 pipeline 放在專屬的 pipeline 帳號（通常是 Deployments 帳號）。以客戶自管 KMS key 加密工件 S3 bucket，key policy 授予每個目標帳號的角色 kms:Decrypt 和 kms:GenerateDataKey；同時確保 S3 bucket policy 允許目標帳號角色的 s3:GetObject*。在每個目標帳號建立一個 CloudFormation 部署角色，信任 pipeline 的 CodePipeline 服務角色（信任政策使用 aws:PrincipalArn 或 sts:ExternalId 條件）。在 pipeline 中，動作的 RoleArn 指定要承擔的跨帳號角色，CloudFormation deploy 動作也指定一個獨立的 DeploymentRoleArn，即 CloudFormation 自身承擔以佈建資源的角色。在嘗試完整部署前，先用最小化的「list-stacks」動作測試信任鏈。如果你想自動生成這些串接，使用 CDK Pipelines。

Q8：如何大規模偵測並自動補救 CloudFormation drift？

結合三種機制。(1) 每個 stack set 或 stack 的 CloudFormation drift detection，透過 EventBridge 每 N 小時排程一次（DetectStackDrift 或 DetectStackSetDrift API）。(2) AWS Config 規則 cloudformation-stack-drift-detection-check 作為偵測控制，記錄 drifted stacks 的不合規。(3) EventBridge 規則匹配 CloudFormation drift detection 完成事件，將 drifted-stack 事件路由至 SNS topic（通知資安維運人員）或 Systems Manager Automation runbook（自動補救）。對於已知安全的 drift 類別（例如新增安全群組規則），runbook 可重新套用 CloudFormation 範本。對於未知 drift，通知人員並凍結 stack 直到調查完成。在 Pro 規模，另外在 root 層級附加 SCP 拒絕對標籤標識的基準資源進行手動編輯，從源頭防止 drift。搭配 Control Tower landing-zone 層級的 drift detection 以獲得完整覆蓋。

Q9：CDK Pipelines 和 CodePipeline 有什麼差異？

CodePipeline 是底層的 AWS 服務——由包含動作的階段組成的線性工作流程。你以 CloudFormation、CDK、SAM 或主控台撰寫 pipeline 定義，AWS 執行它。CDK Pipelines（aws-cdk-lib.pipelines）是更高層級的 CDK construct 程式庫，從你的 CDK 應用程式碼生成 CodePipeline。標誌性功能是自我變更：當你在 CDK 程式碼中新增階段或環境，pipeline 的第一個動作會重建自身以包含新階段。CDK Pipelines 也自動處理跨帳號 CDK bootstrap role 串接，以最佳實踐預設設定工件加密，並自然整合 CDK 應用程式的 stages（dev/staging/prod 作為 CDK stages，各自針對不同的環境）。對於 SAP-C02「帶有多環境晉升且維護工作最少的 pipeline」的答案，如果你已在 CDK 中，CDK Pipelines 是原生選擇。

Q10：SAR（Serverless Application Repository）如何融入多團隊組織？

平台團隊將一個可重複使用的無伺服器模式（比如「標準事件驅動 Lambda，帶有 DLQ、結構化日誌、X-Ray 追蹤和 CloudWatch dashboard」）打包為 SAM 應用程式，並發布到 SAR。發布範圍可以是帳號私有、共享給特定 AWS 帳號、共享給 AWS 組織，或公開。消費團隊在自己的帳號中，以單一 AWS::Serverless::Application 資源（參照 SAR 應用程式 ARN 和版本）部署 SAR app——SAR 在消費者帳號中合成一個巢狀 CloudFormation stack。優點：可重複使用模式的單一真相來源、帶有消費者明確選擇更新的語意化版本控制，以及 SAM 風格的參數傳遞以供自訂。SAR 補充（而非取代）AWS Service Catalog：SAR 是無伺服器特定的，以 SAM 慣例自助服務；Service Catalog 是通用 CloudFormation 包裝在治理中（launch constraints、TagOptions、portfolio 共享），也適合非無伺服器架構。

延伸閱讀

• AWS CloudFormation StackSets
• CloudFormation StackSets Concepts — Self-Managed vs Service-Managed
• CloudFormation Nested Stacks
• CloudFormation Cross-Stack References
• CloudFormation Change Sets
• CloudFormation Drift Detection
• AWS CDK v2 Developer Guide
• AWS CDK Constructs (L1/L2/L3)
• AWS CDK Pipelines
• AWS SAM Developer Guide
• AWS SAM — Gradual Deployments
• AWS Serverless Application Repository
• AWS CodePipeline User Guide
• CodePipeline Cross-Account Actions
• AWS CodeDeploy User Guide
• CodeDeploy Deployment Configurations
• CodeDeploy Blue/Green for Amazon ECS
• Lambda Aliases and Traffic Shifting
• AWS AppConfig User Guide
• AWS Service Catalog Administrator Guide
• AWS Systems Manager Automation
• Terraform AWS Provider Best Practices (AWS Prescriptive Guidance)
• AWS SAP-C02 Exam Guide (PDF)