跳到主要内容

C2-01-云计算核心概念与全球基础设施

1-本章目标​

这一章解决两个最基础的问题：

第一，为什么需要云计算？

以及：

第二，AWS 的“云”在现实世界里到底放在哪里？

后续要学习的 EC2、S3、RDS、VPC、CloudFront、Route 53、Lambda 等服务，都建立在这一层基础设施之上。本章将依次建立下面这套知识结构：

传统数据中心
     │
     ▼
Cloud Computing
云计算
     │
     ├── Pay-as-you-go
     ├── Agility
     ├── Scalability
     ├── Elasticity
     ├── High Availability
     └── Economies of Scale
     │
     ▼
AWS Global Infrastructure
AWS 全球基础设施
     │
     ├── Region
     │     └── Availability Zone
     │
     ├── Edge Location
     ├── Local Zone
     ├── Outposts
     └── Wavelength（题库补充）
     │
     ▼
架构方式
     │
     ├── Single-AZ
     ├── Multi-AZ
     └── Multi-Region
     │
     ▼
Reliability / Resilience
可靠性 / 韧性
     │
     ├── High Availability
     ├── Fault Tolerance
     ├── Disaster Recovery
     ├── RTO
     └── RPO

这些不是零散的英语名词。它们其实都在回答一个问题：

GlobalShop 怎样才能以合理的成本，让全球用户稳定地访问一个不会轻易挂掉、又能够随流量变化扩展的电商平台？

2-★★★★★-Cloud-Computing：什么是云计算？​

Cloud Computing； 中文：云计算；如果只把它理解成：

“把服务器放到互联网上。”

是不够准确的。更好的理解方式是：

把计算、存储、数据库、网络、安全等 IT 能力，从“企业提前购买并自己维护的硬件”，变成可以通过网络按需获取、快速调整、按照实际使用情况付费的服务。

2.1-从-GlobalShop-的传统机房开始​

假设 GlobalShop 还没有使用 AWS。GlobalShop 有：用户系统、商品系统、订单系统、库存系统、支付系统、物流系统、搜索系统、推荐系统、数据分析系统；这些程序必须运行在真实机器上。所以需要：

GlobalShop Data Center
企业数据中心

├── Web Server
├── Application Server
├── Database Server
├── Cache Server
├── File Server
│
├── Router
├── Switch
├── Firewall
├── Load Balancer
│
├── Storage
├── Backup
│
├── UPS
├── Cooling
├── Physical Security
└── Network Lines

这就是传统：On-Premises；简称有时写：On-Prem； 中文：本地部署 / 本地数据中心部署；这里的“本地”不是指：

放在程序员自己的电脑。

而是：

基础设施运行在企业自己控制的数据中心、服务器机房或公司场所，而不是公有云厂商的数据中心中。

2.2-传统基础设施最大的难题：你必须先猜未来​

假设 GlobalShop 平时需要：100 台 Application Server但是“双十一”20:00：需要 2000 台；那么公司应该买多少？

2.2.1-方案-A：买-100-台​

平时：

需求：
██████████

服务器：
██████████

刚好。但双十一：

实际需求：
████████████████████████████████████████████

服务器：
██████████

结果：
Overload
过载

用户可能看到：

504 Gateway Timeout

Service Unavailable

页面打不开

付款失败

2.2.2-方案-B：直接买-2000-台​

双十一安全了。问题是平时：

实际使用：
██

已购买：
████████████████████████████████████████

大量服务器一年绝大多数时间闲置。但：硬件成本、机房成本、电力、网络、维护、折旧；仍然存在。

2.3-★★★★-Capacity-Planning：容量规划​

Capacity；容量。Planning；规划。Capacity Planning； 中文：容量规划；也就是：

根据未来业务量预测，需要提前准备多少计算、存储、网络等资源。

传统 IT 环境必须认真做这件事情。因为从：“发现不够用了”；到：“真正增加100台服务器”；中间可能经历：

需求申请
↓
预算审批
↓
采购
↓
供应商发货
↓
机房上架
↓
网络连接
↓
安装OS
↓
系统配置
↓
应用部署

可能不是几分钟，而是几周甚至几个月。

2.4-★★★★★-云计算的关键变化：On-Demand-Resource​

On-Demand； 中文：按需；核心思想：

需要资源的时候再创建。

例如 GlobalShop：

平时：
100台

双十一：
需求增加
↓
500台
↓
1000台
↓
2000台

双十一结束：
↓
500台
↓
100台

这背后就涉及后面两个非常重要的概念：

Scalability
可扩展性

Elasticity
弹性

但二者不是同一个东西。后面详细区分。

2.5-★★★★★-Fixed-Expense-→-Variable-Expense​

传统基础设施经常存在：Fixed Expense； 中文：固定支出；例如提前购买：服务器、存储、机柜、交换机、数据中心设施；无论最终使用率是多少，投入已经产生。云计算的重要价值之一，是让相当一部分 IT 成本转为：Variable Expense； 中文：可变支出；也就是：

用得多
→ 支出增加

用得少
→ 支出减少

2.6-★★★★-CAPEX-与-OPEX​

在商业和财务题中还会出现两个词。

2.6.1-CAPEX​

完整英文：Capital Expenditure； 中文：资本性支出；例如：一次购买1000台服务器；属于典型资本投入。

2.6.2-OPEX​

完整英文：Operating Expenditure； 中文：运营性支出 / 经营性支出；例如：

这个月用了多少云资源
↓
这个月支付相应费用

更接近运营成本模型。简单理解：

传统自建数据中心
更偏向：
CAPEX

Cloud
可以将大量支出转化为：
OPEX / Variable Expense

但不要绝对化。现实企业财务会复杂得多。CLF-C02 主要考概念。

2.7-★★★★★-Pay-as-you-go​

Pay as you go； 中文：按使用量付费 / 随用随付；这是 AWS 最核心的经济思想之一。但不要理解成：

AWS 所有东西都是一秒多少钱。

不同服务有不同计量方式：

EC2
→ 计算使用时间等

S3
→ 存储容量、请求、数据传输等

Lambda
→ 请求数、计算时间等

CloudFront
→ 请求、数据传输等

真正的共同思想是：

不必为了未来可能出现的需求，提前永久拥有所有容量。

2.8-★★★★-Economies-of-Scale：规模经济​

完整英文：Economies of Scale； 中文：规模经济；它是什么意思？假设 GlobalShop 自己建数据中心：

购买服务器：
500 台

采购带宽：
企业自己的规模

采购硬盘：
企业自己的规模

AWS 面向全球大量客户：

AWS
├── 大量服务器
├── 大量数据中心
├── 大量网络资源
├── 大规模电力采购
└── 大规模基础设施运营

因为采购、建设、运营规模远大于一般企业：

规模增加
↓
单位成本可能降低

AWS 可以利用这种规模经济向客户提供云资源。题库中也反复把：Benefit from massive economies of scale；作为 Cloud 的典型优势。

2.9-★★★★-Agility：敏捷性​

Agility； 中文：敏捷性；这里不是专指：Agile Software Development，敏捷软件开发。；云计算里的 Agility 更强调：

获得 IT 能力和尝试新业务的速度。

2.9.1-GlobalShop-例子​

产品经理提出：

做一个 AI 商品推荐实验。

传统数据中心：

