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

部署與運維方式

4,120 字 · 約 21 分鐘閱讀

在 AWS 進行部署與運維,代表你要選擇用什麼方式在 AWS 全球基礎設施上佈建、設定、更新與自動化雲端資源。CLF-C02 考試(Task Statement 3.1)測驗你是否能分辨三種 AWS 部署存取方法(Management Console、AWS CLI、AWS SDK),解釋以 AWS CloudFormation 與 AWS CDK 實作的 IaC,為情境挑選正確的部署模式(雲端、混合雲、地端),並辨識 AWS Elastic Beanstalk 這類代管部署平台與 AWS Systems Manager 等運維服務。本文會用 CLF-C02 要求的深度,在 Domain 3 範疇內把 AWS 部署方法的完整版圖講清楚。

AWS 部署與運維方法是什麼?

AWS 部署方法是你用來建立與管理 AWS 資源的工具、介面與模式。AWS 運維方法則是你在資源部署完成後,用來執行、監控、修補與更新這些資源的工具。CLF-C02 考試把部署與運維合併到 Task Statement 3.1 同一題組,因為真實世界的 AWS 工作一向是兩者並用:你用 AWS CloudFormation 部署,再用 AWS Systems Manager 運維;你用 AWS CLI 部署,再用 AWS SDK 寫程式做日常運維;你部署到一個混合雲拓撲,再透過 AWS Direct Connect 與 AWS VPN 運維這個拓撲。

從最高層次來看,CLF-C02 考試希望你對「我該怎麼和 AWS 對話?」這個問題給出三個答案:

  1. AWS Management Console——瀏覽器圖形化介面,給人類使用。
  2. AWS CLI——命令列工具,給腳本、終端機與自動化管線使用。
  3. AWS SDK——軟體函式庫,讓應用程式用 Python、JavaScript、Java、Go、.NET、Ruby、PHP、C++ 等語言呼叫 AWS API。

你還要對「我的工作負載要跑在哪?」這個問題給出三個答案:

  1. 全雲端(all-in)——每個工作負載都跑在 AWS Region 裡。
  2. 混合雲——部分工作負載跑在地端,透過 AWS Direct Connect 或 AWS Site-to-Site VPN 連到 AWS,或是跑在安裝於你自家資料中心的 AWS Outposts 硬體上。
  3. 地端(搭配雲端工具)——傳統資料中心,但使用 AWS CDK 或 AWS CloudFormation 等 AWS 相容工具來維持設定的一致性。

這兩條軸線——存取方法與部署模式——再加上 IaC(AWS CloudFormation、AWS CDK)與代管部署平台(AWS Elastic Beanstalk),就構成 CLF-C02 對 AWS 部署方法的完整考點。

AWS 部署方法是 AWS 提供的程式化與互動式機制,用來建立、設定與管理 AWS 資源。三條標準存取路徑是 AWS Management Console(GUI)、AWS CLI(shell)以及 AWS SDK 函式庫。三者背後呼叫的都是同一套 AWS 服務 API,也就是說:任何你能在 AWS Management Console 點得出來的功能,都能用 AWS CLI 寫成腳本,或用 AWS SDK 從程式碼呼叫。參考:https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html

白話文解釋 Deployment & Operation Methods

要真正掌握 AWS 部署方法(AWS deployment methods),先用三個白話類比把概念裝進腦袋。

類比一:點珍奶的三種方式(手搖飲店類比) AWS 就像一間熱鬧的手搖飲店,你想點杯珍奶可以用三種方式。第一種是走進店裡對著菜單指指點點、跟店員說「大杯珍奶微糖少冰」——這就是 AWS Management Console,適合第一次來、想看清楚有什麼料;第二種是拿出手機打給店家照著菜單代號喊「M1 大杯微少」——這就是 AWS CLI,速度快、熟客首選;第三種是透過 foodpanda 的 API 直接把訂單丟到店家 POS——這就是 AWS SDK,讓程式自動下單、完全不用人類動手。三種方式點到的都是同一杯珍奶,因為背後呼叫的都是同一套櫃檯 API。

類比二:蓋房子的圖紙 vs 親手砌磚(工地類比) IaC 像拿藍圖給工班蓋房子。AWS CloudFormation 是一份 JSON 或 YAML 的藍圖,寫清楚「三間臥室、兩間浴室、北向採光」,CloudFormation 就照圖完美蓋出房子,而且每次照同一張圖蓋出來的房子完全一樣。AWS CDK 則像請建築師用程式語言(Python、TypeScript、Java)寫下「生成一張藍圖的邏輯」——你寫程式,CDK 產生 CloudFormation 藍圖,再交給 CloudFormation 去蓋。如果不用 IaC,你就是親手搬磚頭一塊塊砌——可能蓋得起來,但下次想再蓋一棟一模一樣的就難了。

