examlab .net 用最有效率的方法，考取最有價值的認證
Vol. I
本篇導覽 約 21 分鐘

Elastic Beanstalk（重點概覽）

4,180 字 · 約 21 分鐘閱讀 ·

DVA-C02 的 AWS Elastic Beanstalk 入門：平台與受管環境、網頁伺服器環境 vs 工作程式環境、部署策略（All-at-Once、Rolling、Rolling with Additional Batch、Immutable、Traffic Splitting）、透過 CNAME 交換的 blue/green 部署、.ebextensions 與 .platform hooks、環境變數、已儲存組態、RDS 耦合陷阱、版本生命週期，以及遷移至 Amazon ECS / Amazon EKS / AWS App Runner 的路徑。

立即做 20 題練習 → 免費 · 不用註冊 · DVA-C02

AWS Elastic Beanstalk 是 AWS 上用來部署網頁應用程式的經典受管部署服務：您上傳程式碼，AWS Elastic Beanstalk 便會自動佈建執行所需的 Amazon EC2 執行個體、Elastic Load Balancer、Auto Scaling 群組，以及 Amazon CloudWatch 警示。就 DVA-C02 考試而言，這個主題仍在考綱範圍內，但 V2.1 考試指南相較於舊版已明顯降低 AWS Elastic Beanstalk 的比重——預期只會出現少量題目，涵蓋部署策略、工作程式環境 vs 網頁伺服器環境、組態 hooks，以及眾所周知的 RDS 耦合陷阱，而不會有深度操作情境。本指南定位為重點入門：足以正確回答 AWS Elastic Beanstalk 相關題目，但不過度投資在已降低優先序的主題上。

AWS Elastic Beanstalk 是什麼？

AWS Elastic Beanstalk 是一項受管部署服務，它接受應用程式碼（Java、.NET、PHP、Node.js、Python、Ruby、Go 或 Docker），並將其部署至一組完整受管的 AWS 資源環境中。您仍擁有這些 AWS 資源的完整所有權——EC2 執行個體、負載平衡器、Auto Scaling 群組，以及 Amazon CloudWatch 指標全都出現在您的 AWS 帳戶中，可供檢視與修改——但 AWS Elastic Beanstalk 會替您處理資源串接、健康監控，以及部署協調。這使得 AWS Elastic Beanstalk 成為 AWS 上最早的 PaaS 類型服務之一，比 AWS App Runner、Amazon ECS、Amazon EKS 與 AWS Fargate 都要早。

在 DVA-C02 層級，AWS Elastic Beanstalk 的重要知識點如下：

  1. 平台抽象 — AWS Elastic Beanstalk 支援一系列由 AWS 維護版本與修補程式的精選執行平台。
  2. 環境類型 — AWS Elastic Beanstalk 提供兩種不同的環境形態：網頁伺服器環境與工作程式環境。
  3. 部署策略 — AWS Elastic Beanstalk 提供五種內建部署策略，幾乎與 DVA-C02 考試情境一一對應。
  4. 組態介面 — .ebextensions、.platform hooks、環境變數，以及已儲存組態。
  5. 常見陷阱 — 尤其是 RDS 耦合陷阱與應用程式版本生命週期。
  6. 遷移路徑 — AWS Elastic Beanstalk 工作負載通常遷往何處（Amazon ECS、Amazon EKS、AWS App Runner）。

AWS Elastic Beanstalk 是一項 AWS 服務，用於在 Apache、Nginx、Passenger、IIS 等熟悉的伺服器上，部署及擴展以 Java、.NET、PHP、Node.js、Python、Ruby、Go 與 Docker 開發的網頁應用程式和服務。您只需上傳程式碼，AWS Elastic Beanstalk 便會自動處理部署的所有環節，從容量佈建、負載平衡、自動擴展到應用程式健康監控。使用 AWS Elastic Beanstalk 本身不額外收費——您只需支付儲存與執行應用程式所需之 AWS 資源的費用。參見：https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html

白話文解釋

要內化 AWS Elastic Beanstalk，最有效的方式是從三個不同角度各用一個日常類比來理解：PaaS 抽象到底意味著什麼、五種部署策略在實際操作上有何差異，以及受管便利性與自行管控之間的取捨。以下三個類比各自切入不同的生活情境，選擇最有共鳴的那一個作為主要理解框架，其餘兩個則在考題出乎意料時作為交叉驗證。