需要GPU资源
↓
预算审批
↓
采购
↓
安装
↓
配置
↓
几周后开始实验

AWS：

申请适合的Cloud Resource
↓
快速创建
↓
当天开始实验

如果项目失败：关闭资源；如果项目成功：继续扩大；所以：

获取资源更快
↓
实验成本降低
↓
新业务上线速度提高
↓
Agility提高

题库评论也直接使用：

从 weeks 到 minutes，提高组织的 agility。

2.10-★★★★★-Scalability：可扩展性​

Scalability； 中文：可扩展性；核心问题：

当业务规模越来越大时，系统能不能增加能力继续处理？

比如：

今天：
每秒1000个请求

明年：
每秒10000个请求

如果系统可以通过增加资源支撑：

1000
↓
10000
↓
100000

说明系统具有良好的：Scalability

2.11-★★★-Vertical-Scaling：纵向扩展​

Vertical Scaling； 中文：纵向扩展 / 垂直扩展；也叫：Scale Up；意思：

不增加机器数量，而是把原来的机器变强。

例如：

原服务器：

2 vCPU
8 GB RAM

↓

更强服务器：

32 vCPU
128 GB RAM

图：

Small Server

    │
    │ Scale Up
    ▼

Large Server

2.12-★★★★-Horizontal-Scaling：横向扩展​

Horizontal Scaling； 中文：横向扩展 / 水平扩展；也叫：Scale Out；意思：

不只是把一台机器变强，而是增加机器数量。

原来：EC2；变成：EC2、EC2、EC2、EC2、EC2；GlobalShop Web 系统通常非常适合：

         Load Balancer
              │
       ┌──────┼──────┐
       ▼      ▼      ▼
      EC2    EC2    EC2

流量继续增加：

         Load Balancer
              │
   ┌────┬─────┼─────┬────┐
   ▼    ▼     ▼     ▼    ▼
  EC2  EC2   EC2   EC2  EC2

2.13-★★★★★-Elasticity：弹性​

Elasticity； 中文：弹性；这是 CLF-C02 极其重要的概念。它比 Scalability 多了一层意思：

资源能够根据需求变化扩大，也能够在需求减少时缩回来。

2.13.1-GlobalShop-双十一​

11月10日 10:00

EC2：
20台

流量增加：

11月11日 19:00

EC2：
80台

20:00 秒杀：EC2：、300台；凌晨：

02:00

EC2：
50台

第二天：EC2：、20台；这就是：

Scale Out
扩大

+

Scale In
缩小

=

Elasticity
弹性

2.14-★★★★★-Scalability-与-Elasticity-的区别​

这是必须真正理解的地方。

2.14.1-Scalability​

回答：

系统能不能处理越来越大的规模？

2.14.2-Elasticity​

回答：

系统能不能随着当前需求动态地增加和减少资源？

2.14.3-举例​

一家公司从：1000用户长期发展到：100万用户于是服务器从：

5台
→ 100台

这是：Scalability

另一家公司每天：

上午：
20台

晚上高峰：
100台

凌晨：
10台

每天自动变化。这是：Elasticity

可以记成：

Scalability
关注：
“大了以后能不能撑住？”

Elasticity
关注：
“需求变了以后能不能跟着变化？”

题库第 40 题就是非常直接的 Elasticity 题：题库把“随着需求变化进行 rightsize”以及“需要时容易获得资源”作为 Elasticity 的表现，而不是 EC2 重启速度或者 RAM 上限。

2.15-★★★★★-High-Availability：高可用性​

简称：HA；完整英文：High Availability； 中文：高可用性；它关注的问题不是：

流量增加怎么办？

而是：

某些组件坏掉以后，业务还能不能继续？

2.16-★★★★-Single-Point-of-Failure：单点故障​

完整英文：Single Point of Failure；常缩写：SPOF； 中文：单点故障；例如：

         Users
           │
           ▼
          EC2

如果唯一的 EC2：

EC2
 X

整个系统：

Users
  │
  X
Service unavailable

这台 EC2 就是：Single Point of Failure

2.17-用冗余提高-Availability​

Redundancy； 中文：冗余；意思是：

不只准备一个组件，而是准备额外组件，避免一个坏掉整个系统就停止。

例如：

         Load Balancer
              │
       ┌──────┴──────┐
       ▼             ▼
      EC2           EC2

坏掉一个：

EC2-A
  X

EC2-B
继续服务

2.18-★★★★★-High-Availability-与-Scalability-不一样​

题库特别喜欢把：Agility、Elasticity、Scalability、High Availability；放到一起。它们分别回答：

概念核心问题
Agility能不能快速获得资源、快速变化业务
Scalability能不能承受更大的规模
Elasticity能不能随实际需求增减资源
High Availability出现故障以后还能不能尽量继续服务

题库第 77 题就是：

架构能够在发生故障时以最少 downtime 继续运行。

这里对应的是：High Availability；而不是 Elasticity 或 Scalability。题库相关解释也明确指出：Elasticity 主要处理资源随需求变化；Scalability 处理更大的负载；而 High Availability 关注故障情况下减少停机。

2.19-★★★★-Fault-Tolerance：容错能力​

Fault；故障。Tolerance；容忍。Fault Tolerance； 中文：容错 / 故障容忍能力；其目标是：

一个组件出现故障时，系统仍然能够继续完成其功能。

High Availability 和 Fault Tolerance 很接近。可以先这样理解：

High Availability
重点：
尽可能让服务持续可用、减少Downtime

Fault Tolerance
重点：
系统能容忍部分组件失败而继续工作

2.20-★★★-Downtime​

Downtime； 中文：停机时间 / 服务不可用时间；例如：20:00 系统故障、20:05 恢复Downtime：5 minutes

2.21-★★★★-Reliability：可靠性​

Reliability； 中文：可靠性；这个概念比：Availability；范围更大。可以粗略理解为：

系统能够在一段时间内持续、正确地执行预期功能，并能在发生故障时进行恢复。

AWS Well-Architected Framework 中专门有：Reliability Pillar；即：可靠性支柱。(AWS Documentation)后面的 C2-16 会详细介绍。

2.22-★★★★-Resilience/Resiliency：韧性​

Resilience；或：Resiliency；中文常译：韧性 / 弹性恢复能力 / 抗故障恢复能力；注意：这里不要和：Elasticity，资源弹性；混淆。Resilience 更关心：

系统面对故障、灾害或者异常以后，能否抵抗影响并恢复。

例如：

Hardware Failure
硬件故障

AZ Failure
可用区故障

Region Failure
区域级故障

Network Failure
网络故障

Human Error
人为错误

都属于 Resilience 设计需要考虑的事件。

2.23-★★★-Durability：数据持久性​

Durability； 中文：持久性 / 数据耐久性；主要关注：

数据会不会丢？

不要和 Availability 混淆。例如一个存储服务可能：数据没有丢、但是暂时访问不了；那么：

Durability
可能仍然很好

Availability
此刻却受到影响

所以：

Availability
→ 能不能访问

Durability
→ 数据会不会长期保存下来

S3 章节会再次重点讲这个区别。

2.24-★★★★★-云计算核心概念关系图​

                    Cloud Computing
                          │
       ┌──────────────────┼──────────────────┐
       │                  │                  │
       ▼                  ▼                  ▼
     Agility          Scalability        Availability
     敏捷性             可扩展性             可用性
       │                  │                  │
       │                  │                  │