類比三:自己開餐廳 vs 請集團代管(開店經營類比) 假設你要開一家網路餐廳,有三種做法。全自己來就是 Amazon EC2 加手動設定——自由度最高、負擔也最重。用 AWS Elastic Beanstalk 像把餐廳交給一個代管集團:你只負責寫菜單(上傳 app 程式碼),集團自動幫你蓋廚房、請服務生、自動擴編人手、處理水電瓦斯。這就是為什麼 AWS Elastic Beanstalk 常被稱為 PaaS-like 部署方法。再往上一層是 AWS Lambda:你連菜單都不寫完整,只寫一道道菜的食譜,客人點一次才做一次,完全 serverless。三者的抽象層級不同,考試常問「哪個最少營運負擔」,答案通常朝 Lambda 或 Beanstalk 方向走,而不是自己搭 EC2。

把這三個類比串起來:部署方法(deployment methods)回答「我怎麼下單」,部署模式(deployment models)回答「在哪裡蓋廚房」,IaC 回答「用什麼圖紙蓋」,管理平台回答「自己蓋還是請人代管」。CLF-C02 的 Task 3.1 就是把這四條軸線一次講清楚。

核心運作原理——在 AWS 上佈建、運維與自動化

每一種 AWS 部署方法最後都會走到同一個終點:AWS 服務 API。AWS Management Console、AWS CLI 與 AWS SDK 是通往同一棟大樓的三扇不同大門。理解這個核心原理,CLF-C02 Task 3.1 大部分的題目就迎刃而解。

當你在 AWS Management Console 點「Launch Instance」,Console 其實是對 EC2 的 RunInstances API 發出一個 HTTPS 呼叫。當你在 AWS CLI 輸入 aws ec2 run-instances,CLI 發出的是同一個 HTTPS 呼叫。當 Python 程式透過 AWS SDK 呼叫 boto3.client('ec2').run_instances(...),背後發出的也是同一個 HTTPS 呼叫。這三種 AWS 部署方法的差別只在使用體驗:

  • AWS Management Console:最適合第一次探索、一次性的手動工作,以及視覺化檢視資源。
  • AWS CLI:最適合寫腳本、自動化、shell 管線、CI/CD 任務,以及跨帳號的可重複操作。
  • AWS SDK:最適合把 AWS 行為嵌進應用程式裡,讓你的產品程式碼能以程式方式建立、讀取、更新與刪除 AWS 資源。

在這個 API 基礎之上,AWS 又疊了一層更高階的部署方法:

  • AWS CloudFormation 把一份宣告式樣板變成一整組資源堆疊。
  • AWS CDK 從一般程式語言產生 AWS CloudFormation 樣板。
  • AWS Elastic Beanstalk 接收應用程式碼,幫你把周邊基礎設施一起部署起來。
  • AWS Systems Manager 提供運維層:修補、執行命令、參數儲存、工作階段管理。

每一題 CLF-C02 的部署與運維題目,都是在這些層次之間做選擇。

為什麼 AWS 要提供這麼多種部署方法

AWS 提供多種部署方法,是因為不同工作流需要不同層次的抽象。第一次摸索 Amazon S3 的個人開發者需要 AWS Management Console;要跨 12 個 AWS Region 部署 200 個微服務的 DevOps 工程師需要 AWS CloudFormation;要打造一款用 S3 上傳照片的手機 app 的行動開發團隊,需要 Swift 或 Kotlin 版的 AWS SDK。AWS Management Console、AWS CLI、AWS SDK、AWS CloudFormation 與 AWS CDK 是互補(而不是互斥)的選擇,合起來就涵蓋了所有的部署需求。

存取 AWS 的方式:Management Console、CLI、SDK 與 API

每位 CLF-C02 考生都要能流暢分辨這三種作為主要存取點的 AWS 部署方法。

AWS Management Console(GUI)

AWS Management Console 是位於 console.aws.amazon.com 的網頁 GUI,多數人學習 AWS 時第一個接觸到的入口。

AWS Management Console 的優點

  • 不用安裝——任何瀏覽器都能開。
  • 視覺化探索——你可以看到所有 AWS 服務,並按類別瀏覽。
  • 引導式精靈——Amazon RDS、AWS Elastic Beanstalk、Amazon VPC 等服務都有建立資源的精靈,會推薦合理的預設值。
  • 費用與帳單儀表板——AWS Billing and Cost Management 用 AWS Management Console 看最直觀。

