Amazon CLF-C02: 云架构与 Well-Architected 框架 — 学习指南

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

属于 AWS Cloud Practitioner CLF-C02 — 学习指南. 使用经过验证的答案练习： Amazon 考试中心, 或参加限时模拟考试： ExamRoll.io.

设计原则与计算资源采购决策

优秀的云架构始于小步迭代、自动化和松散耦合，以便独立扩展应用程序的各个部分。通过尽可能设计无状态服务来构建弹性架构，推行不可变性和临时计算，并应用最小权限原则进行访问控制。在选择计算定价模型时，要权衡时间范围、使用率的可预测性以及对中断的容忍度：长期运行的、状态稳定的工作负载适合承诺使用定价；突发性或不可预测的工作负载则适合按需（On-Demand）或在适当情况下使用 Spot。一个常见的陷阱是在不了解可变增长的情况下就承诺长期的 Reserved Instances 或 Savings Plans，这可能导致开销浪费或被锁定在错误的实例族中。另一个错误是在没有为中断做好设计的情况下，将 Spot 用于关键的有状态工作负载。考虑许可证和部署位置需求：Dedicated Hosts 支持与软件绑定的许可证和物理隔离，而 Savings Plans 则为计算开销提供了跨实例族和区域的灵活性。标签和自动化成本分配至关重要——没有一致的标签，就很难应用 Savings Plans 或执行规模优化分析。使用监控和警报及早发现低效问题，并随着使用率的变化每季度重新审视采购决策。

On-Demand： 按小时/秒付费，灵活性最高，无需承诺
Reserved Instances / Standard RIs： 针对特定实例属性的长期折扣，对稳定状态的工作负载具有成本效益
Savings Plans： 通过承诺消费换取跨实例族的灵活折扣
Spot Instances： 为可中断的工作负载提供大幅折扣
Dedicated Hosts： 为满足许可证或合规性限制而分配的物理主机

基础设施即代码、预置和隔离

基础设施即代码（IaC）为基础设施带来了可重复性、可审查性和版本控制。AWS CloudFormation 是原生的声明式 IaC 服务，用于描述和预置堆栈（stack）；模板将资源、依赖关系和参数化进行编码。AWS Cloud Development Kit (CDK) 提供了更高级别的构造，并支持多种语言（包括 TypeScript、Python、Java、C# 和 Go），让开发人员能用熟悉的语言来合成 CloudFormation。也可以通过 AWS CLI、SDK、AWS CDK 和 Terraform 等第三方工具进行程序化预置；当您希望与 AWS 功能紧密对齐并利用 CloudFormation 的漂移检测时，应选择原生工具。逻辑隔离由 Amazon Virtual Private Cloud (VPC) 提供，它与子网、路由表、安全组和网络 ACL 相结合，共同建立网络边界。IAM 控制身份和权限——包括用户、角色、组和策略——并用于管理程序化凭证和对资源的访问。从业者常见的陷阱包括存储根账户的访问密钥、未能为自动化建立跨账户角色，以及未在模板中强制执行标签策略。CloudFormation 模板应被视为代码：进行审查、代码风格检查（lint），并存储在版本控制中，以避免配置漂移并实现可预测的部署。

Well-Architected 支柱 — 实践重点

Well-Architected 框架以五大支柱为中心，指导设计决策和权衡取舍。理解每个支柱并将服务与之对应，有助于确定工作优先级和比较不同方案。

卓越运营： 为可观测的运营而设计，使用 CloudWatch 指标、日志和 Systems Manager 自动化；推动运行手册（runbook）和持续改进。
安全性： 使用 IAM 强制执行最小权限，使用 KMS 加密静态数据，启用 CloudTrail 和 GuardDuty 进行审计和检测，并使用 WAF 和 Shield 保护边缘。
可靠性： 使用多可用区（Multi-AZ）、自动恢复、Route 53 健康检查和备份（EBS 快照、RDS 自动备份、AWS Backup）来为故障设计，以满足恢复目标。
性能效率： 使用 Compute Optimizer 进行规模优化，利用缓存（CloudFront、ElastiCache），选择托管服务（Aurora、DynamoDB）和适当的存储层来优化 I/O 和延迟。
成本优化： 通过生命周期策略（例如，为需要立即检索的不常访问对象使用 S3 Intelligent-Tiering 或 Standard-IA）实施成本感知架构，使用 Savings Plans，并为非生产环境安排关机计划。

