跳到主要内容

C2-04-存储体系

本章目标：承接 C2-03 的应用运行平台，从“程序运行以后，数据到底放在哪里”开始，建立 AWS Storage 的完整基础模型。重点理解 Object Storage、Block Storage、File Storage、Ephemeral Local Storage、Hybrid Storage、Backup 的差异，并系统掌握 Amazon S3、Amazon EBS、EC2 Instance Store、Amazon EFS、Amazon FSx、AWS Storage Gateway、AWS Backup 之间的定位与选择方法。

1-本章在整套-AWS-知识体系中的位置​

前面几章解决的是：代码在哪里运行？例如：EC2、Container、ECS / EKS、Fargate、Lambda；但是只要 Application 真正开始运行，就一定会产生数据。例如 GlobalShop：商品图片、订单附件、用户上传文件、日志、系统盘、数据库磁盘、共享文件、备份、归档、大数据文件；这些数据不能全部用同一种存储方式保存。AWS Storage 的第一层思维应该是：

Storage
│
├── Object Storage
│   └── Amazon S3
│
├── Block Storage
│   └── Amazon EBS
│
├── File Storage
│   ├── Amazon EFS
│   └── Amazon FSx
│
├── Local Ephemeral Storage
│   └── EC2 Instance Store
│
├── Hybrid Storage
│   └── AWS Storage Gateway
│
└── Backup Management
    └── AWS Backup

不要先背产品名。先理解：我到底想把数据当成什么来使用？是：Object？、Disk / Block？、File System？、Local Temporary Disk？、Backup？这才是存储题真正的入口。

2-本章与-719-道题库的关系​

按照本项目此前统一使用的粗略统计方法：

在“题干 + 全部选项”中，只要某个服务在一道题里出现，就记 1 次；同一道题重复出现仍只记 1 次。

大致曝光度为：

服务 / 概念题库粗略曝光
Amazon S383
Amazon EBS21
AWS Storage Gateway17
Amazon EFS16
Amazon FSx11
AWS Backup7
Snow Family14 左右

注意：曝光度、≠、正确答案次数；例如某个服务可能经常作为干扰项出现。因此这些数字主要用于判断：哪些概念需要优先掌握；而不是用来背：

出现最多
→ 一定选它

其中 Amazon S3 是整个 CLF-C02 最核心的服务之一。

3-★★★★★-存储基础概念​

3.1-Storage-是什么？​

Storage； 中文：存储；最基本的含义：把数据保存下来，、以后还能再读取。应用程序运行时可能使用：CPU、Memory；但是：Memory；通常不是长期保存数据的地方。例如：

Node.js Process
      │
      ├── Memory
      │   └── 当前请求、对象、变量
      │
      └── Persistent Storage
          └── 应用重启以后仍需要存在的数据

所以：

Compute
解决：
代码在哪里运行

Storage
解决：
数据放在哪里

3.2-Persistent-是什么？​

Persistent； 中文：持久的 / 持久化的；Persistent Storage；=；持久化存储；意思不是：数据永远不会丢；而是：数据的生命周期、不应该仅仅绑定在某个 Application Process、或者某一次临时运行上。例如：EC2 Stop、Application Restart、Container Restart；之后仍然希望数据存在，就需要考虑：Persistent Storage

3.3-Ephemeral-是什么？​

Ephemeral； 中文：临时的、短暂存在的；在云计算中经常看到：Ephemeral Storage；表示：这种存储和某个计算资源的生命周期关系较强，、不应该把它当成长期可靠的数据保存位置。EC2 Instance Store 就属于典型例子。

3.4-Durability、Availability、Performance-不要混在一起​

存储最容易混淆的三个维度是：Durability、Availability、Performance

3.4.1-Durability​

Durability；=；持久性 / 数据耐久性；核心问题：我的数据会不会丢？例如：一个文件保存十年、是否仍然能可靠存在？

3.4.2-Availability​

Availability；=；可用性；核心问题：我现在想读取数据，、能不能访问？所以：

Durability
→ 数据还在不在

Availability
→ 现在能不能访问

这两个不能混成一个概念。

3.4.3-Performance​

Performance；=；性能；存储性能常见维度：Latency、Throughput、IOPS

3.5-Latency、Throughput、IOPS​

3.5.1-Latency​

Latency；=；延迟；例如：

发出一次读请求
↓
多久得到数据

3.5.2-Throughput​

Throughput；=；吞吐量；例如：每秒可以持续传输多少 MB / GB 数据；适合思考：大文件、视频、批处理、大数据

3.5.3-IOPS​

IOPS；=；Input/Output Operations Per Second、每秒输入输出操作次数；更接近：一秒能执行多少次存储 I/O；数据库、随机读写等场景经常关注 IOPS。CLF-C02 不要求计算复杂存储性能公式。需要建立的是：

Latency
→ 一次操作多快

Throughput
→ 单位时间能搬多少数据

IOPS
→ 单位时间能做多少次 I/O

3.6-AWS-Storage-最重要的四种数据模型​

先不看 AWS 服务名。传统计算机系统里最重要的三种持久存储抽象：Block、File、Object；再加一个：Local Ephemeral；于是：

Storage
│
├── Block
├── File
├── Object
└── Local Ephemeral

后面所有 AWS 服务都可以先放进这张图。

4-★★★★★-Block-File-Object数据模型​

4.1-Block-Storage-是什么？​

Block Storage；=；块存储；它给操作系统的感觉更接近：一块磁盘、一个 Volume、一个 Block Device；例如 Linux 可能看到：/dev/nvme0n1；然后你自己：Partition、Format、Create File System、Mount；概念：

Block Storage
      │
      ▼
Operating System
      │
      ▼
File System
      │
      ▼
Files