AWS Management Console 的缺點

  • 無法自動化——你不能排一個 cron job 去「點按鈕」。
  • 不易重現——兩個人照同一份精靈操作,可能會因為一點點差異造成資源漂移。
  • 批次操作緩慢——要用 Console 一個一個建立 50 個 S3 儲存貯體會讓人崩潰。
  • 沒有版本控管——Console 點擊沒有 commit history。

AWS CLI

AWS CLI 是安裝在本機的命令列工具,從 shell 發出 AWS API 呼叫。對 DevOps、SRE 與 CI/CD 管線而言,它是一項基礎的 AWS 部署方法。

AWS CLI 命令結構aws <service> <operation> --<parameter> <value>。舉例來說,aws s3 cp localfile.txt s3://my-bucket/ 會上傳一個檔案;aws ec2 describe-instances --region us-east-1 會列出 EC2 執行個體。

AWS CLI 的優點

  • 可用 bash、zsh、PowerShell 或任何 shell 寫腳本。
  • 跨所有 AWS 服務的語法一致——學會一個套路就等於學會每個服務。
  • 可安裝在 Linux、macOS、Windows、AWS CloudShell、Amazon EC2 執行個體與 AWS Systems Manager 受管節點上。
  • 批次操作速度快——一支腳本就能對 1000 筆資源做迴圈。

AWS CLI 的缺點

  • 學習曲線比 AWS Management Console 陡。
  • 需要先設定好憑證(access key、IAM Role、AWS SSO profile)。

AWS SDK

AWS SDK 是一組特定語言的函式庫,把 AWS API 包成該語言原生的函式呼叫。AWS 官方提供 Python(Boto3)、JavaScript/TypeScript、Java、.NET、Go、Ruby、PHP、C++、Swift、Kotlin 與 Rust 版本的 SDK。當 AWS 功能必須嵌進應用程式碼時,AWS SDK 就是正確的 AWS 部署方法。

AWS SDK 的優點

  • 原生語言結構——慣用的物件設計、async/await 支援、型別化的參數。
  • 整合的憑證解析——會自動使用 EC2 上的 IAM Role、Lambda 的執行角色,或本機的 profile。
  • 內建重試、逾時與 paginator helper。
  • 任何能跑該語言的環境都能用——手機 app、後端服務、AWS Lambda 函式、Amazon ECS 容器。

AWS SDK 的缺點

  • 需要會寫程式。
  • 需要在應用程式裡做相依套件管理。

CLF-C02 可能出題:「哪種 AWS 部署方法支援自動化?」正確答案是 AWS CLI 或 AWS SDK,因為兩者都提供程式化存取。AWS Management Console 支援自動化,它只給人類互動用。記住這個對應:Management Console = 點擊;AWS CLI = 腳本;AWS SDK = 程式碼。三者都是合法的 AWS 部署方法,但只有 AWS CLI 與 AWS SDK 提供程式化存取。參考:https://docs.aws.amazon.com/general/latest/gr/aws-apis.html

程式化存取:深入 AWS CLI 與 AWS SDK

程式化存取是 CLF-C02 對「非人類點擊」那類 AWS 部署方法的統稱。你必須熟悉的兩種程式化存取方法就是 AWS CLI 與 AWS SDK。

透過 AWS CLI 做程式化存取

用 AWS CLI 做程式化存取時,可以靠 access key(access key ID + secret access key),更好的做法是透過 AWS STS 取得短期憑證的 IAM Role。當你要自動化一次性任務、把輸出接給 shell pipe,或驅動 AWS Systems Manager Run Command 對整個執行個體機隊下命令時,AWS CLI 常是最快的途徑。

CLF-C02 常考的 AWS CLI 程式化存取情境:

  • DevOps 工程師用 AWS CLI 寫 bash 腳本,跨帳號輪換 IAM access key。
  • CI/CD 管線用 AWS CLI 把部署產物推到 Amazon S3,再觸發 AWS CodeDeploy。
  • 管理員從 AWS CloudShell(AWS Management Console 內建的瀏覽器 shell)用 AWS CLI,完全不需在本機裝任何東西。

透過 AWS SDK 做程式化存取

當 AWS API 呼叫必須發生在應用程式內部時,AWS SDK 是正確的程式化存取路徑。AWS SDK 使用和 AWS CLI 一模一樣的 IAM 權限模型與憑證解析鏈:環境變數、共用憑證檔、EC2 的 IAM Role,或服務帳號的 IAM Role。

