部署策略：Blue/Green、Canary 與 Rolling

部署策略是決定一次發布能悄悄地推送給數百萬用戶，還是讓應用程式停擺一小時的關鍵因素。在 AWS Certified Developer Associate（DVA-C02）考試中，部署策略是第三領域「部署」的前三大考點之一，與 CodeDeploy 工具鏈及基礎設施即程式碼並列。考試中每一道部署策略題目，本質上都圍繞著同樣的兩條軸線：你願意為每次發布承擔多少風險，以及當版本出錯時你能多快完成回滾。本章將逐一介紹 DVA-C02 要求掌握的每種部署策略模式——原地部署、滾動、附加批次滾動、不可變、藍綠、金絲雀、線性與功能旗標——並對應到具體的 AWS 運算平台：AWS Lambda、Amazon ECS、Amazon EC2 Auto Scaling 與 AWS Elastic Beanstalk。讀完本章後，你將能在不超過 45 秒內看懂任何考試情境並選出唯一正確的部署策略答案。

什麼是部署策略？

部署策略是管理新版本應用程式如何取代舊版本的規則。每一個部署策略決策都涉及四個變數：

1. 一次更新多少個實例、任務或別名權重。
2. 新版本在完全切換前與舊版本共存多長時間。
3. 哪些信號會觸發回滾至舊版本。
4. 觸發後完成回滾需要多長時間。

這四個變數組合出一套部署策略分類，AWS 在每個運算服務上以略微不同的名稱加以實作。DVA-C02 考試測驗你能否將通用的部署策略詞彙（藍綠、金絲雀、線性）對應到 AWS CodeDeploy、AWS Elastic Beanstalk、Amazon ECS 與 AWS Lambda 別名中的具體參數名稱。

為什麼部署策略對 DVA-C02 很重要

部署策略題目約佔第三領域內容的 30–40%。每次考試至少有五道情境題，要求你在兩種技術上都「可行」的部署策略之間做出選擇——例如 Canary10Percent5Minutes 與 Linear10PercentEvery10Minutes，或是「滾動」與「附加批次滾動」。部署策略同時也貫穿第四領域（疑難排解），當一次失敗的發布必須透過 CloudWatch alarm 觸發進行回滾時。將部署策略的取捨記熟一次，你就能在兩個領域同時得分。

DVA-C02 部署策略心智模型

在深入各個 AWS 服務之前，先將以下這個兩問速判框架內化——所有部署策略問題都可以歸結至此：

• 新舊版本能同時運行嗎？ 若能，你可以選擇藍綠或金絲雀部署策略。若不能（例如資料庫 schema 不相容），你只能選擇原地部署或全量部署策略。
• 一次壞的部署影響範圍有多大？ 影響範圍大，應選用搭配 CloudWatch alarm 自動回滾的金絲雀或線性部署策略；影響範圍小，可以接受滾動部署策略。

白話文解釋 部署策略

部署策略是抽象的概念。以下三個類比能將整套分類法牢牢刻入記憶。

類比一——夜市攤位換菜單

想像你在夜市擺攤，要換一套新菜單。你可以選擇的部署策略，與 AWS 的部署策略一一對應：

• 全量部署（原地）：收攤一小時、換掉所有菜單板、重新開攤。快速、省錢，但顧客看到停服。對應 CodeDeploy 的 AllAtOnce 與 Beanstalk 的 All at once 部署策略。
• 滾動部署：一個桌位一個桌位地換菜單。不用收攤，但 20 分鐘內兩套菜單並存，後場必須同時支援。對應 CodeDeploy 的 OneAtATime／HalfAtATime 與 Beanstalk 的 Rolling 部署策略。
• 附加批次滾動：先多擺幾張桌子，再逐批換菜單，座位數不減反增。對應 Beanstalk 的 Rolling with additional batch 部署策略。
• 不可變部署：在隔壁重新搭一個全新的攤位、用新菜單開張、切換日當晚把所有顧客帶過去，再拆掉舊攤位。對應 Beanstalk 的 Immutable 部署策略。
• 藍綠部署：與不可變類似，但舊攤位繼續保留一週「以防萬一」——若新菜單反應差，幾秒內就能重開舊攤。對應 CodeDeploy Blue/Green 與 ECS Blue/Green 部署策略。
• 金絲雀部署：讓 5% 的顧客先試點新菜單。有人抱怨就全部撤回；反應好就推給所有人。對應 Lambda 的 Canary10Percent5Minutes 與 API Gateway 金絲雀部署策略。
• 線性部署：每 10 分鐘多讓 10% 的顧客使用新菜單。對應 Lambda 的 Linear10PercentEvery10Minutes 部署策略。
• 功能旗標：新菜色已經印在菜單上但用灰色遮蔽，只有「跟服務員說暗語」才點得到——你翻動一個開關就能讓特定顧客看見。對應 AWS AppConfig 功能旗標部署策略。

類比二——醫院換班交接

部署策略也很像醫院的輪班交接。全量部署是「所有人下午七點打卡下班、新班七點零一分接手」——中間有一段沒有人值班的空窗。滾動部署是「每位護理師逐一向接班者交接」——服務不中斷，但跨班協調很費力。藍綠部署是「新班六點半到院、陪同值班三十分鐘，確認沒問題才由主管宣布正式交接」——舊班人員仍在現場待命，直到交接確認無誤。金絲雀部署是「只有急診分診台先換成新班，讓訓練疏漏在低風險案例中現形，再換到加護病房」。功能旗標是「新的護理流程已經印在每位護理師的工作板上，但在院長翻轉開關之前誰都不執行。」這個類比凸顯出部署策略的本質是可觀測性窗口：兩個版本同時運行的那段期間，正是你判斷新版本是否安全的機會。

類比三——高速公路收費站換道

流量切換型部署策略，能完美對應高速公路的收費亭換道。想像十二條收費亭車道承載著所有高速公路流量（你的生產負載均衡器）。藍綠部署是「在現有十二條車道旁開通六條全新車道，等流量完全移轉後關閉原有十二條」。金絲雀部署是「保留原有十二條車道，開通一條新車道，讓 10% 的車輛行駛五分鐘，再開放其餘的」。滾動部署是「一次重鋪一條車道，其餘十一條照常通行」。線性部署是「每十分鐘再多鋪兩條，直到十二條全數完成」。功能旗標是「新車道蓋好了但前面放著可移除的隔離墩——隨時可以拉起或放下，完全不必動車道本身。」Route 53 加權 DNS、ALB 加權目標群組與 API Gateway 金絲雀設定，只不過是在不同 OSI 層實現這些部署策略的不同機制。

部署策略分類法

DVA-C02 所有部署策略對話都源自同樣的七種原型。記熟這套分類，你就能將任何考試情境對應到正確模式。

原地（全量）部署策略

原地部署策略在現有基礎設施上直接替換應用程式。每台主機、任務或函式版本都在同一位置更新。CodeDeploy 將最快的形式稱為 AllAtOnce，Elastic Beanstalk 稱之為 All at once。全量部署是最便宜也最快速的部署策略，但風險也最高——新版本失敗時沒有並行的舊版本可以回退，回滾意味著從頭重新部署先前的產出物。全量部署策略僅適用於開發／測試環境或內部工具。

滾動部署策略

滾動部署策略在相同的基礎設施上分批替換實例。CodeDeploy 提供 OneAtATime、HalfAtATime 以及自訂百分比設定；Elastic Beanstalk 稱之為 Rolling 並允許選擇批次大小。滾動部署降低了每批的風險（壞版本只影響一部分主機），但會暫時縮減容量——若批次大小為 25%，部署期間有 25% 的機隊處於不可用狀態。

附加批次滾動部署策略

附加批次滾動部署策略解決了容量縮減的問題。Beanstalk 在終止任何舊實例之前，會先啟動一批額外實例，讓運行中的機隊暫時增大而非縮小。當考試情境說「部署期間不減少容量」卻又不要求完整藍綠隔離時，這個部署策略是預設答案。

不可變部署策略

不可變部署策略絕不修改現有實例——它啟動一個全新的 Auto Scaling 群組（或 Beanstalk 環境），確認健康檢查通過後再終止舊機隊。Elastic Beanstalk 有專屬的 Immutable 部署策略設定。與藍綠的差異在於，不可變將新舊視為「接續關係」而非「同時服務流量的關係」——舊流量不會在藍綠之間分流。

藍綠部署策略

藍綠部署策略在生產環境（藍）旁邊建立一個完整的平行環境（綠），待綠環境驗證通過後一次性切換流量。CodeDeploy 支援 EC2 上的藍綠（透過 Auto Scaling 群組替換）、Lambda 上的藍綠（透過別名權重切換）以及 ECS 上的藍綠（透過 CodeDeploy 管理的監聽器規則）。由於藍環境仍在運行，回滾幾乎是即時的。當考試情境強調「零停機」與「即時回滾」時，藍綠部署策略是預設答案。

金絲雀部署策略

金絲雀部署策略將一小部分流量切換到新版本，等待驗證後再切換剩餘流量。CodeDeploy for Lambda 定義了標準配置：Canary10Percent5Minutes、Canary10Percent15Minutes、Canary10Percent30Minutes、Canary10PercentAnHour。金絲雀與藍綠的區別在於流量是「分流」而非「整批切換」，且金絲雀窗口明確且時間固定。當考試情境說「用少量真實用戶流量測試」時，金絲雀部署策略是預設答案。

線性部署策略