AWS 中最典型：Amazon EBS

4.2-File-Storage-是什么？​

File Storage；=；文件存储；它直接提供：Directory、File、Path；例如：/products/images/a.jpg、/shared/config/app.json、/home/user/report.xlsx；客户端通常通过文件系统协议访问。例如：NFS、SMB；AWS 中：Amazon EFS、Amazon FSx；都属于这一类。

4.3-Object-Storage-是什么？​

Object Storage；=；对象存储；它不是把数据暴露成传统磁盘块，也不是主要让操作系统把它当成普通本地目录。它把数据保存为：Object；通常包含：Object Data、+、Key、+、Metadata；AWS 最典型：Amazon S3；例如：

Bucket:
globalshop-product-images

Key:
products/2026/09/iphone-17/front.jpg

Object:
真正的图片数据

4.4-Object、File、Block-的直觉对比​

模型最像什么AWS 代表服务
Block一块硬盘 / VolumeEBS
File网络共享文件夹EFS / FSx
Object海量对象仓库S3

可以粗略记：

要“磁盘”
→ Block

要“共享目录”
→ File

要“海量文件对象仓库”
→ Object

但是不要把它理解成绝对技术边界。例如：S3 里当然可以保存“文件内容”；只是：S3 的访问模型是 Object Storage，、不是传统 POSIX 文件系统。

5-★★★★★-Amazon-S3对象存储​

5.1-★★★★★-Amazon-S3​

[CURRENT-IN-SCOPE]；正式名称：Amazon Simple Storage Service；简称：Amazon S3；中文通常称：Amazon 简单存储服务、Amazon 对象存储

5.2-为什么叫-S3？​

名字：Simple、Storage、Service；三个单词都以：S；开头。所以：

S + S + S
= S³
= S3

这和：EC2、Elastic Compute Cloud；的命名思路类似。

5.3-S3-为什么存在？​

传统情况下，如果公司要保存：10 TB 商品图片、100 TB 日志、1 PB 历史订单导出、大量备份、视频、数据湖文件自己管理文件服务器会遇到：磁盘容量规划、RAID、服务器扩容、硬盘故障、备份、文件服务器集群、跨机房复制、生命周期管理；而对象存储希望把问题变成：

把 Object 放进去
↓
需要时按 Key 取回来

让用户不再管理：底层磁盘、具体文件服务器、RAID 阵列、单台 Storage Server；这就是 S3 的核心价值之一。

5.4-S3-最重要的三个概念​

Bucket、Object、Key；关系：

Amazon S3
   │
   ▼
Bucket
   │
   ├── Object
   │    ├── Key
   │    ├── Data
   │    └── Metadata
   │
   └── Object

5.5-Bucket-是什么？​

Bucket；中文常翻译：存储桶；它是 S3 中组织 Object 的顶层逻辑容器。例如：globalshop-product-images、globalshop-order-exports、globalshop-access-logs；可以粗略理解：

S3 Service
   │
   ├── Bucket A
   ├── Bucket B
   └── Bucket C

注意：Bucket、不是 EC2 的 Disk。

5.6-Object-是什么？​

Object；=；对象；例如 GlobalShop 中：product-12345.jpg、manual.pdf、invoice-20260905.pdf、access-log-2026-09-05.gz、backup-file.tar；这些都可以作为 Object 保存。

5.7-Key-是什么？​

Key；=；对象键、Object Key；可以理解成：Object 在 Bucket 中的唯一名称 / 标识；例如：products/12345/main.jpg；这里：products/12345/main.jpg；是 Key。看起来像：目录 / 子目录 / 文件名；但从 S3 核心对象模型来说，它本质上仍然是：Key

5.8-S3-为什么不是传统-File-System？​

传统 File System：

/
├── products/
│   └── 12345/
│       └── main.jpg

用户习惯：open()、read()、write()、seek()、rename()；S3 更接近：PUT Object、GET Object、DELETE Object、LIST Objects；所以：S3、≠、传统本地硬盘文件系统；这对考试很重要。如果题目说：EC2 需要一个 Block Volume；一般考虑：EBS；如果说：多个 Linux Server 共享 NFS File System；一般考虑：EFS；如果说：海量图片、备份、日志、静态内容；一般首先考虑：S3

5.9-GlobalShop-中-S3-最典型的用途​

商品图片：

Merchant
   │
   ▼
Upload Image
   │
   ▼
Amazon S3
   │
   ▼
CloudFront
   │
   ▼
Global Users

例如：globalshop-product-images；保存：JPEG、PNG、WebP、Video、PDF Manual；CloudFront 再把这些内容缓存到全球 Edge。完整 CDN 会在 C2-07 详细讲。

5.10-为什么商品图片适合-S3？​

因为商品图片通常：数量巨大、不需要当块设备、不需要多个服务器同时修改同一个 POSIX 文件、主要通过 Object 读写、需要高 Durability、适合和 CDN 组合；所以：S3、+、CloudFront；是非常典型的静态内容架构。

5.11-★★★★★-S3-Durability​

S3 的核心关键词之一：high durability；AWS 对多个 S3 Storage Class 设计的对象耐久性目标是：99.999999999%也就是常说：11 nines、11 个 9考试如果出现：highly durable object storage；Amazon S3 是最典型答案。但不要误解：

Durability
=
Availability

二者仍然是不同指标。

5.12-S3-Storage-Class-是什么？​

Storage Class；=；存储类别；同样是 S3 Object，因为：访问频率、恢复速度、可用性要求、数据保存期限、成本要求；不同，可以选择不同 Storage Class。核心思想：

经常访问
→ 通常愿意为即时访问和较高可用性支付更多存储成本

很少访问
→ 可以降低存储成本

长期归档
→ 可以进一步降低存储成本，
   但读取可能有等待时间或额外取回成本

