CloudFormation — StackSets、Drift Detection 與 Change Sets

CloudFormation 堆疊集 (StackSets)、漂移偵測 (drift detection) 與變更集 (change sets) 構成了 DOP-C02 領域 2 的核心。每當題目描述「向 40 個帳戶部署相同的基準配置」、「偵測工程師是否在範本外手動編輯了安全組」或「在執行前預覽更新將替換哪些資源」時，答案就在這三個原語之中。在專業級別，AWS 期望你了解營運機制、IAM 模型、回滾語義和失效模式 —— 而不只是記住產品名稱。

本指南假設你已具備 Associate 級別的基礎：了解什麼是 CloudFormation 堆疊、範本參數的作用以及堆疊輸出。這裡的重點是 DevOps 工程師專業級的決策：自行管理型 vs 服務管理型堆疊集、委派管理員 (delegated administrator)、跨數千個堆疊執行個體的漂移偵測、包含替換 (replacement) vs 無中斷修改的變更集預覽、與 CloudWatch 警示掛鉤的回滾觸發器、巢狀堆疊 vs 跨堆疊引用，以及防止錯誤範本拖垮整個組織的 操作偏好設定（失敗容許度、最大並行百分比）。

為什麼 CloudFormation 堆疊集在 DOP-C02 中很重要

DOP-C02 將領域 2（組態管理與 IaC）權重設為 17%，而堆疊集/漂移/變更集這三劍客就佔據了其中的重要份額。社群考試報告一致指出，考試會讓堆疊集與其他方案進行對比：堆疊集 vs Service Catalog 組合 (portfolio) 共享、堆疊集 vs CodePipeline 並行部署操作、堆疊集漂移 vs AWS Config 規則、變更集 vs 直接堆疊更新、巢狀堆疊 vs Lambda 驅動的自定義資源。選錯了，你就選了一個技術上可行但在營運上較弱的答案。

考試還側重於堆疊集的細微語義：當你針對某個 OU 時哪些帳戶會收到部署、當服務管理型部署在管理帳戶堆疊執行個體失敗一半時會發生什麼、並行操作如何與失敗容許度交互，以及為什麼堆疊執行個體上的漂移不會自動觸發修正。記住這些細節能將 4 分鐘的排除法難題變成 30 秒的識別練習。

白話文解釋 StackSets, Drift 與 Change Sets

當你將這些機制映射到現實世界的物理操作時，它們會變得容易理解。三個類比從不同角度涵蓋了部署、審計和預覽語義。

類比 1：連鎖餐廳加盟店推廣

想像你經營一家有 40 家分店的咖啡連鎖店。CloudFormation 範本 就是你的 標準作業程序 (SOP) 手冊 —— 精確的義式濃縮咖啡機設置、精確的豆水比、精確的菜單佈局。單個 CloudFormation 堆疊 就是一家運行該手冊的分店。堆疊集 (StackSet) 則是 加盟營運團隊，他們透過一次操作將手冊推送到所有 40 家分店，並設有「一次更新五家，如果超過兩家失敗則中止」的控制項。

自行管理型堆疊集 是你（特許人）與每家分店單獨簽署法律合約，授予營運團隊存取權限的模式。服務管理型堆疊集 則是母公司 (AWS Organizations) 持有主特許協議，當新店加入加盟 OU 時，營運團隊會自動獲得權限。

漂移偵測 是 神秘客，他訪問每家分店並檢查機器設置是否仍符合手冊。如果店員在 SOP 之外調了研磨度，漂移偵測會為該店標記為 MODIFIED。變更集 是 彩排：在推送包含「拆除舊咖啡機並安裝新機器」的新 SOP 之前，你發布變更集，讓分店在接受前看到「此更新將替換你的咖啡機 —— 停工 2 小時」。

類比 2：飯店連鎖店標準化

一家飯店集團在 200 處物業推行新的大廳設計。建築圖紙 是你的 CloudFormation 範本。每家飯店實際的大廳 是一個堆疊執行個體。集團標準辦公室 就是堆疊集本身。當集團想要更新所有 200 處的照明設備時，標準辦公室發布一個工作單；操作偏好設定 規定「同時更新 10 家飯店，如果 5 家飯店報告問題則中止推廣」。

漂移偵測 是集團審計師走進飯店，發現總經理把標準要求的吊燈換成了更便宜的款式 —— 審計師報告 MODIFIED。集團不會自動拆除便宜吊燈；總經理會收到違規通知並必須限期整改。變更集 是正式的現場勘查，審計師警告「新照明計劃需要拆除現有線路 —— 大廳將停用 48 小時」，然後工作單才會被簽署。

巢狀堆疊 對應於 模組化飯店組件：大廳圖紙引用了酒吧圖紙，酒吧圖紙又引用了後台廚房圖紙。更新廚房圖紙，父級大廳圖紙會自動繼承變更。跨堆疊引用 (Cross-stack references) 則是較鬆散的模式，酒吧只是從大廳堆疊的輸出中導入「大廳的 wifi SSID」 —— 酒吧堆疊和大廳堆疊是獨立的，但透過名稱連結。

類比 3：衛生區疫苗推廣

地區衛生局向 60 家診所推廣一種新疫苗。疫苗接種協議 是 CloudFormation 範本。每家診所 是一個堆疊執行個體。地區堆疊集 是推廣管理員。服務管理型許可 模式是州衛生廳 (Organizations) 預先授權地區管理員向州內任何診所發送協議。自行管理型 則是每家診所單獨簽署分發協議。

操作偏好設定 是推廣時程表：「每天 10 家診所，按區域進行，如果超過 5% 的病患報告不良事件則中止推廣」。失敗容許度 (Failure tolerance) 是「在停止整個推廣前，允許多少家診所失敗」的閾值。

漂移偵測 是推廣後的檢查：14 號診所是否偷偷換掉了不合格的存放冰箱？變更集 是協議修訂預覽：在批准「需要不同注射器的協議 v2」之前，每家診所都能看到差異以便提出異議。掛鉤到 CloudWatch 警示的回滾觸發器 是安全感應器：如果在推廣窗口期間，接種後不良事件熱線每小時響起超過 X 次，整個部署將自動撤回。

堆疊集架構：自行管理型 vs 服務管理型

DOP-C02 的第一個大分叉路口是 IAM 許可模型。選擇決定了由誰建立角色、使用什麼目標設定語法，以及新帳戶如何自動上線。

自行管理型許可 (Self-Managed Permissions)

在自行管理模式下，你 需要建立：

• 管理帳戶（擁有堆疊集定義的帳戶）中的 AWSCloudFormationStackSetAdministrationRole。
• 每個目標帳戶 中的 AWSCloudFormationStackSetExecutionRole，並帶有允許管理角色切換它的信任政策。

你透過 明確的帳戶 ID 清單 加上 區域清單 來設定堆疊執行個體的目標。自行管理型早於 Organizations 整合，且無需 Organizations 即可運作 —— 當你有不屬於同一個管理帳戶的無關帳戶，或 SCP 禁止服務管理模式所需的受信任存取要求時，這很有用。

服務管理型許可 (Service-Managed Permissions)

在服務管理模式下，AWS Organizations 會自動：

• 當帳戶加入目標 OU 時，佈署跨帳戶 IAM 角色。
• 當帳戶離開 OU 或關閉時，移除角色。
• 支援透過 OU ID 或 整個組織根節點 來設定目標，而不僅僅是帳戶 ID 清單。

服務管理模式還解鎖了 自動部署 (automatic deployment)：當新帳戶加入目標 OU 時，CloudFormation 會自動在該帳戶的所有配置區域中建立堆疊執行個體。當帳戶離開 OU 時，堆疊執行個體會被刪除（或保留，取決於你的 RetainStacksOnAccountRemoval 設定）。

委派管理員 (Delegated Administrator)

預設情況下，僅 管理帳戶 可以在服務管理模式下執行堆疊集操作。AWS 建議保持管理帳戶簡潔，因此你可以使用 register-delegated-administrator 針對 cloudformation.amazonaws.com 服務委託人將堆疊集管理委派給特定的成員帳戶。委派管理員隨後可以在全組織範圍內執行服務管理型堆疊集操作，但不能針對管理帳戶本身。

堆疊執行個體生命週期與操作偏好設定

堆疊集有兩個層次：堆疊集定義（範本 + 參數）和 堆疊執行個體（按帳戶-區域部署的實際堆疊）。對堆疊集的操作會以顯式的並行與失敗控制傳播到堆疊執行個體。

操作偏好設定 (Operation Preferences)

每個堆疊集操作都接受：

• FailureToleranceCount 或 FailureTolerancePercentage: 在 CloudFormation 中止整個操作前，允許多少個堆疊執行個體失敗。
• MaxConcurrentCount 或 MaxConcurrentPercentage: 可以並行更新多少個堆疊執行個體。
• RegionConcurrencyType: SEQUENTIAL（一次一個區域）或 PARALLEL。
• RegionOrder: 順序模式下的明確區域順序。

對於生產環境部署，標準模式是第一波畫線 (canary) 使用 FailureToleranceCount=0 和 MaxConcurrentCount=1，然後再執行第二次操作，放寬設定進行大宗推廣。

堆疊執行個體狀態

每個堆疊執行個體回報一個獨立於堆疊集的狀態：

• CURRENT: 執行個體與最新的堆疊集範本版本相符。
• OUTDATED: 執行個體是根據較舊的範本版本佈署的，尚未更新。
• INOPERABLE: 先前的操作失敗，必須先手動修復執行個體才能接受進一步更新。

INOPERABLE 狀態是常見的考試陷阱：在先前更新中失敗的堆疊執行個體會默默跳過未來的堆疊集更新，直到你執行 delete-stack-instances 並重新建立它，或使用帶有 --accounts 和 --retain-stacks 標誌的 update-stack-instances 強制重新同步。

漂移偵測：按堆疊與按堆疊集

漂移偵測將實際資源狀態與 CloudFormation 範本的預期狀態進行對比。它按需執行 —— 不會按計畫自動執行，也不會自動修正。

單個堆疊上的漂移

你調用 aws cloudformation detect-stack-drift 並輪詢 describe-stack-drift-detection-status 直到操作完成。每個資源的結果為：

• IN_SYNC: 實際狀態與範本相符。
• MODIFIED: 屬性不一致（例如手動添加了安全組入站規則）。
• DELETED: 資源被帶外 (out-of-band) 刪除。
• NOT_CHECKED: 資源類型不支援漂移偵測（此列表雖小但正在增長）。

堆疊集上的漂移

aws cloudformation detect-stack-set-drift 會分發到所有堆疊執行個體。堆疊集會聚合結果：如果任何資源不一致，執行個體即為 DRIFTED；如果全部相符則為 IN_SYNC。如果任何執行個體發生漂移，堆疊集本身就變為 DRIFTED。

自動化漂移偵測

DOP-C02 預期的全組織漂移偵測模式：

1. EventBridge 排程規則（例如每天）觸發 Lambda。
2. Lambda 遍歷各個堆疊集，並對每個調用 detect-stack-set-drift。
3. 針對 CloudFormation Drift Detection Status Change 事件的 EventBridge 規則過濾 DRIFTED 狀態。
4. 目標：SNS 通知 + 調用 update-stack 重新套用範本的 Step Functions 工作流。

變更集：執行前預覽

變更集是 CloudFormation API，回傳更新的差異而不執行它。

變更集動作類型

每個資源變更被分類為：

• Add: 將建立新資源。
• Modify: 將更新現有資源。包含 Replacement 欄位：True、False 或 Conditional。
• Remove: 將刪除現有資源。
• Import: 僅與資源導入操作相關。

Replacement: True 是危險信號 —— 這意味著 CloudFormation 將建立新資源並刪除舊資源，對於 RDS 執行個體或 EBS 磁碟區等具狀態資源，這意味著數據丟失（除非你有快照）。

變更集類型

• CREATE: 針對尚不存在的堆疊的變更集。
• UPDATE: 針對現有堆疊的變更集。
• IMPORT: 用於將現有資源導入新堆疊或現有堆疊的變更集。

CodePipeline CloudFormation 操作提供了 CHANGE_SET_REPLACE、CHANGE_SET_EXECUTE 和 REPLACE_ON_FAILURE 操作模式。標準的 CD 模式是 兩個管道階段：階段 1 調用 CHANGE_SET_REPLACE（建立/替換變更集），手動審核操作顯示差異，階段 2 調用 CHANGE_SET_EXECUTE。

巢狀堆疊 vs 跨堆疊引用

兩者都允許你將範本分解為可重複使用的片段。兩者間的權衡是直接測試的考量點。

巢狀堆疊 (Nested Stacks)