CLF-C02 常考的 AWS SDK 程式化存取情境:

  • 跑在 Amazon EC2 上的 Python 應用程式用 Boto3(Python 版 AWS SDK)寫資料到 Amazon DynamoDB。不儲存任何長期憑證——執行個體設定檔的 IAM Role 會自動提供短期憑證。
  • JavaScript 網頁 app 使用瀏覽器版 AWS SDK for JavaScript,搭配 Amazon Cognito 做身分驗證。
  • 用 Go 寫的 AWS Lambda 函式透過 AWS SDK for Go 把訊息推到 Amazon SNS。

使用 AWS CLI 或 AWS SDK 做程式化存取時,一律優先使用 IAM Role,而非長期 access key。IAM Role 會透過 AWS STS 簽發臨時憑證,就算憑證外洩,波及範圍也比較小。對跑在 Amazon EC2、AWS Lambda、Amazon ECS 或 AWS Fargate 上的 AWS 部署方法,正確做法是把 IAM Role 掛在運算資源上,讓 AWS SDK 自動取用——程式碼與設定檔裡都不該出現 access key。參考:https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html

IaC:AWS CloudFormation、AWS CDK、AWS SAM

IaC 是把雲端基礎設施定義在文字檔裡的實作方式,這些檔案可以做版本控制、同儕 review,並重複部署。IaC 是正式環境工作負載的主流 AWS 部署方法,因為它解決了純手動點 AWS Management Console 帶來的「無法重現」問題。

AWS CloudFormation

AWS CloudFormation 是 AWS 原生的 IaC 服務。你用 YAML 或 JSON 寫一份 CloudFormation 樣板,描述你要的 AWS 資源(EC2 執行個體、S3 儲存貯體、IAM Role、VPC 等等),AWS CloudFormation 就會把它們當成一個堆疊一次部署完畢。

CLF-C02 必懂的 AWS CloudFormation 核心概念:

  • 樣板(Template)——YAML 或 JSON 檔,描述資源、參數、mapping、outputs 與 condition。
  • 堆疊(Stack)——從一份樣板建立出來的 AWS 資源集合。
  • Change Set——在套用更新前,先預覽 AWS CloudFormation 會改動什麼。
  • 漂移偵測(Drift Detection)——AWS CloudFormation 能偵測堆疊中的資源是否有被樣板以外的操作改掉。
  • 宣告式(Declarative)——你描述期望的最終狀態,AWS CloudFormation 自己決定操作順序。

AWS CloudFormation 是宣告式的:你說你要什麼,而不是要怎麼一步步做。這和命令式腳本「先做第 1 步、再做第 2 步、再做第 3 步」不同。宣告式 IaC 更安全,因為 AWS CloudFormation 可以在部署失敗時自動 rollback、偵測漂移,並以冪等方式更新堆疊。

AWS CDK(Cloud Development Kit)

AWS CDK 是一個更高階的 IaC 框架,讓你用 TypeScript、JavaScript、Python、Java、C# 與 Go 等熟悉的程式語言定義 AWS CloudFormation 堆疊。AWS CDK 在底層產生 AWS CloudFormation 樣板,再交給 AWS CloudFormation 去部署。

AWS CDK 存在的理由:面對複雜架構,AWS CloudFormation YAML 容易寫得又臭又長。開發者偏好通用程式語言提供的迴圈、條件判斷與可重用類別。AWS CDK 讓你用這些工具寫 IaC,同時仍以 AWS CloudFormation 當部署引擎。

AWS SAM(Serverless Application Model)

AWS SAM 是 AWS CloudFormation 針對 serverless 應用程式所做的 IaC 延伸。AWS SAM 讓 AWS Lambda、Amazon API Gateway 與 Amazon DynamoDB 的樣板變得更簡潔。部署時,AWS SAM 會把自己的簡寫語法展開成完整的 AWS CloudFormation 樣板。

AWS OpsWorks

AWS OpsWorks 是支援 Chef 與 Puppet(兩個開放原始碼的組態管理工具)的 AWS 組態管理服務。AWS OpsWorks 讓你對 Amazon EC2 執行個體套用命令式的組態 recipe。它在 CLF-C02 上的考點不如 AWS CloudFormation 頻繁,但常以誘答選項形式出現。

CLF-C02 要求你能用名字直接認出這些 IaC 類 AWS 部署方法:

  1. AWS CloudFormation——宣告式 YAML/JSON 樣板,是 IaC 的基石服務。
  2. AWS CDK(Cloud Development Kit)——用 TypeScript、Python、Java、C# 或 Go 定義基礎設施;編譯後產生 AWS CloudFormation。
  3. AWS SAM(Serverless Application Model)——AWS CloudFormation 針對 serverless(Lambda + API Gateway + DynamoDB)的簡寫。
  4. AWS OpsWorks——Chef 與 Puppet 組態管理。 只要題目提到「宣告式樣板」或「受版本控管的基礎設施」,答案幾乎一定是 AWS CloudFormation。參考:https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html