快速获得资源          系统规模可扩大       故障后仍尽量可用
       │                  │
       │              Elasticity
       │                  弹性
       │                  │
       │             随需求增减资源
       │
       └──────────────────┬─────────────────
                          │
                      Reliability
                        可靠性
                          │
                     Resilience
                         韧性

3-★★★★★-AWS-Global-Infrastructure：AWS-全球基础设施​

到这里，我们已经回答：

Cloud 为什么有价值？

接下来要回答：

这些云服务器实际在哪里？

AWS 的云不是漂浮在空气中。底层仍然是：真实土地、真实建筑、真实服务器、真实交换机、真实光纤、真实电力系统；只是这些物理基础设施由 AWS 建设和运营。

3.1-当前-AWS-全球规模​

【AWS 当前｜2026-09】；截至本章编写时，AWS 官方 Global Infrastructure 页面显示：

Geographic Regions
地理区域：
39

Availability Zones
可用区：
124

CloudFront POPs
以及 Regional Edge Caches：
750+

这些数字会持续增加，因此不建议把具体数字作为长期死记内容；考试更重要的是理解 Region、AZ 和 Edge Network 之间的关系。(Amazon Web Services)

3.2-★★★★★-AWS-全球基础设施第一张总图​

                           AWS Global
                        全球AWS基础设施
                              │
       ┌──────────────────────┼──────────────────────┐
       │                      │                      │
       ▼                      ▼                      ▼
 Tokyo Region            Oregon Region          Frankfurt Region
 东京区域                  俄勒冈区域               法兰克福区域
       │
 ┌─────┼─────┬─────┐
 ▼     ▼     ▼     ▼
AZ-1  AZ-2  AZ-3  AZ-4
 │
 ├── Data Center
 └── Data Center

另外还有：

Edge Locations
Local Zones
Outposts
Wavelength Zones

3.3-★★★★★-Region：区域​

Region； 中文：区域；AWS 官方定义非常直接：

每一个 AWS Region 是一个独立的地理区域。(AWS Documentation)

3.4-一个真实-Region：东京​

GlobalShop 的日本核心系统可以选择：Asia Pacific (Tokyo)； 中文：亚太（东京）区域；Region Code：ap-northeast-1；拆开来看：

ap
Asia Pacific
亚太

northeast
东北方向

1
该系列中的编号

实际使用 AWS API、CLI、SDK 时，经常会看到：ap-northeast-1；而不是完整的：Asia Pacific (Tokyo)

3.5-日本目前有两个-AWS-Region​

【AWS 当前】；例如：

Asia Pacific (Tokyo)
ap-northeast-1
4 AZs

Asia Pacific (Osaka)
ap-northeast-3
3 AZs

AWS 当前 Region 列表确认东京为 4 个 AZ、大阪为 3 个 AZ。(AWS Documentation)这两个都是：Region；不是：

Tokyo = AZ
Osaka = AZ

3.6-为什么-AWS-要划分-Region？​

有几个核心原因。

3.6.1-Geographic-Proximity：地理接近​

Geographic Proximity； 中文：地理接近性；假设用户主要都在日本。部署：Tokyo；通常比部署：Virginia；更有机会获得较低的网络传播延迟。

AWS 官方 Region 指南也明确建议，可以选择靠近主要用户的 Region 来降低网络延迟。(AWS Documentation)

3.6.2-Regulatory/Compliance：监管和合规​

Regulatory；监管。Compliance；合规。有些业务可能规定：某类数据必须保存在指定国家/地区；于是 Region 选择不再只是性能问题。可能是法律和监管问题。

3.6.3-Service-Availability：服务可用范围​

不是所有 AWS 服务：从发布第一天起；都一定在全球每一个 Region 同时提供。所以部署业务前，需要考虑：

我需要的 AWS Service 在这个 Region 有没有？

AWS Region 官方指南将所需服务和功能是否可用明确列为 Region 选择因素。(AWS Documentation)

3.7-GlobalShop-Region-选择案例​

GlobalShop 日本站：

主要用户：
日本

监管：
部分用户数据希望放在日本

主要业务团队：
东京

可能选择：Asia Pacific (Tokyo)、ap-northeast-1；欧洲业务如果存在数据和法律要求：Europe Region；可能更适合。所以：

Region Selection
区域选择

不是只看：
“哪个Region最快？”

而是：

用户位置
+
法律/监管
+
服务Availability
+
业务需求

3.8-★★★★★-Availability-Zone：可用区​

完整英文：Availability Zone；简称：AZ； 中文：可用区

3.9-AZ-到底是什么？​

这是非常重要的一句话：

一个 Availability Zone 是一个 Region 内相互隔离的基础设施位置，可以包含一个或多个离散的数据中心。

题库第 150 题就直接问：

哪一个环境由一个或多个 Data Center 组成？

题库答案：Availability Zone。

3.10-Region-与-AZ-的真实层级​

不要这样理解：

Tokyo
=
一个机房

正确结构更接近：

Japan
│
├── Asia Pacific (Tokyo) Region
│      │
│      ├── Availability Zone 1
│      │      ├── Data Center
│      │      └── Data Center
│      │
│      ├── Availability Zone 2
│      │      └── Data Center(s)
│      │
│      ├── Availability Zone 3
│      │
│      └── Availability Zone 4
│
└── Asia Pacific (Osaka) Region
       │
       ├── AZ
       ├── AZ
       └── AZ

3.11-东京-Region-的实际-AZ​

【AWS 当前】；Tokyo Region：ap-northeast-1；当前包含四个稳定 AZ ID：apne1-az1、apne1-az2、apne1-az3、apne1-az4

AWS 官方 Availability Zone 列表明确列出了这四个 Tokyo AZ ID。(AWS Documentation)

3.12-为什么有-AZ-ID-和-ap-northeast-1a-这种名字？​

这是一个可以了解、但 CLF-C02 不需要深入的细节。你有时会看到：ap-northeast-1a、ap-northeast-1b、...；这是：Availability Zone Code；而 AWS 还提供：apne1-az1；这种：AZ ID；AZ ID 用于稳定标识一个具体的物理 AZ。

AWS 当前文档还说明：对于较早创建的账户，在一些老 Region 中，类似 us-east-1a 这样的字母代码过去可能在不同账户映射到不同的物理 AZ；AZ ID 则跨账户一致。新账户的映射策略已经发生变化。(AWS Documentation)

对 CLF-C02 来说，只需知道：

Region
包含多个AZ

AZ
是Region内部的隔离故障域

就足够。

3.13-为什么一个-Region-不能只有一个-AZ？​

因为：

数据中心也会故障。

例如：停电、网络中断、硬件故障、火灾、洪水、人为故障；如果整个东京 Region 只有一个位置：

Tokyo

└── Data Center
      │
      ├── EC2
      ├── RDS
      └── Application

这个地方发生重大故障：

Tokyo
  X

业务全部停止。因此 AWS Region 采用多个相互隔离的：Availability Zones当前 AWS 官方文档指出，每个 Region 至少有三个 AZ，用于帮助设计高可用应用。(AWS Documentation)

3.14-AZ-为什么要相互隔离？​

