AMI 管理、EC2 Image Builder 與部署策略

SOA-C02 考試指南 Task Statement 3.1 的標題是「佈建並維護雲端資源」，它將 AMI 衛生管理、EC2 Image Builder Pipeline，以及部署策略選擇放在 SysOps 工作描述的核心。SAA-C03 要求架構師「選擇」部署風格，SOA-C02 則要求 SysOps 管理員「操作」那次部署——排定 AMI 建構時程、跨帳號與跨區域發布 AMI、在不停機的情況下將機群滾換至新 AMI、在凌晨兩點排查失敗的部署，並決定要繼續向前、回滾，還是暫停。本主題的每個字——AMI、EC2 Image Builder、部署——都是真實的值班 SysOps 工程師每週都會接觸的工作。

本學習筆記從建立到 deregister 完整走過 AMI 生命週期，涵蓋 EC2 Image Builder Pipeline 機制（Recipes、Components、Build/Test 階段、基礎設施設定、Distribution Settings、Lifecycle Policy），以及四種考試重點部署策略——All-at-Once、Rolling、Blue/Green 與 Canary——並說明 Launch Template、Auto Scaling Group Instance Refresh、Warm Pool 與 CloudFormation UpdatePolicy 如何將這些策略串接進運維流程。途中你會看到反覆出現的 SOA-C02 陷阱：AMI 跨帳號共享因快照使用 customer-managed KMS key 加密而失敗、deregister AMI 卻沒有意識到這不會終止正在運行的 instance、Image Builder Lifecycle Policy 刪除了 Launch Template 仍在參照的 AMI，以及因為 MinHealthyPercentage 和 warmup 未調整而在 Rolling 部署中產生短暫的 5xx 飆升。CodeDeploy 與 CodeBuild 不在 SOA-C02 範圍內，此處僅作為背景脈絡提及。

為什麼 AMI、Image Builder 與部署是 TS 3.1 的核心

官方 SOA-C02 考試指南 v2.3 在 Task Statement 3.1 下列出五項技能：建立並管理 AMI（明確點名 EC2 Image Builder）、建立/管理/疑難排解 CloudFormation、跨區域與跨帳號佈建、選擇部署情境（Blue/Green、Rolling、Canary），以及識別並修復部署問題（服務配額、子網路大小、CloudFormation 錯誤、權限）。本主題完全涵蓋第一與第四項技能，以及第五項中與 AMI 相關的失敗模式；CloudFormation 有自己的主題（cloudformation-stacks-and-stacksets）負責第二項技能，StackSets/RAM 涵蓋第三項。

在 SysOps 層級，問題框架是運維導向的。SAA-C03 問「哪種部署策略符合這個 RTO 需求？」SOA-C02 問「Rolling 部署在 instance 替換期間產生 5xx 錯誤——你要調整哪個設定？」答案很少是換一個策略，而是 MinHealthyPercentage、health-check grace period、target group deregistration delay，或是 warm pool 大小。AMI 的情境也一樣：問題很少是「我們應該使用 golden AMI 嗎？」——生產機群當然應該——而是「Patching Pipeline 兩週前就產生了新 AMI，機群卻還在舊的上面——哪裡出了問題？」答案可能是 Image Builder Pipeline 排程、EventBridge 規則、從未觸發的 Instance Refresh，或者 Launch Template 仍被釘選在某個特定 AMI ID 而非 $Latest。

白話文解釋 AMI、EC2 Image Builder 與部署策略

映像與部署術語堆疊得很快。三個類比能讓這些概念更容易記憶。

類比一：壽司師傅的標準食譜與每日握壽司

把 AMI 想成師傅在傳授技藝前精心訂定的標準食譜卡——每位師傅按照這張卡做出來的握壽司，米飯、醋、厚度都一模一樣。AMI ID 就是那張食譜卡上的編號標籤（ami-0abc...），讓你能在儲藏室中精確取出同一份配方。EC2 Image Builder 是每週一自動啟動的壽司廚房流水線：它取出上週的食譜，拿來最新一批的米（上游 Amazon Linux 2023 AMI），按順序加入標準食材（CloudWatch agent、SSM agent、安全基線、應用程式執行環境），捏成測試品，讓評鑑師試吃（Component 測試階段），只有通過才會在新食譜卡上蓋章並歸檔。Image Recipe 是那張手寫的食譜卡——基礎米飯加上有序的食材清單。Components 是廚房裡標示清楚的食材罐（amazon-cloudwatch-agent-linux、update-linux、你自訂的 install-payment-app 罐）。Distribution Settings 是外送名單——哪些分店（region）、哪家合作餐廳（其他 AWS 帳號）能拿到這份新食譜卡，以及各地冷藏箱用的是哪把鑰匙（KMS key）。Image Lifecycle Policy 是過期食譜卡銷毀規則——超過 90 天的舊食譜卡一律銷毀，避免儲藏室堆滿過時配方。Deprecation 是在食譜卡上貼「請勿再點用」的貼紙；Deregistration 才是真正將食譜卡撕毀丟棄。最重要的是：已經按舊食譜做好端上桌的壽司（正在運行的 EC2 instance）並不受影響——客人繼續享用，直到下次點餐才會依新食譜製作。

類比二：飯店客房翻新的四種策略

現在把部署新版本想成翻新一間有 100 個房間的飯店。All-at-Once 部署是關閉整棟飯店一個週末，同時翻新所有房間——最快、最省事，但飯店在翻新期間分文未賺，萬一新裝潢客人不喜歡，週一開門所有人都看到同樣的錯誤。Rolling 部署是每次只翻新 10 間——其他 90 間的住客不受影響繼續住宿，但如果新裝潢出了問題，等你發現時 30 間已經翻完，整棟飯店風格不統一，直到修復前都是大雜燴。Blue/Green 部署是另建一棟全新的 100 間新館，裝潢完美後把所有新訂房導向新館，舊館讓已入住的客人住完再拆除——成本最高（要短暫付兩棟的費用），但最安全，因為舊館還在，客人若有怨言可以立刻切回。Canary 部署是先只開放新館的 5 間給一小群熟客試住，觀察評論兩天，口碑良好才開放其餘客房。SOA-C02 考試的重點在於：什麼時候選哪種方式——Rolling 適合例行版本更新與無狀態應用；Blue/Green 適合必須保證零停機且需要即時回滾的情境；Canary 適合不能讓全部使用者同時承受風險的變更；All-at-Once 只用在非生產環境或排定維護視窗。