代管部署平台:AWS Elastic Beanstalk

AWS Elastic Beanstalk 是一項代管部署的 AWS 服務,它接收你的應用程式碼(Java、.NET、PHP、Node.js、Python、Ruby、Go 或 Docker),再自動佈建周邊基礎設施:Amazon EC2 執行個體、Elastic Load Balancer、Auto Scaling group 與 AWS CloudWatch 監控。AWS Elastic Beanstalk 經常被形容為「PaaS-like」,因為你管的是自己的 app,而不是伺服器。

CLF-C02 必懂的 AWS Elastic Beanstalk 關鍵特性:

  • 你上傳程式碼,AWS Elastic Beanstalk 負責部署。
  • 你挑平台(Python、Node.js、Docker 等等),AWS Elastic Beanstalk 會佈建相對應的執行環境。
  • 你保有完整控制權——底層的 AWS 資源會出現在你的 AWS 帳號裡,可以檢視或修改。
  • 服務本身不另外收費——你只付底層 AWS 資源(EC2、ELB、Auto Scaling)的費用。

AWS Elastic Beanstalk 是一種部署方法,不是運算服務。 考試把兩者分得很清楚:

  • 運算服務(Task 3.3):Amazon EC2、AWS Lambda、Amazon ECS、Amazon EKS、AWS Fargate。
  • 部署方法(Task 3.1):AWS CloudFormation、AWS CDK、AWS Elastic Beanstalk、AWS OpsWorks。

AWS Elastic Beanstalk 底層確實用 Amazon EC2,但在 CLF-C02 的考試大綱裡被歸成部署方法,因為它的價值是部署自動化,而不是運算元件本身。

CLF-C02 情境題很常要求你根據工作負載描述挑出正確的 AWS 部署方法。陷阱是挑錯抽象層級:

  • 「開發者想上傳網頁應用程式,但不想管伺服器」 → AWS Elastic Beanstalk(針對 web app 的平台抽象)。
  • 「團隊跑 Docker 容器,需要代管式的編排」 → Amazon ECS 或 Amazon EKS(容器服務,不算是部署方法)。
  • 「工作負載是事件驅動、短時間爆發執行」 → AWS Lambda(serverless 運算)。
  • 「團隊需要對作業系統與執行個體類型有完整控制」 → Amazon EC2(IaaS 運算)。

在這份清單裡,AWS Elastic Beanstalk 是唯一被 CLF-C02 正式標記為部署方法的選項;其餘都是 Task 3.3 的運算服務。只要題目出現「web application deployment」或「upload code, AWS handles infrastructure」這類字眼,答案就是 AWS Elastic Beanstalk。參考:https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html

AWS Systems Manager——運維自動化

AWS Systems Manager 是和 AWS 部署方法並肩的運維服務。資源部署完成後(不論是透過 AWS Management Console、AWS CLI、AWS SDK、AWS CloudFormation 或 AWS Elastic Beanstalk),AWS Systems Manager 就接手日常運維:修補、執行命令、參數儲存,以及類似 SSH 的安全存取。

CLF-C02 會考的 AWS Systems Manager 核心能力:

  • AWS Systems Manager Patch Manager——為 Amazon EC2 執行個體與混合雲中的地端伺服器自動化作業系統修補。
  • AWS Systems Manager Run Command——跨整個執行個體機隊執行命令,不需要 SSH 或 RDP。
  • AWS Systems Manager Parameter Store——儲存設定值與機密(明文或 KMS 加密)。
  • AWS Systems Manager Session Manager——提供瀏覽器的 shell 存取,無需開啟對外連接埠,也不用管 SSH 金鑰。
  • AWS Systems Manager State Manager——對受管執行個體強制維持期望的組態狀態。
  • AWS Systems Manager Automation——runbook 式的工作流,把可重複的運維任務自動化。

AWS Systems Manager 是 AWS 部署方法與 Day-2 運維之間的黏著劑。CLF-C02 把 AWS Systems Manager 也視為一種運維類 AWS 部署方法,因為它負責 Task 3.1 裡「運維」那一半。

部署模式:全雲端、混合雲、地端

CLF-C02 定義了三種 AWS 部署模式,用來描述你的工作負載落腳於何處。

全雲端(Cloud-Native)部署