類比一：附設管家服務的公寓（平台抽象） 把 AWS Elastic Beanstalk 想像成一間附傢俱、有管家服務的公寓。您提著一個行李箱（應用程式 ZIP）走進去，床、冰箱、冷氣和網路（Amazon EC2、Elastic Load Balancer、Auto Scaling、Amazon CloudWatch）都已安裝完畢並正常運作。您仍是房客——可以移動傢俱、加個立燈、換床單——但水電管路和承重牆是房東的責任。相比之下，在純 Amazon EC2 上從零搭建，就像租一塊空地自己蓋房子，每一根管線都得自己鋪。這種「有設施但仍屬你所有」的感覺，就是 AWS Elastic Beanstalk 上 PaaS 的含義。

類比二：餐廳換菜單的五種方式（部署策略） 想像一家餐廳要換新菜單。All-at-Once 是暫時關店一小時、一口氣換掉所有菜單——最快，但換的期間顧客無法點餐。Rolling 是桌次輪流換，服務持續不中斷，但同一時間只有部分桌次可用新菜單。Rolling with Additional Batch 是在室外加開一個臨時帳篷，讓總座位數在菜單輪換期間始終不減少。Immutable 是在隔壁另開一間全新用餐區，完整測試後再把所有顧客帶過去——速度慢、短暫成本高，但回退只需關掉新用餐區。Traffic Splitting 則是先把一成顧客帶進新用餐區試吃，觀察評價，再決定全面推廣或撤回。

類比三：IKEA 預裁板材 vs 訂製木工（受管 vs 自行管理） AWS Elastic Beanstalk 是 AWS 運算服務裡的 IKEA 書架：零件已裁好、說明書已標準化，任何人都能快速組出一個可用的書架。自行管理一批 Amazon EC2 主機、搭配客製 AMI、user-data 腳本與手工設定的 Auto Scaling，則是找訂製木工的路線——每個榫頭都是量身打造，貼合度完美，但時間成本高出許多。AWS App Runner 比 AWS Elastic Beanstalk 更往「預裝好」的方向走：它就像直接出廠組裝完成的平板包裝。DVA-C02 不斷要求您在這個光譜上選擇正確的位置：需要 PaaS 預設值但還想看到 EC2 執行個體時選 Elastic Beanstalk；完全不想看到 EC2 時選 App Runner；IKEA 書架根本不合用時才選自行管理的 EC2。

AWS Elastic Beanstalk 平台與受管環境

AWS Elastic Beanstalk 平台是作業系統、語言執行環境、網頁伺服器與 AWS Elastic Beanstalk 代理程式的精選組合。AWS Elastic Beanstalk 維護了適用於 Java（Corretto）、.NET on Windows Server、Node.js、PHP、Python、Ruby、Go、Docker，以及預設定 Docker 映像的各類平台。每個平台都有 AWS 管理生命週期的平台版本——次要版本用來修補 OS 和執行環境；主要版本則帶來破壞性變更。

建立 AWS Elastic Beanstalk 環境時，AWS Elastic Beanstalk 會佈建下列受管資源：

  • Amazon EC2 Auto Scaling 群組，用來託管您的應用程式。
  • Amazon EC2 執行個體，執行所選平台及您上傳的應用程式套件。
  • Elastic Load Balancer（網頁伺服器環境預設為 Application Load Balancer）。
  • Amazon CloudWatch 警示，驅動 Auto Scaling 決策。
  • Amazon S3 儲存貯體，儲存應用程式版本、日誌與組態快照。
  • IAM 角色：AWS Elastic Beanstalk 本身的服務角色，以及授予應用程式所需權限的執行個體設定檔。
  • 安全群組，限制入站流量僅允許應用程式所需的連接埠。

您只需為這些底層資源付費；AWS Elastic Beanstalk 本身不加收任何費用。

環境 URL 與 CNAME

每個 AWS Elastic Beanstalk 環境都會取得一個格式為 environment-name.region.elasticbeanstalk.com 的唯一 URL。這個 CNAME 是您在 blue/green 部署中使用的識別碼——在兩個環境之間交換 CNAME，就是 AWS Elastic Beanstalk 實現零停機切換的方式。此 CNAME 也是 Amazon Route 53 記錄應指向的目標（通常透過別名或 CNAME 記錄）以處理正式流量。

網頁伺服器環境 vs 工作程式環境

AWS Elastic Beanstalk 提供兩種環境層，決定應用程式接收工作的方式。

網頁伺服器環境

網頁伺服器環境在 Elastic Load Balancer 後方執行 HTTP 應用程式。HTTP 用戶端（瀏覽器、行動 App、其他服務）連到負載平衡器 URL，再由它將請求分發至 Auto Scaling 群組中的 EC2 執行個體。這是預設層，符合傳統「三層式網頁應用程式」模式。