5.13-★★★★★-S3-Standard​

正式名称：S3 Standard；定位：通用、频繁访问、低延迟、高吞吐；适合：网站内容、移动应用数据、常用图片、数据分析输入、活跃业务数据；GlobalShop：

正在销售商品的主图片
→ S3 Standard

5.14-★★★★-S3-Intelligent-Tiering​

Intelligent；=；智能；Tiering；=；分层；S3 Intelligent-Tiering 的核心问题是：我不知道数据以后到底访问得频繁还是不频繁。例如：某些商品图片突然爆火、某些图片几个月没人访问、之后又突然重新热卖；访问模式不可预测。此时希望：AWS 根据访问模式、自动把对象移动到更合适的访问层；所以题目看到：unknown access pattern、changing access pattern、automatically optimize storage cost

优先想到：S3 Intelligent-Tiering

5.15-★★★★-S3-Standard-IA​

IA；=；Infrequent Access、低频访问；完整名称：S3 Standard-Infrequent Access；适合：不经常访问、但需要时仍希望快速获得；例如：历史报表、较老但仍可能随时下载的订单附件、灾备数据；核心：低频、+、需要毫秒级访问；而不是深度归档。

5.16-★★★-S3-One-Zone-IA​

One Zone；=；一个 Availability Zone；它和 Standard-IA 的一个重要区别：

Standard-IA
→ 设计为跨多个 AZ

One Zone-IA
→ 数据保存在单个 AZ

因此价格可以更低，但适合：可以重新生成的数据、非关键副本、不要求跨 AZ 韧性的数据；不要把关键的唯一业务数据只因为“便宜”就机械选择 One Zone-IA。

5.17-Glacier-在当前-S3-中应该怎么理解？​

这是旧资料里很容易形成错误印象的地方。不要粗暴记成：

Amazon Glacier
=
一个和 S3 完全分离的普通存储服务

当前学习更准确的方式是：

S3 Storage Classes
│
├── S3 Glacier Instant Retrieval
├── S3 Glacier Flexible Retrieval
└── S3 Glacier Deep Archive

也就是：Glacier 类存储层级、属于当前 S3 长期、低频访问 / 归档体系的重要组成部分。

5.18-★★★-S3-Glacier-Instant-Retrieval​

Instant Retrieval；=；即时取回；适合：长期很少访问、但真正访问时仍希望快速读取；例如：医疗影像归档、媒体素材归档、历史资产；虽然低频，但不能接受每次取数据都等很久。

5.19-★★★★-S3-Glacier-Flexible-Retrieval​

Flexible Retrieval；=；灵活取回；用于：归档数据；核心特征：不是主要为了频繁在线访问、可以接受取回存在等待、以换取更低的存储成本；题目出现：archive、rarely accessed、retrieval can wait；就要进入 Glacier 思路。

5.20-★★★★-S3-Glacier-Deep-Archive​

Deep Archive；=；深度归档；定位：非常长期、极低访问频率、极低存储成本导向；例如：法规要求保留 7 年、审计档案、长期合规记录、历史备份；如果题目强调：几年几乎不访问、主要为了长期保留、最低存储成本；通常要重点考虑：S3 Glacier Deep Archive

5.21-★★-S3-Express-One-Zone​

当前 S3 还存在：S3 Express One Zone；它是：单 AZ、高性能、低延迟、面向非常频繁数据访问；的 S3 Storage Class。但对于 CLF-C02 学习优先级，先掌握：Standard、Intelligent-Tiering、Standard-IA、One Zone-IA、Glacier Instant Retrieval、Glacier Flexible Retrieval、Glacier Deep Archive；更加重要。不要因为它名字里有：

One Zone；就把它和：One Zone-IA；混为一谈。

5.22-S3-Storage-Class-决策直觉​

频繁访问
   │
   ├── 一般通用
   │      └── S3 Standard
   │
   └── 极高性能、单 AZ 特定场景
          └── S3 Express One Zone

访问模式未知 / 经常变化
   │
   └── S3 Intelligent-Tiering

低频，但需要快速访问
   │
   ├── 跨 AZ 韧性
   │      └── S3 Standard-IA
   │
   └── 可接受单 AZ
          └── S3 One Zone-IA

非常低频 / 归档
   │
   ├── 仍需即时访问
   │      └── Glacier Instant Retrieval
   │
   ├── 可等待取回
   │      └── Glacier Flexible Retrieval
   │
   └── 超长期深度归档
          └── Glacier Deep Archive

这张图比死背价格更重要。

5.23-★★★★-S3-Lifecycle​

Lifecycle；=；生命周期；S3 Lifecycle 解决：数据随着时间变老，、应该自动怎么处理？例如 GlobalShop：

0～30 天
S3 Standard

30～180 天
S3 Standard-IA

180 天以后
Glacier Flexible Retrieval

7 年以后
Delete

可以配置：Lifecycle Rule；自动完成：Transition、Expiration

5.24-Transition-与-Expiration​

Transition；=；转换存储类别；例如：

Standard
↓
Standard-IA
↓
Glacier

Expiration；=；到期删除；例如：

日志只保留 365 天
↓
365 天后删除

考试看到：automatically move old objects、reduce storage cost over time、archive after N days、delete after N days；重点考虑：S3 Lifecycle

5.25-★★★★-S3-Versioning​

Versioning；=；版本控制；例如同一个 Key：config/app.json；可能先后上传不同版本。Versioning 可以保留：Version 1、Version 2、Version 3；它特别适合降低：误覆盖、误删除；带来的风险。但：Versioning、≠、完整 Backup 策略的全部内容；后面还会看到 AWS Backup。

5.26-S3-Replication-简要理解​

