# 第4天：AWS 全球基础设施——你的数据存在哪里

## 今天你将学到什么

今天我们来看 AWS 在全球的"地盘"是怎么布局的。这不是纯理论——它直接决定了：
- 你的用户访问速度快不快
- 你的系统能不能扛住灾难
- 你的数据是否满足法律要求

学完今天，你会明白 Region、可用区、边缘节点这三个概念，以及怎么选择它们。

---

## 先想一个问题

假设你在北京开了一家网店，服务器放在北京。那么：
- 北京的用户访问你的网站：很快（几十毫秒）
- 上海的用户访问：还行（稍微慢一点）
- 美国的用户访问：很慢（数据要跨越太平洋，几百毫秒）

如果你想让全球用户都快，怎么办？**在全球多个地方都放服务器。**

这就是 AWS 全球基础设施要解决的问题。

---

## 三层结构：Region → 可用区 → 边缘节点

想象一个连锁酒店品牌：

- **Region（区域）** = 酒店在不同城市的分店（北京店、上海店、东京店）
- **可用区（AZ）** = 同一城市内的多个酒店大楼（北京朝阳店、北京海淀店）
- **边缘节点（Edge Location）** = 散布在各处的快递柜（方便就近取件）

---

## Region（区域）

Region 是 AWS 在全球某个地理位置的一组数据中心集群。

截至 2024 年，AWS 在全球有 **33 个 Region**，分布在美洲、欧洲、亚太、中东、非洲。

**Region 的命名规则**：`地区-方位-编号`

举几个例子：
| 代号 | 位置 | 常用场景 |
|------|------|----------|
| us-east-1 | 美国东部（弗吉尼亚） | AWS 最老最全的区域，新服务最先上线 |
| ap-northeast-1 | 亚太（东京） | 服务日本和东亚用户 |
| ap-southeast-1 | 亚太（新加坡） | 服务东南亚用户 |
| eu-west-1 | 欧洲（爱尔兰） | 服务欧洲用户 |
| cn-north-1 | 中国（北京） | 中国大陆用户（独立运营） |

**每个 Region 是完全独立的**：
- 数据不会自动从一个 Region 跑到另一个 Region
- 你在东京创建的服务器，在弗吉尼亚是看不到的
- 这是为了数据主权——你的数据留在你选择的地方

### 选 Region 要考虑什么？

**举个例子**：你要做一个面向中国用户的电商网站。

| 考虑因素 | 分析 | 结论 |
|----------|------|------|
| 用户在哪 | 用户在中国 | 选中国区域或离中国近的（东京、新加坡） |
| 法律要求 | 中国法律要求某些数据存储在境内 | 必须选 cn-north-1 或 cn-northwest-1 |
| 服务可用性 | 某些新服务可能还没在中国区上线 | 需要确认你要用的服务是否可用 |
| 价格 | 不同 Region 价格不同 | 弗吉尼亚最便宜，亚太和南美较贵 |

**小贴士**：如果没有特殊要求，学习阶段建议用 `us-east-1`（弗吉尼亚），因为它服务最全、价格最低、教程最多。

---

## 可用区（Availability Zone，简称 AZ）

每个 Region 里面有 **3 个或更多可用区**。每个可用区是一个或多个独立的数据中心。

**为什么一个 Region 要有多个可用区？**

用一个故事来解释：

假设你开了一家面包店，所有的烤箱都在同一栋楼里。如果这栋楼停电了、着火了、或者被水淹了，你的整个生意就停了。

但如果你在同一个城市的不同地方开了 3 家分店，每家都能独立运营。即使一家店出了问题，另外两家还能继续卖面包。

**可用区就是这个道理**：

- 每个 AZ 有独立的电力供应（不同的变电站）
- 每个 AZ 有独立的网络连接
- 每个 AZ 有独立的制冷系统
- AZ 之间物理距离足够远（通常几十公里），避免同一场自然灾害同时影响多个 AZ
- 但 AZ 之间通过高速专用光纤连接，延迟极低（< 2 毫秒）

**这意味着什么？**

如果你把应用部署在同一个 Region 的 2-3 个 AZ 中，即使一个数据中心完全瘫痪（火灾、地震、断电），你的服务依然正常运行。用户甚至感觉不到。

**这就是 AWS 高可用架构的基石。**

---

## 边缘节点（Edge Location）

AWS 在全球有 **600 多个边缘节点**，分布在各大城市。

**边缘节点是干什么的？**

还是用例子说明：

你在东京有一台服务器，上面放着你网站的图片和视频。一个巴西的用户要看你的网站，数据要从东京传到巴西，跨越半个地球，需要 200-300 毫秒。

但如果你把这些图片和视频提前"复制"一份到巴西的边缘节点，巴西用户直接从本地的边缘节点获取，只需要 10-20 毫秒。

**边缘节点主要服务于**：
- **CloudFront（CDN）**：缓存网站的静态内容（图片、视频、CSS、JS），让全球用户就近获取
- **Route 53（DNS）**：就近解析域名，加快网站打开速度
- **AWS WAF**：在边缘拦截恶意攻击，坏流量根本到不了你的服务器

---

## 三者的关系总结

```
全球
├── Region: 美国东部 (us-east-1)
│   ├── 可用区 A (us-east-1a) — 数据中心群 1
│   ├── 可用区 B (us-east-1b) — 数据中心群 2
│   ├── 可用区 C (us-east-1c) — 数据中心群 3
│   └── ...更多 AZ
├── Region: 亚太东京 (ap-northeast-1)
│   ├── 可用区 A
│   ├── 可用区 B
│   └── 可用区 C
├── ...更多 Region
│
└── 边缘节点（600+，遍布全球各大城市）
    ├── 北京
    ├── 上海
    ├── 东京
    ├── 纽约
    ├── 伦敦
    └── ...
```

**记住一个口诀**：
- **用 AZ 实现高可用**（一个机房挂了，另一个顶上）
- **用 Region 实现灾难恢复**（一个地区出大问题，切换到另一个地区）
- **用边缘节点实现低延迟**（内容推到用户身边）

---

## 一个真实的故障案例

2017 年 2 月 28 日，AWS 美国东部（us-east-1）的 S3 存储服务发生了大规模故障，持续约 4 小时。

受影响的知名服务包括：Slack、Trello、Quora，甚至 AWS 自己的状态页面都挂了（因为状态页面也托管在 S3 上）。

**教训**：
- 即使是 AWS 自己的服务也会出故障
- 不要把所有东西都放在一个 Region
- 关键业务要考虑多 Region 部署
- 你的架构要能容忍底层服务的故障

---

## 今天的小测验

1. 如果你的用户主要在日本，应该选哪个 Region？
2. 为什么一个 Region 要有多个可用区？用你自己的话解释。
3. 边缘节点和 Region 有什么区别？它们各自解决什么问题？
4. 如果你只把应用部署在一个可用区，会有什么风险？

---

## 延伸阅读

- [AWS 全球基础设施地图（可交互）](https://aws.amazon.com/about-aws/global-infrastructure/)
- [AWS 2017 年 S3 故障复盘报告](https://aws.amazon.com/message/41926/)

---

## 明天预告

明天我们动手了！注册 AWS 账户、设置安全保护、配置账单告警。正式踏入 AWS 的大门。我会一步步带你操作，确保你不会踩坑（尤其是不会被意外扣费）。