線性部署策略以相等的增量逐步切換流量。CodeDeploy for Lambda 定義了 Linear10PercentEvery1Minute、Linear10PercentEvery2Minutes、Linear10PercentEvery3Minutes 與 Linear10PercentEvery10Minutes。線性與金絲雀的區別在於切換是持續漸進的，而非「小批次驗證，再大批切換」。當考試情境說「逐步切換流量」但未指定初始小比例窗口時，線性部署策略是正確答案。

功能旗標部署策略

功能旗標部署策略將部署與發布解耦。程式碼以停用狀態上線；由操作人員翻轉旗標來啟用功能。AWS AppConfig 是 AWS 上的受管功能旗標儲存服務。當考試情境說「現在部署但稍後啟用」或「僅對 beta 用戶開啟功能」時，功能旗標部署策略是正確答案。

Amazon EC2 Auto Scaling 的部署策略

EC2 Auto Scaling 群組（ASG）是 DVA-C02 的經典運算目標，支援四種不同的部署策略。

EC2 與 CodeDeploy 的原地部署策略

CodeDeploy 以運算平台 Server 與部署類型 In-place 組合，在每台現有 EC2 實例上執行 CodeDeploy agent，並按序執行生命週期鉤子（ApplicationStop、DownloadBundle、BeforeInstall、Install、AfterInstall、ApplicationStart、ValidateService）。部署配置 CodeDeployDefault.AllAtOnce、CodeDeployDefault.HalfAtATime 與 CodeDeployDefault.OneAtATime 控制批次大小。當影響範圍小、基礎設施成本敏感且不需要即時回滾時，原地部署策略是合適的選擇。

透過 ELB Draining 的滾動部署策略

當 EC2 實例掛載到 Elastic Load Balancer 時，CodeDeploy 會協調 ELB 在停止舊應用程式之前先完成連線排除（透過取消註冊延遲，預設 300 秒），確保進行中的請求在替換前處理完畢。當考試情境說「最小化進行中請求的遺失」時，搭配 ELB draining 的滾動部署策略是預設答案。

透過 ASG 替換的藍綠部署策略

EC2 上的 CodeDeploy 藍綠部署會建立一個搭載新版本應用程式的全新 Auto Scaling 群組，將其掛載到現有 ELB 目標群組，切換流量後選擇性地終止舊 ASG。必要條件包括：一個 ELB（流量切換機制）、一個啟動範本，以及部署類型設為 Blue/green 的 CodeDeploy 部署群組。這種藍綠部署策略支援即時回滾（重新將舊 ASG 掛載到 ELB），因為舊 ASG 在可設定的等待窗口期間會被保留。

透過 Instance Refresh 的不可變部署策略

Amazon EC2 Auto Scaling Instance Refresh 是內建的替換機制，能依據最新啟動範本啟動新實例，待新實例通過健康檢查後再終止舊實例。Instance Refresh 支援 MinHealthyPercentage 參數（預設 90%），可控制滾動與完整不可變部署策略的行為。將 MinHealthyPercentage 設為 100%，可強制新容量在線後再撤除舊容量——這在 ASG 層面等同於不可變部署策略。

AWS Lambda 的部署策略

AWS Lambda 在 DVA-C02 考試中獲得了最深入的部署策略處理。請記熟每一個具名配置。

Lambda 別名與加權路由：基礎

Lambda 別名是指向特定 Lambda 函式版本的具名指標。部署策略的關鍵功能是路由配置：一個別名可同時指向兩個版本，並按照權重在兩者之間分配調用流量。例如，配置了 "AdditionalVersionWeights": {"2": 0.1} 的別名，在主要版本為 1 的情況下，會將 90% 的調用路由到版本 1、10% 路由到版本 2。這是 CodeDeploy 中所有 Lambda 金絲雀與線性部署策略的底層原語。

# AWS SAM 片段：展示帶有加權流量的 Lambda 別名
Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.handler
      Runtime: nodejs20.x
      AutoPublishAlias: live
      DeploymentPreference:
        Type: Canary10Percent5Minutes
        Alarms:
          - !Ref ErrorAlarm
        Hooks:
          PreTraffic: !Ref PreTrafficHook
          PostTraffic: !Ref PostTrafficHook

Lambda 金絲雀部署策略：Canary10Percent5Minutes

CodeDeploy for Lambda 提供四種金絲雀部署策略配置，形式均為「先切 10%，等待 N 分鐘，再切 100%」：

• CodeDeployDefault.LambdaCanary10Percent5Minutes
• CodeDeployDefault.LambdaCanary10Percent15Minutes
• CodeDeployDefault.LambdaCanary10Percent30Minutes
• CodeDeployDefault.LambdaCanary10PercentAnHour

在等待窗口期間，10% 的調用打到新版本，90% 打到舊版本。若部署群組中掛載的任何 CloudWatch alarm 在等待窗口期間進入 ALARM 狀態，CodeDeploy 會立即回滾，將別名重新指向 100% 的舊版本。考試常見情境：「團隊希望在正式全量切換前，先讓 10% 的流量抓出錯誤」，此時選擇正確的具名 Lambda 金絲雀部署策略配置即為答案。

Lambda 線性部署策略：Linear10PercentEvery10Minutes

Lambda 線性部署策略以相等增幅逐步切換流量：

• CodeDeployDefault.LambdaLinear10PercentEvery1Minute
• CodeDeployDefault.LambdaLinear10PercentEvery2Minutes
• CodeDeployDefault.LambdaLinear10PercentEvery3Minutes
• CodeDeployDefault.LambdaLinear10PercentEvery10Minutes

採用 Linear10PercentEvery10Minutes 時，別名權重從 0% 新版本，每十分鐘增加 10%，共十步達到 100%——整體部署耗時 100 分鐘。線性與金絲雀的差異在於：線性沒有單一「在 10% 處驗證」的窗口，整個部署過程本身就是驗證窗口。

Lambda 全量部署策略

CodeDeployDefault.LambdaAllAtOnce 會立即將 100% 的流量切換到新版本。此部署策略選項僅適用於開發環境；沒有自動金絲雀緩衝來偵測錯誤。

Pre-Traffic 與 Post-Traffic 鉤子

CodeDeploy for Lambda 支援兩個生命週期鉤子，這兩個鉤子本身也是 Lambda 函式：

• BeforeAllowTraffic（pre-traffic 鉤子）：在任何流量切換之前執行。可用於透過 Lambda:InvokeFunction 對鉤子接收到的 functionVersion 執行煙霧測試。
• AfterAllowTraffic（post-traffic 鉤子）：在 100% 流量切換完成後執行。可用於執行整合測試或暖機快取。

兩個鉤子都必須呼叫 codedeploy:PutLifecycleEventHookExecutionStatus 回報 Succeeded 或 Failed。回報 Failed 會觸發自動回滾。

CloudWatch Alarm 自動回滾

Lambda 的每個 CodeDeploy 部署群組都可以在 AlarmConfiguration 中列出 CloudWatch alarm。若任何列出的 alarm 在部署期間（金絲雀窗口、線性窗口或 post-traffic 鉤子期間）進入 ALARM 狀態，CodeDeploy 會立即停止切換並將別名權重回滾至 100% 舊版本。Lambda 部署策略的常見 alarm 監控目標：

• AWS/Lambda 的 Errors 指標（函式層級錯誤計數）。
• AWS/Lambda 的 Throttles 指標。
• 透過 Embedded Metric Format（EMF）發出的自訂 CloudWatch 指標。
• 調用 Lambda 的 API Gateway Stage 上的 5XXError 指標。

Amazon ECS 的部署策略

Amazon ECS 支援兩種部署策略：原生滾動更新（ECS 部署控制器）與 CodeDeploy 管理的藍綠部署（CODE_DEPLOY 部署控制器）。

ECS 滾動更新部署策略

預設的 ECS 部署控制器（ECS）透過逐步以新任務替換舊任務來更新服務。服務參數 minimumHealthyPercent（預設 100）與 maximumPercent（預設 200）限定了滾動部署策略窗口——minimumHealthyPercent = 100 且 maximumPercent = 200，表示 ECS 在部署期間可暫時將任務數加倍，同時絕不低於期望任務數。當考試情境說「逐步替換任務，且無需專用負載均衡器監聽器切換」時，ECS 滾動部署策略是正確答案。

ECS 藍綠部署策略搭配 CodeDeploy

將 ECS 服務的部署控制器設為 CODE_DEPLOY，即可解鎖透過 CodeDeploy 的完整藍綠部署策略。此機制需要兩個目標群組掛載到 Application Load Balancer：

• 一個生產監聽器（埠 80 或 443），指向當前目標群組。
• 一個測試監聽器（通常為 8080 埠），始終指向替換任務集，允許在正式生產驗證前針對真實基礎設施進行預生產驗證。

部署流程：

1. CodeDeploy 在服務中建立新的 ECS 任務集（綠）。
2. 綠色任務集向測試監聽器目標群組進行注冊。
3. AppSpec 的 AfterAllowTestTraffic 鉤子（一個 Lambda 函式）針對測試監聽器 URL 執行驗證。
4. 生產監聽器的流量透過 CodeDeploy 流量切換配置（AllAtOnce、Linear 或 Canary）從藍色任務集切換至綠色任務集。
5. 可設定的等待期（最長 2 天）讓舊的藍色任務集保持閒置以備手動回滾，之後 CodeDeploy 終止藍色。

# ECS 藍綠部署的 appspec.yaml
version: 0.0
Resources:
  - TargetService:
      Type: AWS::ECS::Service
      Properties:
        TaskDefinition: "arn:aws:ecs:...:task-definition/my-app:42"
        LoadBalancerInfo:
          ContainerName: "web"
          ContainerPort: 80
Hooks:
  - BeforeInstall: "arn:aws:lambda:...:function:PreInstallHook"
  - AfterInstall: "arn:aws:lambda:...:function:PostInstallHook"
  - AfterAllowTestTraffic: "arn:aws:lambda:...:function:TestTrafficValidator"
  - BeforeAllowTraffic: "arn:aws:lambda:...:function:PreTrafficHook"
  - AfterAllowTraffic: "arn:aws:lambda:...:function:PostTrafficHook"

ECS 手動驗證等待時間

CodeDeploy ECS 藍綠部署群組支援 terminationWaitTimeInMinutes（最長 2880 分鐘 = 48 小時）——在流量切換後的這段時間內，舊的藍色任務集維持運行。這個手動驗證窗口是 ECS 考試的陷阱——若題目說「部署後保留舊版本整整一天，以便即時還原」，答案就是 ECS 藍綠搭配 terminationWaitTimeInMinutes 設為 1440 分鐘。

ECS 藍綠中的自動回滾鉤子

與 Lambda 相同，ECS 藍綠部署群組透過 AlarmConfiguration 掛載 CloudWatch alarm。若任何 alarm 在部署期間進入 ALARM 狀態，CodeDeploy 會將生產監聽器重新指向藍色任務集並終止綠色任務集。

AWS Elastic Beanstalk 的部署策略

AWS Elastic Beanstalk 以具名部署政策的方式在環境配置中公開部署策略。

Beanstalk 部署政策矩陣

Traffic splitting 是 Beanstalk 的受管金絲雀部署策略——它啟動一個不可變的新機隊，將設定比例的入站流量路由到新機隊，等待設定的評估窗口，然後根據健康狀況切換 100% 或執行回滾。

Beanstalk 藍綠部署透過 CNAME Swap

Beanstalk 沒有原生的「藍綠」部署政策名稱。標準的 Beanstalk 藍綠部署策略方法是：

1. 將當前環境（藍）克隆為新環境（綠）。
2. 將新版本部署到綠環境。
3. 使用 Beanstalk 指定的綠環境 URL 驗證綠環境。
4. 在 Beanstalk 主控台交換環境 URL。CNAME 翻轉幾乎是即時的；DNS 傳播是唯一的延遲。
5. 驗證窗口後終止舊的藍環境。

CodeDeploy 以外的流量切換機制

涉及百分比流量切換的部署策略需要路由機制。AWS 提供多種選項，每一種都在 DVA-C02 中有考試。

Route 53 加權 DNS 部署策略

Route 53 加權路由記錄為每筆記錄指定 Weight（0–255）。DNS 解析器依照各記錄的權重比例回傳結果。加權 DNS 是粒度最粗的流量切換部署策略機制：TTL（通常 60 秒）意味著切換不是即時的，客戶端的 DNS 快取可能讓過期答案持續數分鐘。Route 53 加權部署策略通常用於跨區域藍綠切換，或在兩個完全不同的技術棧之間切換（例如從單體架構遷移至微服務架構）。

API Gateway Stage 金絲雀部署策略

每個 REST API Gateway Stage 都可以定義金絲雀發布配置：canarySettings.percentTraffic 在 API Gateway 層面將請求分流至主要部署與金絲雀部署。當考試情境說「在少量流量上測試新 API 版本，但不涉及 Lambda 別名」時——例如後端是 HTTP 端點而非 Lambda 函式——API Gateway 金絲雀部署策略是正確答案。

ALB 加權目標群組部署策略

Application Load Balancer 在每條監聽器規則上支援多個目標群組，並可為每個目標群組設定權重（0–999）。當你希望在兩個目標群組之間分流，且不以 CodeDeploy 作為協調器時，ALB 加權目標群組是 ECS、EC2 或 Fargate 藍綠或金絲雀部署策略的正確答案。CodeDeploy ECS 藍綠部署本身內部就使用 ALB 加權目標群組。

流量切換部署策略機制比較

AWS AppConfig 與功能旗標部署策略

AWS AppConfig 是 AWS 上的受管功能旗標與配置部署服務。它在配置層面（而非程式碼層面）實作部署策略。

AppConfig 建構模塊

• Application：應用程式的邏輯分組（例如 checkout-service）。
• Environment：部署目標（例如 prod、staging）。
• Configuration Profile：版本化的配置文件（功能旗標對應表或自由格式 JSON/YAML）。
• Deployment Strategy：配置版本如何推送到環境的規則。

AppConfig 部署策略目錄

AppConfig 內建四種預定義部署策略，並支援自訂部署策略：

• AppConfig.AllAtOnce — 100% 的目標立即接收新配置。
• AppConfig.Linear50PercentEvery30Seconds — T+0 時 50%，T+30 秒時 100%。
• AppConfig.Linear20PercentEvery6Minutes — 每 6 分鐘 20%，共 30 分鐘完成。
• AppConfig.Canary10Percent20Minutes — 10% 持續 20 分鐘，然後 100%。

自訂部署策略可讓你指定 DeploymentDurationInMinutes、GrowthFactor、GrowthType（LINEAR 或 EXPONENTIAL）以及 FinalBakeTimeInMinutes（100% 後的觀察窗口）。

AppConfig 自動回滾

AppConfig 監控部署策略中指定的 CloudWatch alarm；若 alarm 在部署期間或 FinalBakeTime 期間進入 ALARM 狀態，AppConfig 會自動將環境回滾至先前的配置版本。這是功能旗標部署策略中相當於 CodeDeploy alarm 回滾的機制。

AppConfig 功能旗標部署策略使用情境

當考試情境出現以下描述時，功能旗標部署策略是正確答案：

• 「現在部署程式碼，但稍後再啟用功能。」
• 「只對特定用戶群開啟功能。」
• 「不重新部署的情況下關閉現有功能。」
• 「逐步推出配置變更，發生錯誤率異常時自動回滾。」

部署策略的監控與回滾觸發器

每個生產級部署策略實作都需要可觀測性來觸發回滾。DVA-C02 考試測驗三種主要的回滾觸發機制。

CloudWatch Alarm 作為部署策略回滾觸發器

CloudWatch alarm 是 CodeDeploy（Lambda、ECS、EC2）與 AppConfig 的標準回滾觸發器。部署配置中引用 alarm ARN；任何列出的 alarm 進入 ALARM 狀態，都會停止部署並啟動回滾。部署策略的常見 alarm 目標：

• Lambda 的 Errors、Throttles、Duration P99。
• API Gateway 的 5XXError、Latency P99。
• ECS 服務的 RunningTaskCount 下降、ALB 目標群組的 UnHealthyHostCount。
• 透過 Embedded Metric Format（EMF）發出的業務層級錯誤自訂指標（結帳失敗、付款失敗）。

CloudWatch Synthetics Canaries

CloudWatch Synthetics Canaries 是排程執行的 Puppeteer/Selenium 腳本，模擬真實用戶操作應用程式，並發布通過/失敗指標。將合成金絲雀與 CloudWatch alarm 掛載在金絲雀的 SuccessPercent 指標上，你就擁有了可覆蓋任何部署策略的端對端功能性回滾觸發器——填補了純指標 alarm 的盲點（例如 API 回傳 HTTP 200 但 HTML 內容已損毀）。

X-Ray 錯誤率作為部署策略信號

AWS X-Ray 發布追蹤層級的錯誤與故障率，CloudWatch 可透過 X-Ray 指標設定 alarm。在部署策略情境下，X-Ray 能捕捉到純 Lambda 或 API Gateway 指標遺漏的回退問題——例如新的 Lambda 程式碼改變了存取模式後，才出現的下游 DynamoDB 節流。基於 X-Ray 的 alarm 同樣接入 CodeDeploy 的 AlarmConfiguration 機制。

部署策略決策樹

使用這棵決策樹，在任何 DVA-C02 情境中選出正確的部署策略。

步驟一：新舊版本能同時運行嗎？

• 否（破壞性 schema 變更、不相容的客戶端）：使用全量部署策略，安排維護窗口，接受停機。
• 是：進入步驟二。

步驟二：目標運算平台是什麼？

• AWS Lambda：步驟 3L。
• Amazon ECS：步驟 3E。
• EC2 Auto Scaling：步驟 3A。
• Elastic Beanstalk：步驟 3B。
• 僅配置變更（無程式碼）：AppConfig 部署策略（Canary10Percent20Minutes 或 Linear20PercentEvery6Minutes）。

步驟 3L：Lambda 部署策略選擇

• 需要「先測試小比例再全量切換」：Canary10Percent5Minutes（或依驗證時間選 15/30/60 分鐘變體）。
• 需要「持續漸進斜坡」：Linear10PercentEvery10Minutes（低風險變更可選擇更快的變體）。
• 僅開發/測試，速度優先於安全：AllAtOnce。
• 需要不重新部署的功能切換：AppConfig 功能旗標。

步驟 3E：ECS 部署策略選擇

• 需要即時回滾 + 測試監聽器驗證：搭配 ALB 的 CodeDeploy ECS 藍綠部署。
• 需要簡單的漸進任務替換，無第二個監聽器：ECS 滾動更新，minimumHealthyPercent=100，maximumPercent=200。
• 需要長時間手動驗證窗口（數小時至數天）：ECS 藍綠搭配 terminationWaitTimeInMinutes，最長 2880 分鐘。

步驟 3A：EC2 Auto Scaling 部署策略選擇