全雲端代表 100% 的應用程式堆疊都跑在 AWS Region 中,客戶資料中心裡沒有任何伺服器。這是新創公司、綠地專案與完成現代化的企業工作負載的預設 AWS 部署模式。全雲端能最大化 AWS 全球基礎設施的效益:自動擴展、跨可用區彈性、按量計費的經濟效益,以及與每一項 AWS 服務的整合。

混合雲部署

混合雲部署把地端資料中心和 AWS 連在一起,讓工作負載跨越兩邊。企業正在進行多年雲端遷移,或是因為資料主權、延遲、軟體授權等因素必須保留部分地端工作負載時,就會走混合雲路線。

混合雲 AWS 部署方法的三大支柱:

  1. AWS Direct Connect——從你的資料中心拉一條專屬私有光纖到 AWS Direct Connect 站點。延遲穩定低、頻寬大(1 Gbps、10 Gbps、100 Gbps 可選),流量不會經過公共網際網路。適合長期、高吞吐的混合雲工作負載。
  2. AWS Site-to-Site VPN——從地端 VPN 裝置到 AWS Virtual Private Gateway 或 AWS Transit Gateway,透過公共網際網路的加密 IPsec 通道。建置快、比 Direct Connect 便宜,但因為走公共網際網路,延遲會比較浮動。
  3. AWS Outposts——由 AWS 代管、實體安裝在你的資料中心的伺服器機櫃。AWS Outposts 把 AWS 服務(EC2、EBS、RDS、ECS、EKS、S3 on Outposts)延伸到你的機房,讓你在本地運算的同時仍享有 AWS API 與 AWS Management Console 的體驗。適合極低延遲、資料主權或 air-gapped 場景。

地端部署

地端部署代表工作負載完全跑在客戶資料中心裡,但仍可以使用 AWS CloudFormation 樣板、AWS CDK construct、AWS SDK 整合或 AWS 容器映像檔等 AWS 相容工具來維持一致性。AWS 對應的地端部署方法包括 AWS Outposts、VMware Cloud on AWS、AWS Local Zones(靠近都會區的邊緣 Region),以及 Amazon ECS Anywhere / Amazon EKS Anywhere(在你自己的硬體上跑 AWS 容器編排)。

CLF-C02 常用 Direct Connect vs Site-to-Site VPN 的情境題考混合雲 AWS 部署方法:

  • AWS Direct Connect → 專屬私有光纖、穩定高頻寬、不經公共網際網路。最適合「高吞吐、穩定延遲、嚴格安全」需求。
  • AWS Site-to-Site VPN → 走公共網際網路的加密通道、建置快、成本低。最適合「快速搭建混合雲連線」或「在既有網際網路上加上加密通道」。
  • AWS Outposts → AWS 硬體實體落在你的資料中心。最適合「AWS 服務需要在地端跑」或「資料主權/本地低延遲運算」。

CLF-C02 至少會有一題要你把情境對應到這三種混合雲 AWS 部署方法之一。參考:https://docs.aws.amazon.com/directconnect/latest/UserGuide/Welcome.html

一次性操作 vs 可重複的自動化流程

把 AWS 部署方法照「一次性操作」與「可重複自動化」分類,是理解 CLF-C02 題目的好角度。

一次性操作是做一次、不預期重複、可以安心用手做的工作。例如:建立第一個 IAM 管理員使用者、啟用 AWS CloudTrail 組織追蹤、探索一項剛推出的 AWS 服務。這時用 AWS Management Console 很合適。

可重複的自動化流程是會重複發生很多次的任務,而且經常是跨多個帳號與 AWS Region。例如:為每個功能分支佈建一套新環境、每月輪換 IAM 憑證、一天部署微服務 50 次。這時該用 AWS CLI、AWS SDK、AWS CloudFormation、AWS CDK 與 AWS Systems Manager。

CLF-C02 獎勵那些在「只要會重複做」的情境裡,穩定選擇 IaC 與程式化存取,而不是選 AWS Management Console 點擊的考生。

API——所有 AWS 部署方法底下的基石

所有 AWS 部署方法最終都在和 AWS 服務 API 對話——這些是接收簽章請求、回傳結構化回應的 HTTPS 端點。AWS Management Console、AWS CLI、AWS SDK、AWS CloudFormation 與 AWS CDK 通通都是這些 API 的客戶端。

CLF-C02 不需要你背 API 端點或簽章演算法。你需要知道的是:

  • 每一項 AWS 服務都有對應的 API。
  • AWS CLI、AWS SDK 與 AWS Management Console 都是這些 API 的客戶端。
  • AWS CloudFormation 建立堆疊時,會代替你呼叫這些 API。
  • AWS Identity and Access Management(IAM)負責管控誰能對哪些資源呼叫哪些 API——這也是為什麼 AWS 部署方法和 IAM 密不可分。

