一、先看整体：这张图在表达什么？
这是一张 典型的 EFS + EC2 跨可用区（Multi-AZ）架构图，核心思想只有一句话：
EFS 是一个跨 AZ 的共享文件系统，通过在每个 AZ 放一个“挂载入口（Mount Target）”，让 EC2 就近访问同一个文件系统。
二、关键组件逐个解释（对着图看）
1️⃣ VPC（最外层紫色框）
EFS 和 EC2 必须在同一个 VPC
EFS 不是公网服务
访问 EFS 全部走 VPC 内部私网 IP
结论：没有 VPC，就没有 EFS + EC2
2️⃣ 多个 Availability Zone（AZ 1 / AZ 2 / AZ 3）
每个 AZ 内都有：
一个或多个 Subnet
EC2 实例
一个 EFS Mount Target
📌 这是高可用的关键
EFS 本身是区域级服务，但访问入口是 AZ 级的
3️⃣ Subnet（10.0.1.0/24、10.0.2.0/24、10.0.3.0/24 …）
每个 subnet 属于一个 AZ
EC2 实例运行在 subnet 中
EFS 的 Mount Target 也必须放在 subnet 里
📌 注意
EFS 不是“挂到 EC2 上”，而是“通过 subnet 里的 Mount Target 被访问”
4️⃣ Amazon EC2（橙色）
每个 EC2：
有私有 IP（如 10.0.1.30、10.0.4.14）
通过 NFS 协议挂载 EFS
不同 AZ 的 EC2：
看见的是 同一个文件系统
就像访问同一个共享目录
📌 这点非常重要
EFS = 多台 EC2 同时读写同一份数据
5️⃣ Mount Target（绿色虚线框，关键点）
这是整张图最容易被忽略、但最关键的东西。
每个 AZ 至少一个 Mount Target
每个 Mount Target：
是一个 ENI（弹性网卡）
有一个 私有 IP
属于某个 subnet
EC2 挂载 EFS 时：
- 实际连的是 本 AZ 的 Mount Target
📌 为什么要这样设计？
| 原因 | 解释 |
|---|---|
| 就近访问 | EC2 不跨 AZ 走流量 |
| 高可用 | 某个 AZ 挂了，其他 AZ 不受影响 |
| 可扩展 | AZ 数量 = 挂载入口数量 |
6️⃣ Amazon EFS（底部绿色）
一个 EFS 文件系统
后端数据：
自动分布
自动复制
AWS 托管
用户完全看不到底层存储细节
📌 你只关心：
挂载 → 用 → 不用管容量
三、EC2 实际是“怎么用 EFS 的”？
① 创建 EFS 文件系统
选 VPC
创建 Mount Target（每个 AZ 一个）
② 配置 Security Group（非常重要）
Mount Target 的 SG：
- 允许 TCP 2049（NFS）
EC2 的 SG：
- 能访问 Mount Target SG
📌 否则会出现：
挂载命令不报错，但一直卡住
③ 在 EC2 上挂载（示意）
sudo mount -t nfs4 fs-xxxx:/ /mnt/efs
或使用 AWS 推荐方式（带 DNS）
④ 使用方式（像本地目录一样）
cd /mnt/efs
touch test.txt
AZ1 的 EC2 创建文件
AZ3 的 EC2 立刻能看到
四、为什么不用 EBS，而要用 EFS？
需求 EBS EFS
| 需求 | EBS | EFS |
|---|---|---|
| 多 EC2 同时访问 | ❌ | ✅ |
| 自动扩容 | ❌ | ✅ |
| 文件系统 | ✅ | ✅ |
| 跨 AZ 高可用 | ❌ | ✅ |
| 典型用途 | 数据库 | 共享文件 |
📌 一句话结论
EBS 是“独占硬盘”，EFS 是“共享网盘”
五、这张图背后的“架构设计思想”
1️⃣ 解耦计算与存储
EC2 随时增减
数据不动
2️⃣ AZ 级容灾
任意一个 AZ 出问题
其他 AZ 仍能访问同一数据
3️⃣ 云原生共享存储
不需要 NAS
不需要自己做文件同步
六、典型使用场景（考试 & 实战）
Web 服务器共享静态资源
多实例应用共享配置文件
CI/CD 构建目录
用户 home 目录
容器持久化存储（EKS + EFS）
七、一句话终极总结
Amazon EFS 通过在每个可用区提供 Mount Target，把一个区域级的共享文件系统，安全、高可用地“送到”每一台 EC2 面前，让多实例像访问本地目录一样访问同一份数据。