• 需要 ASG 層級替換加即時回滾：CodeDeploy 藍綠搭配 ELB 後方的 ASG 替換。
• 僅需 AMI 輪換，不需要 CodeDeploy：ASG Instance Refresh，MinHealthyPercentage=100。
• 需要在現有實例上僅更新應用程式，低風險：CodeDeploy 原地部署（OneAtATime 或 HalfAtATime）。

步驟 3B：Elastic Beanstalk 部署策略選擇

• 速度優先，可接受風險（開發環境）：All at once。
• 不縮減容量，低複雜度：Rolling with additional batch。
• 需要全新機隊，不做原地變更：Immutable。
• 需要百分比金絲雀：Traffic splitting。
• 需要近即時回滾加環境隔離：Beanstalk 藍綠透過 CNAME swap（環境克隆）。

依風險等級的部署策略速查表

DVA-C02 常見部署策略考試陷阱

考試反覆測驗相同的部署策略辨別點。熟記以下陷阱。

金絲雀 vs 線性部署策略混淆

金絲雀部署策略先切換固定的小比例（通常 10%），等待固定窗口，再切換 100%。線性部署策略在整個部署過程中以相等的小增幅持續切換。若情境提到「先切 10%，等待，再切剩餘」，答案是金絲雀。若情境提到「每隔 N 分鐘等量切換」，答案是線性。

Lambda 部署策略中別名 vs 版本的區別

Lambda 版本是不可變的凍結快照，無法被切換或加權。Lambda 別名是可攜帶加權路由配置的可變指標。任何 Lambda 部署策略題目問「哪個構件承載加權流量分流」，答案永遠是別名，絕不是版本。

滾動 vs 附加批次滾動部署策略

滾動部署策略會因批次大小而暫時縮減容量；附加批次滾動則不會（額外容量先行增加）。若情境提到「部署期間不縮減容量」，答案是附加批次滾動。

藍綠 vs 不可變部署策略

藍綠在切換期間保持兩個環境同時在線以實現即時回滾。不可變在新環境健康後拆除舊環境——回滾需要重建舊環境。強調「即時回滾」的情境選藍綠；強調「絕不修改在線主機」的情境選不可變。

API Gateway Stage 金絲雀 vs Lambda 別名金絲雀部署策略

兩者都是金絲雀部署策略，但在不同層面運作。API Gateway 金絲雀部署策略在 HTTP Stage 層運作，透過 canarySettings 在兩個 API Gateway 部署之間分流。Lambda 別名金絲雀部署策略在函式調用層運作，透過別名加權路由在兩個函式版本之間分流調用。當情境指定 REST API 變更時使用 API Gateway 金絲雀；當情境指定 Lambda 程式碼變更時使用 Lambda 別名金絲雀。

Beanstalk 藍綠不是部署政策

Beanstalk 部署政策中不包含藍綠。Beanstalk 上的藍綠部署策略是透過克隆加 CNAME swap 實現的。任何將「藍綠」列為 Beanstalk 部署政策的選項都是錯的。

ECS 藍綠需要 ALB

透過 CodeDeploy 的 ECS 藍綠部署策略需要一個 Application Load Balancer 搭配兩個目標群組與兩個監聽器。若情境描述的是 NLB、CLB 或直接暴露的 Fargate 任務，ECS 藍綠不可用；正確答案是 ECS 滾動更新。

CodeDeploy AllAtOnce 沒有 Alarm 回滾窗口

CodeDeploy 的 AllAtOnce for Lambda 會立即切換 100% 的流量——沒有金絲雀或線性窗口供 CloudWatch alarm 在觸發回滾前偵測到問題。若情境要求「錯誤率飆升時自動回滾」，AllAtOnce 是錯的；答案是金絲雀或線性。

部署策略限制與配額

• CodeDeploy 每帳號每區域的部署數量：1,000 個活躍部署。
• Lambda 別名加權路由：每個別名最多 2 個版本（主要版本 + 一個附加版本）。
• CodeDeploy Lambda 部署配置：可透過 CreateDeploymentConfig 接受自訂配置。
• ECS 藍綠 terminationWaitTimeInMinutes：0–2880 分鐘（0–48 小時）。
• AppConfig 自訂部署策略 DeploymentDurationInMinutes：0–1440 分鐘。
• AppConfig FinalBakeTimeInMinutes：0–1440 分鐘。
• API Gateway 金絲雀流量百分比：0.0–100.0%。
• Route 53 加權路由權重：0–255。
• ALB 加權目標群組權重：0–999。

FAQ：部署策略七大常見問題

Q1：哪個 Lambda CodeDeploy 部署配置會先將 10% 的流量切換 5 分鐘，再切換剩餘的 90%？