關鍵數字與必背事實

CLF-C02 是基礎級考試,會避開太細的數字,但以下幾個 AWS 部署方法數字常常出現:

  • 3 種主要存取方法:AWS Management Console、AWS CLI、AWS SDK。
  • 3 種部署模式:雲端(all-in)、混合雲、地端。
  • 2 種混合雲網路選項加上 AWS Outposts:AWS Direct Connect、AWS Site-to-Site VPN、AWS Outposts。
  • AWS Direct Connect 頻寬:1 Gbps、10 Gbps、100 Gbps(代管連線可低於 1 Gbps)。
  • AWS CloudFormation 樣板格式:YAML 與 JSON。
  • AWS CDK 支援語言:TypeScript、JavaScript、Python、Java、C#、Go。
  • AWS SDK 支援語言(CLF-C02 範圍):Python、JavaScript、Java、.NET、Go、Ruby、PHP、C++(再加上 Swift、Kotlin、Rust)。
  • AWS Elastic Beanstalk 支援平台:Java、.NET、PHP、Node.js、Python、Ruby、Go、Docker。
  • AWS Elastic Beanstalk 價格:服務本身 $0;你只付底層的 EC2、ELB、EBS 等等。

常見考試陷阱——必背的誘答題

陷阱 1:「AWS Management Console 支援自動化」

錯。AWS Management Console 是給人用的瀏覽器 GUI。自動化要靠 AWS CLI 或 AWS SDK。只要 CLF-C02 題目出現「team needs to automate provisioning」,就先把 AWS Management Console 從選項裡刪掉。

陷阱 2:「AWS CloudFormation 是命令式的」

錯。AWS CloudFormation 是宣告式的。你描述期望狀態,AWS CloudFormation 自己決定順序。命令式的 AWS 部署方法會是一份由上往下執行 AWS CLI 命令的 bash 腳本。

陷阱 3:「AWS Elastic Beanstalk 是運算服務」

錯。AWS Elastic Beanstalk 是一種部署方法,底層的運算服務是 Amazon EC2。CLF-C02 Task 3.1 涵蓋 AWS Elastic Beanstalk;Task 3.3 才直接考 Amazon EC2。

陷阱 4:「AWS CDK 取代 AWS CloudFormation」

錯。AWS CDK 會產生 AWS CloudFormation 樣板,並以 AWS CloudFormation 作為部署引擎。兩者互補,不是競爭對手。

陷阱 5:「Direct Connect 永遠比 VPN 好」

錯。AWS Direct Connect 需要實體佈線(前置時間以「週」為單位),費用也比 AWS Site-to-Site VPN 高。只要情境是快速建置混合雲連線或頻寬需求較低,AWS Site-to-Site VPN 才是對的 AWS 部署方法。

陷阱 6:「AWS Outposts 是 Direct Connect 的一種」

錯。AWS Outposts 是安裝在你資料中心的 AWS 硬體,不是網路連線。你通常還是會把 AWS Outposts 搭配 AWS Direct Connect 使用,把流量回傳到某個 AWS Region。

陷阱 7:「AWS Systems Manager 只是部署方法」

只對一部分。AWS Systems Manager 主要是運維服務(修補、執行命令、參數儲存),但它被放進 Task 3.1,是因為它自動化了部署之後的 Day-2 運維。

部署方法 vs 運算服務——範疇界線(3.1 vs 3.3)

CLF-C02 考試大綱把 Task 3.1(部署與運維方法)與 Task 3.3(運算服務)分開。界線如下:

屬於 Task 3.1(部署) 屬於 Task 3.3(運算)
AWS Management Console Amazon EC2
AWS CLI AWS Lambda
AWS SDK Amazon ECS
AWS CloudFormation Amazon EKS
AWS CDK AWS Fargate
AWS SAM Amazon Lightsail
AWS OpsWorks AWS Batch
AWS Elastic Beanstalk (底層是 EC2,但 Beanstalk 本身屬於部署)
AWS Systems Manager
AWS Direct Connect
AWS Site-to-Site VPN
AWS Outposts

當 CLF-C02 問「你會挑哪一種部署方法?」正確答案在左邊那欄。問「哪項運算服務在跑這個工作負載?」正確答案在右邊那欄。盯緊這條界線,就能避開 Elastic-Beanstalk vs EC2 vs Lambda 的陷阱。