網頁伺服器環境的主要特性：

  • 入站協定：HTTP / HTTPS，可選 WebSocket。
  • 負載平衡器：Application Load Balancer（預設）、Classic Load Balancer 或 Network Load Balancer。
  • 擴展觸發條件：CPU 使用率、延遲、請求數，或自訂 Amazon CloudWatch 指標。
  • 健康狀態：AWS Elastic Beanstalk 監控 HTTP 回應並回報綠色 / 黃色 / 紅色。

工作程式環境

工作程式環境不直接提供 HTTP 服務。相反地，AWS Elastic Beanstalk 會佈建一個 Amazon SQS 佇列，並在每個 EC2 執行個體上執行一個小型 daemon（SQS daemon），該 daemon 會輪詢佇列，並將每則訊息以 POST 方式發送至應用程式的本機 HTTP 端點（預設為 http://localhost/）。應用程式處理完訊息後，回傳 HTTP 2xx 狀態以表示確認。非 2xx 回應視為失敗；AWS Elastic Beanstalk 會將訊息放回佇列，反覆失敗的訊息最終會路由至死信佇列。

工作程式環境的主要特性：

  • 入站協定：Amazon SQS 訊息，而非來自網際網路的 HTTP。
  • 擴展觸發條件：SQS 佇列深度。
  • 使用情境：非同步背景工作、圖片處理、報表產生、排程任務（透過 cron.yaml 週期性組態）、電子郵件派送、ETL。
  • 互動方式：應用程式套件根目錄的 cron.yaml 定義排程工作，AWS Elastic Beanstalk 會在每個環境的一個主要執行個體上執行這些工作。

DVA-C02 情境：「一個非同步圖片處理工作每則訊息最多需要 5 分鐘，且必須在失敗時重試。」正確的 AWS Elastic Beanstalk 答案是由 Amazon SQS 支撐的工作程式環境，而非網頁伺服器環境。在網頁伺服器環境中執行長時間工作，會有 ELB 閒置逾時錯誤的風險，並且佔用請求處理容量。工作程式環境將運算與負載平衡器解耦，並依佇列深度進行擴展。參見：https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts-worker.html

AWS Elastic Beanstalk 部署策略

部署策略是 DVA-C02 中 AWS Elastic Beanstalk 題目的核心。AWS Elastic Beanstalk 提供五種內建策略，用於將新版應用程式部署至現有環境。您需要根據部署速度、成本、停機時間與回退行為之間的取捨來選擇策略。

All-at-Once

使用 All-at-Once 部署策略時，AWS Elastic Beanstalk 會同時將新版應用程式部署至環境中的所有 EC2 執行個體。

  • 速度：最快。
  • 停機時間：有——所有執行個體同時重啟，服務短暫不可用。
  • 成本：最低——無需佈建額外執行個體。
  • 回退：手動重新部署舊版本。
  • 適用場景：短暫中斷可接受的開發與測試環境。

Rolling

使用 Rolling 部署策略時，AWS Elastic Beanstalk 會分批更新執行個體——例如每次更新 25%。每批完成更新後，下一批才開始。

  • 速度：中等。
  • 停機時間：無（前提是負載平衡器始終有健康的執行個體）。
  • 部署期間容量：降低——某批正在更新時，總容量會下降。
  • 成本：無需額外執行個體。
  • 回退：以相同批次方式重新部署舊版本來回退。
  • 適用場景：可接受暫時降低容量的正式環境。

Rolling with Additional Batch

Rolling with Additional Batch 在部署開始前先新增一批全新執行個體，確保部署期間環境始終擁有完整容量。

  • 速度：中等（略慢於純 Rolling）。
  • 停機時間：無。
  • 部署期間容量：完整——額外批次維持了總容量。
  • 成本：小幅增加——您需要為額外批次在部署期間付費。
  • 回退：以相同模式回退。
  • 適用場景：正式環境中無法接受部署期間容量降低的情況。

Immutable

Immutable 部署策略會佈建一個全新的 Auto Scaling 群組，並在其中以全新 EC2 執行個體執行新版應用程式。唯有新 ASG 回報健康後，AWS Elastic Beanstalk 才會將這些執行個體掛載至負載平衡器，並終止舊 ASG。

  • 速度：原地部署策略中最慢。
  • 停機時間：無。
  • 部署期間容量：加倍。
  • 成本：原地部署策略中最高——短暫期間需同時支付兩個完整機隊的費用。
  • 回退：非常快——舊 ASG 在新 ASG 完全健康之前仍然存在，回退只需終止新 ASG。
  • 適用場景：正式環境中安全性與快速回退優先於成本的情況。

Traffic Splitting（金絲雀）

Traffic Splitting 是最新的 AWS Elastic Beanstalk 部署策略。與 Immutable 相同，它會啟動一組執行新版本的平行執行個體，但接著在負載平衡器層分流流量——例如 90% 流向舊版本、10% 流向新版本——讓您能在全面切換前以真實流量驗證新版本。評估期結束後，AWS Elastic Beanstalk 會將 100% 的流量切至新版本，或在 CloudWatch 警示觸發時自動回退。

  • 速度：慢——包含評估期。
  • 停機時間：無。
  • 成本：部署期間與 Immutable 相近。
  • 回退：依警示自動回退。
  • 適用場景：在全面推廣前對新版本進行金絲雀發布或 A/B 驗證。

為 DVA-C02 熟記此決策表：

  • All-at-Once → 最快、有停機、僅限開發/測試。
  • Rolling → 無停機、部署期間容量降低、成本低。
  • Rolling with Additional Batch → 無停機、維持完整容量、小幅額外成本。
  • Immutable → 無停機、全新 ASG、最高安全性、快速回退、部署期間成本較高。
  • Traffic Splitting → 金絲雀 / A/B、以真實流量驗證、依警示自動回退。

若考題提到「零停機且快速回退」，選 Immutable。若提到「金絲雀」或「一定比例的正式流量」，選 Traffic Splitting。若提到「開發/測試、停機可接受」，選 All-at-Once。若提到「無停機、降低成本」，選 Rolling。若提到「無停機、維持完整容量」，選 Rolling with Additional Batch。參見：https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.deploy-existing-version.html

透過 CNAME 交換實現 Blue/Green 部署

上述五種內建部署策略都是原地部署——它們部署至現有的 AWS Elastic Beanstalk 環境中。若要在 AWS Elastic Beanstalk 上實現真正的 blue/green 部署，模式如下：

  1. 保持目前的正式環境持續運行（稱為 blue），其 CNAME 為 myapp.elasticbeanstalk.com。
  2. 複製 blue 環境，建立一個具有不同 CNAME 的獨立 green 環境，然後將新版應用程式部署至 green。
  3. 對 green 執行冒煙測試。
  4. 使用 AWS Elastic Beanstalk 的 Swap Environment URLs 操作來交換 CNAME。使用者連線的公開 DNS 名稱現在會解析至 green 環境；舊的 blue 環境成為回退目標。
  5. 若發生問題，再次交換 CNAME——回退幾乎是即時的。
  6. green 穩定後，終止舊的 blue 環境以釋放資源。

CNAME 交換式 blue/green 是針對 DVA-C02 題目「零停機、全新環境、透過 DNS 變更快速回退」的標準答案。請注意重要細節：交換發生在 CNAME 層，因此快取了舊 DNS 記錄的用戶端，在 TTL 到期前仍可能持續連至 blue；計畫交換時請縮短 DNS TTL。

DVA-C02 常見陷阱：誤以為 AWS Elastic Beanstalk 的 Immutable 策略等同於 blue/green。事實並非如此。Immutable 是在同一個環境內建立新的 Auto Scaling 群組，並重複使用相同的環境 URL。真正的 blue/green 是兩個各有獨立 CNAME 的環境，再透過 Swap Environment URLs 完成切換。若考題強調「兩個環境」和「交換 URL」，答案是 CNAME 交換式 blue/green 模式——而非 Immutable，也非 Traffic Splitting。參見：https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html

組態：.ebextensions 與 .platform Hooks

AWS Elastic Beanstalk 在您的應用程式套件中提供兩個自訂介面。了解兩者對 DVA-C02 而言至關重要。

.ebextensions

應用程式來源套件根目錄下的 .ebextensions/ 目錄，存放 YAML 或 JSON 組態檔（副檔名 .config），AWS Elastic Beanstalk 會在佈建或更新環境時套用這些組態。支援的區段包括：

  • packages — 透過 yum、rpm、apt 或語言專屬套件管理器安裝 OS 套件。
  • files — 以指定的擁有者與權限將檔案寫入執行個體的檔案系統。
  • commands — 在應用程式設定前執行命令。
  • container_commands — 在應用程式解壓縮後、部署前執行命令。
  • services — 啟動、停止、啟用或停用 sysvinit 或 systemd 服務。
  • option_settings — 覆寫 AWS Elastic Beanstalk 組態選項（擴展、負載平衡器、環境變數等），或設定 AWS 資源屬性。
  • Resources — 以額外的 AWS 資源擴充底層 AWS CloudFormation 堆疊，因為 AWS Elastic Beanstalk 底層使用的正是 AWS CloudFormation。

.platform Hooks（Amazon Linux 2 與 Amazon Linux 2023）