如果两个所谓“可用区”：共用同一个电源、共用同一个交换机、共用同一个建筑；那么：

电源故障
↓
两个一起挂

就失去了意义。所以 AZ 的设计重点是：Fault Isolation； 中文：故障隔离；也就是：

尽可能防止一个基础设施位置发生故障时，把其他位置一起带走。

3.15-为什么多个-AZ-之间还要高速连接？​

另一方面，如果 AZ：完全隔离、但是彼此网络很慢；也很难组成一个实时业务系统。所以一个 Region 内的 AZ 既需要：故障隔离；又需要：高带宽、低延迟的网络连接；让：AZ-A Application；能够和：AZ-B Database；进行可靠通信。

3.16-★★★★★-Multi-AZ：多可用区​

Multi；多个。AZ；Availability Zone。Multi-AZ； 中文：多可用区部署；它不是一个单独的 AWS 产品名称。它是一种：Architecture Pattern； 中文：架构模式

3.17-Single-AZ-的问题​

GlobalShop：

Tokyo Region
│
└── AZ-A
      │
      ├── EC2
      └── Database

如果：

AZ-A
  X

整个服务：X

3.18-Multi-AZ-架构​

                 Tokyo Region
                      │
             Load Balancer
                  /       \
                 /         \
                ▼           ▼
             AZ-A         AZ-B
              │             │
             EC2           EC2

数据库也可以采取适当的 Multi-AZ 高可用设计。当：

AZ-A
  X

还有：

AZ-B
 ✓

所以服务仍有机会继续提供。

3.19-★★★★★-Multi-AZ-的主要目的是什么？​

主要：

High Availability
高可用

Fault Isolation
故障隔离

Resilience
韧性

而不是：服务美国用户更快；因为：AZ-A、AZ-B；仍然都属于：Tokyo Region

3.20-题库如何考-Multi-AZ？​

例如题库存在典型数据库题：

Database must be highly available and fault tolerant.

选项包括：

RDS Single-AZ

RDS Snapshot

RDS Multi-AZ

DMS

题库对应：RDS with multiple Availability Zones。这类题真正考的是：

High Availability
+
AZ Failure protection
↓
Multi-AZ

而不是简单背：

RDS = Multi-AZ

3.21-★★★★★-Multi-Region：多区域​

Multi-Region； 中文：多区域部署；这里比 Multi-AZ 再高一层。

3.22-Multi-AZ-与-Multi-Region​

Japan

┌────────────────────────┐
│ Tokyo Region           │
│                        │
│ AZ-A  AZ-B  AZ-C AZ-D  │
└────────────────────────┘

          │
          │ Multi-Region
          ▼

┌────────────────────────┐
│ Osaka Region           │
│                        │
│ AZ-A  AZ-B  AZ-C       │
└────────────────────────┘

3.23-Multi-AZ-主要保护什么？​

例如：某个数据中心故障、某个Availability Zone故障、部分基础设施问题

3.24-Multi-Region-主要进一步考虑什么？​

例如：整个地理区域重大灾害、区域级业务连续性、全球业务、跨区域灾难恢复、部分法规需求

3.25-★★★★★-一个非常重要的原则​

不要理解成：

“只要系统重要，就一定 Multi-Region。”

不一定。Multi-Region 会引入：更高成本、更复杂数据复制、一致性问题、跨Region网络、Failover机制、运维复杂性；AWS 当前架构指导也明确指出：

不是所有 workload 都需要 Multi-Region；对于很多场景，同一 Region 内良好的 Multi-AZ 已经能够提供高可用。(AWS Documentation)

所以：

Multi-AZ
≠ 低级架构

Multi-Region
≠ 永远更正确

要根据业务要求。

3.26-题库中的-Multi-Region-场景​

题库第 147 题：

EC2 必须保持高可用，即使某一个特定 geographic area 发生 natural disaster。

选项中包括：

multiple AWS Regions

multiple CloudFront locations

multiple Edge Locations

Local Zones

题库答案：multiple AWS Regions。为什么？因为：natural disaster、+、particular geographic area；已经超出了单纯：离用户更近；的问题。

4-★★★★-Disaster-Recovery：灾难恢复​

简称：DR；完整英文：Disaster Recovery； 中文：灾难恢复 / 灾备

4.1-DR-和-High-Availability-不完全一样​

High Availability：

主要希望正常运行期间，即使局部组件发生故障，也尽量维持服务。

Disaster Recovery：

发生重大灾害之后，如何恢复整个 workload。

AWS 官方 Reliability 文档明确区分：Availability 关注一段时间内对组件故障、负载尖峰、软件 Bug 等事件的韧性；DR 则关注面对自然灾害、大规模技术故障或攻击/人为错误时的一次恢复目标。(AWS Documentation)

4.2-GlobalShop-的-DR-场景​

正常：

Tokyo Region
     │
     ├── AZ-A
     └── AZ-B

正常提供业务

另外：

Osaka Region
     │
     └── 保留备份 / 副本 / 恢复能力

重大区域事件：

Tokyo Region
     X

      │
      │ Disaster Recovery
      ▼

Osaka Region
恢复业务

4.3-★★★★-RTO：Recovery-Time-Objective​

完整英文：Recovery Time Objective；简称：RTO； 中文：恢复时间目标；核心问题：

最多允许业务停多久？

例如：GlobalShop 定义：

RTO = 30 minutes

意思：

发生灾害以后，希望最多 30 分钟以内恢复业务。

4.4-★★★★-RPO：Recovery-Point-Objective​

完整英文：Recovery Point Objective；简称：RPO； 中文：恢复点目标；核心问题：

最多允许丢多少时间范围的数据？

例如：

RPO = 5 minutes

意味着：

灾害发生后，最多接受最近约 5 分钟的数据无法恢复。

AWS 官方定义也是：

  • RTO：服务中断到恢复之间最大可接受时间。
  • RPO：最后可恢复的数据点与故障之间最大可接受时间。(AWS Documentation)

4.5-★★★★★-RTO/RPO-文字时间轴​

假设：

10:00
最后一次可恢复数据

10:05
灾害发生

10:25
业务恢复

则：

             Disaster
                │
                ▼
09:55  10:00  10:05             10:25
─────────●───────X────────────────●────→
         │                         │
         │                         │
      RPO范围                   RTO范围

简单理解：

RPO
向灾害之前看

“最多丢多少数据？”

RTO
向灾害之后看

“最多停多久？”

4.6-RTO-越低意味着什么？​

例如：

RTO = 24 hours

业务允许慢慢恢复。成本可能相对较低。而：

RTO = 30 seconds

意味着：

灾害发生以后几乎马上恢复。

通常需要：更多预先运行的资源、更多自动化、更复杂架构、更高成本

4.7-RPO-越低意味着什么？​

例如：

RPO = 24 hours

每天备份一次或许有机会满足。而：RPO ≈ 0；意味着几乎不能丢数据。通常需要：持续复制、实时复制、更复杂的数据架构；所以：

RTO ↓
RPO ↓

通常意味着：

Cost ↑
Complexity ↑

4.8-★★★-DR-的四种典型思想​

AWS Reliability 指导中常见四种 DR 策略：

Backup and Restore
备份与恢复

Pilot Light
指示灯 / 最小核心环境

Warm Standby
温备

Multi-Site Active/Active
多站点双活 / 多活

它们通常：

成本逐渐增加
↓
恢复速度逐渐提高
↓
RTO / RPO 通常逐渐降低

AWS 当前 Well-Architected Reliability 文档仍使用这些恢复策略。(AWS Documentation)C2-16 和后续架构章节会详细展开。本章只建立概念。

4.9-★★★★-Data-Residency：数据驻留​

Data；数据。Residency；驻留。Data Residency； 中文：数据驻留；AWS 对其定义可以简单理解为：

数据在物理或地理上存储和处理在哪里。

(AWS Documentation)

4.10-GlobalShop-数据驻留例子​

假设监管要求：

日本客户的特定敏感数据必须留在日本。

那么架构不能随便：

Japan Data
    │
    ▼
US Region

而要根据法规和业务要求选择合适：Japan Region；例如：Tokyo、Osaka；Region 就变成一个非常重要的合规控制点。

4.11-★★★-Data-Sovereignty：数据主权​

Sovereignty；主权。Data Sovereignty； 中文：数据主权；它比 Data Residency 范围更广。AWS 当前的解释是：

数据受到其物理位置对应法律和监管体系的约束。Data Residency 强调数据实际在哪里；Data Sovereignty 进一步强调该地的法律和治理如何作用于数据。(Amazon Web Services)

4.12-★★★★★-Data-Residency-与-Data-Sovereignty​

可以先记：

Data Residency
↓
数据在哪里？

Data Sovereignty
↓
数据受到哪里的法律、
监管和治理体系约束？

例如：日本客户数据、实际存储：、Tokyo Region；这是：Residency；然后：

这些数据如何受到日本相关法律和监管制度约束？

属于：Sovereignty

4.13-题库怎样考地理位置和法规？​

题库第 529 题：

公司需要在 specific geographic area 部署应用以满足 regulations。

题库把 AWS 的：Global Footprint；作为相关优势，并在评论中把它和 Region/AZ 的全球分布以及数据驻留联系起来。真正理解应该是：

Compliance Requirement
        │
        ▼
需要控制部署地理位置
        │
        ▼
选择适合的 AWS Region

而不是死记：

regulation = global footprint

4.14-★★★-Global-Footprint-是什么？​

Global；全球。Footprint；原意是“足迹”。这里：Global Footprint；可以理解：全球基础设施覆盖范围；AWS 在全球存在许多：Regions、Availability Zones、Edge Locations、Local Zones；因此企业可以根据：用户位置、法律、延迟、业务连续性；选择部署地点。

5-★★★★-Edge：什么叫“边缘”？​

现在进入一个很容易被一句：

“离用户更近。”

糊弄过去的概念。

5.1-网络中的-Core-与-Edge​

Core；核心。Edge；边缘。这里的 Edge 不是：

城市边缘。

而是：

相对于云中心基础设施而言，更靠近终端用户和接入网络的位置。

想象：

                  Cloud Core
                 AWS Region
                     │
                     │
                Backbone
                     │
                     │
                Edge Network
                     │
                     ▼
                   Users

越靠近：最终用户；越接近：Network Edge；网络边缘。

5.2-★★★★-Edge-Location：边缘站点​

Edge Location；中文常理解为：边缘站点 / 边缘节点；主要服务于：CDN、DNS、Network Acceleration、Edge Security；等全球网络能力。

5.3-为什么需要-Edge-Location？​

GlobalShop 所有商品图片原文件存在：Tokyo、S3；日本用户：

Tokyo User
    │
    ▼
Tokyo Region

距离较近。美国用户：

US User
   │
   │ long network path
   │
   ▼
Tokyo Region

每次都跑东京，网络路径很长。

5.4-★★★★-CloudFront-怎么使用-Edge-Location？​

后面 C2-07 会完整讲 CloudFront。现在只理解边缘节点。第一次访问：

US User
   │
   ▼
US Edge Location
   │
Cache miss
   │
   ▼
Tokyo Origin
S3
   │
   ▼
Object returned
   │
   ▼
Edge Cache

下一位附近用户：

US User
   │
   ▼
Nearby Edge Location
   │
   ▼
Cached Object
   │
   ▼
直接返回

不必每次跨越远距离到 Tokyo。

5.5-★★★-Origin-是什么？​

Origin； 中文：源站；在 CDN 中：

保存原始内容、CloudFront 最终回源访问的位置。

GlobalShop：S3 Bucket；可以作为 CloudFront Origin。也可以是：Load Balancer、HTTP Server；等。

5.6-★★★★-Cache-是什么？​

Cache； 中文：缓存；其思想：

把经常需要的数据暂时保存在离使用者更近或访问更快的位置。

例如：

Original:
Tokyo S3

Cached Copy:
US Edge

这样后续请求可以直接从 Cache 返回。

5.7-★★★★★-Edge-Location-与-Availability-Zone-最大区别​

对比Availability ZoneEdge Location
中文可用区边缘站点
所属逻辑Region 内基础设施全球边缘网络
主要目标故障隔离、高可用靠近用户、降低内容访问延迟
常见服务EC2、RDS、EBS 等CloudFront、DNS/边缘能力等
典型问题一个 AZ 挂了怎么办全球用户离源站太远怎么办

不要因为两个地方都有服务器就认为是同一个概念。

5.8-★★-Regional-Edge-Cache​

CloudFront 还存在：Regional Edge Cache； 中文：区域边缘缓存；可以粗略理解为：

位于 Edge Location 与 Origin 之间更大一级的中间缓存层。

概念图：

User
 │
 ▼
Edge Location
 │
 ▼
Regional Edge Cache
 │
 ▼
Origin

它可以进一步减少：每次都直接回源；的需求。CLF-C02 一般不要求深入 CloudFront 多级缓存实现，本章知道层级即可。

5.9-★★★-Local-Zone：本地区域​

AWS Local Zones；中文通常：AWS 本地区域；它是：

AWS Region 向特定大城市或人口/产业中心方向的基础设施延伸。

AWS 官方定义：

Local Zone 将计算、存储、数据库等部分 AWS 资源部署到更靠近大型人口和产业中心的位置，以提供低延迟访问。(AWS Documentation)

5.10-为什么已经有-Region，还要-Local-Zone？​

假设：Parent Region:、Oregon；而你的用户/业务就在：Los Angeles；某些业务要求：极低延迟；但并不一定有一个完整 AWS Region 就建在那个城市。于是 AWS 可以提供：Local Zone；把部分：Compute、Storage、Database；资源放到更接近当地用户的位置。

5.11-一个真实-Local-Zone-例子​

AWS 当前文档给出的典型 Local Zone：us-west-2-lax-1a；其中：

us-west-2
Parent Region
美国西部（俄勒冈）

lax
Los Angeles
洛杉矶

所以它表达的是：

这个 Local Zone 属于 us-west-2 Region 的扩展，但基础设施靠近 Los Angeles。

(AWS Documentation)

5.12-GlobalShop-为什么可能用-Local-Zone？​

普通电商页面：几十毫秒差异；往往没有必要专门使用 Local Zone。但如果 GlobalShop 开始做：

AR虚拟试衣

直播电商实时视频处理

仓库实时视觉系统

远程图形工作站

这些业务对：Low Latency；低延迟非常敏感。如果目标用户靠近 Local Zone：可以考虑。AWS 官方列出的 Local Zone 典型用途也包括实时游戏、直播、AR/VR、虚拟工作站以及低延迟混合部署。(AWS Documentation)

5.13-★★★★-Local-Zone-和-Edge-Location-的区别​

两者都说：

靠近用户。

但不是一个东西。

5.13.1-Edge-Location​

更偏：Cache、Content Delivery、DNS、Edge Network

5.13.2-Local-Zone​

可以真正部署部分：EC2、Storage、Database、Application Workload；所以：

CloudFront缓存商品图片
→ Edge Location

在洛杉矶本地运行低延迟EC2 workload
→ Local Zone

5.14-★★★-AWS-Outposts​

Outpost；英文原义：前哨 / 前哨站；产品：AWS Outposts；中文一般仍直接叫：AWS Outposts

5.15-Outposts-为什么存在？​

有些公司说：

我想使用 AWS 的服务器、API 和运维模式。

但是又说：

我的计算资源必须放在我自己的机房里。

原因可能：

需要极低本地延迟

大量数据不适合一直传Cloud Region

本地数据处理

法规 / Residency

现有系统高度依赖本地网络

于是：只使用普通AWS Region；不能完全满足。

5.16-Outposts-做了什么？​

AWS 把：AWS managed hardware、AWS compute capacity、AWS storage capacity、AWS APIs、AWS tools；直接延伸到：Customer Premises； 中文：客户现场 / 客户自己的数据中心；AWS 官方当前定义：

Outposts 是完全托管服务，将 AWS 基础设施、服务、API 和工具扩展到客户所在地；Outpost 本身是部署在客户现场的一组 AWS 计算和存储容量，并由 AWS 作为其关联 Region 的一部分进行运营、监控和管理。(AWS Documentation)

5.17-Outposts-实际结构​

GlobalShop Data Center
企业自己的机房
│
├── Legacy Server
├── Mainframe
├── Local Database
│
└── AWS Outposts Rack
       │
       ├── AWS Compute
       ├── AWS Storage
       └── AWS Services
              │
              │ Service Link
              ▼
          AWS Region

这里非常关键：

Outposts 不是“通过专线访问 AWS Region”。

而是：

AWS 的基础设施本身真的部署进客户现场。

5.18-Outposts-与-Direct-Connect-不一样​

后面 C2-07 会详细讲。先记：

Direct Connect
→ 网络连接

Outposts
→ AWS基础设施部署到客户现场

比如：

自己家没有AWS服务器
只拉了一条专线
→ Direct Connect

自己机房里真的放了AWS管理的Rack
→ Outposts

5.19-GlobalShop-Outposts-场景​

假设 GlobalShop 有一个大型物流中心。仓库自动化系统：摄像头、机械臂、分拣机、传送带；需要：极低延迟本地控制；不能每个控制信号：

仓库
↓
公网
↓
Tokyo Region
↓
计算
↓
再回来

但公司又希望：使用AWS API、AWS管理方式、与AWS VPC集成；于是：Outposts；可能成为方案之一。

5.20-Outposts-当前产品状态补充​

【AWS 当前】AWS 当前文档注明，原来的 1U 和 2U Outposts Server 已停止销售，AWS 正把重点放到 Outposts Rack 以及新的形态上。Outposts 本身仍然是当前 AWS 服务。(AWS Documentation)

CLF-C02 不需要记这种产品生命周期细节。这里只是为了保证文档与当前 AWS 状态一致。

5.21-★-AWS-Wavelength​

【题库补充】【CURRENT-OUT-OF-SCOPE】；AWS 当前 CLF-C02 官方 Out-of-Scope 页面已经明确将：AWS Wavelength；列在：Compute、Out-of-Scope

中。(AWS Documentation)但是你的 719 题中存在 Wavelength，因此仍然需要知道它是什么。

5.22-Wavelength-是什么？​

AWS Wavelength 将部分标准 AWS 计算和存储能力部署到：Telecommunication Carrier 5G Edge； 中文：电信运营商的 5G 网络边缘；AWS 当前 Global Infrastructure 文档仍然这样描述 Wavelength Zone：

用于让开发者构建面向 5G 设备和终端用户的超低延迟应用。(AWS Documentation)

5.23-普通移动应用路径​

5G Phone
   │
   ▼
Telecom Network
运营商网络
   │
   ▼
Internet / Backbone
   │
   ▼
AWS Region
   │
   ▼
EC2

5.24-Wavelength​

5G Phone
   │
   ▼
Telecom Network
   │
   ▼
Wavelength Zone
   │
   └── Compute / Storage
          │
          ▼
      AWS Region

某些实时业务不需要每一次都走到较远的核心 Region 再回来。

5.25-Wavelength-场景​

比如：实时多人云游戏、AR / VR、联网汽车、实时视频分析；这些业务可能对：几毫秒级延迟；非常敏感。普通 GlobalShop 商品页通常并不需要这种能力。

5.26-★★★★★-Local-Zone、Wavelength、Outposts、Edge-Location-对比​

技术中文理解基础设施在哪里主要目的
Availability Zone可用区AWS Region 内高可用、故障隔离
Edge Location边缘站点靠近终端用户的 AWS Edge NetworkCDN、DNS、内容与网络加速
Local Zone本地区域靠近特定城市/产业中心运行低延迟 AWS workload
Wavelength Zone5G 边缘区域电信运营商 5G 网络边缘移动设备超低延迟
OutpostsAWS 本地基础设施客户自己的机房本地运行 AWS 基础设施

这五个概念都涉及：Location、位置；但目的完全不同。

5.27-★★★★★-一张位置层级图​

                         AWS GLOBAL
                             │
             ┌───────────────┴───────────────┐
             │                               │
             ▼                               ▼
       Tokyo Region                    Oregon Region
             │                               │
   ┌─────────┼─────────┐                ┌────┼────┐
   ▼         ▼         ▼                ▼    ▼    ▼
  AZ1       AZ2       AZ3              AZ1  AZ2  AZ3
   │
   └── Data Centers

Region Extension:

Oregon Region
     │
     └──── Los Angeles Local Zone

Near Users:

User
 │
 ▼
Edge Location
 │
 ▼
CloudFront
 │
 ▼
Region

5G:

Mobile User
 │
 ▼
Carrier Network
 │
 ▼
Wavelength Zone
 │
 ▼
Region

Customer Premises:

GlobalShop Data Center
 │
 └── AWS Outposts
        │
        ▼
     AWS Region

6-★★★★-Regional、Zonal、Global-Service-Scope​

AWS 服务并不都是一个地理作用域。可以粗略分成：

Global
全球

Regional
区域级

Zonal
可用区级

理解这一点非常重要。

6.1-Regional-Resource：区域资源​

例如很多 AWS 服务的资源：在某一个Region创建；比如 EC2：Tokyo Region；和：Oregon Region；里的实例是两个不同 Region 内的资源。

6.2-Zonal-Resource：可用区资源​

有些资源与具体 AZ 强关联。例如后续会学习：Amazon EBS Volume；通常创建在：某个Availability Zone；如果：EBS in AZ-A；要直接挂到：EC2 in AZ-B；就不能把它当普通本地硬盘一样理解。后面 C2-04 详细讲。

6.3-Global-Services：全球服务​

有一些服务的管理范围呈全球性质。例如：

AWS IAM

Amazon Route 53

Amazon CloudFront

但“Global Service”不代表：

所有数据和行为都完全没有地域概念。

这部分涉及具体服务细节，后续相关章节再准确说明。当前只需要知道：

AWS 资源存在不同地理 Scope，不能假设所有服务都绑在同一个 AZ。

6.4-★★★★-Latency：延迟​

Latency； 中文：延迟；例如：

用户发送请求
12:00:00.000

收到响应
12:00:00.100

总耗时：100ms其中存在：网络延迟、服务器处理时间、数据库时间

6.5-为什么-Region-位置影响-Latency？​

光纤再快，也不能突破物理规律。日本用户：

Tokyo
↓
Tokyo Region

网络路径通常比：

Tokyo
↓
US East

短。所以 AWS 官方也把：

靠近主要用户以降低 network latency

列为选择 Region 的考虑因素。(AWS Documentation)

6.6-★★★-Throughput：吞吐量​

Throughput； 中文：吞吐量；不要与 Latency 混淆。

6.6.1-Latency​

回答：

一次需要多久？

例如：50 ms

6.6.2-Throughput​

回答：

一段时间能够处理多少？

例如：

10 GB/s

100,000 requests/second

所以：

Latency
像：
一个快递包裹多久送到

Throughput
像：
一天一共能运多少包裹

6.7-★★★-Bandwidth：带宽​

Bandwidth； 中文：带宽；可以粗略理解为：

网络链路理论上可以承载的数据传输能力。

虽然：Bandwidth、Throughput；经常相关，但不是完全同义。

6.8-Availability、Latency、Cost-不一定可以同时做到最好​

真实架构必须做：Trade-off； 中文：权衡 / 取舍；例如：

只部署东京
↓
成本较简单
日本用户很好
美国用户延迟可能较高
Region级DR能力有限

全球多Region Active-Active
↓
全球性能更强
区域级韧性更好
但是：
成本更高
架构更复杂
数据同步更难

所以：

云架构不是“选最贵的就是最好”。

而是：业务需求、+、风险、+、成本、+、复杂度；之间取得平衡。

7-GlobalShop-的完整基础设施选择过程​

现在把本章所有概念串起来。

7.1-Step-1：用户主要在哪？​

Japan、US、Europe；所以需要考虑：Regions、Edge Network

7.2-Step-2：日本核心系统在哪里？​

选择：Asia Pacific (Tokyo)、ap-northeast-1

7.3-Step-3：东京只有一个-AZ-可以吗？​

不希望。生产环境：AZ-A、+、AZ-B；至少形成 Multi-AZ 思维。

7.4-Step-4：商品图片美国用户怎么办？​

S3 Origin、+、CloudFront Edge Network；后面 C2-07 详细实现。

7.5-Step-5：某城市有超低延迟业务怎么办？​

如果有合适 Local Zone：Local Zone；可能考虑。

7.6-Step-6：物流中心必须本地处理怎么办？​

可能考虑：Outposts

7.7-Step-7：整个东京-Region-都不可用怎么办？​

如果业务真的有这个要求：Multi-Region DR；例如：Tokyo、+、Osaka

7.8-Step-8：能停多久？​

定义：RTO

7.9-Step-9：能丢多少数据？​

定义：RPO

7.10-★★★★★-GlobalShop-基础设施总图​

                         Global Users
             Japan          US          Europe
               │             │             │
               ▼             ▼             ▼
          Edge Location  Edge Location  Edge Location
               │             │             │
               └─────────────┼─────────────┘
                             │
                         CloudFront
                             │
                             ▼
                    Asia Pacific (Tokyo)
                       ap-northeast-1
                             │
               ┌─────────────┼─────────────┐
               │             │             │
               ▼             ▼             ▼
             AZ-1          AZ-2          AZ-3
               │             │
              EC2           EC2
               │             │
               └──────┬──────┘
                      │
                 Multi-AZ
                      │
                      ▼
               High Availability

                         DR
Tokyo Region ───────────────────────── Osaka Region
    │                                      │
 Primary                                Recovery
 Workload                                Region

Local Requirement:

Large City
   │
   ▼
Local Zone

On-Prem Requirement:

GlobalShop Data Center
   │
   ▼
AWS Outposts
   │
   ▼
AWS Region

8-题库中的本章主要考法​

根据 719 题，本章知识主要以以下几种方式出现。

8.1-类型-1：云计算优势​

例如：

固定成本还是可变成本？

为什么AWS可以降低单位成本？

为什么Cloud提高Agility？

为什么不用提前Overprovision？

高频答案方向：

Variable expense

Economies of scale

Speed and agility

Elastic capacity

题库中也反复讨论“Trade fixed expense for variable expense”以及规模经济等云价值。

8.2-类型-2：Elasticity/Scalability/Availability-区分​

典型选项：

Agility

Elasticity

Scalability

High Availability

判断：

快速上线资源
→ Agility

规模越来越大还能撑
→ Scalability

随流量自动增加又减少
→ Elasticity

故障以后还能提供服务
→ High Availability

8.3-类型-3：Region/AZ​

题目可能问：

one or more data centers

→ Availability Zone。或者：

choose geographic deployment area

→ Region。题库中也有题直接将 RDS 的 deployment area 选择和 AWS Regions 联系起来。

8.4-类型-4：法规和地理要求​

题目：

specific geographic location

regulatory requirements

data must remain...

通常首先想到：Region Selection；而不是：Availability Zone；因为 Region 才是：Geographic Area；更高层级的位置概念。

8.5-类型-5：High-Availability​

题目：

AZ failure

highly available

fault tolerant

通常考虑：Multiple Availability Zones

8.6-类型-6：Geographic-Disaster​

题目：

natural disaster

entire geographic area

Regional failure

需要开始考虑：Multiple Regions；但不要机械：

Disaster
=
Multi-Region

现实 AWS 架构中，Multi-AZ 也能缓解许多火灾、洪水、电力等局部灾害；只有当业务要求保护到整个 Region 无法运行这种级别，才真正需要跨 Region 策略。AWS 当前 Reliability 指导也明确区分了这两级。(AWS Documentation)

8.7-类型-7：Edge/Local/Outposts​

判断：

CDN / content near users
→ Edge Location

run AWS compute near a metro area
→ Local Zone

AWS infrastructure in customer's own data center
→ Outposts

5G ultra-low-latency
→ Wavelength
【当前CLF-C02范围外】

9-本章高频英文词汇表​

英文全称/解释中文
Cloud Computing—云计算
On-PremisesOn-Prem本地部署
Capacity—容量
Capacity Planning—容量规划
Provision—创建/供应资源
Pay-as-you-go—按使用量付费
CAPEXCapital Expenditure资本性支出
OPEXOperating Expenditure运营性支出
Economies of Scale—规模经济
Agility—敏捷性
Scalability—可扩展性
Scale UpVertical Scaling纵向扩展
Scale OutHorizontal Scaling横向扩展
Scale In—缩减资源
Elasticity—弹性
HAHigh Availability高可用性
SPOFSingle Point of Failure单点故障
Redundancy—冗余
Fault Tolerance—容错能力
Reliability—可靠性
ResilienceResiliency韧性
Durability—持久性/数据耐久性
Downtime—停机时间
Region—区域
AZAvailability Zone可用区
Multi-AZMultiple Availability Zones多可用区
Multi-RegionMultiple Regions多区域
Data Center—数据中心
Edge—边缘
Edge Location—边缘站点
Local Zone—本地区域
Outposts—AWS 本地基础设施服务
DRDisaster Recovery灾难恢复
RTORecovery Time Objective恢复时间目标
RPORecovery Point Objective恢复点目标
Data Residency—数据驻留
Data Sovereignty—数据主权
Latency—延迟
Throughput—吞吐量
Bandwidth—带宽
Origin—源站
Cache—缓存
Trade-off—权衡