類比三：共用同一份規格書的外送車隊

Launch Template 是公司交給車輛工廠的規格書：底盤型號（instance 類型）、引擎（AMI ID）、車體塗裝（安全群組）、司機工具包（IAM instance profile）、預載軟體（user data）。車隊管理員不需要每次手動輸入規格——只要參照這份規格書。當底盤型號升級時，管理員發布規格書的新版本（Version 4），並告訴調度系統「從現在起，所有替換車輛都用規格書 $Latest」。Auto Scaling Group 是調度系統：它知道要隨時保持 50 輛車在路上，每次補充都從 Launch Template 最新版本取規格，並可執行 Instance Refresh——也就是「把所有舊規格的車換成新規格，但絕不讓健康的車隊容量低於 90%」。Warm Pool 是停在車庫裡已組裝好但待命中的預備車，一旦調度系統需要車輛，可以立刻出動——比冷啟動省時，比什麼都不準備省錢。

AMI 基礎：結構、權限與 Block Device Mapping

在部署策略有意義之前，你需要對 AMI 的實際內容有精確的認識。

AMI 的內部構成

AMI 是元資料加上指向一個或多個 EBS 快照的指標。元資料記錄了：架構（x86_64、arm64）、虛擬化類型（HVM 是現代唯一選項）、根裝置類型（幾乎都是 ebs）、核心/RAM disk ID（舊式）以及 Block Device Mapping——列出 instance 啟動時將獲得的每個磁碟區。Block Device Mapping 為每個磁碟區參照 EBS 快照——根磁碟區快照是必填，可額外指定資料磁碟區用於暫時資料、swap 或預填充的參考資料。

AMI 本身不儲存快照資料，只儲存指標。當你把 AMI 複製到另一個 region 時，底層快照也會一起複製，目標 region 的新 AMI 指向目標 region 的快照。當你 deregister 一個 AMI 時，快照不會自動刪除——它們持續產生儲存費用，直到你明確刪除為止。Image Builder Lifecycle Policy 在刪除 AMI 時會一併刪除底層快照，這是最乾淨的運維模式。

AMI 權限與共享

每個 AMI 都有一組啟動權限，決定誰可以從它啟動 instance：public（任何人）、特定 AWS 帳號 ID，或只有你自己的帳號（預設）。SOA-C02 你必須記住，與另一個帳號共享 AMI 需要三件事同時到位：

1. AMI 本身的啟動權限已授予目標帳號 ID。
2. 底層快照的 EBS 快照權限也已授予目標帳號。
3. 如果快照使用 customer-managed KMS key 加密，則需要為目標帳號設定 KMS key grant 或 key policy 權限，否則目標帳號雖然看得到 AMI，卻無法從中啟動 instance。

第三個條件是 SOA-C02 最常讓考生落入的陷阱。你可以完美地共享 AMI 元資料，但如果快照使用的 CMK 的 key policy 沒有授權目標帳號，啟動時就會失敗並出現 key 存取錯誤。預設的 aws/ebs AWS-managed key 完全無法跨帳號共享——你必須在複製時使用 customer-managed key 重新加密。

AMI 生命週期狀態

AMI 歷經一個定義明確的生命週期：

• Create / register — AMI 誕生，來源可以是正在運行的 instance（CreateImage）、快照（RegisterImage），或是 Image Builder Pipeline 執行結果。
• Available — instance 可以從中啟動；AMI 顯示在 EC2 主控台的「My AMIs」下。
• Deprecated — AMI 被標記為自某日起 deprecated；擁有帳號仍可以透過明確 ID 啟動，但對其他帳號的搜尋結果和主控台列表中已隱藏。Auto Scaling Group 仍會繼續從 deprecated AMI 啟動。
• Disabled — 為更強的生命週期控制引入的獨立狀態：disabled AMI 連擁有帳號也完全無法用來啟動新 instance，直到重新啟用為止。
• Deregistered — AMI 元資料已移除；任何人都無法再從這個 AMI ID 啟動新 instance。從該 AMI 啟動的既有 instance 繼續正常運行，不受影響。
• 快照刪除 — 底層 EBS 快照被刪除（獨立 API），回收儲存成本。若省略此步驟，deregistered AMI 的快照將持續存在並產生費用。

跨 region AMI 複製

copy-image API 將 AMI（及其快照）複製到另一個 region。三個運維注意事項：

• 加密：你可以選擇用不同的 KMS key 加密目標 AMI——通常是為了使用該 region 本地的 CMK，而非重複使用來源 region 的 key。若來源未加密，可以在複製時加密。若來源使用 CMK 加密，複製操作需要在來源 key 上有 kms:CreateGrant，以及在目標 key 上有 kms:Encrypt/kms:GenerateDataKey。
• 權限：複製的 AMI 不繼承啟動權限——目標 AMI 預設對你的帳號設為 private，必須明確重新授予。
• 費用：兩個 region 都產生儲存費用，初次複製還有跨 region 快照資料傳輸費。

對於多 region 部署，Image Builder Distribution Settings 會自動處理這一切——你在 Distribution Config 中宣告目標 region，Image Builder 就會執行複製，並套用各 region 的啟動權限和加密 key，無需另行呼叫 API。

Golden AMI 模式：為什麼每個機群都應該從它開始

Golden AMI 是組織預先加固的基礎映像，所有機群的 Launch Template 都指向它。它包含已修補的 OS、標準 agent（CloudWatch、SSM、OS 層級監控）、安全基線（CIS 對齊的加固設定、sshd 設定、稽核規則），以及可選的應用程式執行環境基線（JDK 版本、語言執行環境）。應用程式程式碼本身「不在」Golden AMI 裡——那部分透過 user data、設定管理或從 Golden AMI 建構的獨立應用程式 AMI 來疊加。

Golden AMI 模式是運維標準，原因有三：