CodeDeployDefault.LambdaCanary10Percent5Minutes。這是金絲雀部署策略配置——固定 10% 窗口、固定 5 分鐘等待，然後 100%。它是 DVA-C02 上最常被引用的金絲雀答案，因為 5 分鐘窗口足以透過 CloudWatch alarm 捕捉錯誤率飆升，同時讓整體部署時間控制在 10 分鐘以內。

Q2：Lambda 部署策略的自動回滾如何運作？

CodeDeploy for Lambda 部署策略在以下情況自動回滾：部署群組 AlarmConfiguration 中列出的 CloudWatch alarm 在金絲雀或線性窗口期間的任何時間點進入 ALARM 狀態，或者pre-traffic 或 post-traffic 鉤子回報 Failed。回滾會將 Lambda 別名重新指向先前的版本，並賦予 100% 權重，在幾秒內恢復部署前的狀態。

Q3：ECS 滾動更新與 ECS 藍綠部署策略有什麼差異？

ECS 滾動更新使用 ECS 部署控制器，在同一個服務內逐步以新任務替換舊任務，受 minimumHealthyPercent 與 maximumPercent 限制。ECS 藍綠部署策略使用 CODE_DEPLOY 部署控制器，需要一個 ALB 搭配兩個目標群組與兩個監聽器；CodeDeploy 管理測試監聽器，在切換生產流量前進行驗證，並支援最長 48 小時的手動驗證等待窗口，之後才終止舊任務集。

Q4：Elastic Beanstalk 能使用藍綠部署策略嗎？

可以，但不是作為部署政策。Beanstalk 的藍綠部署策略是透過克隆當前環境、將新版本部署到克隆環境、在克隆環境的 URL 上驗證，然後交換環境 CNAME 來實現的。Beanstalk 部署政策（All at once、Rolling、Rolling with additional batch、Immutable、Traffic splitting）不包含「藍綠」——CNAME swap 才是 Beanstalk 上的藍綠機制。

Q5：Lambda 部署策略中 pre-traffic 鉤子與 CloudWatch alarm 有什麼差異？

pre-traffic 鉤子（BeforeAllowTraffic）是一個 Lambda 函式，在任何生產流量切換到新版本之前，針對新部署的版本執行合成測試。CloudWatch alarm 在流量開始切換後，在金絲雀或線性窗口期間監控指標（錯誤、節流、延遲）。pre-traffic 鉤子在用戶看到問題之前就能捕捉；CloudWatch alarm 捕捉的是只有在真實用戶負載下才會出現的問題。任何生產 Lambda 部署策略的最佳實踐是同時使用兩者。

Q6：何時應使用 AWS AppConfig 功能旗標部署策略，而非 Lambda 金絲雀部署策略？

當變更僅涉及配置（旗標、閾值、字串），且處理兩種狀態的程式碼已經部署完畢時，使用 AppConfig 功能旗標部署策略。當變更涉及 Lambda 函式本身的新程式碼時，使用 Lambda 金絲雀部署策略。功能旗標將部署與發布解耦——你以暗地狀態上線程式碼，再翻轉旗標——而 Lambda 金絲雀是程式碼層面的部署機制。兩者可以結合使用：透過 Lambda 金絲雀部署策略將新程式碼部署在功能旗標後面，再透過 AppConfig 推送旗標。

Q7：Route 53 加權路由與 ALB 加權目標群組在藍綠部署策略上如何比較？

Route 53 加權 DNS 在 DNS 層運作，TTL 為分鐘級；切換傳播緩慢，客戶端 DNS 快取可能讓過期答案持續存在。ALB 加權目標群組在 HTTP 層運作，具備每請求粒度；切換即時生效。跨區域或跨技術棧的藍綠部署策略（例如在兩個完全分離的 AWS 帳號之間遷移）使用 Route 53 加權路由。在區域內需要即時、精確流量百分比的藍綠或金絲雀部署策略使用 ALB 加權目標群組。Lambda 別名權重粒度更細，在 Lambda 後端服務的調用層面運作。

DVA-C02 部署策略摘要

部署策略是第三領域的骨幹。掌握七種原型分類（原地、滾動、附加批次滾動、不可變、藍綠、金絲雀、線性、功能旗標），並記熟 Lambda 的 CodeDeploy 配置名稱（Canary10Percent5Minutes、Linear10PercentEvery10Minutes、AllAtOnce）。牢記：Lambda 部署策略以別名加權路由為軸心；ECS 藍綠部署策略需要帶有雙監聽器的 ALB；EC2 部署策略包含 CodeDeploy 藍綠搭配 ASG 替換與原生 Instance Refresh；Beanstalk 藍綠是 CNAME swap 而非部署政策；AppConfig 功能旗標部署策略將部署與發布解耦。永遠將部署策略與 CloudWatch alarm、Synthetics Canary 及 pre-traffic 鉤子搭配，建立分層的回滾觸發器。帶著以上決策樹進考場，每一道部署策略題都能在一分鐘內作答。