9.1-★★★★★-本章最重要的概念对比​

9.1.1-Scalability-vs-Elasticity​

Scalability
=
能不能扩大

Elasticity
=
能不能随需求扩大和缩小

9.1.2-Availability-vs-Durability​

Availability
=
现在能不能访问

Durability
=
数据会不会丢

9.1.3-Multi-AZ-vs-Multi-Region​

Multi-AZ

同一个Region
多个AZ

主要：
High Availability

Multi-Region

不同Region

主要：
Region级DR
全球业务
部分法规需求

9.1.4-AZ-vs-Edge-Location​

AZ
=
完整AWS workload基础设施位置
主要解决Fault Isolation

Edge Location
=
靠近用户的Edge Network节点
主要解决Content Delivery / Latency

9.1.5-Local-Zone-vs-Outposts​

Local Zone
=
AWS在靠近特定城市的位置提供基础设施

Outposts
=
AWS基础设施进入客户自己的数据中心

9.1.6-High-Availability-vs-Disaster-Recovery​

High Availability
=
正常运行期间局部故障
尽量不中断业务

Disaster Recovery
=
重大灾害以后
整个workload如何恢复

9.1.7-RTO-vs-RPO​

RTO
=
最多停多久

RPO
=
最多丢多少时间的数据

9.2-做题快速判断图​

题目说：
“需求变化”
      │
      ├── 规模可以扩大
      │      → Scalability
      │
      └── 自动增加/减少
             → Elasticity

题目说：
“故障”
      │
      ├── 尽量不中断
      │      → High Availability
      │
      ├── 一个AZ挂掉
      │      → Multi-AZ
      │
      └── 整个地理区域灾害
             → Multi-Region / DR

题目说：
“位置”
      │
      ├── Geographic Area
      │      → Region
      │
      ├── Region内隔离位置
      │      → Availability Zone
      │
      ├── CDN / 离用户近
      │      → Edge Location
      │
      ├── 城市级低延迟Compute
      │      → Local Zone
      │
      └── 自己机房运行AWS
             → Outposts

题目说：
“灾备目标”
      │
      ├── 停多久
      │      → RTO
      │
      └── 丢多少数据
             → RPO

9.3-GlobalShop-本章最终案例​

最后完整走一遍。GlobalShop 计划建设日本电商平台。

9.3.1-第一步：选择-Region​

主要用户在日本：Asia Pacific (Tokyo)、ap-northeast-1；考虑：Latency、Regulation、Service Availability

9.3.2-第二步：不能只部署一个-AZ​

Tokyo Region
│
├── AZ-A
└── AZ-B

Web Server 分布在两个 AZ。目标：High Availability

9.3.3-第三步：双十一自动增加资源​

Normal:
20 servers

Peak:
300 servers

After peak:
20 servers

体现：Elasticity；同时整个系统能够长期增长：Scalability

9.3.4-第四步：全球商品图片​

使用靠近全球用户的：Edge Locations；配合后续会学习的：CloudFront；目标：Lower Latency

9.3.5-第五步：东京大型仓库要求本地处理​

如果要求：AWS infrastructure、+、local processing、+、very low latency；可以研究：Outposts

9.3.6-第六步：整个东京-Region-都不能运行​

业务要求：Regional Disaster Protection；考虑：Tokyo、+、Recovery Region；形成：Multi-Region Disaster Recovery

9.3.7-第七步：明确业务恢复要求​

公司定义：

RTO = 30 minutes

RPO = 5 minutes

意思：

最多允许停：
30分钟

最多允许丢：
约5分钟的数据

然后架构团队才能根据这些业务目标选择相应 DR 策略。

9.4-本章重点等级总结​

9.4.1-★★★★★-必须完全掌握​

Cloud Computing

Pay-as-you-go

Scalability

Elasticity

High Availability

Region

Availability Zone

Multi-AZ

Multi-Region

Region vs AZ

AZ vs Edge Location

RTO vs RPO

9.4.2-★★★★-高频理解​

Agility

Economies of Scale

Fault Tolerance

Reliability

Resilience

Disaster Recovery

Edge Location

Latency

Data Residency

Data Sovereignty

9.4.3-★★★-应该理解​

CAPEX / OPEX

Vertical Scaling

Horizontal Scaling

Single Point of Failure

Durability

Local Zones

Throughput

Regional Edge Cache

9.4.4-★★-～-业务场景知识​

AWS Outposts

9.4.5-★-题库补充​

AWS Wavelength

当前：
CLF-C02官方Out-of-Scope

但：
719题中存在

9.5-本章总结​

本章最重要的不是记住 AWS 有多少 Region。真正需要建立的是下面这套因果关系：

传统机房需要提前采购
       │
       ▼
Cloud允许按需获得资源
       │
       ├── Agility
       │
       ├── Pay-as-you-go
       │
       ├── Scalability
       │
       └── Elasticity
       │
       ▼
但Cloud仍然运行在真实基础设施上
       │
       ▼
AWS Global Infrastructure
       │
       ▼
Region
       │
       ▼
Availability Zones
       │
       ├── Single-AZ
       │
       └── Multi-AZ
       │        │
       │        ▼
       │   High Availability
       │
       ▼
Multi-Region
       │
       ▼
Disaster Recovery
       │
       ├── RTO
       └── RPO

与此同时：

全球用户距离Region太远
       │
       ▼
Edge Network

城市级低延迟需求
       │
       ▼
Local Zone

AWS需要直接进入企业机房
       │
       ▼
Outposts

因此整个 AWS 全球基础设施可以用一句话概括：

Region 决定“业务部署在哪个大的地理区域”；Availability Zone 决定“同一个 Region 内如何隔离故障并实现高可用”；Edge、Local Zone 和 Outposts 则把不同类型的 AWS 能力进一步延伸到更靠近用户或企业本地的位置。

而对于 GlobalShop：

Region
决定：
系统在哪

Multi-AZ
决定：
一个AZ坏了还能不能跑

Elasticity
决定：
双十一能不能自动扩大再缩回来

Edge
决定：
全球用户访问内容够不够快

Multi-Region + DR
决定：
极端区域级灾害后怎么恢复

这些概念会直接成为后续 EC2、RDS、S3、VPC、CloudFront、Route 53、Auto Scaling、Elastic Load Balancing 等服务的基础。下一文件进入：

届时会从最基本的“什么叫 Compute、什么叫服务器、物理机和虚拟机有什么区别”开始，完整展开 EC2 → Instance → AMI → Instance Type → CPU/Memory/Storage → Auto Scaling → Load Balancer → On-Demand/Reserved/Spot/Dedicated → Elastic Beanstalk/Lightsail/Batch，并继续使用 GlobalShop 的普通流量与双十一场景贯穿整个计算体系。