• 啟動時一致性：每個新 instance 起點完全相同。不再有「這台 instance 缺少 CloudWatch agent，因為 user-data 靜默失敗了」的情況。
• 縮短修補延遲：最新的 Golden AMI 帶有上週的 CVE 修補。每週重新烘焙意味著新 instance 啟動就具備最新修補，無需事後追趕就地修補。
• 稽核與合規：Golden AMI 是單一、不可變的產出物，可以簽署、雜湊並在合規稽核中引用。手工建置的 instance 無法以這種方式稽核。

EC2 Image Builder 是 AWS 原生製作 Golden AMI 的方式，SOA-C02 要求你詳細了解其機制。

EC2 Image Builder：Pipeline、Recipe、Components

EC2 Image Builder 是自動化 AMI 與容器映像建構、測試與發布的受管服務。它透過 Pipeline DSL、Component DSL、Distribution Settings 和 Lifecycle Policy 作為第一級 AWS 資源，消除了手工搭建 Packer 加 Jenkins（或 shell 腳本加 AMIs.sh）的需求。

Pipeline 物件模型

Image Builder Pipeline 是頂層物件，它將以下元素綁定在一起：

• 一個 Image Recipe（或 Container Recipe）——要建構什麼的規格。
• 一個基礎設施設定——執行建構所使用的 EC2 instance 類型、子網路、IAM instance profile、key pair 與安全群組（Image Builder 會啟動一個暫時的 builder instance，在其中執行 recipe、拍攝快照，再銷毀 instance）。
• 一個 Distribution Settings——產生的 AMI 複製到哪裡（region 和帳號）、使用什麼權限和哪些 KMS key。
• 可選的排程——pipelineExecutionStartCondition 為 EXPRESSION_MATCH_ONLY（僅依 cron 執行）或 EXPRESSION_MATCH_AND_DEPENDENCY_UPDATES_AVAILABLE（依 cron 執行，同時在上游基礎 AMI 或參照的 Component 發布新版本時也執行）。cron 表達式本身使用標準 cron(...) 語法。
• 可選的映像測試設定——是否執行 recipe 的測試 Components，以及等待多長時間。

Pipeline 執行時，Image Builder 會產生一個新的映像（Image Builder 用來稱呼輸出 AMI 加上其元資料的術語），指派語意版本號（1.2.3/4 代表 recipe 版本 1.2.3、建構計數器 4），並執行發布。

Image Recipe

Recipe 宣告：

• Parent Image — AWS-managed 基礎 AMI（例如 Amazon Linux 2023 x86）、AMI ID，或 Image Builder 先前建構的另一個映像。Parent Image 是版本化參照；選擇 latest 代表下次 Pipeline 執行時自動拉取最新基礎版本。
• 有序的 Build Components 清單——安裝套件、複製檔案、執行腳本、設定 agent。
• 可選的有序 Test Components 清單——建構後執行驗證腳本，若失敗則中止 Pipeline。
• Block Device Mapping — 根磁碟區大小、類型（通常是 gp3）、若需要可加額外資料磁碟區，以及加密設定。
• 可選的工作目錄和額外 instance 設定（user data 覆寫）。

Recipe 一經發布即不可變——要更改任何內容，必須發布新的 recipe 版本。Pipeline 以名稱和版本（或 latest）參照 recipe。

Components

Component 是 YAML 文件，宣告一系列包含步驟的階段（build、validate、test）。步驟可以：

• 執行 shell 腳本（ExecuteBash、ExecutePowerShell）。
• 從 S3 下載檔案（S3Download）。
• 設定環境變數並重新開機。
• 呼叫 SSM agent 操作。

AWS 提供數百個受管 Components 用於常見任務——update-linux、amazon-cloudwatch-agent-linux、aws-cli-version-2-linux、chrony-time-configuration-test、simple-boot-test-linux 等。客戶可自行撰寫自訂 Components 以完成組織特有的設定：安裝企業根憑證、設定 syslog forwarder、安裝應用程式執行環境。

Components 有版本號（1.0.0、1.0.1），發布至各 region 的 Component 儲存庫。跨 region Pipeline 需要 Component 在每個目標 region 都可用——Image Builder 對 AWS-managed Components 透明處理，但自訂 Components 必須發布到各 region，或透過 Component DSL 跨 region 共享。

基礎設施設定

基礎設施設定告訴 Image Builder 使用哪種 instance 作為 builder，以及放入哪個網路。重要欄位：

• Instance types — 至少一個（若容量不足，Image Builder 會回退到其他類型）。
• Subnet ID 和安全群組 ID — 必須允許輸出存取 S3（Component 產出物）、Amazon Linux 套件庫，以及 AWS API。典型設定：private 子網路加 NAT gateway，再加上 SSM、EC2、S3 和 Image Builder 的 VPC Endpoints（若想要完全私有的建構環境）。
• IAM instance profile — builder instance 假設此角色來執行工作。必須包含 EC2InstanceProfileForImageBuilder、AmazonSSMManagedInstanceCore，以及你的 Components 所需的任何自訂權限（S3 讀取用於下載等）。
• Logging — 寫入建構日誌的 S3 bucket；疑難排解失敗建構時不可或缺。
• 失敗時終止 — 建構失敗時保留 builder instance 以便 SSH 進去除錯，或終止它（預設：終止，但開發 Pipeline 可改為保留）。

Distribution Settings

Distribution Settings 指定產生的 AMI 要去哪裡：

• Regions — 目標 region 清單（來源 region 隱含其中；其他 region 為複製）。
• 各 region：AMI 名稱與描述、啟動權限（帳號 ID、組織或 all），以及用於加密目標快照的 KMS key。
• License configurations — 選用的 License Manager 附件，用於 BYOL 工作負載。
• Launch Template 關聯 — Image Builder 可以自動更新目標 Launch Template，使其指向最新版本的 AMI，並可選擇透過 SNS 或 EventBridge 通知。這是將「新 AMI 已就緒」連結到「ASG 可以取用」的運維膠水。

Image Lifecycle Policy

Image Lifecycle Policy 是 Image Builder 規則，依排程自動 deprecate 並刪除舊 AMI（及其快照）。沒有 Lifecycle Policy，AMI 數量和快照儲存將無限增長——每週 Pipeline 執行一次就產生一個新 AMI，費用不斷累積。

Lifecycle Policy 宣告：

• Resource selection — 依映像名稱模式、標籤或 recipe 篩選。
• Retention rules — 保留最新 N 個版本，或保留 X 天內的版本。
• Action sequence — 通常先 deprecate（將舊 AMI 標記為不建議使用）、等待 Y 天，然後刪除（deregister AMI 並刪除快照）。考試要求你記住標準流程：deprecate → 等待 → disable → 等待 → delete。
• 跨帳號行為 — 操作可以只在來源帳號套用，或也傳播到 AMI 已發布至的目標帳號。

Launch Template：AMI 釘選 vs Latest 參照

Launch Template 是版本化的 EC2 啟動規格。ASG 和 EC2 主控台在啟動新 instance 時參照它們。

為什麼 Launch Template 優於 Launch Configuration

Launch Configuration 是舊式替代方案——不可變、沒有版本控制、新 ASG 已棄用。Launch Template 有版本控制，支援更多 EC2 功能（T3 unlimited mode、Hibernation、Capacity Reservations、強制 instance metadata service v2），並與 EC2 Image Builder Distribution 整合。SOA-C02 全程使用 Launch Template；Launch Configuration 只出現在錯誤選項中。

AMI ID 釘選 vs $Latest

在 Launch Template 版本中，AMI ID 以字面值儲存（ami-0abc...）。當底層 AMI 改變（新的 Image Builder 執行產生 ami-0def...），你有兩個選項：

• 釘選到特定 AMI ID — 每個 Launch Template 版本明確參照一個 AMI。要向前滾動，你發布帶有新 AMI ID 的新 Launch Template 版本，ASG 指向新版本（或 $Latest）。
• 在 ASG 設定中使用特殊版本 $Latest — ASG 永遠從最新的 Launch Template 版本啟動新 instance。若最新版本昨天帶著新 AMI 發布，今天啟動的 instance 就使用新 AMI。

第三個選項 $Default 指向 Launch Template 指定的預設版本，通常是你已驗證可供生產使用的版本。有些團隊在 ASG 啟動時使用 $Default，而 $Latest 保留給 Canary 或測試 ASG。

將機群更新至新 AMI

更新 Launch Template 版本不會自動替換已在運行的 instance。新啟動會取用新 AMI，但既有 instance 會保留，直到被明確替換。替換途徑：

• Auto Scaling Group Instance Refresh — ASG-managed 機群的 SOA 標準答案。
• CloudFormation UpdatePolicy: AutoScalingRollingUpdate — 當 ASG 由 CloudFormation 管理時的 IaC 驅動等效方式。
• CloudFormation UpdatePolicy: AutoScalingReplacingUpdate — Blue/Green 風格的 stack 替換。
• 手動終止 — 一個一個終止舊 instance，讓 ASG 用新 AMI 啟動替換；僅適用於極小機群。

Auto Scaling Group Instance Refresh：運維核心

Instance Refresh 是用新 Launch Template 版本替換正在運行 instance 的 ASG 操作。它是 SOA-C02 中運維測試最多的部署機制。

Instance Refresh 如何運作

你啟動 ASG 的 Instance Refresh 時帶有以下參數：

• Strategy — 目前只有 Rolling（可能有更多策略加入，但 Rolling 是 SOA-C02 生產就緒的選項）。
• MinHealthyPercentage（預設 90）— 刷新期間健康容量的下限。若設 90，有 10 個 instance 的 ASG 每次最多替換 1 個；有 100 個 instance 的 ASG，最多同時替換 10 個。降低此值可加快刷新（更多並行）但代價是容量短暫降低；調高到 100 則要求先啟動新 instance 再終止舊的（零降幅 Rolling，速度較慢）。
• InstanceWarmup — 新 instance 啟動後、被計為健康並允許開始下一批前要等待的時間。依應用程式的暖身時間調整（JIT 編譯、快取預熱、ELB target 健康檢查穩定）。
• CheckpointPercentages 和 CheckpointDelay — 在指定完成百分比暫停刷新以供驗證。常見模式：在 25% 時暫停一小時以驗證 canary 群組，再繼續。
• Skip Matching — 跳過已在執行新 Launch Template 版本的 instance，確保恢復部分失敗的刷新時不會重複替換。

MinHealthyPercentage 與部署風格的交互作用

MinHealthyPercentage 設定實際上決定了 Instance Refresh 呈現何種部署風格：

• MinHealthyPercentage = 100 — 先啟動新 instance，再終止舊的。實現 instance 層級的零降幅 Rolling，需要 ASG MaxSize 大於 DesiredCapacity 才能同時存在新舊 instance。最接近 Blue/Green。
• MinHealthyPercentage = 90（預設）— 就地小批替換，短暫容量下降。標準 Rolling。
• MinHealthyPercentage = 50 — 激進的並行替換，高峰時半數機群離線。用於非面向客戶的批次機群。
• MinHealthyPercentage = 0 — All-at-Once 風格（全部終止，重新啟動）。生產環境請避免。

Warm Pool

Warm Pool 是一個保持在 Stopped 或 Hibernated 狀態的預初始化 instance 池，一旦 ASG 需要擴充或刷新，可以迅速上線。Warm Pool 將有效啟動時間從數分鐘（冷啟動 + user data + 暖身）縮短至數秒（恢復 + 向 ELB 註冊）。

Warm Pool 對 Instance Refresh 的意義在於讓 InstanceWarmup 可以縮短——Hibernated instance 帶著已暖好的 JIT 和預熱的快取恢復，因此部署可以在更快的同時仍維持安全。SOA-C02 偶爾測試用 Warm Pool 加速刷新的大小設定。

部署策略：All-at-Once、Rolling、Blue/Green、Canary

四種標準 EC2 部署策略。SOA-C02 測試在給定的運維限制下選擇正確策略，並設定實現它的 AWS 原生資源。

All-at-Once

同時終止所有舊 instance 並啟動所有新 instance（或以單一批次無健康管控）。最快、最簡單、運行成本最低，但整個機群短暫無法使用，且 AMI 有問題時整個機群同時倒下。適用於非生產環境、下班時間的批次作業或排定維護視窗；絕不用於 24/7 面向客戶的生產環境。

實作方式：MinHealthyPercentage = 0 的 Instance Refresh，或 aws autoscaling update-auto-scaling-group 更換 Launch Template 版本後手動終止所有 instance。

Rolling

分批替換 instance，其餘機群繼續服務流量。SOA-C02 例行部署的主導策略。可透過 MinHealthyPercentage、InstanceWarmup 和 target group DeregistrationDelay 調整。單一機群，無雙倍成本。回滾方式是「用舊 Launch Template 版本再啟動一次 Instance Refresh」，若新 AMI 有問題則較慢。

實作方式：帶有預設或自訂 MinHealthyPercentage 的 ASG Instance Refresh。CloudFormation：UpdatePolicy: AutoScalingRollingUpdate { MaxBatchSize, MinInstancesInService, MinSuccessfulInstancesPercent, PauseTime, WaitOnResourceSignals }。

Blue/Green

在新 AMI 上啟動全新機群（Green）並與現有機群（Blue）並行，驗證後再切換流量。EC2 上有兩種實作：

• ALB target group swap — 保留 ALB，切換 listener 轉發到哪個 target group。次秒級切換，切回去即可即時回滾。新 ASG 必須在 Green target group 中完成健康 target 註冊後再執行切換。
• Route 53 weighted routing — Blue 與 Green 機群各有自己的 ALB 或 NLB；Route 53 weighted records 同時指向兩者，權重從 100/0 到 0/100，可選擇中間 50/50 做 Canary 測試。切換速度取決於 DNS TTL。
• CloudFormation stack swap — 部署兩個並行的 CloudFormation stacks（Blue stack 和 Green stack），使用 UpdatePolicy: AutoScalingReplacingUpdate 讓 CloudFormation 建立新 ASG 並切換 LB target，舊 ASG 隨後刪除。

Blue/Green 具備最強的回滾方案（驗證視窗期間舊機群仍在運行），但重疊期間成本加倍。

Canary

將少量流量（通常 5–10%）導向執行新 AMI 的小型機群，觀察指標，只有 Canary 健康才繼續。實作方式：

• ALB weighted target groups — listener 的 forward action 同時參照新舊 target group，例如設定權重 (95, 5)。流量在 listener 層拆分。
• Route 53 weighted records — 透過權重拆分 DNS 回應，精確度不及 ALB 加權，因為客戶端會快取 DNS。
• Instance refresh checkpoints — 以 CheckpointPercentages: [10, 100] 和 30 分鐘 CheckpointDelay 啟動 Instance Refresh。刷新在 10% 機群替換後暫停，讓你觀察 Canary 指標，若未中止則繼續到 100%。

Canary 是題目強調「先讓少量使用者測試」且「若指標惡化則提早中止」時的正確答案。

SOA-C02 常見的生產情境：Rolling Instance Refresh 每次替換一批時都產生 30 秒的 5xx 飆升。依序調整三個設定：(1) 將 MinHealthyPercentage 調高接近 100，讓新 instance 先上線「再」終止舊的；(2) 延長 InstanceWarmup，讓新啟動的 instance 完成 JIT 暖身和 ELB 健康檢查穩定才被計為健康；(3) 增加 target group DeregistrationDelay，讓終止中的 instance 上的飛行中請求在連線斷開前完成。三者組合可消除 5xx 飆升，代價是部署速度略微降低。參考：https://docs.aws.amazon.com/autoscaling/ec2/userguide/asg-instance-refresh.html ::

策略選擇決策矩陣

CloudFormation UpdatePolicy：ASG Rolling 與 Replacing 更新

當 ASG 由 CloudFormation 管理時，AWS::AutoScaling::AutoScalingGroup 上的 UpdatePolicy 屬性控制 CloudFormation 如何滾動 Launch Template 變更。

AutoScalingRollingUpdate

就地滾動現有 ASG。關鍵欄位：

• MaxBatchSize — 每批替換的 instance 數量。
• MinInstancesInService — 更新期間的最低健康容量（類似 MinHealthyPercentage）。
• MinSuccessfulInstancesPercent — 每批新啟動 instance 中必須成功發送訊號的百分比，才能繼續下一批。
• PauseTime — 批次之間等待的時間（ISO 8601 格式，例如 PT5M）。
• WaitOnResourceSignals — 若設為 true，CloudFormation 等待每個新 instance 發送 cfn-signal 才計為健康。搭配 user-data 在應用程式啟動後呼叫 cfn-signal 使用。

AutoScalingReplacingUpdate

建立全新的 ASG，將其啟動至滿容量，切換 load balancer target，再刪除舊 ASG。實際上是 ASG 層級的 Blue/Green。新 ASG 在 stack 內具有新的邏輯資源 ID。

AutoScalingScheduledAction

特殊處理在更新期間有排程擴展操作的 ASG——暫停或跳過它們。

考試測試識別哪個 UpdatePolicy 符合題目需求。「完全替換 ASG 以便可以刪除新 ASG 來回滾」→ AutoScalingReplacingUpdate。「以 25% 批次大小就地滾動，每批之間暫停 5 分鐘」→ AutoScalingRollingUpdate 搭配 MaxBatchSize: 25% 等效值 和 PauseTime: PT5M。

情境模式：修補週期後機群仍在執行過時 AMI

SOA-C02 的標準疑難排解情境。Image Builder Pipeline 應該每週執行，但機群仍顯示六週前的 AMI。診斷步驟：

1. 在 Image Builder 主控台查看 Pipeline 執行歷史。Pipeline 上週執行了嗎？上個月？若最近一次執行是六週前，排程已出問題。
2. 檢查排程 — pipelineExecutionStartCondition 和 cron 表達式。常見問題：cron 格式錯誤（CloudWatch Events cron(...) 與 Linux cron 不同——有六個欄位，包含年份），或排程已被停用。
3. 查看觸發 Pipeline 的 EventBridge 規則（若透過事件觸發而非 cron）。它被停用了嗎？規則的 IAM role 是否失去了啟動 Pipeline 的權限？
4. 查看最近失敗建構的日誌，寫入基礎設施設定中指定的 S3 bucket。常見失敗：recipe 參照的 Component 已刪除；Parent 基礎 AMI 已 deprecated 且未設定替換；builder instance 磁碟空間不足；Test Component 失敗且 Pipeline 設定為在測試失敗時中止建構。
5. 確認 Launch Template 已被 Distribution Settings 更新。若 Pipeline 成功但 Launch Template 未變更，表示 Distribution Settings 未包含 Launch Template 關聯。
6. 確認 ASG 參照 $Latest — 若仍參照特定版本號，新的 Launch Template 版本將被忽略。
7. 確認已觸發 Instance Refresh — ASG 只在 Instance Refresh 執行時才替換既有 instance。若其他一切正確，但既有 instance 仍在執行舊 AMI，表示刷新從未發生。