Replication；=；复制；常见概念：Same-Region Replication、Cross-Region Replication；核心作用可以包括：跨 Region 副本、合规、灾备、数据位置需求；完整 Multi-Region 与 DR 会在后面的架构章节继续展开。这里先建立：

Versioning
→ 同一个对象的多个版本

Replication
→ 在其他 Bucket / Region 维护副本

Backup
→ 独立的数据保护与恢复策略

不要把三者混成同一个词。

6-★★★★★-EBS与Instance-Store​

6.1-★★★★★-Amazon-EBS​

[CURRENT-IN-SCOPE]；正式名称：Amazon Elastic Block Store；简称：Amazon EBS； 中文：Amazon 弹性块存储

6.2-为什么叫-Elastic-Block-Store？​

Elastic；=；弹性；Block；=；块；Store；=；存储；它强调：给 EC2 提供可配置、持久化的 Block Storage Volume。所以：

EC2
解决计算

EBS
解决 EC2 所需要的持久化块存储

6.3-EBS-Volume-是什么？​

Volume； 中文：卷、存储卷；可以理解：一块通过网络提供给 EC2 的虚拟块设备；例如：

EC2 Instance
     │
     ├── Root EBS Volume
     │
     └── Data EBS Volume

操作系统看到后可以：Format、Mount、Read / Write；因此：EBS、更像云中的磁盘；而不是：S3 Object Bucket

6.4-EBS-为什么和-S3-完全不同？​

S3：

Application
   │
   ▼
S3 API
   │
   ▼
Bucket / Object

EBS：

EC2
 │
 ▼
Block Device
 │
 ▼
File System
 │
 ▼
File

所以：

问题S3EBS
数据模型ObjectBlock
最像对象仓库磁盘
常见使用图片、备份、日志EC2 系统盘、数据盘
是否直接给 OS 当普通块设备否是

6.5-★★★★★-EBS-与-Availability-Zone​

EBS Volume 是：Availability Zone 级资源；例如：

EC2
AZ-A
 │
 ▼
EBS
AZ-A

不能把某个 AZ-A 的 EBS Volume，当成：AZ-B 的普通本地磁盘；直接随便挂载。这和：S3；的使用模型非常不同。

6.6-EBS-Persistence​

EBS 的重要价值：Persistent Block Storage；例如：

EC2 Stop
↓
EBS Volume 仍可以保留
↓
再次 Start
↓
继续读取原来的数据

但这里还要看：Delete on Termination；等具体配置。CLF 层级最需要的直觉：

EBS
→ Persistent

Instance Store
→ Ephemeral

6.7-★★★★-EBS-Snapshot​

Snapshot；=；快照；EBS Snapshot 用于：对 EBS Volume 做时间点备份；概念：

EBS Volume
    │
    ▼
Snapshot
    │
    ▼
未来恢复出新的 EBS Volume

快照由 AWS 管理，底层利用 AWS 的存储基础设施保存，但用户不是去某个普通 S3 Bucket 里直接操作 Snapshot 文件。

6.8-Snapshot-的典型用途​

例如 GlobalShop 后台服务器：

EBS Volume
当前系统
   │
   ▼
Snapshot
   │
   ├── 恢复
   ├── 创建新 Volume
   └── 灾备 / 迁移

如果准备做高风险系统升级：

先 Snapshot
↓
升级
↓
出现问题
↓
从 Snapshot 恢复

这是典型使用方式。

6.9-EBS-Volume-Type-需要学到什么程度？​

EBS 有不同 Volume Type。CLF-C02 不要求像 Solutions Architect 那样深入记：每种 IOPS 上限、每种 Throughput 数值、复杂配额；但要知道选型逻辑：

General Purpose SSD
→ 通用工作负载

Provisioned IOPS SSD
→ 高 IOPS、延迟敏感、数据库类工作负载

Throughput Optimized HDD
→ 大吞吐、顺序访问

Cold HDD
→ 更低频、吞吐导向

重点：不是所有 Disk Workload 都需要同一种 EBS。

6.10-★★★★-EC2-Instance-Store​

正式叫：EC2 Instance Store； 中文：EC2 实例存储；核心：Local、+、Ephemeral

6.11-Instance-Store-为什么快？​

概念上：

EC2 Host
│
├── Compute
└── Local Storage
      │
      ▼
Instance Store

它和宿主机本地硬件联系更紧密。因此适合：Temporary Data、Cache、Buffer、Scratch Data、可重新生成的数据

6.12-Instance-Store-为什么不能当长期数据库备份？​

因为：数据生命周期、与底层 Instance / Host 生命周期关系更强；如果发生特定生命周期变化或底层硬件问题，数据可能消失。所以：唯一一份重要数据、长期订单记录、唯一数据库备份；不应该只放：Instance Store

6.13-Instance-Store：Reboot、Stop、Terminate-的准确区分​

这是前面项目中特别要求修正的一个点。不要背：

EC2 一重启
→ Instance Store 一定丢

这是错误的。更准确：

Reboot
→ 通常仍在同一 Host
→ Instance Store 数据通常保留

而：Stop / Start、Hibernate、Terminate、某些底层 Host 故障 / 生命周期变化；会导致原 Instance Store 数据不能继续保留。因此考试学习应该记：

Instance Store
=
Ephemeral Local Storage

不是：
“任何 Restart 都会丢”

6.14-★★★★★-EBS-vs-Instance-Store​

维度EBSInstance Store
类型Network-attached Block StorageHost-local Ephemeral Storage
持久性持久化临时
Stop / Start可保留 Volume原本地数据不能依赖
Snapshot支持 EBS Snapshot不按 EBS Snapshot 模型使用
适合系统盘、持久数据盘Cache、Temporary、Scratch

核心：

要持久
→ EBS

要本地临时高速空间
→ Instance Store

7-★★★★★-EFS与FSx文件存储​

7.1-★★★★-Amazon-EFS​

[CURRENT-IN-SCOPE]；正式名称：Amazon Elastic File System；简称：Amazon EFS； 中文：Amazon 弹性文件系统

7.2-为什么叫-Elastic-File-System？​

Elastic；=；容量可以随数据变化自动扩展 / 缩减；File System；=；文件系统；它解决的核心问题：多个 Compute 资源、需要共享一个真正的文件系统。

7.3-EFS-为什么存在？​

假设 GlobalShop 有：EC2 #1、EC2 #2、EC2 #3；它们都需要读取：/shared/product-import/、/shared/reports/、/shared-media/；如果每台 EC2 都有自己的 EBS：

EC2 #1 → EBS #1
EC2 #2 → EBS #2
EC2 #3 → EBS #3

这些并不是天然的：同一个共享文件系统；于是需要：EFS

7.4-EFS-的典型架构​

              Amazon EFS
                  ▲
          ┌───────┼───────┐
          │       │       │
          │       │       │
        EC2      EC2      EC2
        AZ-A     AZ-B     AZ-C

多个 Compute 可以挂载同一个 EFS。AWS 当前还支持多种计算环境访问 EFS，例如：EC2、ECS、EKS、Lambda、Fargate

7.5-NFS-是什么？​

NFS；=；Network File System、网络文件系统；EFS 支持：NFSv4；所以对 Linux / Unix 风格应用来说，它更像：共享网络目录；例如：/mnt/shared

7.6-EFS-Regional-与-One-Zone​

当前 EFS 有：Regional、One Zone

7.6.1-Regional​

数据冗余存储在：同一 Region 的多个 AZ；适合更高可用性与耐久性要求。

7.6.2-One-Zone​

数据位于：单个 AZ；成本更低，适合能够接受单 AZ 风险的工作负载。这和 S3 的：One Zone-IA；虽然名字都出现 One Zone，但它们是不同服务、不同存储模型。

7.7-★★★★★-EFS-vs-EBS​

这是考试非常常见的判断。EBS：Block Storage、更像磁盘、通常围绕 EC2 Volume、AZ 级；EFS：File Storage、NFS、多个 Compute 可共享、可使用 Regional 多 AZ 文件系统、容量弹性；所以：

一个 EC2 需要系统盘
→ EBS

多个 Linux EC2 共享文件
→ EFS

7.8-EFS-vs-S3​

EFS：File System Semantics、NFS、Directory / File；S3：Object Storage、Bucket / Object / Key、API；如果应用代码明确依赖：POSIX-style file access、NFS mount、shared directory；EFS 更自然。如果需求是：海量图片、日志、对象、备份、数据湖文件；S3 通常更自然。

7.9-★★★-Amazon-FSx​

[CURRENT-IN-SCOPE]；Amazon FSx；是一组：Fully Managed File System；服务。它不是一个单一文件系统引擎。当前主要家族包括：FSx for Windows File Server、FSx for Lustre、FSx for NetApp ONTAP、FSx for OpenZFS；对于 CLF-C02，最重要的是先知道：

FSx
=
AWS 托管的专业文件系统家族

7.10-★★★★-FSx-for-Windows-File-Server​

正式名称：Amazon FSx for Windows File Server；核心：Managed Windows File Server、+、SMB

7.11-SMB-是什么？​

SMB；=；Server Message Block；是一种常见的：网络文件共享协议；Windows 企业环境中非常常见。所以题目看到：Windows、SMB、Microsoft Active Directory、Windows file shares；首先考虑：FSx for Windows File Server

7.12-题库典型：SMB-文件存储​

题库中有一道非常典型的题：需求：fully managed、highly reliable、scalable file storage、SMB protocol；选项里有：S3、EFS、FSx for Windows File Server、EBS；这里真正的定位不是：哪个都能“存文件”；而是：SMB、+、Windows File Server；直接指向：FSx for Windows File Server

7.13-★★★-FSx-for-Lustre​

Lustre；是一种：High-Performance File System、高性能文件系统；典型场景：HPC、Machine Learning、Video Processing、Financial Modeling、Large-scale Data Processing；HPC；=；High Performance Computing、高性能计算

7.14-FSx-for-Lustre-与-S3​

FSx for Lustre 可以与 S3 数据仓库集成。典型：

大量 Data
   │
   ▼
Amazon S3
   │
   ▼
FSx for Lustre
   │
   ▼
High-performance Compute

核心区分：

S3
→ durable object repository

FSx for Lustre
→ high-performance file system for compute workloads

所以不要看到：S3 Integration；就认为两者是同一个服务。

7.15-★★-FSx-for-NetApp-ONTAP-与-OpenZFS​

对于 CLF-C02：不需要深入学它们的企业存储管理细节。只需知道：

FSx for NetApp ONTAP
→ 托管 NetApp ONTAP 文件存储

FSx for OpenZFS
→ 托管 OpenZFS 文件系统

它们体现的是：AWS 不只提供一个通用 File Storage，、也可以提供企业熟悉的特定文件系统技术。

7.16-EFS-vs-FSx​

可以这样理解：

EFS
→ AWS 原生、弹性的 NFS 文件存储
→ Linux / cloud-native shared file system 场景很典型

FSx
→ 托管特定成熟文件系统技术
→ Windows SMB、Lustre、NetApp ONTAP、OpenZFS 等

题目如果没有特殊协议 / 技术要求，不要因为：FSx 听起来更高级；就自动选 FSx。需求决定答案。

8-★★★★★-Storage-Gateway-Backup与Snow-Family​

8.1-★★★★-AWS-Storage-Gateway​

[CURRENT-IN-SCOPE]；正式名称：AWS Storage Gateway；核心关键词：Hybrid Storage；Hybrid；=；混合；即：On-Premises、+、AWS Cloud Storage

8.2-为什么需要-Storage-Gateway？​

很多企业不会一天之内把所有应用改成：S3 API、EFS、Cloud-native application；本地系统可能几十年都在使用：NFS、SMB、iSCSI、Tape；但企业又想让后端数据进入 AWS。于是：

On-Premises Application
        │
        ▼
Traditional Storage Protocol
        │
        ▼
Storage Gateway
        │
        ▼
AWS Storage

Storage Gateway 就像：本地传统存储世界、和 AWS 云存储之间的桥梁

8.3-Storage-Gateway-三个核心方向​

当前学习重点：

Storage Gateway
│
├── Amazon S3 File Gateway
├── Volume Gateway
└── Tape Gateway

历史 / 当前状态特殊：Amazon FSx File Gateway；后面单独说明。

8.4-★★★★-Amazon-S3-File-Gateway​

核心：

本地应用看到：
NFS / SMB File Share

后端：
Object 存入 Amazon S3

架构：

On-Premises App
      │
      │ NFS / SMB
      ▼
S3 File Gateway
      │
      ▼
Amazon S3

这非常重要。

8.5-为什么-File-Gateway-不等于-EFS？​

EFS：AWS managed NFS File System；File Gateway：Gateway、把传统文件协议、桥接到 AWS Storage Backend；例如题目说：On-premises application、must continue using NFS、store objects in S3；重点：NFS、+、S3 backend、+、Hybrid；应考虑：S3 File Gateway；而不是：EFS

8.6-题库典型：NFS-访问-S3​

题库中存在典型需求：使用 NFS 协议、存取 Amazon S3 中的对象；这类题真正考：

传统 File Protocol
      ↓
Gateway
      ↓
S3 Object Storage

所以：S3 File Gateway；比：EFS、FSx、EBS；更符合需求。

8.7-★★★-Volume-Gateway​

Volume Gateway 面向：Block Storage；而不是：File Share；客户端常通过：iSCSI；访问。iSCSI；=；Internet Small Computer Systems Interface；可以粗略理解成：通过 IP 网络提供 Block Storage

8.8-Volume-Gateway-的两个经典模式​

常见概念：Cached Volumes、Stored Volumes

8.8.1-Cached-Volumes​

核心：主要数据放 AWS、本地保留常用数据 Cache；概念：

On-Prem
Local Cache
     │
     ▼
AWS Backend

8.8.2-Stored-Volumes​

核心：完整主数据保留本地、同时异步备份到 AWS；CLF-C02 通常不会要求深入部署细节，但要理解：

File Gateway
→ File Protocol

Volume Gateway
→ Block / iSCSI

8.9-★★★-Tape-Gateway​

Tape；=；磁带；很多传统企业备份系统使用：Physical Tape Library；例如：

备份软件
↓
磁带
↓
异地仓库

Tape Gateway 提供：Virtual Tape Library、VTL；VTL；=；Virtual Tape Library、虚拟磁带库；让已有备份软件继续使用“磁带”逻辑，但底层进入 AWS 存储体系。

8.10-FSx-File-Gateway-的当前状态​

[UPDATED]；[LEGACY]；[QUESTION-BANK]；旧题和旧资料里可能看到：Amazon FSx File Gateway；当前 AWS 官方状态是：不再向新客户提供；已有客户仍可以继续使用。所以教材需要同时知道：

历史题：
可能考 FSx File Gateway

当前 AWS：
新客户不再新开此服务

不要把历史题的产品状态直接当成 2026 年当前状态。

8.11-★★★-AWS-Backup​

[CURRENT-IN-SCOPE]；正式名称：AWS Backup；名字很直接：

Backup
=
备份

它的核心价值不是：发明一种新的 Block / File / Object Storage；而是：集中管理多个 AWS 服务的备份策略

8.12-为什么需要-AWS-Backup？​

如果企业同时有：EBS、RDS、DynamoDB、EFS、FSx、其他支持的 AWS Resources；分别手动管理：Backup Schedule、Retention、Backup Policy、Recovery Point、Compliance；会越来越复杂。AWS Backup 提供：Centralized Backup Management

8.13-AWS-Backup-的核心思路​

AWS Resources
│
├── EBS
├── RDS
├── DynamoDB
├── EFS
└── ...
      │
      ▼
   AWS Backup
      │
      ├── Backup Plan
      ├── Schedule
      ├── Retention
      └── Recovery

重点：

AWS Backup
=
集中备份编排 / 治理服务

8.14-Snapshot-与-AWS-Backup-不要混淆​

EBS Snapshot：EBS 自己的快照能力；RDS Snapshot：RDS 自己的快照能力；AWS Backup：跨多个支持服务、统一组织备份策略；所以：

Snapshot
是具体资源的数据保护机制之一

AWS Backup
是集中备份管理层

8.15-Backup、Replication、High-Availability-不一样​

这是非常重要的架构思想。

8.15.1-High-Availability​

组件坏了、业务尽量继续运行

8.15.2-Replication​

维护数据副本

8.15.3-Backup​

保留可恢复的历史恢复点；例如：数据库误删 100 万条订单；如果复制是实时的：错误、也可能立即复制到副本；因此：Replication、≠、Backup；同样：Multi-AZ、≠、Backup

8.16-Snow-Family-在本章的位置​

Snow Family；包括历史和当前不同设备 / 服务形态，核心属于：大量数据传输、Migration / Transfer、Edge；而不是日常在线 Storage Access 的主服务。所以本章只建立关系：

On-Premises 大量数据
       │
       ▼
Snow Family
       │
       ▼
AWS
       │
       └── S3 等