巢狀堆疊是由父範本中的 AWS::CloudFormation::Stack 引用的子堆疊。子範本存儲在 S3 中（或在 aws cloudformation package 的同一個包中）。當父堆疊更新時，CloudFormation 將子堆疊視為單個資源進行評估 —— 如果子堆疊的範本 URL 發生變化，則整個子堆疊都會更新。

巢狀堆疊在 緊密耦合的組別 中表現優異，其生命週期共享 —— 更新父級，子級會原子性地更新。回滾父級會自動回滾所有子級。

跨堆疊引用 (Cross-Stack References)

從堆疊 A Export 一個輸出；在堆疊 B 中透過 Fn::ImportValue 導入。堆疊之間是獨立的。更新堆疊 A 不會更新堆疊 B，即使導入的值發生變化 —— 事實上，當另一個堆疊正在導入時，你無法刪除匯出的值。

跨堆疊引用在 鬆散耦合 場景中表現優異，其中堆疊生命週期不同：一個長期的網路堆疊向許多短期的應用程式堆疊匯出 VPC ID。

回滾觸發器與堆疊政策

CloudFormation 除了變更集之外，還提供了兩個安全網。

回滾觸發器 (Rollback Triggers - CloudWatch Alarms)

當你建立或更新堆疊時，可以附加最多 5 個 CloudWatch 警示作為 回滾觸發器，並設定 MonitoringTimeInMinutes（0 到 180 分鐘）。在堆疊達到 CREATE_COMPLETE 或 UPDATE_COMPLETE 後，CloudFormation 會繼續監控警示；如果在監控窗口期間任何警示進入 ALARM 狀態，CloudFormation 會自動回滾。

這是 IaC 與運行時健全狀況之間的橋樑：資源層級部署成功，但應用程式錯誤率激增 —— 回滾觸發器能捕捉到這一點並復原。

堆疊政策 (Stack Policies)

堆疊政策是附加在堆疊上的 JSON 文件，除非運維人員透過 --stack-policy-during-update-body 顯式覆蓋，否則會 拒絕更新特定資源。標準生產模式會對 AWS::RDS::DBInstance 和 AWS::EC2::Volume 類型的所有資源拒絕 Update:Replace 和 Update:Delete。如果沒有覆蓋，任何涉及這些資源的變更集都會在執行前失敗。

CodePipeline 整合模式

DOP-C02 要求能流暢地將堆疊集和變更集整合進 CodePipeline。

透過堆疊集操作進行多帳戶部署

CodePipeline 直接支援 CloudFormationStackSet 和 CloudFormationStackInstances 操作類型。CloudFormationStackSet 操作建立或更新堆疊集定義（範本 + 參數）；CloudFormationStackInstances 操作則佈署執行個體。將它們分開可以讓你在堆疊集定義更新後但在執行個體佈署前執行整合測試。

跨帳戶管道模式

傳統的（堆疊集操作出現前）模式是使用帶有跨帳戶角色的每個環境一個 CodePipeline：

1. 工具帳戶中的 CodePipeline。
2. Source 操作從 CodeCommit/GitHub 拉取範本。
3. CloudFormation 操作切換到目標帳戶中的部署角色。
4. 變更集替換 + 手動審核 + 變更集執行，針對每個目標帳戶重複此過程。

對於 5-10 個帳戶，這還可以應付；除此之外，堆疊集操作在營運簡便性上勝出。

常見陷阱 (Common Pitfalls)

1. 在需要服務管理型時選擇了自行管理型: 如果場景提到「新帳戶加入 OU 時自動部署」，只有服務管理型能滿足 —— 自行管理型沒有自動上線功能。
2. 假設漂移偵測會自動修正: 考試喜歡將「偵測到漂移且安全組已恢復」作為錯誤選項。漂移偵測是唯讀的。修正需要 EventBridge + Lambda 或 Config + SSM 自動化。
3. 忘記委派管理員無法觸及管理帳戶: 需要「向包括管理帳戶在內的所有帳戶部署護欄」的場景必須從管理帳戶本身執行。
4. 忽略 INOPERABLE 堆疊執行個體: 先前失敗的操作會使執行個體處於 INOPERABLE 狀態；隨後的堆疊集更新會默默跳過它。修復方法是使用 update-stack-instances --regions --accounts 強制重新同步。
5. 將變更集的 Replacement: Conditional 視為安全: 它並不安全；CloudFormation 只是提前無法確定。請將其視為 True 進行風險評估。
6. 對緊密耦合資源使用跨堆疊引用: 跨堆疊 ImportValue 會鎖定生產者的匯出，直到每個取用者都釋放它 —— 你無法刪除或重新命名該匯出。對於緊密耦合的組別，巢狀堆疊是正確答案。
7. 忘記回滾觸發器上的 MonitoringTimeInMinutes: MonitoringTimeInMinutes=0 的回滾觸發器根本不會進行監控 —— 堆疊達到完成狀態後，CloudFormation 就停止監視警示。