根據我們的經驗，最常見的根本原因是步驟 6——ASG 建立時使用了特定的 Launch Template 版本號，導致更新永遠無法流入。

情境模式：新 AMI 已部署但舊 Instance 未被替換

新 Launch Template 版本已發布。ASG 參照 $Latest。然而既有 instance 仍在執行舊 AMI。診斷步驟：

1. 新啟動使用新 AMI：Launch Template 版本化在啟動時生效，不追溯既往。既有 instance 從舊版本啟動，不會自動替換。
2. 觸發 Instance Refresh：這是明確替換既有 instance 的操作。考試期待你知道 aws autoscaling start-instance-refresh --auto-scaling-group-name <name> 是答案。
3. 調整刷新參數：MinHealthyPercentage、InstanceWarmup、用於 Canary 的 CheckpointPercentages、SkipMatching: true 確保已更新的 instance 不被重複替換。
4. 在 EC2 Auto Scaling 主控台或透過 describe-instance-refreshes 觀察刷新進度。刷新狀態在 Pending、InProgress、Successful 或 Failed/Cancelled 之間轉換。

情境模式：AMI 跨帳號共享在加密快照上失敗

SysOps 團隊與合作夥伴帳號共享 AMI。合作夥伴帳號在主控台看得到 AMI，但 RunInstances 失敗並出現 Client.InvalidVolume.NotFound 或 KMS 存取錯誤。步驟：

1. 確認 AMI 啟動權限 — 合作夥伴帳號 ID 必須在 AMI 的啟動權限中。使用 describe-images --image-ids ... --owners self 並檢查。
2. 確認快照權限 — AMI Block Device Mapping 參照的每個快照，也必須在 createVolumePermission 中包含合作夥伴帳號。使用 describe-snapshots --owner-ids self。
3. 確認加密情況 — 若快照已加密，找出 KMS key。若是 AWS-managed aws/ebs key，無法共享——你必須複製 AMI 並使用 customer-managed CMK 重新加密。
4. 確認 KMS key policy — CMK 的 key policy 必須授予合作夥伴帳號 kms:Decrypt、kms:DescribeKey、kms:CreateGrant 和 kms:GenerateDataKey*。可透過 key policy statement 或 aws kms create-grant 授予。
5. 在合作夥伴帳號中進行測試啟動以驗證。

常見陷阱：預設 aws/ebs Key 無法共享

SOA-C02 的一個干擾項利用了加密權限模型。考生「共享」了 AMI 啟動權限和快照權限，但快照是使用 AWS-managed aws/ebs key 加密的，而那個 key 無法跨帳號共享。正確流程：在來源帳號中複製 AMI 並指定 customer-managed CMK 加密，共享新 AMI 及其 CMK 加密的快照，並在 CMK key policy 上授予合作夥伴帳號權限。

常見陷阱：Pipeline Lifecycle Policy 刪除活躍 AMI

Image Builder Lifecycle Policy 可能刪除 Launch Template 版本仍在參照的 AMI。刪除是靜默發生的——Lifecycle Policy 不會檢查 Launch Template。下次 ASG 嘗試啟動時以 InvalidAMIID.NotFound 失敗。緩解措施：在 Launch Template 中使用 $Latest；或將 Lifecycle 保留期設定得比最長部署週期更長；或只使用 deprecate 操作，在較長的人工審查視窗後再刪除。

常見陷阱：用 User Data 取代 Image Builder Component 模式

有個團隊寫了 200 行 user-data shell 腳本來安裝 CloudWatch agent、設定 syslog、放入應用程式程式碼並啟動服務。這樣可行，但每個新 AMI 都需要在啟動時執行 90 秒的 user-data，而靜默的 user-data 失敗會導致機群不一致。SOA 正確的模式是透過 Image Builder Components 將 agent 和設定烘焙進 Golden AMI，讓 user-data 縮減為只需幾秒的最小設定腳本（設定 instance role、取得 secrets、啟動應用程式）。

SOA-C02 vs SAA-C03：運維視角的差異

SAA 和 SOA 都涉及 AMI 和部署，但問題的框架不同。

考試信號：如何辨識 TS 3.1 AMI/部署題

SOA-C02 Domain 3.1 的 AMI 與部署題目遵循可預測的模式。

• 「機群執行過時的 AMI」 — 答案涉及 Image Builder Pipeline 排程、Distribution Settings 更新 Launch Template、ASG 使用 $Latest，以及 Instance Refresh。
• 「部署在替換期間產生 5xx 錯誤」 — 答案是 MinHealthyPercentage、InstanceWarmup、target group deregistration delay，可能還有 health check grace period。
• 「應先讓少量使用者測試新版本」 — Canary，透過 ALB weighted target groups 或 Instance Refresh checkpoints 實作。
• 「需要即時回滾」 — Blue/Green via ALB target group swap 或 CloudFormation AutoScalingReplacingUpdate。
• 「跨帳號 AMI 啟動失敗」 — customer-managed CMK 的 KMS key policy + 快照權限 + AMI 啟動權限，三者全都需要。
• 「AMI 數量無限增長」 — Image Builder Lifecycle Policy 搭配 deprecate-then-delete 流程。
• 「AMI 已 deregister 但 instance 仍在運行」 — 這是預期行為；deregister 只阻止新啟動。
• 「每個新 instance 的記憶體和磁碟指標都遺失」 — 透過 Image Builder Component 將 CloudWatch agent 烘焙進 Golden AMI，而非 user-data。

決策矩陣 — 依 SysOps 目標對應 AMI 與部署工具

考試期間可用此表格查詢。

常見陷阱總整理 — AMI、Image Builder 與部署

每次 SOA-C02 考試都會遇到其中兩三個。

陷阱 1：Deregister 完全刪除 AMI

不是的。Deregister 只阻止新啟動。正在運行的 instance 不受影響。快照保留並持續收費，直到另行刪除。

陷阱 2：AWS-managed aws/ebs Key 可以共享

不行。跨帳號共享加密 AMI 需要 customer-managed CMK 以及明確的合作夥伴帳號 key policy grant。

陷阱 3：詳細監控意味著更多指標

不同主題但反覆出現。記憶體和磁碟指標需要在 Golden AMI 中烘焙 CloudWatch agent；詳細監控只改變既有 Hypervisor 指標的頻率。

陷阱 4：ASG 明確參照 Launch Template 版本 5

新版本將被忽略。使用 $Latest 或 $Default，讓 Launch Template 更新自動流向新啟動。

陷阱 5：Launch Template 變更後 Instance Refresh 自動執行

不是的。更新 Launch Template 版本只影響新啟動。既有 instance 保留，直到你明確啟動 Instance Refresh。

陷阱 6：Lifecycle Policy 預設是安全的

不是的。Lifecycle Policy 不檢查 Launch Template 參照，可能刪除 Launch Template 仍釘選的 AMI。使用 $Latest 或設定較長的保留期。

陷阱 7：Rolling 部署始終是零停機

不是的。當 MinHealthyPercentage 低於 100 且 InstanceWarmup 過短時，Rolling 部署可能產生 5xx 飆升。兩者都要調整，加上 deregistration delay。

陷阱 8：Blue/Green 沒有額外成本

有。Blue 和 Green 機群在驗證視窗期間同時運行，短暫雙倍運算成本。

陷阱 9：User Data 是安裝 Agent 的正確位置

不是的。Image Builder Components 將 agent 烘焙進 AMI；user data 只用於 instance 特有的執行時設定。

陷阱 10：CodeDeploy 是 SOA 部署的答案

不是的。根據考試指南附錄，CodeDeploy、CodeBuild 明確列為 SOA-C02 範圍之外。SOA 使用 ASG Instance Refresh、CloudFormation UpdatePolicy，以及 Image Builder Distribution。

FAQ — AMI、EC2 Image Builder 與部署策略

Q1：Deprecated、Disabled 和 Deregistered 有什麼差別？

Deprecate 將 AMI 標記為某日起不建議使用——對擁有帳號仍可透過明確 ID 啟動，ASG 繼續從中啟動，但對其他帳號的搜尋結果和主控台列表中已消失。Disable 封鎖所有新啟動，包括擁有帳號；這是更強的封鎖，用於需要立即停止使用但尚未準備刪除的情況。Deregister 完全移除 AMI 元資料——任何人都無法再從這個 AMI ID 啟動新 instance——但正在運行的 instance 不受影響，底層快照保留（並持續收費）直到你另行刪除。退役 AMI 的操作流程：先 Deprecate（發出不要使用的信號）、等待、Disable（強制停止）、等待、Deregister（移除元資料）、刪除快照（回收成本）。

Q2：我的 EC2 Image Builder Pipeline 執行成功，但 ASG 從未取用新 AMI。哪裡出了問題？

三個環節都必須接通。(a) Image Builder Distribution Settings 必須參照目標 Launch Template——沒有這個，Pipeline 成功也不會建立新的 Launch Template 版本。(b) ASG 的 Launch Template 版本必須是 $Latest 或 $Default，而非字面版本號，這樣新版本才能自動流入。(c) ASG 只對「新啟動」使用新 AMI——既有 instance 仍執行舊 AMI，直到你明確執行 aws autoscaling start-instance-refresh。依序確認每個環節。最常見的失敗是 (b)——ASG 使用固定版本建立，忽略了更新的版本。

Q3：為什麼跨帳號 AMI 共享在 AMI 加密時出現 KMS 錯誤？

加密權限必須和 AMI 元資料及快照權限一起共享。若快照使用 AWS-managed aws/ebs key 加密，完全無法共享——那個 key 不可共享。修正方式：在來源帳號中複製 AMI，指定 customer-managed CMK 作為加密 key，共享新 AMI，共享其快照，並在 CMK key policy 上授予合作夥伴帳號（kms:Decrypt、kms:DescribeKey、kms:CreateGrant、kms:GenerateDataKey*）。這四個步驟缺一不可；缺少任何一個，合作夥伴帳號在啟動時都會收到 AccessDenied。

Q4：ASG Instance Refresh 應該使用什麼 MinHealthyPercentage？

取決於應用程式。對無狀態面向客戶應用的例行版本更新，90（預設值）在速度和容量之間取得平衡。對零降幅部署——例如有狀態 Session 或冷啟動成本高的應用——設為 100，讓新 instance 先啟動、舊的在替換完成後才終止；這需要 ASG MaxSize 高於 DesiredCapacity 以允許新舊同時運行。對不服務客戶流量的內部批次機群，50 可加快部署。對 Canary 風格的部署，將 MinHealthyPercentage 與 CheckpointPercentages: [10, 100] 和 30+ 分鐘的 CheckpointDelay 組合，讓刷新在 10% 時暫停進行指標審查再繼續。生產環境中唯一要避免的設定是 0，那等同於 All-at-Once。

Q5：何時應選擇 Blue/Green 而非 Rolling 部署？

選擇 Blue/Green 的情境：(a) 需要即時回滾——驗證期間保留舊機群讓你在數秒內切回；(b) 不能容忍部署期間任何容量降幅——兩個機群全程都在滿容量運行；(c) 可以承擔暫時的雙倍運算成本；(d) 應用程式支援兩個並行機群（無共享可變狀態，或狀態層是外部的）。選擇 Rolling 的情境：(a) 無狀態應用的例行版本更新；(b) 成本考量使雙倍運算不可接受；(c) 機群規模夠小，即使小批次也能快速部署完成。考試給出的線索：「必須即時回滾」或「不能有容量降幅」指向 Blue/Green；「例行部署」或「最小化成本」指向 Rolling。

Q6：為什麼我的 Rolling 部署在 Load Balancer 上造成短暫的 HTTP 5xx 飆升？