完整 Snow Family 放在：C2-14-迁移数据传输与混合云

8.17-Storage-Gateway-vs-Snow-Family​

Storage Gateway：持续连接、Hybrid Storage、本地应用长期通过 Gateway 使用 AWS Storage；Snow Family：大量数据搬迁、网络传输不现实 / 不够快时、可使用专用设备或相关能力；直觉：

“长期桥接”
→ Storage Gateway

“搬大量数据”
→ Snow Family

9-★★★★★-GlobalShop存储架构与选型​

9.1-GlobalShop-完整存储层​

现在可以把 GlobalShop 的 Storage 画出来：

                         GlobalShop
                              │
        ┌─────────────────────┼─────────────────────┐
        │                     │                     │
        ▼                     ▼                     ▼
   Application             Shared Files         Objects
      EC2/ECS                  │                     │
        │                      ▼                     ▼
        ▼                     EFS                   S3
       EBS              / shared import       product images
 system / data disk      report files         logs / exports
        │                                            │
        │                                            ▼
        │                                      S3 Lifecycle
        │                                            │
        │                                      Glacier Classes
        │
        ├── temporary high-speed data
        │        │
        │        ▼
        │  Instance Store
        │
        └── backup policy
                 │
                 ▼
             AWS Backup

企业本地还有：

On-Premises
     │
     ▼
Storage Gateway
     │
     ▼
S3 / AWS Storage

9.2-一个商品图片的完整生命周期​

例如：

商品图片上传
      │
      ▼
S3 Standard
      │
      ▼
CloudFront
      │
      ▼
全球用户访问

半年后商品下架：

S3 Standard
      │
      │ Lifecycle
      ▼
S3 Standard-IA
      │
      ▼
Glacier

多年后：

Retention 到期
      │
      ▼
Expiration
      │
      ▼
Delete

这就是：Object Storage、+、Lifecycle、+、Cost Optimization；的完整思路。

9.3-一个-EC2-Server-的存储生命周期​

AMI
 │
 ▼
Launch EC2
 │
 ├── Root EBS
 │
 ├── Data EBS
 │
 └── Instance Store

其中：

EBS
→ 持久化

Instance Store
→ 临时本地数据

需要备份：

EBS
 │
 ▼
Snapshot / AWS Backup

9.4-多个-Application-Server-共享文件​

如果：EC2 #1、EC2 #2、EC2 #3；都需要：/shared/upload；可以：

              EFS
               ▲
       ┌───────┼───────┐
       │       │       │
      EC2     EC2     EC2

而不是：每台 EC2 各放一份、然后靠人工同步

9.5-Windows-企业共享目录​

需求：Windows Server、SMB、Active Directory、Enterprise File Share；优先思路：FSx for Windows File Server

9.6-HPC-高性能文件处理​

需求：大量计算节点、高吞吐、高性能文件系统、ML / HPC、S3 数据集；优先思路：FSx for Lustre

9.7-S3、EBS、EFS、FSx-最核心对比​

服务存储模型最典型关键词
S3ObjectBucket、Object、海量对象、Durability
EBSBlockEC2 Disk、Volume、Snapshot
EFSFileNFS、共享 Linux 文件系统、Elastic
FSxFileWindows SMB / Lustre / ONTAP / OpenZFS
Instance StoreLocal EphemeralTemporary、Scratch、Host-local

9.8-Storage-Gateway、AWS-Backup-的定位​

服务核心问题
Storage Gateway本地传统存储协议如何连接 AWS Storage
AWS Backup多个 AWS 资源的备份如何集中管理

它们不是：S3 / EBS / EFS 的“同类磁盘”；而是在更高一层解决：Hybrid、Backup Management

9.9-高频选型决策树​

需要存储数据
   │
   ├── 是 Object？
   │      │
   │      └── S3
   │
   ├── 是 EC2 的 Block Disk？
   │      │
   │      └── EBS
   │
   ├── 是临时本地磁盘？
   │      │
   │      └── Instance Store
   │
   ├── 多个 Linux Compute 共享 NFS？
   │      │
   │      └── EFS
   │
   ├── Windows SMB？
   │      │
   │      └── FSx for Windows File Server
   │
   ├── HPC / Lustre？
   │      │
   │      └── FSx for Lustre
   │
   ├── On-Prem + NFS/SMB + S3？
   │      │
   │      └── S3 File Gateway
   │
   ├── On-Prem Block / iSCSI？
   │      │
   │      └── Volume Gateway
   │
   ├── Virtual Tape？
   │      │
   │      └── Tape Gateway
   │
   └── 多服务集中备份？
          │
          └── AWS Backup

10-★★★★★-高频错误与关键词​

10.1-常见错误-1：看到“文件”就选-EFS​

错误：“题目说 file，、所以一定 EFS。”；不对。因为：S3 也可以保存文件内容、FSx 也是文件存储、Storage Gateway File Gateway 也处理文件协议；真正要看：Object?、NFS?、SMB?、Hybrid?、Shared File System?

10.2-常见错误-2：S3-是云硬盘​

错误：

S3
=
EC2 的网络硬盘

不准确。S3 是：Object Storage；EC2 的典型持久 Block Disk：EBS

10.3-常见错误-3：EBS-可以天然给多台-EC2-当共享-NFS​

EBS：Block Storage；EFS：Shared File Storage；即使某些 EBS 类型 / 场景存在更高级的多挂载能力，CLF 的基础选型题看到：多个 Linux Server、共享文件系统、NFS；仍应首先想到：EFS

10.4-常见错误-4：Glacier-=-永远不能访问​

不对。Glacier 类 Storage Class 仍然是：可恢复的数据；区别在于：访问频率、取回方式、取回时间、成本；例如：Glacier Instant Retrieval；本身就强调：Instant Retrieval

10.5-常见错误-5：Multi-AZ-就不需要-Backup​

不对。例如：

Application Bug
↓
删除数据

HA 副本可能同步这个错误。Backup 解决：回到历史恢复点；所以：High Availability、Replication、Backup；是三个不同问题。

10.6-常见错误-6：Storage-Gateway-是一个网络-Gateway​

AWS 中很多服务名都有：Gateway；例如：Internet Gateway、NAT Gateway、Transit Gateway、API Gateway、Storage Gateway；Storage Gateway 的核心领域是：Storage / Hybrid；不是：VPC Internet Routing；看到 Gateway 不能只背一个词。必须先看：题目想把什么连接到什么？

10.7-高频英文关键词​

10.7.1-Object-Storage​

对象存储

10.7.2-Block-Storage​

块存储

10.7.3-File-Storage​

文件存储

10.7.4-Persistent​

持久化

10.7.5-Ephemeral​

临时的

10.7.6-Durability​

持久性 / 数据耐久性

10.7.7-Availability​

可用性

10.7.8-Throughput​

吞吐量

10.7.9-IOPS​

每秒 I/O 操作次数

10.7.10-Infrequent-Access​

低频访问

10.7.11-Archive​

归档

10.7.12-Lifecycle​

生命周期

10.7.13-Snapshot​

快照

10.7.14-File-System​

文件系统

10.7.15-NFS​

Network File System、网络文件系统

10.7.16-SMB​

Server Message Block、服务器消息块 / Windows 常见文件共享协议

10.7.17-Hybrid-Storage​

混合存储

10.7.18-Backup​

备份

10.8-题目看到哪些词应该想到什么？​

highly durable object storage
→ S3

bucket / object
→ S3

unknown access pattern
→ S3 Intelligent-Tiering

archive / long-term retention
→ Glacier Storage Classes

EC2 persistent block volume
→ EBS

snapshot of EC2 disk
→ EBS Snapshot

temporary local storage
→ Instance Store

shared NFS file system
→ EFS

SMB / Windows file share
→ FSx for Windows File Server

HPC / Lustre
→ FSx for Lustre

on-premises NFS/SMB to S3
→ S3 File Gateway

iSCSI / block hybrid storage
→ Volume Gateway

virtual tape
→ Tape Gateway

centralized backup policy
→ AWS Backup

10.9-本章服务不要和后面数据库混淆​

一个非常重要的边界：Storage、≠、Database；例如：S3、能保存 JSON 文件；不等于：S3 是 DynamoDB；EBS：可以作为数据库底层磁盘；不等于：EBS 自己就是关系数据库；数据库还会提供：Data Model、Query、Index、Transaction、Consistency、Database Engine；所以：

Storage
解决“数据放在哪”

Database
进一步解决“数据按什么模型组织、查询和修改”

这就是下一章要进入的内容。

11-★★★★★-本章总结与官方资料​

11.1-本章核心知识压缩​

如果最后只保留一张图：

                        AWS Storage
                            │
      ┌─────────────┬───────┼──────────┬─────────────┐
      │             │       │          │             │
      ▼             ▼       ▼          ▼             ▼
    Object         Block    File       Local        Hybrid
      │             │       │          │             │
      ▼             ▼       ├── EFS    ▼             ▼
      S3            EBS     └── FSx Instance Store Storage Gateway
      │
      ├── Standard
      ├── Intelligent-Tiering
      ├── Standard-IA
      ├── One Zone-IA
      └── Glacier Classes

                Cross-service Backup
                       │
                       ▼
                    AWS Backup

11.2-最重要的七句话​

1. S3 = Object Storage。
2. EBS = EC2 常用 Persistent Block Storage。
3. Instance Store = Local Ephemeral Storage。
4. EFS = Elastic Shared NFS File System。
5. FSx = Managed Specialized File Systems。
6. Storage Gateway = On-Premises 与 AWS Storage 的 Hybrid Bridge。
7. AWS Backup = 跨多个支持服务的集中备份管理。

11.3-AWS-官方资料​

Amazon S3：AWS 官方文档：What is Amazon S3?；S3 Storage Classes：

AWS 官方文档：Understanding and managing Amazon S3 storage classes；S3 Lifecycle：

AWS 官方文档：Managing your storage lifecycle；Amazon EBS：AWS 官方文档：Amazon EBS volumes

EBS Snapshots：AWS 官方文档：Amazon EBS snapshots；EC2 Instance Store：

AWS 官方文档：Amazon EC2 instance store；Amazon EFS：AWS 官方文档：What is Amazon Elastic File System?

Amazon FSx for Windows File Server：AWS 官方文档：What is FSx for Windows File Server?；Amazon FSx for Lustre：

AWS 官方文档：What is Amazon FSx for Lustre?；AWS Storage Gateway：

AWS 官方文档：What is AWS Storage Gateway?；AWS Backup：

AWS 官方文档：What is AWS Backup?

11.4-下一章​

本章解决了：数据保存在哪里？但是 GlobalShop 还有更复杂的问题。例如订单：order_id、user_id、product_id、price、status、created_at；我们不仅要：把这些字节保存下来；还要：按 user_id 查订单、按 order_id 查详情、更新 status、保证交易一致性、建立索引、做高可用、扩展读写能力；这已经不是单纯 Storage。于是下一章进入：C2-05-数据库与缓存体系.md；核心主线：

Database
│
├── Relational
│   ├── Amazon RDS
│   └── Amazon Aurora
│
├── NoSQL
│   └── Amazon DynamoDB
│
├── In-Memory Cache
│   └── Amazon ElastiCache
│
├── Document
│   └── Amazon DocumentDB
│
└── Graph
    └── Amazon Neptune