Amazon CLF-C02: 核心運算服務 — 學習指南

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

屬於 AWS Cloud Practitioner CLF-C02 — 學習指南. 使用經過驗證的解答練習： Amazon 考試中心, 或參加限時模擬考試： ExamRoll.io.

EC2 核心概念、採購模型與可用性模式

Amazon EC2 是基礎的 IaaS 運算服務：您可以選擇執行個體類型來決定 CPU、記憶體、儲存和網路規格，執行您自己控制的作業系統，並可選擇性地掛載 Elastic Block Store (EBS) 磁碟區以獲得持久性的區塊儲存。為了設計高可用性，需要將工作負載部署到多個可用區域 (AZ)，並在適當時部署到多個區域 (Region)。對於託管式關聯式資料庫，可使用 Amazon RDS Multi‑AZ 實現同步備援和自動容錯移轉；若需要極致的讀取擴展或跨區域災難復原，則可考慮使用 Amazon Aurora Global Database。執行個體的採購選擇會影響成本和彈性的權衡：On‑Demand 提供無須承諾的靈活性；Reserved Instances 或 Compute Savings Plans 為穩定且持續使用的情境提供最大的可預測性節省；Spot Instances 則為容錯、可中斷的工作負載提供最低的價格。常見的陷阱包括依賴單一 AZ、在執行個體上嵌入長期有效的憑證，以及「以防萬一」而過度佈建資源。應使用 Auto Scaling 群組搭配運作狀況檢查、生命週期掛鉤和混合執行個體政策 (On‑Demand + Spot) 來平衡成本與可用性。在 Reserved/Savings Plans 與 Spot 之間做決定時，需評估所需的正常運行時間、對中斷的容忍度以及預測的準確性；根據 RTO/RPO 要求和跨區域延遲的限制，來選擇 Multi‑AZ 或 Multi‑Region 策略。

託管式容器、批次與無伺服器運算：決策標準

AWS 提供多種託管式運算平台以符合不同的架構目標。AWS Lambda 支援事件驅動的無伺服器函式，具備自動擴展和依毫秒計費的特性，最適合無狀態、生命週期短的任務。Amazon ECS 提供託管式容器協同運作選項，可與 Fargate 整合以實現無伺服器容器執行，或與 EC2 整合以獲得更多控制權。Amazon EKS 為標準化採用 Kubernetes 的團隊提供託管式控制平面，其工作節點可以是 EC2 或 Fargate。AWS Batch 可在 EC2 或 Spot 容量上排程和擴展批次運算任務，為高效能或高流量的任務優化吞吐量。Elastic Beanstalk 是一個應用程式平台，用於部署 Web 應用程式而無需管理底層基礎設施；它抽象化了 EC2、autoscaling、ELB 和 RDS 的設定，以加速直接遷移 (lift‑and‑shift) 的部署。關鍵的決策標準包括：維運技能組合 (具備 Kubernetes 專業知識的團隊偏好 EKS)、部署速度 (Beanstalk)、成本可預測性 (Fargate 簡化了流程但成本可能更高)，以及工作負載特性 (Lambda 適用於短時間、事件觸發的任務；ECS/EKS 適用於長時間運行的服務)。應避免選擇功能最豐富的選項，當一個更簡單的託管服務 (如 Lambda 或 Fargate) 能夠減少維運負擔並提高敏捷性時，應優先考慮。

自動擴展、彈性與成本優化策略

彈性 (Elasticity) 是指根據需求擴展或縮減資源的能力；自動擴展 (autoscaling) 則是實現彈性的機制。使用 EC2 的 Auto Scaling 群組 (ASG)，根據目標追蹤、步階或預測性政策來新增或移除執行個體。對於容器，使用 ECS 或 EKS 的自動擴展功能來調整任務和叢集，並使用 Lambda 內建的並行控制來管理函式。架構設計應追求無狀態 (statelessness)，並將狀態外部化到託管服務中，例如 Amazon RDS、DynamoDB、ElastiCache 或 S3，這樣執行個體就可以是暫時性的。透過定期的規模審查來適當調整執行個體大小 (Right-size)，使用監控 (CloudWatch 指標和警報)，並考慮為穩定的基線用量購買 Savings Plans 或 Reserved Instances，同時將變動的工作負載放在 Spot 上。需要權衡的定價模型：

On‑Demand: 無須承諾，按小時/秒付費。
Reserved Instances / Savings Plans: 承諾 1 年或 3 年以獲得大幅折扣。
Spot Instances: 為可中斷的工作負載提供最大折扣。
Dedicated Hosts/Instances: 為滿足合規性要求提供實體隔離，成本較高。常見的陷阱包括低估自動擴展的暖機時間、未使用生命週期掛鉤來實現優雅關閉，以及對有狀態的關鍵工作負載過度使用 Spot。應採用藍/綠部署或金絲雀部署來安全地發布版本，並使用生命週期政策來自動化控制未使用資源的成本。

運算服務的安全性、合規性與維運工具

在 AWS 中，安全性與維運是運算服務的基礎。根據責任共擔模型，AWS 負責保護全球基礎設施和受管服務，而客戶在使用 IaaS 時，則需負責客體作業系統 (guest OS)、應用程式組態、資料以及 IAM 權限。應避免內嵌長期存取金鑰；取而代之的是，將 IAM 角色附加到 EC2 執行個體，或對 EKS 使用 IAM Roles for Service Accounts (IRSA)，並使用 AWS Secrets Manager 或 Systems Manager Parameter Store (SecureString) 來輪替並集中管理密碼。為了稽核與調查，請啟用 AWS CloudTrail 來擷取整個帳戶的 API 活動，並使用 AWS Config 來記錄資源組態。使用 Amazon Macie 來發現並分類 S3 中的敏感資料，並使用 IAM Access Analyzer 或 S3 Access Analyzer 來找出跨帳戶或公開的資源共享。若需合規證據，可使用 AWS Artifact 來擷取稽核報告。透過用於網路流量的 VPC Flow Logs、用於帳戶特定事件的 AWS Personal Health Dashboard，以及用於全球服務狀態的 Service Health Dashboard，可以提升維運的可視性。從業人員常見的錯誤包括：讓根帳戶帶有作用中的金鑰、未在根使用者上啟用 MFA，以及未使用 IAM Identity Center (前身為 AWS SSO) 來集中化身分，以實現對外部應用程式的 SAML 型單一登入。

實務問題：使用案例情境

情境：Acme Analytics 公司在一個生產環境的 AWS 帳戶中，於單一 AZ 內的 EC2 上執行一個資料處理應用程式。他們有夜間處理大量資料的批次作業，並希望降低成本、從 AZ 故障中更快復原，以及實現安全的密碼處理。

挑戰：在不立即重新架構整個應用程式的前提下，降低運算成本，同時確保夜間批次處理量並改善跨 AZ 的可用性。

建議方法：

將批次工作者遷移到 AWS Batch 運算環境，並使用混合執行個體政策 (Spot + On-Demand) 來降低成本，同時維持基準容量。
設定 AWS Batch 使用多個 AZ，並啟用 Retry/RetryStrategy，將任務佇列分散到多個 AZ 以提高彈性。
將內嵌的憑證替換為用於 EC2/Batch 作業的 IAM 角色，並將輪替的密碼儲存在 AWS Secrets Manager 中；與 IAM 整合以實現自動擷取。
對於任何剩餘的具狀態元件，在一個最小化的 EC2 機群上實作 CloudWatch 警示和 Auto Scaling 政策，若有使用資料庫 (DB)，則啟用跨 AZ 的 RDS Multi‑AZ。

基本原理：使用受管的批次處理 (managed batch) + Spot 可降低成本與維運開銷，而多 AZ 分佈以及 IAM/Secrets Manager 則能改善可用性與安全性——這與彈性、最低權限和自動化密碼輪替的最佳實踐相符。

← AWS 全球基礎設施 · 所有領域 · 核心儲存服務 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →