云计算概念
这章是 CLF-C02 的地基。
虽然权重大约 24%，不是最高，但它决定你后面做服务题和计费题时能不能快速判断。
学完这章你要达到 3 个结果：
- 听到云术语时，能用人话解释（不是背定义）。
- 看到场景题时，能判断它在考“云优势、服务模型还是部署模型”。
- 能把 Region / AZ / Edge Location 的关系说清楚，并知道它们为什么影响可用性与延迟。
☁️ 云计算到底在说什么？
先不讲定义，讲一个你熟悉的场景。
你开了一家网店，最初每天订单不多，一台服务器够用。但赶上双十一，流量瞬间翻十倍，服务器直接挂掉，顾客打不开页面。等你临时去买服务器、等货、装机，活动早结束了。
传统 IT 就是这个处境：你必须按"可能出现的最大需求"来备货，平时大量资源闲置，高峰又担心不够。
云计算换了一种玩法——你不再买设备，而是租能力。AWS 帮你把服务器、存储、网络都准备好了，你要多少就用多少，双十一前扩容，活动结束缩回来，只为实际用到的资源付钱。
CapEx（资本支出）vs OpEx（运营支出） 买服务器是 CapEx——一次性大额投入，不管用没用都占了预算。 云计算是 OpEx——按月按量结算，就像订阅 Netflix，不看就退订。 考试里这两个词出现频率极高，见到就要反应出"传统 IT vs 云"的对比。
还有两个术语和这个场景直接相关：
- Elasticity（弹性）：流量大了自动扩，小了自动缩，不需要人工干预。双十一的故事就是弹性解决的。
- Agility（敏捷性）：以前采购一台服务器要等几周，现在在控制台点几下，几分钟内就能用。这不只是速度快，它改变了你"能不能快速试错"的能力。
传统 IT 云计算
┌──────────────────┐ ┌──────────────────┐
│ 🏢 自建数据中心 │ │ ☁️ AWS 云服务 │
│ │ │ │
│ 预先采购硬件 │ │ 按需获取资源 │
│ 固定容量 │ │ 弹性扩展 │
│ 自行维护 │ │ AWS 负责维护 │
│ 高前期投资 │ │ 按使用量付费 │
│ 采购需要数周 │ │ 分钟级部署 │
└──────────────────┘ └──────────────────┘
资本支出 (CapEx) 运营支出 (OpEx)
"买房子" "租房子"
🌟 云计算的六大优势
AWS 官方总结了六个上云的好处，这几乎是每次 CLF-C02 考试必出的内容。
但别去死记"第三条是什么、第五条是什么"——这样考试一紧张就乱了。更有效的办法是理解每条优势在解决什么痛点，遇到场景题自然就能对上号。
第一条：把资本支出转为可变支出。 就是刚才说的 CapEx → OpEx。公司不需要在项目启动时就砸几百万建机房，上云之后按实际用量付费，现金流更灵活，失败了损失也小。
第二条：规模经济。 AWS 同时服务全球几百万客户，采购服务器的量是普通公司的几万倍。供应商给 AWS 的价格远低于给你的价格。这个成本节省会传递给你，所以云的单位计算成本通常比你自建便宜。
第三条：无需猜测容量。 这是传统 IT 的老大难——买多了浪费，买少了撑不住。云上不存在这个问题，Auto Scaling 会根据实际流量自动调整资源。
第四条：速度和敏捷性。 以前想做一个实验性项目，光等服务器到货就一个月。云上几分钟内就能跑起来，试错成本极低，失败了直接关掉，不浪费任何硬件。
第五条：节省数据中心运营成本。 机房不只是放服务器的地方，还需要专业的空调、UPS 不间断电源、门禁系统、专职运维人员……这些成本加起来相当可观。上云之后这些都交给 AWS，你的团队可以专注做产品。
第六条：全球化部署。 AWS 在全球 30 多个地理区域都有数据中心。你的应用如果想覆盖澳大利亚、欧洲、北美的用户，以前可能需要在多个国家分别建机房，现在在控制台选一下区域就行了。
六大优势速记
| # | 优势 | 传统 IT 的痛点 | 关键词 |
|---|---|---|---|
| 1 | 资本转可变支出 | 项目启动要先砸大钱 | CapEx → OpEx |
| 2 | 规模经济效益 | 自己采购价格高 | 成本随规模降低 |
| 3 | 无需猜测容量 | 买多了浪费买少了不够 | 弹性伸缩 |
| 4 | 速度和敏捷性 | 采购周期长，试错成本高 | 分钟级部署 |
| 5 | 节省运营成本 | 机房运维耗人耗钱 | 专注业务 |
| 6 | 全球化部署 | 跨国扩展要建多套机房 | 低延迟，全球覆盖 |
⚠️ 考试读题提示：题干里出现"前期预算有限"、"需求波动大"、"想快速试错"——通常是在考六大优势里的某一条，不是在考某个具体服务。
🏗️ 三种云服务模型：到底管多少
IaaS、PaaS、SaaS 是这一章最高频的考点，几乎每次考试都会出 2-3 道题。
理解它们最简单的方式是用租房来类比：
想象你要做饭吃。你有三种选择：
- 在菜市场买食材，自己回家洗、切、炒（IaaS：材料都有，工序自己来）
- 叫一份半成品料理包，食材都备好了，你只需要按步骤烹饪（PaaS：底层都搞定，你只管写"应用代码"）
- 直接叫外卖（SaaS：什么都不管，软件拿来就用）
IaaS（Infrastructure as a Service，基础设施即服务）
AWS 给你一台"虚拟服务器"。硬件、虚拟化、机房——这些 AWS 都处理好了。但操作系统怎么配置、装什么软件、数据怎么保护，全是你的责任。
代表服务：EC2（虚拟机）、VPC（虚拟网络）、EBS（块存储）。
适合什么人？需要完全控制服务器环境的团队，比如把本地应用"原封不动"搬到云上。
PaaS（Platform as a Service，平台即服务）
AWS 把操作系统、运行时、中间件都管了，你只需要把代码和数据交上来。就像租了个精装修的工作台，开机就能干活。
代表服务：Elastic Beanstalk（上传代码就能部署）、Lambda（写函数就能运行）、RDS（托管数据库）。
适合什么人？开发团队想专注写业务逻辑，不想花时间在服务器运维上。
SaaS（Software as a Service，软件即服务）
直接用别人做好的软件。你不管服务器，不管更新，不管安全补丁，打开浏览器就能用。你负责的只有：把它用好，管好自己的账号和数据。
代表服务：Amazon WorkSpaces（云上桌面）、Amazon Chime（视频会议）。
你每天用的微信、Gmail、Figma，其实都是 SaaS。只是它们不是 AWS 的服务。
服务模型对比一览
管理层级 本地自建 IaaS PaaS SaaS
─────────────────────────────────────────────────
应用程序 你 你 你 供应商
数据 你 你 你 供应商
运行时/中间件 你 你 供应商 供应商
操作系统 你 你 供应商 供应商
虚拟化 你 供应商 供应商 供应商
服务器/存储/网络 你 供应商 供应商 供应商
控制权： ◀────────最高──────────────────────最低────▶
| 模型 | 你管的 | AWS 管的 | AWS 代表服务 | 类比 |
|---|---|---|---|---|
| IaaS | OS、应用、数据 | 硬件、虚拟化 | EC2, VPC, EBS | 毛坯房，自己装修 |
| PaaS | 应用代码、数据 | OS、运行时 | Lambda, Beanstalk, RDS | 精装房，拎包入住 |
| SaaS | 直接使用 | 全部 | WorkSpaces, Chime | 住酒店，全程服务 |
有一个点容易混淆：EC2 是 IaaS，但 Lambda 是 PaaS。因为 EC2 你还是需要管理操作系统；Lambda 你只写函数代码，AWS 把剩下的全包了。这道题几乎每次考试都出。
🌍 三种部署模型：在哪里跑
服务模型说的是"你管多少"，部署模型说的是"运行在哪里"。
公有云（Cloud）
100% 运行在 AWS 云端，没有本地基础设施。弹性最大，前期成本最低，新公司和新项目的首选。如果没有特殊约束，这通常是默认答案。
混合云（Hybrid）
一部分系统在 AWS，一部分在自己的本地数据中心，两者通过 VPN 或 Direct Connect 互通。
VPN（Virtual Private Network）：通过公网建立加密隧道，让本地和 AWS 像在同一个内网里。 Direct Connect：一条物理专线，直接连到 AWS，不走公网，速度更快更稳定，但成本更高。
哪些公司需要混合云？典型场景是金融机构——核心交易数据必须留在本地（法规要求），但报表分析、备份、开发测试可以放云上。混合云不是过渡方案，对很多大型企业来说是长期战略。
私有云（On-Premises）
所有东西都在自己的数据中心，用 VMware 或 OpenStack 这类虚拟化技术跑。你有完全控制权，但也没有任何云的弹性优势。成本最高，扩展最难。
CLF-C02 考试里，私有云常作为"错误答案"出现——题干描述的场景通常都能上公有云或混合云，选私有云往往是没想清楚业务需求。
部署模型对比
| 模型 | 优点 | 缺点 | 最典型场景 |
|---|---|---|---|
| 公有云 | 弹性最大、零硬件投入 | 数据不在自己手里 | 新应用、初创公司 |
| 混合云 | 灵活、逐步迁移 | 架构更复杂 | 有遗留系统或合规约束 |
| 私有云 | 完全掌控 | 没有云的弹性 | 极严格的数据主权要求 |
选择时的判断逻辑：
有没有数据必须留在本地（合规/法规）？
- 没有 → 公有云
- 有，但还需要云的弹性 → 混合云
- 有，完全不需要云 → 私有云
配图：公网服务 vs 私网服务
这张图说的是另一个层面的"公 vs 私"——不是部署模型，而是 AWS 服务的网络访问路径。同一个 AWS 账户里，有些服务默认暴露在公网（Public），有些只在 VPC 内部可达（Private）。
私网资源不会自动暴露，你得显式配置网络路径和安全策略才能让外部访问。这是考试里"最小权限"思想的体现：默认不通，需要就开。
🌐 AWS 全球基础设施
你在 AWS 控制台选 "Asia Pacific (Sydney) ap-southeast-2" 时，背后是什么？
AWS 把全球基础设施分成三层：
Region（区域） 是最大的地理单位，比如"悉尼"、"新加坡"、"美东"。每个 Region 是物理上独立的，有自己的电力、网络和法律管辖区。你的数据默认不会跑到别的 Region 去，这是数据主权合规的基础。
AZ（Availability Zone，可用区） 是 Region 内的子单位，每个 Region 通常有 2-6 个 AZ。每个 AZ 是一个或多个实际数据中心，它们之间有独立的电力和网络，但通过低延迟专线互连。AZ 的设计目的是：一个机房着火了，另一个不受影响。
Edge Location（边缘位置） 是全球 400+ 个内容分发节点，不是用来跑你的主要业务的，而是用来缓存内容、降低延迟的。CloudFront 用来做 CDN，Route 53 做 DNS 解析，都依赖这些节点。
Region（悉尼 ap-southeast-2）
┌──────────────────────────────────────────────┐
│ │
│ AZ-a AZ-b AZ-c │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │ 🏢🏢 │ │ 🏢🏢 │ │ 🏢🏢 │ │
│ └──────┘ └──────┘ └──────┘ │
│ │ │ │ │
│ └──────── 低延迟专线互连 ──────┘ │
│ │
│ 每个 AZ：独立电力 + 独立网络 + 物理隔离 │
└──────────────────────────────────────────────┘
Edge Location（全球 400+）
→ CloudFront CDN、Route 53、Global Accelerator
→ 离用户最近，不是部署主业务的地方
配图：全球网络视角
地图上橙点是 Region，粉点是 Edge Location。一眼就能看出 Edge 的数量远多于 Region——这正是它的用途：覆盖用户，而不是跑主业务。
很多同学看到"降低用户访问延迟"就直觉选"多 Region 部署"，但如果场景是静态内容或缓存友好的请求，正确答案往往是 CloudFront 边缘加速，成本低很多。
配图：Region 与 AZ 的关系
一个 Region 里的 AZ 共享低延迟专线，但彼此物理隔离。跨 AZ 部署你的应用，是最基础也最常用的高可用手段——不需要跨国容灾，也不需要复杂架构。
配图：服务的弹性等级
AWS 服务的高可用能力分三个等级：
- AZ Resilient：在一个 Region 内跨 AZ 容灾。最常见、成本最低，大多数业务够用。
- Region Resilient：跨 Region 架构，应对整个区域级故障。复杂度和成本都更高，适合关键业务。
- Globally Resilient：少数服务（如 IAM、Route 53）本身就是全球部署，没有单一 Region 限制。
考试里的原则：不要一步到位选最重的方案。"提高可用性"通常答 Multi-AZ；"全球容灾"才考虑 Multi-Region；"加速全球用户访问"考虑 Edge/CloudFront。
选哪个 Region？四个考虑因素
合规性 > 延迟 > 服务可用性 > 价格——这个优先级在考试里是固定答案。
- 合规/数据主权：某些行业或国家要求数据不能离境，这是硬约束，其他因素都得让路。
- 用户延迟：选离用户最近的 Region，减少网络传输时间。
- 服务可用性：不是所有 AWS 服务在所有 Region 都有，新服务通常先在 us-east-1 发布。
- 价格：同样的服务，不同 Region 定价不同，美国区域通常最便宜。
高频混淆点
| 容易搞混的 | 正确区分 |
|---|---|
| Region vs AZ | Region 是大地理范围；AZ 是区域内的独立机房集群 |
| Multi-AZ vs Multi-Region | Multi-AZ 解决高可用；Multi-Region 解决跨区域容灾 |
| Edge Location vs Region | Edge 用于缓存加速，不是部署主业务的地方 |
| AZ 的数量 | 每个 Region 至少 2 个 AZ（通常 3 个），考试里不要说"一个 AZ = 一个 Region" |
💰 云经济学：上云真的省钱吗？
这个问题没有统一答案，但有一个思考框架：TCO（Total Cost of Ownership，总拥有成本）。
很多团队做"上云 vs 自建"的比较时，只算了服务器的钱，然后发现"云好贵"。但这个计算漏掉了大量隐性成本：
- 机房：租金、电费、冷却、物理安保
- 人力：系统管理员、网络工程师、安全团队的工资
- 软件授权：操作系统、数据库、监控工具
- 扩容风险：买多了闲置，买少了撑不住
- 机会成本：工程师花在运维上的时间，本可以做产品
把这些都算进去，再和云的费用对比，才是公平的 TCO 分析。
AWS 官方提供 AWS Pricing Calculator 来帮助你做这个对比——输入你的本地基础设施规模，它会估算出迁云后的成本。考试有时会直接问"哪个工具帮你估算迁云成本"，答案就是这个。
| 维度 | 自建 IT | AWS 云 |
|---|---|---|
| 付款节奏 | 前期大额 CapEx | 按月按量 OpEx |
| 容量规划 | 预估 3-5 年，容易买多 | 按需弹性，不浪费 |
| 采购规模 | 你自己的量 | AWS 全球亿级规模，成本更低 |
| 硬件维护 | 你负责 | AWS 承担 |
⚠️ 需要说明的是：云计算不是"一定便宜"，而是"结构不同"。前期没有资本支出，但如果你的资源一直满负荷运行、没有弹性需求，自建有时反而更便宜。云的优势在于弹性和不需要为可能性买单，而不是无条件的低价。考试里不要选"云总是比本地便宜"这种绝对选项。
📐 Well-Architected Framework：怎么算一套好架构？
你搭好了一个 AWS 系统，怎么判断它设计得好不好？AWS 用六个维度来衡量，叫 Well-Architected Framework。
把它想象成一份"云架构体检表"——体检完了，你能知道哪根"柱子"不够扎实。
图解说明：
- 这是 AWS Well-Architected Tool 的图标，用于在控制台里对架构做系统化评估
- 考试遇到"系统化评估架构是否符合最佳实践"，答案指向 Well-Architected Tool
- 第 7 章《架构设计原则》会深入讲解每个支柱的具体服务和考试场景
| 支柱 | 核心关注 | 一句话记忆 |
|---|---|---|
| Operational Excellence（卓越运营） | 系统运行顺畅，故障能快速恢复和改进 | "跑得好，改得快" |
| Security（安全性） | 数据保护、权限控制、加密 | "最小权限，默认拒绝" |
| Reliability（可靠性） | 故障时自动恢复，跨 AZ 高可用 | "出了问题能自愈" |
| Performance Efficiency（性能效率） | 用对服务，不浪费算力 | "选对工具，不大材小用" |
| Cost Optimization（成本优化） | 按需付费，消除闲置 | "用多少付多少，不烧冤枉钱" |
| Sustainability（可持续性） | 减少碳排放，绿色计算 | "环保也是架构考量" |
本章只需记住六个支柱的名字和大概方向。第 7 章会深入讲每个支柱的设计原则。
考试怎么考：给你一个架构决策，让你判断对应哪个支柱。抓住关键词：
- 跨 AZ / 故障恢复 → Reliability
- 最小权限 / 加密 → Security
- 降低成本 / 消除闲置 → Cost Optimization
- 提升响应速度 / 换合适实例类型 → Performance Efficiency
- 自动化运维 / 快速发现问题 → Operational Excellence
🗺️ AWS CAF：上云从哪开始？
技术方案有了，但公司上云还会卡在另一个地方——组织层面的混乱：技术团队说能做，HR 不知道要培训谁，CFO 不知道预算怎么算，合规团队不知道谁负责审批……
这就是 AWS CAF（Cloud Adoption Framework，云采用框架） 想解决的问题。它不是技术工具，而是帮企业把上云的工作按角色分清楚的一套方法论。
你可以把它比作公司搬新办公室：不是只有 IT 部门的事，行政要找装修队，HR 要通知员工怎么通勤，财务要审批预算，安保要重新规划门禁——每个部门都有自己的任务。
AWS CAF 把这些任务分成六个"视角（Perspective）"：
AWS CAF 六大视角
├─ Business（业务） → 高管/CFO：上云能带来多少业务价值？ROI 如何？
├─ People（人才） → HR/培训：员工需要学什么？组织架构要怎么调？
├─ Governance（治理） → CIO/风控：合规怎么保证？预算怎么管控？
├─ Platform（平台） → CTO/架构师：技术架构和迁移路线怎么定？
├─ Security（安全） → CISO：数据保护、访问控制怎么设计？
└─ Operations（运营） → 运维团队：上线后的日常监控和运维怎么做？
| 视角 | 负责角色 | 核心问题 |
|---|---|---|
| Business | CFO/高管 | 上云值不值？业务价值和 ROI |
| People | HR/培训 | 员工准备好了吗？技能和文化转型 |
| Governance | CIO/风控 | 风险和合规怎么管？预算如何控制？ |
| Platform | CTO/架构师 | 技术平台和迁移路线 |
| Security | 安全团队 | 数据和系统安全怎么保障 |
| Operations | 运维团队 | 日常运维、监控和支持 |
考试里，CAF 题目几乎都是"场景判断"——看题干里的角色是谁，对应哪个 Perspective：
- 公司 CTO 规划技术迁移路线 → Platform
- HR 安排员工云技能培训 → People
- CFO 评估上云的业务回报 → Business
- CIO 建立合规审批和预算管控机制 → Governance
🚀 迁移策略：7 R's 速记
当企业决定把现有系统迁移到云上，不同的应用适合不同的迁移方式。AWS 总结了七种主要迁移策略，简称"7 R's"。CLF-C02 会考你识别不同场景对应哪种策略。
图解说明：
- 这张图把七种迁移策略按"迁移改动量"从低到高排列，横轴代表对原有应用的修改程度
- 从底部 Retire（直接关闭）到顶部 Refactor（彻底重构），越往上投入越大，但同时获益也越多
- 大多数企业迁移项目是 Rehost 打头，逐步推进到 Replatform 和 Refactor
- 考试常考"哪种策略改动最小"（Rehost）和"哪种策略充分利用云原生能力"（Refactor）
| 策略 | 中文名 | 改动程度 | 核心特征 | 一句话记忆 |
|---|---|---|---|---|
| Rehost | 重新托管 | 最小 | 原样搬到 EC2，不改代码 | "搬家不换家具" |
| Replatform | 重新平台化 | 小改 | 换托管组件（如自建 MySQL → RDS），应用基本不动 | "搬家顺便换了几件家具" |
| Refactor | 重新架构 | 最大 | 用云原生服务重写，如单体→微服务 + Lambda | "重新装修" |
| Repurchase | 重新购买 | — | 放弃自建，改用 SaaS（如自建 CRM → Salesforce） | "换个现成的" |
| Retire | 退役 | — | 评估后发现没人用，直接关掉 | "断舍离" |
| Retain | 保留 | — | 暂时不迁，留在本地，之后再说 | "先不动" |
| Relocate | 重新定位 | 最小 | 把 VMware 工作负载直接搬到 VMware Cloud on AWS | "连同基座一起搬" |
⚠️ 考试视角：
- "应用要快速迁云，不改代码" → Rehost（Lift & Shift）
- "想充分利用云原生能力，接受大改" → Refactor
- "发现某些系统已经没人用了" → Retire
- "用现成 SaaS 代替自建系统" → Repurchase
⚠️ 常见误区
这几个错误在考试里出现频率很高，但都有点"反直觉"，值得单独列出来：
| 常见错误理解 | 正确认知 |
|---|---|
| 云计算 = 没有服务器 | 服务器还在，只是由 AWS 管理，你看不见而已 |
| Lambda = IaaS | Lambda 是 PaaS——你只写代码，不管任何基础设施 |
| 可用区 = 区域 | 一个区域（Region）里有 2-6 个可用区（AZ），概念层级不一样 |
| 边缘位置可以跑 EC2 | Edge Location 是 CDN 缓存节点，不是通用计算区域 |
| 私有云 = 混合云 | 私有云是纯本地，没有任何云资源；混合云是云 + 本地连通 |
| 云总是比本地便宜 | 云更灵活，但"是否更便宜"取决于使用模式，不是绝对的 |
| 高可用 = Multi-Region | 高可用通常只需要 Multi-AZ；Multi-Region 是更高级别的容灾 |
📝 考试场景题
场景 1：创业公司选云
一家刚成立的初创公司正在开发移动 App，团队五人，没有任何 IT 基础设施经验，希望尽快上线第一个版本。
分析：没有遗留系统、没有合规约束、需要快速上线——这是典型的公有云场景。没有理由选混合云或私有云，那两个都会增加复杂度和成本。
答案：公有云（Cloud）
场景 2：银行的合规约束
一家银行计划将部分业务迁移到 AWS，但监管机构要求客户核心交易数据必须存储在本地数据中心。
分析：关键词是"部分迁移"+"核心数据留本地"。这是混合云的典型用例——敏感数据本地存，其他业务上云。
答案：混合云（Hybrid），通过 VPN 或 Direct Connect 连接本地和 AWS。
场景 3：开发团队选服务模型
开发团队想快速部署 Web 应用，不想管理服务器和操作系统，只关注应用代码本身。
分析：不管服务器、不管 OS，只关注代码 = PaaS。如果还要管 OS，才需要 IaaS。
答案：PaaS，使用 Elastic Beanstalk 或 Lambda。
场景 4：评估迁云成本
公司 CFO 要求在决定迁移之前，提供一份详细的本地 IT 与 AWS 云的成本对比报告，包含硬件、人力、机房运营在内的所有费用。
分析：这是 TCO 分析，AWS 专门有工具支持这类评估。
答案：使用 AWS Pricing Calculator 进行 TCO 对比分析。
场景 5：架构支柱判断
电商公司为了应对双十一流量激增，在架构中加入了 Auto Scaling 和跨 AZ 负载均衡，确保即使某个 AZ 出故障，服务仍可正常运行。
答案：Reliability（可靠性） — 核心是"系统在异常情况下能继续运行和恢复"。
场景 6：AWS CAF 视角匹配
大型制造企业启动上云项目。公司 CIO 需要确保迁移过程满足行业法规要求，并建立云资源的预算审批机制。
答案：Governance Perspective（治理视角） — 合规管控 + 预算管理 = 治理层面的工作。
场景 7：迁移策略选择
某公司有 200 个应用需要迁移到 AWS。由于时间紧、预算有限，初步计划是快速把所有应用搬上去，不修改代码，之后再逐步优化。
分析：快速迁移、不改代码 = 最小改动量的迁移策略。
答案：Rehost（Lift & Shift） — 把应用原封不动搬到 EC2，速度最快，风险最低。
场景 8：迁移策略 — 放弃自建
某公司自建了一套 HR 管理系统，但维护成本很高，而且系统功能已经落后。调研后发现市面上的 SaaS HR 软件完全能满足需求。
分析：放弃自建，换成现成软件 = 不迁移，直接替换。
答案：Repurchase — 停用自建系统，转向 SaaS 产品。
场景 9：弹性 vs 可扩展性
双十一当天流量是平时的 50 倍，活动结束后流量恢复正常。系统需要在高峰时自动扩容，高峰过后自动缩容，不产生闲置成本。
分析：自动扩容 + 自动缩容 + 避免闲置 = 弹性（Elasticity），不只是可扩展（Scalability）。
答案：这是**弹性（Elasticity）**的典型场景，使用 Auto Scaling 实现。可扩展性只说"能变大"，弹性同时强调"能自动变小"。
场景 10：Well-Architected 可持续性支柱
某公司为了降低碳排放，决定把工作负载从普通 x86 服务器迁移到 AWS Graviton 处理器实例，同时关闭了一批低利用率的 EC2 实例。
答案：Sustainability（可持续性） — 提高资源利用率、使用节能处理器 = 可持续性支柱的核心实践。
✏️ 练习题
题目 1
以下哪项最准确地描述了云计算的核心特征？
- A. 将服务器部署在本地数据中心
- B. 通过互联网按需获取 IT 资源，按使用量付费
- C. 购买专用硬件并长期使用
- D. 只能由大型企业使用
答案：B
云计算的两个核心特征：按需获取（不需要预先购买）和按使用量付费（用多少算多少）。A 和 C 描述的是传统 IT，D 是错误认知。
</details>题目 2
AWS Lambda 属于哪种云服务模型？
- A. IaaS
- B. PaaS
- C. SaaS
- D. 以上都不是
答案：B
Lambda 是无服务器函数计算，你只写代码，AWS 管理所有底层基础设施（包括 OS、运行时、扩展）。这是 PaaS 的定义。EC2 才是 IaaS，因为你还要管 OS。
</details>题目 3
一家公司需要将应用迁到 AWS，但法规要求部分数据必须保留在本地。应使用什么部署模型？
- A. 公有云
- B. 私有云
- C. 混合云
- D. 社区云
答案：C
混合云 = 云 + 本地同时存在，用 VPN 或 Direct Connect 连通。"部分在云、部分必须在本地"是混合云的经典定义场景。
</details>题目 4
以下哪项最准确地描述 AWS 区域（Region）？
- A. 单个数据中心
- B. 包含多个可用区的地理位置
- C. CloudFront 内容分发节点
- D. 专门用于灾难恢复的备份站点
答案：B
Region 是地理上独立的区域，包含 2-6 个 AZ（可用区）。单个数据中心是 AZ 的组成部分，CloudFront 节点是 Edge Location，和 Region 是两个不同概念。
</details>题目 5
云计算的"规模经济效益"优势对客户意味着什么？
- A. 客户的公司规模变大
- B. AWS 大规模运营带来的成本节省，最终以更低价格传递给客户
- C. 客户必须采购更多服务器
- D. 客户需要签订长期合同才能享受低价
答案：B
规模经济的逻辑：AWS 服务数百万客户 → 超大规模采购硬件和能源 → 单位成本极低 → 这个成本优势传递给客户。客户不需要自己变大，也不需要长期合同。
</details>题目 6
公司希望比较自建数据中心和迁移到 AWS 的全部成本（包括硬件、人力和机房运营）。应使用哪个工具？
- A. AWS Cost Explorer
- B. AWS Pricing Calculator
- C. AWS Budgets
- D. AWS CloudTrail
答案：B
AWS Pricing Calculator 专门用于迁云前的成本估算，可输入本地基础设施参数与 AWS 成本对比，帮助 TCO 分析。Cost Explorer 分析已有账单，Budgets 设置告警，CloudTrail 是操作审计日志。
</details>题目 7
根据 AWS Well-Architected Framework，将应用部署在多个可用区并配置自动故障转移，主要体现哪个支柱？
- A. Security（安全性）
- B. Cost Optimization（成本优化）
- C. Reliability（可靠性）
- D. Operational Excellence（卓越运营）
答案：C
多 AZ 部署 + 自动故障转移 = 提高系统在故障时的自愈能力，这是 Reliability（可靠性）支柱的核心实践。Security 关注权限和加密，Cost Optimization 关注消除闲置，Operational Excellence 关注运维流程改进。
</details>题目 8
AWS CAF 中，HR 部门负责规划员工云技能培训和组织变革，对应哪个视角？
- A. Business Perspective
- B. People Perspective
- C. Governance Perspective
- D. Operations Perspective
答案：B
People Perspective 关注人员技能、组织文化和变革管理，直接对应 HR 的职责范围。Business 关注 ROI，Governance 关注合规和预算管控，Operations 关注日常运维。
</details>题目 9
以下哪种迁移策略对原有应用的改动最小，速度最快？
- A. Refactor（重新架构）
- B. Replatform（重新平台化）
- C. Rehost（重新托管）
- D. Repurchase（重新购买）
答案：C
Rehost（也叫 Lift & Shift）是把应用原封不动地从本地服务器搬到 AWS EC2，不改代码、不改架构，改动量最小，速度最快。Refactor 是改动最大的策略（从架构层面重构），Replatform 有小改动（如换托管数据库），Repurchase 是放弃自建换 SaaS。
</details>题目 10
弹性（Elasticity）与可扩展性（Scalability）的主要区别是什么？
- A. 可扩展性是 AWS 专有功能，弹性适用于所有云服务商
- B. 弹性同时支持自动扩容和自动缩容，可扩展性只关注扩容能力
- C. 可扩展性只能纵向扩展（Scale Up），弹性只能横向扩展（Scale Out）
- D. 两者含义完全相同，只是叫法不同
答案：B
可扩展性（Scalability）强调系统能应对更大的负载，但不一定能自动缩小。弹性（Elasticity）在可扩展性基础上加了"自动缩容"的能力——需求减少时自动归还资源，避免闲置成本。云架构里用 Auto Scaling 实现弹性，高峰自动扩、低谷自动缩。
</details>题目 11
一家公司有一套自建的电子邮件系统，维护成本很高。他们决定直接改用 Gmail（Google Workspace）。这对应 7 R's 迁移策略里的哪种？
- A. Rehost
- B. Replatform
- C. Retain
- D. Repurchase
答案：D
Repurchase 是放弃自建系统，转而购买或订阅现成的 SaaS 产品。用 Gmail 代替自建邮件系统是典型的 Repurchase 场景。Rehost 是把系统搬到 EC2，Replatform 是小改后上云，Retain 是暂时保留本地不迁移。
</details>题目 12
AWS 的规模经济（Economies of Scale）给客户带来的最直接好处是什么？
- A. 客户可以使用更多 AWS 功能
- B. AWS 大规模采购降低了基础设施成本，这些节省会转化成更低的服务定价
- C. 所有 AWS 服务对客户免费
- D. 客户可以直接访问 AWS 数据中心
答案：B
规模经济的核心逻辑：AWS 为全球数百万客户服务，采购量极大，在硬件供应商面前话语权极强，采购价格更低。这个成本优势会反映在 AWS 的服务定价上，让客户受益。AWS 也因此能持续降价——自 2006 年成立以来已多次主动降价。
</details>题目 13
某公司正在评估一个应用的迁移策略。该应用使用自建的 MySQL 数据库，团队决定在迁移时把数据库换成 Amazon RDS，但其他应用代码基本不改。这属于哪种迁移策略？
- A. Rehost
- B. Replatform
- C. Refactor
- D. Retire
答案：B
Replatform（也叫 Lift, Tinker and Shift）的特点是：迁移时做少量优化，通常是换掉某个底层组件（如自建数据库→托管 RDS），但不重写应用架构。不同于 Rehost（完全不改）和 Refactor（大改架构）。
</details>题目 14
以下哪项最准确地描述了 AWS 全球基础设施中 Region（区域）和 AZ（可用区）的关系？
- A. 一个 AZ 包含多个 Region
- B. Region 和 AZ 是同一个概念的不同叫法
- C. 一个 Region 包含多个 AZ，每个 AZ 是独立的数据中心设施
- D. AZ 是比 Edge Location 更小的地理单元
答案：C
AWS 基础设施层级：Region（地理区域）> AZ（可用区）> Edge Location（非计算，仅 CDN）。一个 Region 通常包含 2-6 个 AZ，每个 AZ 是独立的物理设施（独立电源、冷却、网络），通过低延迟高带宽网络互连。跨 AZ 部署是实现高可用的基础。
</details>题目 15
以下哪项是 CapEx 和 OpEx 的主要区别？
- A. CapEx 用于软件，OpEx 用于硬件
- B. CapEx 是一次性大额资本投入（如购买服务器），OpEx 是日常运营费用（如按月付费的云服务）
- C. CapEx 比 OpEx 更贵
- D. OpEx 只适用于大型企业
答案：B
CapEx（资本支出）：购买资产的一次性大额投入，如买服务器、建机房，前期金额大，资产逐年折旧。OpEx（运营支出）：日常运营产生的持续性费用，如云服务订阅、按量付费，前期几乎为零，随用随付。云计算把 IT 支出从 CapEx 转成了 OpEx，让公司不需要大额前期投入就能启动项目。
</details>📚 本章小结
本章的内容是 AWS CLF-C02 所有其他章节的基础。把下面这些关系记清楚，后面的题目会顺很多：
| 核心概念 | 记忆要点 |
|---|---|
| 云计算 | 按需获取 + 按量付费，CapEx → OpEx |
| 六大优势 | 省前期投入、规模经济、弹性容量、快速部署、减运维、全球覆盖 |
| IaaS | 给你服务器，OS 和应用你管（EC2） |
| PaaS | 给你平台，你只管代码（Lambda, Beanstalk） |
| SaaS | 给你软件，直接用（WorkSpaces） |
| 公有云 | 全在 AWS，无本地约束 |
| 混合云 | 云 + 本地，VPN 或 Direct Connect 互通 |
| 私有云 | 纯本地，有控制权但无云优势 |
| Region | 地理独立区域，含 2-6 个 AZ |
| AZ | 区域内独立数据中心集群，高可用靠跨 AZ |
| Edge Location | CDN 缓存节点，不是主业务区域 |
| TCO | 总拥有成本，用 AWS Pricing Calculator 对比 |
| Well-Architected | 六支柱：运营/安全/可靠/性能/成本/可持续 |
| AWS CAF | 六视角按角色分工，题干看角色选 Perspective |
| 7 R's 迁移 | 7 种策略：Rehost(不改)/Replatform(小改)/Refactor(大改)/Repurchase(换SaaS)/Retire(关闭)/Retain(留本地)/Relocate(VMware搬迁) |
考前 30 秒复盘
- 服务模型：管 OS → IaaS；只管代码 → PaaS；直接用 → SaaS
- 部署模型：有本地约束 → Hybrid；完全无约束 → Public
- 基础设施：高可用 → Multi-AZ；全球容灾 → Multi-Region；加速内容分发 → Edge/CloudFront
- 选 Region 优先级：合规 > 延迟 > 服务可用 > 价格
- Well-Architected 支柱：抓题干关键词，故障恢复→Reliability，权限加密→Security，省钱→Cost Optimization
- AWS CAF：题干角色是谁 → 对应哪个 Perspective
- 7 R's：快速迁移不改→Rehost；换托管组件→Replatform；云原生重写→Refactor；换SaaS→Repurchase；关掉→Retire