在 Amazon Linux 2 與 Amazon Linux 2023 的 AWS Elastic Beanstalk 平台上，較新的 .platform/hooks/ 目錄讓您可以將可執行 shell 腳本放入各個生命週期階段：

  • prebuild/ — 在原始碼解壓縮後、建置工具執行前執行。
  • predeploy/ — 在建置後、應用程式部署前執行。
  • postdeploy/ — 在應用程式部署後執行。
  • confighooks/prebuild/、confighooks/predeploy/、confighooks/postdeploy/ — 對應的 hooks，在組態變更（非程式碼部署）時執行。

在較新的平台版本上，.platform hooks 取代了許多傳統的 .ebextensions 模式，對於命令式腳本的需求，應優先使用 .platform hooks，而非 .ebextensions。

在 Amazon Linux 2 與 Amazon Linux 2023 的 AWS Elastic Beanstalk 平台上，請使用 .platform/hooks/ 來執行部署期間的 shell 腳本（安裝代理程式、預熱快取、執行資料庫遷移），並將 .ebextensions/ 保留給宣告式 AWS 資源組態（option_settings、額外 AWS CloudFormation Resources、packages）。這樣的分工讓部署邏輯更易於理解，也符合目前 AWS 建議的模式。參見：https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/platforms-linux-extend.html

環境變數與環境屬性

AWS Elastic Beanstalk 透過鍵值對形式的環境屬性（有時稱為環境變數）將設定值傳遞給執行中的應用程式程序。設定方式如下：

  • AWS Elastic Beanstalk 主控台（Configuration → Software）。
  • AWS CLI：aws elasticbeanstalk update-environment --option-settings Namespace=aws:elasticbeanstalk:application:environment,OptionName=KEY,Value=VALUE。
  • .ebextensions 中 aws:elasticbeanstalk:application:environment 命名空間下的 option_settings。

環境屬性是傳遞非機密組態（功能旗標、端點 URL、日誌層級）的標準方式，並以 OS 環境變數的形式暴露給應用程式。若需傳遞機密資訊，請優先使用 AWS Systems Manager Parameter Store 或 AWS Secrets Manager——透過 .platform hooks 在啟動時取回機密，而非將其寫入環境屬性，以避免它們出現在 AWS Elastic Beanstalk 的組態快照中。

已儲存組態

已儲存組態是 AWS Elastic Beanstalk 環境組態選項（執行個體類型、擴展設定、環境變數、負載平衡器類型、VPC 設定）的具名快照。已儲存組態存放於 AWS Elastic Beanstalk 的 Amazon S3 儲存貯體中，可在建立新環境時套用，或重設至現有環境。

當 DVA-C02 詢問如何跨多個環境複製已知良好的組態，或如何將組態與應用程式碼一起納入版本控制時，已儲存組態就是正確的 AWS Elastic Beanstalk 答案。

RDS 耦合陷阱 — 正式環境務必解耦

DVA-C02 中最常出現的 AWS Elastic Beanstalk 陷阱之一，就是 RDS 耦合問題。建立 AWS Elastic Beanstalk 環境時，您可以選擇讓 AWS Elastic Beanstalk 在環境內一併佈建 Amazon RDS 資料庫。這在開發上很方便，但在正式環境中相當危險：

  • Amazon RDS 執行個體由 AWS Elastic Beanstalk 環境的 AWS CloudFormation 堆疊所擁有。
  • **若環境被終止，Amazon RDS 資料庫也會隨之終止。**您的資料將不復存在。
  • 複製環境或執行 blue/green 切換時，風險極高，因為資料庫綁定於某一特定環境。

正式環境的最佳做法是將 Amazon RDS 從 AWS Elastic Beanstalk 解耦：

  1. 在 AWS Elastic Beanstalk 之外建立 Amazon RDS 資料庫（透過 AWS CloudFormation、AWS CDK 或直接使用 Amazon RDS 主控台）。
  2. 透過環境屬性將資料庫端點、使用者名稱與密碼傳入 AWS Elastic Beanstalk 環境（機密資訊於執行時從 AWS Secrets Manager 取回）。
  3. 設定環境的安全群組，允許流量在資料庫連接埠上連至 RDS 安全群組。
  4. 如此一來，資料庫的生命週期便獨立於 AWS Elastic Beanstalk 環境的生命週期——您可以自由複製、執行 blue/green 或終止環境，而不會遺失資料。

DVA-C02 情境：「AWS Elastic Beanstalk 環境被終止，團隊失去了正式環境的資料庫。」根本原因是 RDS 與環境耦合。解決方案：在 AWS Elastic Beanstalk 之外建立 Amazon RDS 執行個體，並以環境屬性的方式傳入端點。若考題提到「跨環境終止保留資料庫」、「共用資料庫的 blue/green」或「將 AWS Elastic Beanstalk 與 RDS 解耦」，正確答案一律是解耦模式。參見：https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.db.html

應用程式版本生命週期

AWS Elastic Beanstalk 應用程式版本是一個已上傳的來源套件（通常是 ZIP），儲存於 Amazon S3 並以標籤追蹤。每次部署都會參照一個版本標籤。隨著時間累積，未使用的版本會不斷增加，並可能觸及每個應用程式 1000 個版本的軟性上限。

應用程式版本生命週期政策可自動清理這些版本。您可以設定為：

  • 依數量刪除 — 保留最近 N 個版本（例如 200 個），刪除較舊的版本。
  • 依時間刪除 — 保留 N 天以內的版本，刪除較舊的版本。
  • 可選擇在刪除 AWS Elastic Beanstalk 版本記錄時，保留 Amazon S3 中的來源套件，以便日後還原。
  • 可選擇保護目前已部署至任何環境的版本，防止其被刪除。

就 DVA-C02 而言，請記住：除非您設定生命週期政策，否則 AWS Elastic Beanstalk 不會自動清理應用程式版本；觸及版本上限是一個常見的操作問題。

遷移路徑：Amazon ECS、Amazon EKS、AWS App Runner

AWS Elastic Beanstalk 在 DVA-C02 V2.1 中已被降低比重，因為較新的服務能以現代化的預設值涵蓋相同的使用情境。當考題詢問「採用容器的團隊應以哪個服務取代 AWS Elastic Beanstalk」時，請了解以下遷移路徑：

  • Amazon ECS on AWS Fargate — 當您想要無伺服器容器並搭配完整 AWS 原生整合時，是 AWS Elastic Beanstalk Docker 平台的直接替代方案。適合需要掌控任務定義、服務探索與 Amazon ECS 自動擴展的情境。
  • Amazon EKS on AWS Fargate — 當團隊已標準化至 Kubernetes，並需要跨雲端或與現有地端叢集互通時。
  • AWS App Runner — 最接近 AWS Elastic Beanstalk PaaS 風格的網頁應用程式後繼服務。您給 AWS App Runner 一個容器映像或來源儲存庫，它就會處理負載平衡器、TLS、自動擴展，並自動部署。無需管理任何 Auto Scaling 群組或 Amazon EC2 執行個體。
  • AWS Lambda + Amazon API Gateway — 當工作負載是事件驅動、突發性的，或天生適合每個端點對應一個函式的模型時。

DVA-C02 V2.1 考試指南相較於舊版大幅縮減了 AWS Elastic Beanstalk 的涵蓋範圍。現代考題更可能參考 AWS App Runner、Amazon ECS on AWS Fargate 或 AWS CodeDeploy 的部署策略，而非深度的 AWS Elastic Beanstalk 操作。學習 AWS Elastic Beanstalk 時，目標是能辨識其核心概念（環境類型、部署策略、CNAME 交換、.ebextensions、RDS 耦合），但無需投入與 AWS Lambda、Amazon DynamoDB 或 AWS IAM 相同的深度。參見：https://d1.awsstatic.com/training-and-certification/docs-dev-associate/AWS-Certified-Developer-Associate_Exam-Guide.pdf

AWS Elastic Beanstalk 的監控與健康狀態

AWS Elastic Beanstalk 提供兩種健康回報模式：

  • 基本健康回報 — 使用 Amazon EC2 與 Elastic Load Balancer 健康檢查，將環境分類為綠色、黃色、紅色或灰色。
  • 增強型健康回報 — 每個執行個體上的 AWS Elastic Beanstalk 代理程式會收集詳細的請求指標（p50/p90/p99 延遲、請求數、HTTP 狀態碼），並發布至 Amazon CloudWatch。增強模式是啟用許多實用的 AWS Elastic Beanstalk 警示所必需的。

增強型健康回報通常是正式環境的正確選擇。它能提供基本模式無法呈現的百分位延遲與錯誤率資訊。

擴展與 Auto Scaling

AWS Elastic Beanstalk 封裝了 Amazon EC2 Auto Scaling 群組。您可以設定：

  • 最小與最大執行個體數量。
  • 擴展觸發條件（Amazon CloudWatch 指標、閾值、統計值、週期）。
  • 擴大與縮小的增量及冷卻時間。

對於網頁伺服器環境，CPU 使用率與請求數是常見的觸發條件。對於工作程式環境，SQS 佇列深度是自然的訊號——AWS Elastic Beanstalk 將 ApproximateNumberOfMessagesVisible 作為擴展指標公開。

打包與部署應用程式套件

您透過上傳來源套件來部署至 AWS Elastic Beanstalk——通常是儲存庫根目錄的 ZIP 檔，包含 .ebextensions/、.platform/ hooks、平台專屬清單（Procfile、buildfile、Dockerrun.aws.json）以及應用程式碼。

常見的部署方式：

  • AWS Elastic Beanstalk CLI（eb CLI） — 本機 CLI，執行 eb init、eb create、eb deploy、eb open 與 eb logs。
  • AWS Management Console — 透過瀏覽器上傳 ZIP。
  • AWS CodePipeline + AWS CodeBuild — CI/CD 管道，呼叫 AWS Elastic Beanstalk API 部署新版應用程式。
  • AWS CloudFormation — 定義 AWS::ElasticBeanstalk::Application、AWS::ElasticBeanstalk::ApplicationVersion 與 AWS::ElasticBeanstalk::Environment 資源。

服務比較：AWS Elastic Beanstalk vs AWS App Runner vs AWS CodeDeploy

  • AWS Elastic Beanstalk — 用於網頁應用程式的受管環境（EC2 + ELB + ASG）；五種部署策略；.ebextensions 自訂；成熟但已降低比重。
  • AWS App Runner — 針對容器化與來源碼式網頁應用程式的新一代 PaaS；看不到 EC2；心智模型更簡單；不開放部署策略選擇。
  • AWS CodeDeploy — 適用於 Amazon EC2、AWS Lambda 與 Amazon ECS 的部署協調服務；透過 appspec.yml 提供原地與 blue/green 策略。當 DVA-C02 考題涉及 AWS Elastic Beanstalk 範疇之外的部署策略時，通常 AWS CodeDeploy 才是正確答案。

若 DVA-C02 考題描述上傳含有平台執行環境的網頁應用程式 ZIP，AWS Elastic Beanstalk 是合適的選擇。若描述的是容器映像且要求零 EC2 管理，AWS App Runner 是合適的選擇。若描述的是在 Amazon ECS 或 AWS Lambda 上協調 blue/green 部署，AWS CodeDeploy 是合適的選擇。

關鍵數字與必背事實

  • 5 種部署策略：All-at-Once、Rolling、Rolling with Additional Batch、Immutable、Traffic Splitting。
  • 2 種環境層：網頁伺服器環境、工作程式環境。
  • 8 個支援的平台系列（不含 Docker）：Java、.NET、PHP、Node.js、Python、Ruby、Go，加上 Docker 作為獨立平台系列。
  • 1000 — 每個應用程式的版本軟性上限（透過生命週期政策管理）。
  • $0 — AWS Elastic Beanstalk 服務本身不收費；您只需支付底層資源的費用。
  • 2 個自訂介面：.ebextensions/ 與 .platform/hooks/。
  • 1 種 blue/green 機制：Swap Environment URLs（在兩個環境之間進行 CNAME 交換）。

常見考試陷阱 — 必背易錯點

陷阱一：「Immutable 等同於 blue/green」

錯誤。Immutable 是在同一個 AWS Elastic Beanstalk 環境內替換 Auto Scaling 群組，並重複使用相同的 CNAME。Blue/green 是兩個 AWS Elastic Beanstalk 環境透過 CNAME 交換。

陷阱二：「All-at-Once 在正式環境中是安全的」

錯誤。All-at-Once 會造成停機。它只適用於開發/測試環境。正式環境請選 Rolling、Rolling with Additional Batch、Immutable 或 Traffic Splitting。

陷阱三：「AWS Elastic Beanstalk 會依佇列深度為網頁伺服器環境自動擴展」

錯誤。佇列深度擴展適用於工作程式環境。網頁伺服器環境依 HTTP 相關指標（CPU、請求數、延遲）擴展。

陷阱四：「.ebextensions 只能設定環境變數」

錯誤。.ebextensions 可以安裝套件、寫入檔案、執行命令、啟動服務、覆寫 AWS Elastic Beanstalk 選項，甚至新增 AWS CloudFormation 資源。

陷阱五：「在 AWS Elastic Beanstalk 內佈建 RDS 是最佳實踐」

錯誤。這種做法將資料庫的生命週期與環境耦合。正式環境的最佳實踐是獨立建立 Amazon RDS，並以環境屬性的方式傳入端點。

陷阱六：「AWS Elastic Beanstalk 與 AWS CodeDeploy 是同一回事」