一个常见的决策标准是，是否使用托管服务来权衡运营开销与成本。一个常见的陷阱是为最坏情况下的峰值进行过度预置，而不是利用自动扩展（autoscaling）和缓存以更低的成本维持性能。

运维工具、数据服务、安全性及边缘选择

运维可见性和安全工具是架构良好环境的支柱。AWS CloudTrail 记录 API 活动以供审计，而 Amazon GuardDuty 则提供持续的威胁检测，以防范账户级别的异常行为。CloudWatch 收集指标和日志，并支持针对 EBS 卷写入峰值等事件的警报；如果原生指标不足，请使用 CloudWatch Agent 获取操作系统级别的指标。对于托管数据服务，RDS 为关系型数据库提供自动补丁和备份，DynamoDB 是 NoSQL、完全托管的键值和文档存储，而 Amazon Neptune 是一个托管的图形数据库，专为高度连接的数据集优化。对于全球内容分发和低延迟分发，边缘的 CloudFront 与 Shield 和 WAF 相结合，可提供 CDN 加 DDoS 防护和应用层过滤。对于边缘或本地的低延迟需求，请评估 AWS Outposts 或 Local Zones；Outposts 将 AWS 硬件部署在本地，以实现最低延迟和一致的 API。用户的身份联合和账户访问通过 AWS IAM Identity Center（前身为 AWS SSO）进行处理。在设计监控时，应将警报与自动修复（Lambda 或 Systems Manager）相结合，并避免一些常见错误，例如依赖单个可用区、使用根凭证或为必须即时检索的对象选择深度归档存储（Glacier）。

关键服务选择与用例： RDS 用于托管关系型数据库；DynamoDB 用于 NoSQL；Neptune 用于图形数据库；Lex 用于聊天机器人；CloudFront + WAF + Shield 用于全球 Web 交付和 DDoS 防护

实践问题：用例场景

场景：Acme Manufacturing 在 AWS 上运行混合工作负载，包括 VPC 中的生产 EC2 实例、用于订单处理的 RDS 实例，以及通过 S3 和 CloudFront 部署的静态资源网站。团队使用 AWS CLI 和 CloudFormation，开发人员需要安全的跨账户访问权限以进行 CI/CD。

挑战：他们必须降低持续运行的应用服务器的计算成本，在不使用根凭证的情况下保障自动化安全，并确保对由 EBS 支持的实例进行快速恢复，同时将停机时间降至最低。

推荐方法：

承诺与持续的小时计算支出相匹配的 Savings Plan，并将符合条件的实例转换为使用 Savings Plans 以立即节省成本。
在分析利用率后，才将长期运行的特定实例需求迁移到 Reserved Instances，并在适当情况下应用实例大小灵活性。
将所有根账户访问替换为 IAM 用户和角色：为 CI/CD 创建一个具有最低权限策略的 IAM 角色，并通过 STS AssumeRole 使用短期凭证进行跨账户自动化。
使用 AWS Backup 或计划的 Data Lifecycle Manager 策略实施自动化的 EBS 快照，并使用 AMI 加用户数据（user-data）进行快速实例更换，以及使用附加了 EBS 快照恢复功能的 Auto Scaling 组，以实现最短停机时间。

基本原理：将承诺定价与可预测的支出相匹配，可以在不牺牲可用性的情况下降低成本；用 IAM 角色和短期凭证替换根账户的使用，遵循了最低权限的最佳实践；自动快照和 AMI 支持快速恢复，这与可靠性和卓越运营支柱的原则一致。

← 账单、定价与支持 · 所有领域 · 管理、监控与分析 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →