AWS Service Catalog 與 AWS AppConfig 是 DOP-C02 中涉及受管自我服務與執行階段配置的關鍵服務。Service Catalog 將 CloudFormation 模板封裝為經核准且可啟動的產品，開發人員可以從精選的組合中自我服務 —— 解決了「如何在不放棄 IaC 紀律的情況下，讓開發人員在沒有 IAM-DBAdmin 權限時自行建立 RDS」的問題。AppConfig 則提供具備驗證器與漸進式部署策略的功能旗標與執行階段配置 —— 解決了「如何在不重新部署應用程式的情況下，安全地在執行階段切換行為並具備自動回滾保障」的問題。
本指南假設您已瞭解 CloudFormation 模板和功能旗標。DOP-C02 的重點在於：Service Catalog 組合、產品與版本、啟動約束、模板約束、通知約束、StackSet 約束、ResourceUpdate 約束、跨組織的組合共享、用於治理標記的 TagOptions、AppConfig 應用程式、環境、配置設定檔、部署策略、JSON Schema 與 Lambda 驗證器、基於 CloudWatch 警示的自動回滾、來自客戶端的功能旗標評估，以及 AppConfig vs Parameter Store vs Secrets Manager 的選擇。
為什麼 Service Catalog 與 AppConfig 在 DOP-C02 中很重要
DOP-C02 明確將「將基礎設施模式、治理控制與安全標準實作到可重複使用的 IaC 模板中（例如 AWS Service Catalog, CloudFormation 模組, AWS CDK）」列為領域 2.1 的技能，而 AppConfig 則是 2023 年新增的內容，考試指南強調其為相對於 DOP-C01 的全新內容。社群考試回報指出，在某些情境下，Service Catalog 優於純 IAM 策略方法，因為它在單個產品中交付了配置 (Provisioning) + 治理 + 標記 + 資源更新鎖定，而純 IAM 僅能處理權限門檻。
現實世界的 DevOps 團隊經常面臨一種張力：開發人員追求速度，安全部門追求控制。Service Catalog 透過讓開發人員從預先核准的 CloudFormation 模板組合中自我服務來解決此問題，而無需接觸底層服務的 IAM 權限 —— 他們只需要 servicecatalog:ProvisionProduct 權限。AppConfig 則解決了執行階段配置的類似張力：變更經過驗證、逐漸部署且可自動回滾，而無需重新部署應用程式。
考試會測試精確的適用範圍：Service Catalog 何時優於原始的 CloudFormation StackSets、AppConfig 何時優於 Parameter Store，以及哪種 Service Catalog 約束類型能解決哪種治理需求。
- Service Catalog 產品：為受管啟動而封裝的具備版本的 CloudFormation 模板（或透過 Service Catalog Terraform 引擎實現的 Terraform 配置）。
- 組合 (Portfolio)：具有共享存取控制與標籤的產品分組。
- 已佈建的產品 (Provisioned product)：終端使用者啟動的產品執行個體；由 CloudFormation 堆疊支持。
- 啟動約束 (Launch constraint)：Service Catalog 在啟動產品時假設的 IAM 角色，將使用者的 IAM 與底層資源建立解耦。
- 模板約束 (Template constraint)：限制終端使用者可以提供的參數值的 JSON 規則（例如
Type: String, AllowedValues: [t3.micro, t3.small]）。 - 通知約束 (Notification constraint)：用於在產品啟動事件發生時發送通知的 SNS 主題。
- StackSet 約束：在一次配置調用中，將產品作為 StackSet 部署到多個帳戶和區域。
- ResourceUpdate 約束：防止終端使用者更新由目錄管理員管理的標籤。
- TagOption：管理員定義一次並分配給組合/產品的鍵值對，用於強制執行一致的標記。
- AppConfig 應用程式：相關配置的邏輯分組。
- AppConfig 環境：應用程式內的部署目標（如 dev, staging, prod）。
- 配置設定檔 (Configuration profile)：指向配置數據所在地（S3, Parameter Store, CodeCommit, 託管）的指標，加上驗證器和類型 (
AWS.Freeform,AWS.AppConfig.FeatureFlags)。 - 部署策略 (Deployment strategy)：配置版本如何推出（線性 vs 一步到位），具備烘焙時間 (Bake time) 和增長因子。
- 驗證器 (Validator)：在部署前核准/拒絕新配置版本的 JSON Schema 或 Lambda 函數。
- 參考：https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html
白話文解釋 Service Catalog 與 AppConfig
這兩項服務透過不同的機制解決相鄰的問題。從受管啟動模型、執行階段配置模型以及驗證器三個角度來理解。
類比 1：餐廳核准食譜書 vs 每日特餐菜單
一家連鎖餐廳有兩個治理介面。Service Catalog 就像是核准的食譜書 —— 總部已經審核了 30 道菜，每道菜都有精確的配料（模板參數）、每道菜都有最大份量（模板約束）、每道菜都需要特定的廚房設置（啟動約束 —— 鑰匙由主廚持有，而非生產線廚師）。新廚師從書中自我服務點餐，而無需擁有香料櫃（底層 IAM）的存取權；他們只需請求「大份瑪格麗特披薩」，總部核准的廚師角色負責實際準備。
AppConfig 則是每日特餐菜單板 —— 廚房可以在不重寫食譜書的情況下切換供應內容。「今日鮭魚特餐：七折」是一個逐漸推向所有分店的功能旗標（部署策略）。如果銷售額下降超過預期，菜單會自動恢復（基於警示的自動回滾）。
驗證器就像是食品安全檢查員 —— 任何新的菜單項在上线前都必須通過 JSON Schema 檢查（過敏原標註正確）以及選用的 Lambda 檢查（特餐不得違反當天的庫存水平）。
類比 2：醫院核准程序目錄 vs 每班次規程更新
一家醫院有兩個治理介面。Service Catalog 是核准的醫療程序目錄 —— 200 個經過審核的程序，每個程序都具備受控的參數（參數約束：劑量範圍、設備清單）。任何合格的醫生都可以啟動「標準膽囊切除術，ASA-2 病患」，手術室就會配置正確的團隊（啟動約束 —— 醫院授權的團隊配置角色，而非醫生的個人憑證）。TagOptions 是附加到每個程序用於計費和報告的標準收費代碼。
AppConfig 是每班次的臨床規程更新 —— 新的敗血症規程可以逐漸為夜班開啟（部署策略：10% 床位，然後 50%，最後 100%），根據 JSON Schema 進行驗證（必填欄位如觸發閾值是否存在），如果早報顯示結果變差，則自動還原（基於警示的回滾）。
功能旗標是針對每位醫生的切換開關 —— 「史密斯醫生的實驗性抗生素規程」可以為一部分病患啟用，而無需重新部署整個電子健康記錄 (EHR) 系統。客戶端 (EHR) 在請求時調用 AppConfig，並根據旗標值做出不同行為。
類比 3：建築許可系統 vs 即時工地調整
一個城市有兩個控制介面。Service Catalog 是建築許可辦公室 —— 50 種預先核准的建築類型（單戶住宅、兩層公寓、商業倉庫），每種都有受限的參數（地塊大小限制、高度限制）。市民無需成為城市規劃師即可自我服務申請許可；辦公室的許可發放角色（啟動約束）負責實際備案。
AppConfig 是交通號誌控制中心 —— 「此路口的綠燈時間增加 5 秒」可以部署到一個號誌燈，經過驗證，然後擴展到一條走廊，最後全市推廣，如果在變更期間事故報告尖峰增加，則自動恢復。
StackSet 約束是多轄區許可模式 —— 一個許可申請可同時在三個相連的區塊配置相同的倉庫，適用於在相鄰社區開設連鎖店。
對於 Service Catalog 啟動約束的推理（「使用者不需要底層 IAM」），餐廳廚師 + 香料櫃映射最清晰。對於 AppConfig 部署策略與自動回滾，交通號誌控制中心最接近。對於 TagOptions 與治理標記，醫院程序計費代碼更直觀。參考：https://docs.aws.amazon.com/servicecatalog/latest/adminguide/constraints.html
Service Catalog 架構
Service Catalog 有三個主要實體，其上層疊了一個約束系統。
組合、產品與版本
產品 (Product) 是一個 CloudFormation 模板（或透過 Terraform 引擎實現的 Terraform 配置）。每個產品有多個版本（如 v1.0, v1.1），以便管理員在不破壞現有已佈建產品的情況下進行迭代。
組合 (Portfolio) 對產品進行分組，並透過主體授權將其分配給 IAM 主體（使用者、群組、角色）。終端使用者僅能看到他們有權存取的組合中的產品。
終端使用者配置 (Provision) 產品並提供參數值；Service Catalog 在啟動約束角色下調用 CloudFormation，並將結果追蹤為具備 terminate、update、view-history 操作的已佈建產品。
約束類型
約束附加到 (組合, 產品) 對上：
- 啟動約束 (Launch constraint)：Service Catalog 在啟動時假設的 IAM 角色。終端使用者只需要
servicecatalog:ProvisionProduct權限；該角色擁有底層 CloudFormation 所需的任何權限（RDS 建立、EC2 啟動）。如果沒有啟動約束，終端使用者將需要對模板建立的每個資源擁有直接的 IAM 權限 —— 這違背了治理的初衷。 - 模板約束 (Template constraint)：縮小參數值的 JSON 規則（
AllowedValues,MinValue,MaxValue, 正則表達式）。比 CloudFormation 參數約束更嚴格，因為它們僅在透過 Service Catalog 啟動時套用。 - 通知約束 (Notification constraint)：用於啟動事件的 SNS 主題。
- StackSet 約束：在一次配置調用中，將產品作為 CloudFormation StackSet 部署到多個帳戶和區域。
- ResourceUpdate 約束 (
TagUpdates)：防止終端使用者更改由目錄管理員擁有的資源上的標籤。
組合共享
您可以透過以下方式將組合共享給另一個帳戶或組織單位：
- 帳戶級別共享：按帳戶明確授權；接收帳戶匯入組合。
- 組織共享 (Organizations sharing)：與 OU 或整個組織共享；接收者無需明確匯入即可看到組合。
- 中樞與輻輳 (Hub-and-spoke) 模式：工具帳戶中的中央組合共享給所有成員帳戶；產品會進行版本控制並傳播。
在接收帳戶中啟動共享產品時，啟動約束角色存在於接收帳戶（而非來源帳戶）中 —— 共享組合要求每個接收者都具備等效的啟動角色。
配置產品的終端使用者僅需要 servicecatalog:ProvisionProduct 和 servicecatalog:DescribeRecord 權限。啟動約束角色則擁有重量級權限（CloudFormation create stack, RDS create instance, EC2 launch）。這是核心治理價值 —— 開發人員在不直接持有強大 IAM 權限的情況下，自我服務獲取合規資源。參考：https://docs.aws.amazon.com/servicecatalog/latest/adminguide/constraints-launch.html
TagOptions
TagOptions 是管理員定義的鍵值對，可附加到組合或產品。啟動產品時，匹配的 TagOptions 會套用於產生的 CloudFormation 堆疊，並傳播到可標記資源。這強制執行了一致的標記（如 CostCenter, DataClassification），而無需依賴終端使用者記住。
更新組合上的 TagOption 不會傳播到現有的已佈建產品。若要在已啟動的產品上強制執行新標籤，您必須更新每個已佈建產品（這會觸發 CloudFormation 堆疊更新） —— 或者使用 AWS Config 修復來追溯性地修復標籤。參考：https://docs.aws.amazon.com/servicecatalog/latest/adminguide/tagoptions.html
Service Catalog vs StackSets vs 直接使用 CloudFormation
| 需求 | 選擇 |
|---|---|
| 終端使用者在具備治理的情況下自我服務啟動 | Service Catalog |
| 將相同的基準推送到多個帳戶，無需終端使用者選擇 | StackSets |
| 具備完整 CloudFormation IAM 的高級使用者 | 直接使用 CloudFormation |
| 無需使用者感知的一致性標記 | 具備 TagOptions 的 Service Catalog |
| 具備版本的產品目錄 | Service Catalog |
| 從單一組合進行多帳戶啟動 | 具備 StackSet 約束的 Service Catalog |
AppConfig 架構
AppConfig 有四個實體：應用程式、環境、配置設定檔和部署策略。
應用程式與環境
應用程式是邏輯範圍（如 OrdersService）。環境是應用程式內的部署目標（dev, staging, prod）；每個環境都可以附加用於自動回滾的 CloudWatch 警示。
配置設定檔 (Configuration Profile)
配置設定檔指向配置數據所在地：
- AppConfig 託管：數據存儲在 AppConfig 內部。
- Amazon S3：從 S3 獲取數據。
- Systems Manager 參數存放區：從參數存放區獲取數據。
- Systems Manager 文件：從 SSM 文件獲取數據。
- CodeCommit：從 CodeCommit 儲存庫路徑獲取數據。
設定檔還具備類型：
AWS.Freeform：任意文本/JSON/YAML。AWS.AppConfig.FeatureFlags：結構化的功能旗標架構。
驗證器 (Validators)
配置設定檔可以具備在部署新配置版本時運行的驗證器：
- JSON Schema 驗證器：根據架構驗證結構（必須包含必填欄位、枚舉約束、類型檢查）。
- Lambda 驗證器：使用配置數據調用 Lambda 函數；Lambda 返回成功或失敗。
如果任何驗證器失敗，部署將在任何客戶端接收新版本之前被拒絕。
部署策略 (Deployment Strategy)
部署策略定義：
- 部署持續時間：從開始到所有目標的總時間。
- 增長因子 (Growth factor)：每個增長間隔額外增加的流量百分比。
- 增長類型：
LINEAR（均勻）或EXPONENTIAL。 - 最終烘焙時間 (Final bake time)：在宣佈成功前在 100% 處等待的時間（期間 CloudWatch 警示可觸發回滾）。
- 複寫至：選擇性保存到 SSM（跨帳戶傳播）。
AWS 提供預定義策略：
AppConfig.AllAtOnce：立即 100%，無烘焙時間。AppConfig.Linear50PercentEvery30Seconds：30 秒時 50%，60 秒時 100%。AppConfig.Canary10Percent20Minutes：10% 持續 20 分鐘，然後在接下來的 20 分鐘內提升至 100%。
基於 CloudWatch 警示的自動回滾
每個環境都可以附加 CloudWatch 警示。在部署期間（以及最終烘焙時間期間），如果任何附加的警示轉換為 ALARM，AppConfig 會自動回滾到以前的配置版本。這是配置變更與執行階段健康狀況之間的橋樑。
基於 CloudWatch 警示的回滾僅在部署持續時間加上最終烘焙時間期間有效。烘焙時間成功完成後，AppConfig 不再監控回滾 —— 後續警示不會自動還原。為了實現持續保護，您需要由警示上的 EventBridge 規則觸發一次對先前版本的新部署。參考：https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-deployment-strategy.html
功能旗標 (Feature Flags)
AWS.AppConfig.FeatureFlags 設定檔類型提供結構化的功能旗標架構：
- 每個旗標具有名稱、描述、屬性。
- 旗標值為
enabled: true|false加上選用屬性（例如rolloutPercentage: 50）。 - 客戶端透過讀取部署的配置並檢查旗標值來評估旗標。
功能旗標 + 部署策略 + 驗證器讓您在 AWS 原生環境中獲得類似 LaunchDarkly 的行為，其執行階段成本為 AppConfig 數據平面 API 調用（擴充層快取可大幅減少這些調用）。
AppConfig 數據平面 (Data Plane)
客戶端透過 AppConfig 數據平面獲取配置：
- AppConfig 代理程式：Sidecar（Lambda 擴充層、ECS Sidecar、EC2 守護程序），定期輪詢 AppConfig 並透過本地 HTTP 端點公開當前配置。客戶端從
localhost讀取，絕不直接從 AppConfig 讀取。 - SDK 直接調用：客戶端自行調用
StartConfigurationSession和GetLatestConfiguration。
偏好代理程式模式，因為它可以快取並減少 API 調用。
AppConfig vs 參數存放區 vs Secrets Manager
| 需求 | 選擇 |
|---|---|
| 很少更改的靜態配置（DB 端點） | 參數存放區 (Parameter Store) |
| 需要輪換的秘密（DB 密碼） | Secrets Manager |
| 具備逐漸推出的功能旗標 | AppConfig |
| 具備驗證器 + 自動回滾的執行階段配置 | AppConfig |
階層式結構化配置 (/app/env/key) |
參數存放區 |
| 跨區域複寫的秘密 | Secrets Manager (複本) |
| 經過 JSON Schema 驗證的配置 | AppConfig |
AppConfig 存儲配置數據；它並非為認證資訊設計。對於輪換秘密請使用 Secrets Manager，對於低頻率秘密請使用參數存放區 SecureString。AppConfig 的數據平面針對高吞吐量讀取進行了優化，而非靜態加密與輪換。參考：https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html
Service Catalog 營運模式
DOP-C02 情境會測試三種 Service Catalog 營運模式。受限的產品啟動： 組合定義啟動約束（配置時假設的 IAM 角色）和模板約束（終端使用者可覆寫哪些 CloudFormation 參數）。僅具備 servicecatalog:ProvisionProduct 權限的終端使用者可以啟動產品，但無法查看或更改底層 CloudFormation 堆疊 —— 約束角色承擔了繁重的工作。用於成本分配的 TagOptions： 附加到組合的 TagOptions 在每個已佈建產品上強制執行必填的標籤鍵與值，因此中央平台團隊可以保證 cost-center、environment 和 owner 等標籤存在，而無需每位終端使用者記住。透過 AWS Organizations 進行跨帳戶產品共享： 與其為每個帳戶複製組合，不如在整個組織中共享一次並集中更新 —— 版本更新會傳送到取用帳戶而無需重新配置。
AppConfig 部署策略選擇
AppConfig 的三種受管部署策略對應於考試測試的三種風險設定。AppConfig.AllAtOnce 在單個脈衝中將新配置推向 100% 的客戶端 —— 對於微不足道的變更很快，對於行為變更則很危險。AppConfig.Linear50PercentEvery30Seconds 以 50/50 的步驟進行，並具備 30 秒的烘焙期 —— 當警示連接到回歸時短路很有用。AppConfig.Canary10Percent20Minutes 運行真正的金絲雀：10% 持續 20 分鐘，然後 20%，然後 40%，最後 100% —— 生產環境功能旗標最防禦性的預設選擇。考試會設置圈套，讓考生在功能旗標後的行為變更上選擇 AllAtOnce，而正確答案是「切換到金絲雀策略並連接 CloudWatch 警示以停止部署」。
常見陷阱 (Common Pitfalls)
- 忘記 Service Catalog 啟動約束角色：終端使用者在啟動期間會收到 IAM 權限錯誤，即使他們擁有
ProvisionProduct權限。 - 在沒有接收方啟動角色的情況下共享組合：啟動約束引用的是接收帳戶中的角色；如果該角色不存在，啟動會失敗。
- 更新 TagOptions 並期望追溯套用：TagOptions 僅在啟動時套用。
- 將 AppConfig 自動回滾視為持續保護：它僅在部署 + 烘焙窗口期間監控。
- 在 AppConfig 中存儲秘密：請改用 Secrets Manager 或參數存放區 SecureString。
- 跳過驗證器：將無效配置部署到生產環境是人為引發的故障；驗證器可以捕捉它。
- 在不快取的情況下直接使用 AppConfig SDK：高吞吐量客戶端應使用 AppConfig 代理程式（Lambda 擴充層或 Sidecar）以進行快取並避免流量調整。
FAQ
Q1：何時應偏好 Service Catalog 而非 CloudFormation StackSets？
當終端使用者需要根據參數選擇進行自我服務時選擇 Service Catalog；當管理員在沒有終端使用者輸入的情況下將相同的基準推送到許多帳戶時選擇 StackSets。具備 StackSet 約束的 Service Catalog 結合了兩者 —— 終端使用者配置一個產品，該產品本身作為 StackSet 展開。
Q2：Service Catalog 可以使用 Terraform 嗎？
可以，AWS 發布了 Service Catalog Terraform 參考引擎以及 AWS 支持的 Terraform 整合。產品可以是存儲在 S3 中的 Terraform 配置，由 Service Catalog 管理版本控制與終端使用者啟動。CloudFormation 仍然是預設且測試最多的選項。
Q3：AppConfig 與功能旗標 SaaS（如 LaunchDarkly）有何不同？
AppConfig 是 AWS 原生的（無額外供應商），與 CloudWatch 警示整合以進行自動回滾，具備內建驗證器，並且是 Systems Manager 的一部分。SaaS 功能旗標工具通常具備更豐富的客戶端 SDK、進階目標鎖定（按使用者屬性）以及專用儀表板。對於僅具備簡單旗標需求的 AWS 工作負載，AppConfig 已足夠且無需額外供應商。
Q4：AppConfig 支持巢狀配置或按租戶數據嗎？
AppConfig 為環境中的所有客戶端交付相同的配置。對於按租戶或按使用者的配置，配置文檔本身可以包含結構（例如 tenants: { tenantA: {...}, tenantB: {...} }），客戶端選擇其切片。AppConfig 本身不按客戶端身分進行細分。
Q5：我可以在 CodePipeline 中使用 Service Catalog 產品嗎？
可以，CodePipeline 具備 Service Catalog 動作，可從 CodeCommit/S3 來源建立或更新產品與版本。這是「開發人員提交 CloudFormation 模板；CodePipeline 進行測試；Service Catalog 自動發布新版本」的模式。
Q6：當底層產品被刪除時，已佈建的產品會發生什麼？
已佈建的產品在底層產品版本刪除後仍會存續。終端使用者仍可以終止、更新（在原本啟動的版本內）並查看歷史。無法再啟動該版本的新執行個體。若要移除已佈建的產品，您必須明確終止它們。
Q7：如何處理 AppConfig 客戶端需要讀取的秘密？
將 AppConfig 用於非秘密的執行階段配置（功能旗標、閾值、行為切換），並將 Secrets Manager / 參數存放區 SecureString 用於秘密。客戶端兩者都讀取 —— AppConfig 用於行為配置，Secrets Manager 用於認證資訊。在 AppConfig 中混合它們是一種反模式。
總結
Service Catalog 將 CloudFormation 模板封裝為受管的自我服務產品，具備啟動約束、模板約束、TagOptions、StackSet 展開與組合共享 —— 賦予開發人員速度而不會造成 IAM 擴張。AppConfig 交付具備驗證器、逐漸部署策略與基於 CloudWatch 警示自動回滾的執行階段配置與功能旗標 —— 賦予操作員安全的執行階段控制而無需重新部署。受管配置選擇 Service Catalog，受管執行階段配置選擇 AppConfig，靜態配置選擇參數存放區，輪換秘密選擇 Secrets Manager。記住約束類型、部署策略的增長與烘焙機制以及數據平面快取模式，這些情境題目就能迎刃而解。