錯誤。AWS Elastic Beanstalk 是包含部署功能的環境抽象；AWS CodeDeploy 是適用於 Amazon EC2、AWS Lambda 或 Amazon ECS 的獨立部署服務。DVA-C02 經常測驗兩者的區別。

陷阱七：「Traffic Splitting 像 AWS Lambda 線性別名一樣逐步轉移流量」

部分正確。Traffic Splitting 確實可設定流量比例並評估 CloudWatch 警示，但其觸發模型與回退語義是 AWS Elastic Beanstalk 特有的，與 AWS CodeDeploy 使用的 AWS Lambda 別名路由並不相同。

FAQ — AWS Elastic Beanstalk DVA-C02 高頻考題

Q1：用一句話說明 DVA-C02 中的 AWS Elastic Beanstalk 是什麼？ 答：AWS Elastic Beanstalk 是一項受管部署服務，它接受您的網頁應用程式碼，在一個完整佈建的 AWS 環境（EC2、ELB、Auto Scaling、CloudWatch）上執行，除了這些底層資源本身的費用外，不額外收取任何費用。您保留資源的所有權；AWS Elastic Beanstalk 負責協調生命週期。

Q2：零停機且回退最快，應選哪種 AWS Elastic Beanstalk 部署策略？ 答：Immutable。它會平行佈建新的 Auto Scaling 群組，僅在新 ASG 健康後才切換，並保留舊 ASG 以便透過終止新 ASG 快速回退。若考題還要求以真實流量進行金絲雀測試，則選 Traffic Splitting。

Q3：如何在 AWS Elastic Beanstalk 上執行 blue/green 部署？ 答：在現有環境（blue）旁建立第二個環境（green），將新版本部署至 green，執行冒煙測試，然後使用 Swap Environment URLs 交換 CNAME。回退只需再次交換 CNAME。請記住，這是環境層級的操作，而非部署策略。

Q4：網頁伺服器環境與工作程式環境有何差異？ 答：網頁伺服器環境透過 Elastic Load Balancer 接收 HTTP 請求。工作程式環境透過執行個體上的 daemon 接收 Amazon SQS 訊息，專為非同步背景處理而設計。工作程式環境依佇列深度擴展；網頁伺服器環境依 HTTP 相關指標擴展。

Q5：為何在正式環境中應避免在 AWS Elastic Beanstalk 環境內建立 Amazon RDS？ 答：因為終止 AWS Elastic Beanstalk 環境時，RDS 執行個體也會隨之終止，導致資料遺失。最佳實踐是獨立建立 Amazon RDS，並以環境屬性的方式傳入端點，使資料庫的生命週期獨立於環境生命週期。

Q6：.ebextensions 與 .platform hooks 有何差異？ 答：.ebextensions 是原始的宣告式組態機制（packages、files、commands、services、option_settings、Resources），適用於所有平台。.platform/hooks/ 是較新的 Amazon Linux 2 / 2023 機制，在 prebuild、predeploy 與 postdeploy 階段執行可執行 shell 腳本。命令式腳本優先使用 .platform hooks；宣告式 AWS 資源組態優先使用 .ebextensions。

Q7：若團隊要從 AWS Elastic Beanstalk 遷移，應遷往何處？ 答：對於最小化維運的容器化網頁應用程式，AWS App Runner 是最接近 PaaS 風格的後繼選擇。需要更多掌控時選 Amazon ECS on AWS Fargate。若要標準化至 Kubernetes，選 Amazon EKS on AWS Fargate。對於事件驅動或低吞吐量端點，選 AWS Lambda 搭配 Amazon API Gateway。

Q8：AWS Elastic Beanstalk 在 EC2 和 ELB 費用之外還需額外付費嗎？ 答：不需要。AWS Elastic Beanstalk 本身免費。您只需支付其代為佈建的 Amazon EC2、Elastic Load Balancer、Amazon EBS、Amazon CloudWatch 與 Amazon S3 資源費用。

延伸閱讀 — AWS 官方文件

AWS Elastic Beanstalk 是 AWS 上「上傳程式碼，AWS 管理環境」的經典部署服務，雖然 DVA-C02 V2.1 已縮小其考試比重，但核心概念仍是可測驗的範圍：請理解兩種環境層、五種部署策略、CNAME 交換式 blue/green、兩個組態介面（.ebextensions 與 .platform hooks）、環境變數、已儲存組態、RDS 耦合陷阱、應用程式版本生命週期，以及遷移至 Amazon ECS、Amazon EKS 或 AWS App Runner 的路徑。回答 AWS Elastic Beanstalk 考題時，只要將情境對應至上述概念之一，就能穩固拿下它在 DVA-C02 中所配置的分數。

官方資料來源

更多 DVA-C02 主題