FAQ

Q1：何時應選擇堆疊集而非 CodePipeline 跨帳戶部署？

當你針對 10 個以上帳戶使用相同的範本和相同的參數（或 OU 範圍模式）時，選擇堆疊集。當每個目標需要不同的測試門檻、每個環境需要手動審核，或參數值由上游管道輸出驅動時，選擇 CodePipeline 跨帳戶。兩者可以組合使用：CodePipeline 可以包含一個堆疊集操作，作為單個管道階段向 50 個帳戶分發。

Q2：漂移偵測能看到隨後被撤回的手動變更嗎？

不能。漂移偵測是在偵測時刻將實際狀態與範本進行對比。如果工程師添加了入站規則並在下次漂移執行前將其移除，漂移偵測將回報 IN_SYNC。對於持續偵測，你需要 CloudTrail + 針對 ConfigurationChange 事件的 EventBridge 規則，或者在每次變更時記錄資源狀態的 AWS Config 規則。

Q3：堆疊集漂移結果與堆疊漂移結果有什麼區別？

堆疊漂移結果是針對單個堆疊內的每個資源。堆疊集漂移結果會按堆疊執行個體進行聚合：每個執行個體不是 IN_SYNC 就是 DRIFTED，如果任何執行個體發生漂移，父級堆疊集即為 DRIFTED。要查看資源層級的詳細資訊，你必須單獨查看每個堆疊執行個體的漂移結果。

Q4：為什麼我的服務管理型堆疊集失敗並顯示「未啟用受信任存取」？

服務管理模式要求在 Organizations 受信任存取中啟用 cloudformation.amazonaws.com。請從管理帳戶執行 aws organizations enable-aws-service-access --service-principal cloudformation.amazonaws.com，然後重試。沒有這個步驟，AWS Organizations 會拒絕佈署跨帳戶角色。

Q5：如何回滾已經部署到 30 個帳戶的堆疊集？

沒有「回滾堆疊集」的 API。支援的模式是執行一個新的堆疊集操作，將範本更新回先前的版本 —— 實際上是向前滾動 (roll-forward)。如果單個堆疊執行個體卡住，delete-stack-instances 可以將其移除；使用新範本重新建立即可重新部署。

Q6：變更集能告訴我部署需要多長時間嗎？

不能。變更集描述 什麼 會改變，但不包括 何時 或 多久。如需時間估計，請在過去的部署中使用 aws cloudformation describe-stack-events，或圍繞 CodePipeline 操作持續時間指標建置可觀測性。CodeDeploy 的 CloudWatch 指標提供了每次部署的持續時間數據；CloudFormation 不直接公開類似指標。

Q7：服務管理型堆疊集在一次操作中最多可以針對多少個帳戶？

帳戶數量沒有硬性上限，但每個區域有並行操作限制。實際模式是使用 MaxConcurrentPercentage 而非絕對計數，以便推廣規模隨組織大小擴展，且如果你觸發了底層帳戶級別 CloudFormation API 的節流 (throttling)，請將大型 OU 拆分為多個堆疊集操作。

總結

CloudFormation 堆疊集、漂移偵測與變更集共同涵蓋了 DOP-C02 領域 2 中測試最多的三個營運原語。堆疊集處理多帳戶分發；漂移偵測處理審計；變更集處理每次套用前的安全審核。記住 IAM 模型劃分（自行管理型 vs 服務管理型）、委派管理員限制（無法觸及管理帳戶）、操作偏好設定預設值（一次一個，零失敗容許度）以及回滾觸發器語義（帶有監控窗口的 CloudWatch 警示）。將這些與用於原子更新的巢狀堆疊和用於共享基礎設施的跨堆疊引用相結合，大多數帶有堆疊集色彩的考試問題都能在不到一分鐘內解決。