三個設定相互影響。(a) MinHealthyPercentage 低於 100 意味著舊 instance 在替換完全上線前就終止；調高接近 100（並確保 MaxSize > DesiredCapacity）以實現零降幅 Rolling。(b) InstanceWarmup 太短意味著新 instance 在應用程式 stack 就緒前就被計為健康（冷 JVM、空快取）；延長 warmup 以超過健康檢查穩定時間和 JIT 暖身時間。(c) Target group DeregistrationDelay 太短導致終止中的 instance 上的飛行中請求被丟棄；增加以匹配最長預期請求時間（短 HTTP 30–60 秒，WebSocket 最長 3600 秒）。三者全部調整以實現乾淨的 Rolling 部署。

Q7：CloudWatch agent 和 SSM agent 應該安裝在 AMI 中、user data 中，還是透過 Run Command？

透過 EC2 Image Builder Components 烘焙進 AMI。AWS 提供 amazon-cloudwatch-agent-linux（及 Windows 等效版本），SSM agent 在 Amazon Linux 2/2023 上預裝。User-data 安裝可行但脆弱（只執行一次，可能靜默失敗，停止/啟動時重播）且延長啟動時間。Run Command 安裝是命令式的——事後修復 instance，但意味著每個新 instance 啟動時都暫時未受監控，直到 Run Command 趕上。SOA 正確的模式是 Golden AMI：agent 已安裝並在 AMI 中設定好，user-data 縮減為小段的每個 instance 設定（設定 role tag、取得 secrets、啟動應用），機群中的每個成員啟動後即可被監控。這也產生了一致、可稽核的機群。

Q8：如何在整個 AWS Organization 中大規模共享 AMI？

三個選項比逐帳號共享更具擴展性。(a) Image Builder Distribution Settings 搭配 targetAccountIds 一次指定所有成員帳號，包括各帳號的啟動權限和 KMS key——宣告式且 IaC 友好。(b) AWS Resource Access Manager (RAM) 用於組織內的 AMI-as-resource 共享，但 RAM 不處理 KMS key 共享，因此仍需在 CMK 上設定 key policy grant。(c) 集中式 AMI 帳號模式 — 專用帳號擁有所有 Golden AMI，透過 Image Builder 發布，成員帳號透過名稱查詢（Systems Manager Parameter Store 搭配 aws:ec2:image 資料類型）而非 ID 來參照 AMI。第三種模式最具彈性，因為 Launch Template 在啟動時從指向最新核准 AMI 的 Parameter Store 解析 AMI，使得退役和替換是原子操作。

Q9：如果我刪除了 ASG Launch Template 所參照的 AMI，會發生什麼？

Launch Template 仍以字面值儲存該 AMI ID。既有 instance 繼續運行，因為它們已經啟動了。新啟動——無論是擴展、Instance Refresh 還是替換不健康的 instance——都會以 InvalidAMIID.NotFound 失敗。ASG 進入無法達到期望容量的部分失敗狀態。修正方式：發布指向有效 AMI 的新 Launch Template 版本，將 ASG 設定為使用 $Latest，並啟動 Instance Refresh。事先的緩解措施：使用 Image Builder Lifecycle Policy 搭配足夠長的保留視窗，確保活躍 AMI 永不被刪除；讓 Launch Template 釘選到 $Latest 以確保永遠參照最新 AMI；並為 AMI 加上標籤，讓 Lifecycle Policy 可以排除標記為「使用中」的 AMI。

Q10：SOA-C02 考試考 CodeDeploy 和 CodeBuild 嗎？

不考。CodeDeploy、CodeBuild、CodeCommit 和 CodeStar 在 SOA-C02 考試指南附錄中明確列為範圍之外。SOA-C02 有關部署的問題使用範圍內的 AWS 原生資源：ASG Instance Refresh、CloudFormation UpdatePolicy: AutoScalingRollingUpdate 和 AutoScalingReplacingUpdate、EC2 Image Builder Pipeline、Systems Manager Automation Runbooks、用於 Blue/Green 和 Canary 的 ALB target group routing、Route 53 weighted routing，以及 EventBridge 排程觸發器。若某題的選項中包含 CodeDeploy，那個選項在 SOA-C02 上幾乎肯定是錯的。DOP-C02（DevOps Engineer Professional）考試才是 CodeDeploy 策略（就地、Blue/Green、hooks、deployment groups）被深入測試的地方。

延伸閱讀與相關運維模式

• Amazon Machine Images (AMI) — 使用者指南
• 與特定 AWS 帳號共享 AMI
• 複製 AMI
• Deprecate 一個 AMI
• Deregister 一個 AMI
• AMI 的 Block Device Mapping
• 什麼是 EC2 Image Builder
• 管理 Image Builder Pipeline
• 管理 Image Builder Recipe
• Image Builder Components
• Image Builder Distribution Settings
• Image Builder Image Lifecycle Policy
• EC2 Launch Templates
• 使用 Instance Refresh 更新 ASG 中的 Instance
• Auto Scaling Warm Pool
• CloudFormation UpdatePolicy 用於 ASG Rolling 更新
• AWS 上的 Blue/Green 部署 — 白皮書
• AWS SOA-C02 考試指南 v2.3 (PDF)

AMI 工廠與部署工作流程就緒後，下一步的運維層是：CloudFormation Stacks 與 StackSets——編排 AMI 所在的周邊基礎設施（TS 3.1 的第二項技能）；Systems Manager Automation 與 Patch Manager——在 AMI 重新烘焙的間隔期間對運行中機群進行就地修補；EC2 Auto Scaling、ELB 與 Multi-AZ 高可用——提供 AMI 所服務的機群容量模型；以及排程任務與 Config 自動補救——串接 Image Builder Pipeline 觸發器和 Config 規則驅動的補救 Runbook 的 EventBridge 自動化。

• CloudFormation Stacks、StackSets 與疑難排解 — SOA-C02 學習筆記
• Systems Manager：Automation、Patch Manager 與 Session Manager — SOA-C02 學習筆記
• EC2 Auto Scaling、ELB 與 Multi-AZ 高可用 — SOA-C02 學習筆記
• 排程任務、Config 自動補救與程序自動化 — SOA-C02 學習筆記