vs 相似概念:AWS CloudFormation vs Terraform vs AWS CDK

  • AWS CloudFormation:AWS 原生的 IaC 工具,YAML/JSON,宣告式,對所有 AWS 服務的支援最即時。
  • AWS CDK:用真正的程式語言(TypeScript、Python、Java 等)包裝 AWS CloudFormation。
  • HashiCorp Terraform:第三方多雲 IaC 工具。它不是 AWS 服務——在 CLF-C02 的正確答案裡超出範疇,但可能以誘答形式出現。AWS 原生的正確答案永遠是 AWS CloudFormation 或 AWS CDK。

練習題方向——對應 Task 3.1 的題型

讀完這個主題後,用下列題型練功:

  • 把情境對應到正確的 AWS 部署方法:Management Console、AWS CLI、AWS SDK、AWS CloudFormation、AWS CDK、AWS Elastic Beanstalk。
  • 在混合雲連線上,從 AWS Direct Connect、AWS Site-to-Site VPN 與 AWS Outposts 中三選一。
  • 判斷某項服務是部署方法還是運算服務(Task 3.1 vs Task 3.3)。
  • 認出什麼情境的正確答案是 IaC、什麼情境才需要手動點擊流程。

FAQ——部署與運維方法熱門問題

Q1:CLF-C02 上與 AWS 部署方法互動的三種主要方式是什麼? A:AWS Management Console(瀏覽器 GUI)、AWS CLI(命令列腳本)與 AWS SDK(語言函式庫)。三者背後呼叫的是同一套 AWS API,但服務不同的工作流:探索、自動化腳本、以及嵌在應用程式內的整合。

Q2:在 CLF-C02 裡,AWS Elastic Beanstalk 屬於運算服務還是部署方法? A:AWS Elastic Beanstalk 在 Task 3.1 被分類為部署方法。它底層佈建 Amazon EC2,但考試把它當作代管部署平台來考。底層的 Amazon EC2 屬於 Task 3.3 的運算服務。

Q3:AWS CloudFormation 與 AWS CDK 的差別是什麼? A:AWS CloudFormation 是原生的宣告式 IaC 引擎,使用 YAML 或 JSON 樣板。AWS CDK 讓你用真正的程式語言(TypeScript、Python、Java、C#、Go)寫同一份基礎設施,再合成為 AWS CloudFormation 樣板。AWS CDK 沒有取代 AWS CloudFormation——它疊在它上面。

Q4:混合雲 AWS 部署方法中,什麼時候該選 AWS Direct Connect,而不是 AWS Site-to-Site VPN? A:如果你需要穩定高頻寬、可預期的低延遲、且流量不能走公共網際網路(常見於搬運大量資料的企業工作負載),就選 AWS Direct Connect。如果你需要快速建置、較低成本,或只是想在既有網際網路上加一層加密通道,就選 AWS Site-to-Site VPN。

Q5:AWS Management Console 可以自動化嗎? A:不行。AWS Management Console 是給人用的瀏覽器介面。要自動化,請用 AWS CLI、AWS SDK、AWS CloudFormation 或 AWS CDK。這是 CLF-C02 的常見陷阱:只要情境提到自動化、排程任務或可重複部署,答案一定是程式化存取(AWS CLI、AWS SDK)或 IaC(AWS CloudFormation、AWS CDK)。

Q6:AWS Elastic Beanstalk 會在底層資源之外再收錢嗎? A:不會。AWS Elastic Beanstalk 本身沒有額外費用。你只付它代你佈建的 AWS 資源:Amazon EC2 執行個體、Elastic Load Balancer、Amazon EBS 磁區,以及 Amazon CloudWatch。這讓 AWS Elastic Beanstalk 相較於直接跑 Amazon EC2,是一種不會增加成本的 AWS 部署方法。

Q7:AWS Outposts 算混合雲還是地端 AWS 部署方法? A:兩者都算,看題目怎麼問。AWS Outposts 是安裝在客戶資料中心的 AWS 硬體,把 AWS 服務延伸到地端。它能支撐混合雲架構(通常搭配 AWS Direct Connect 回到某個 Region),也是 CLF-C02 描述「AWS 服務跑在我自己的資料中心裡」時最主要的 AWS 原生答案。

延伸閱讀——AWS 官方文件

精通 AWS 部署方法是拉高 CLF-C02 Domain 3 分數最快的一條路。把三種存取類 AWS 部署方法(AWS Management Console、AWS CLI、AWS SDK)、兩種主流 IaC 工具(AWS CloudFormation、AWS CDK)、代管部署平台(AWS Elastic Beanstalk)、運維服務(AWS Systems Manager)以及三種部署模式(雲端、混合雲、地端)內化到直覺,所有 Task Statement 3.1 的題目都會化約成「從這些清單裡選對答案」。

官方資料來源