AWS存储选型：S3、EBS与EFS核心差异与实战指南

第一次在AWS控制台里同时看到S3、EBS、EFS这三种存储服务的时候，我盯着页面上的英文缩写和一堆性能参数发了好一会儿呆。它们看起来都是“存数据的地方”，名字也都带Storage或者File的味儿，但仔细一琢磨又不知道到底该选哪一个。后来我陆续做过几个真实项目，也踩过不少坑，才慢慢把它们之间的差异摸透。这篇东西我想把S3对象存储、EBS块存储、EFS文件存储这三者的核心差异、底层逻辑、选型思路和实操方法一次性讲清楚，尤其适合刚接触AWS、准备考SAA认证、或者在公司里做架构设计时拿不准存储选型的朋友。

一句话总结我的体会：这三种存储不是“谁替代谁”的关系，而是三种完全不同的“数据使用方式”。你只要搞明白数据是要“挂载成硬盘”“通过URL访问”还是“共享给多台机器读写”，选型就已经对了一半。剩下的就是性能、成本和可用性层面的权衡。

1. 先分清楚：对象、块、文件到底在说啥

1.1 用生活场景给三种存储画个像

我经常用三个生活类比来给团队里的小朋友讲清楚这三种存储，这比直接解释协议和术语要直观得多。

S3对象存储，你可以把它理解成一个云端的超大仓库。你往仓库里扔东西，仓库管理员会给你一个唯一的取货凭证（URL），以后你凭这个凭证就能取回东西。仓库内部怎么摆、怎么分区、有没有货架，你完全不用操心，也用不着进去翻箱倒柜。仓库容量几乎是无限的，你也不用预付租金，放多少货算多少钱。

EBS块存储，它更像电脑里的那块硬盘。它不能独立存在，必须“插”在某台EC2主机上才能用。你拿到一块EBS之后，要先分区、格式化，才能往里写文件。它的特点是延迟极低、性能稳定，数据库这类对IOPS和延迟敏感的应用就吃这一套。但它有一个硬限制：一块普通的EBS通常只能插在同一台服务器上，不能随手拔下来插到另一台机器上直接共享。

EFS文件存储，最接近公司的共享文件夹。它在云端搭了一个文件系统，你可以让很多台EC2同时挂载它，大家读写的是同一份文件，A机器写入的数据，B机器马上能看到。它保留了目录层级、文件名、权限这些传统文件系统的概念，所以很多传统应用不需要改代码就能直接使用。

这三种存储背后对应的是IT行业非常有名的三大存储范式：块存储、文件存储、对象存储。AWS只是把这三类范式做成了云服务，分别叫EBS、EFS和S3。所以搞懂了这三兄弟，你不仅搞懂了AWS，也搞懂了整个存储行业的三个基本方向。

1.2 为什么AWS要同时提供三种存储

有人可能会问，能不能只保留一种最便宜的，把另外两个砍掉？答案是不能，因为不同的应用程序对数据的读写方式完全不同。

举个例子，像MySQL这类数据库，它需要把数据精确地读写到磁盘的某个块上，要求极低的延迟和极高的IOPS，这种场景只有块存储能接得住。而像图片、视频、备份文件这种海量非结构化数据，动辄几百TB甚至PB级别，如果用块存储去存，成本会直接爆掉，而且根本没有那么多服务器可以挂载。这时候对象存储的无限容量和极低单价就成了最佳选择。到了多台服务器共享一份配置、共享一批待处理文件这类场景，文件存储的POSIX语义和共享能力又是块存储和对象存储无法替代的。

所以AWS把三种存储同时摆在那里，不是功能重复，而是因为它们各自有明确的适用区间。真实的云上架构里，三者通常是组合出现的，很少说一个应用只用一种存储就搞定一切。下一章我从原理层面把这三种存储切开看，你就能理解它们的差异为什么会存在。

2. 从原理层面拆开看：底层到底有什么不同

2.1 S3对象存储的内在逻辑

S3的完整叫法是Simple Storage Service，但这个名字容易让人误以为它很“简单”。它的数据模型其实是一个扁平的键值命名空间。

整个S3由三个层级组成：桶（Bucket）、对象（Object）、键（Key）。桶是存储容器，对象是存储单元，键是对象的唯一标识。你可能在网上看到类似s3://my-bucket/images/photo.jpg这样的路径，其实images/photo.jpg并不是真实的目录层级，它只是键名里带了一个斜杠字符。S3内部并不存在“目录”这个实体，所有对象都平铺存储在桶里，那个斜杠只是给人眼看的。

这个设计带来的最大好处是扩展性极强，因为键值结构天然适合海量数据，不存在单目录文件数上限，也不用维护复杂目录树。而坏处也很明显，就是S3没法像文件系统那样直接“追加写”或“修改一部分”，你想改一个对象，通常只能整体覆盖。

S3的持久性在云存储里是出名的强悍，标准存储的设计持久性高达99.999999999%，也就是常说的11个9。这个数字的背后是AWS会自动把你的对象在同一个区域内的多个可用区里存多份副本。即便某个可用区整体宕机，你的数据依然可以从其他副本恢复。

还有一个容易被忽略的点：S3在2020年12月之后已经支持强一致性。以前S3是最终一致性，写入后立刻读可能读到旧数据，现在读后写、列出现有对象、覆盖写后读取都是强一致的，这让很多依赖S3做数据主存储的应用变得更加可靠。

S3本身不是一个挂载型存储，它通过REST API提供访问。你可以用控制台、SDK、AWS CLI，也可以直接用HTTP工具请求对象URL。正因为通过URL就可以访问，S3特别适合做静态网站托管、CDN回源、数据湖、备份归档这类场景。

S3还有一个很大的看点，就是存储类别分层。标准S3存热数据，S3-IA存不常访问但需要快速取回的数据，Glacier家族存归档冷数据。每一层的价格不一样，取回时间也不一样。只要配置好生命周期策略，数据就能在热、温、冷之间自动流转，这是成本控制的重要手段。

2.2 EBS块存储的内在逻辑

EBS的全称是Elastic Block Store，它本质上就是一块云上的虚拟硬盘。EBS卷通过AWS的网络基础设施挂载到EC2实例上，操作系统看到的是一块真实的块设备，你可以对它分区、格式化、创建文件系统，使用体验和本地硬盘没有任何区别。

块存储的最大特点是低延迟和高性能。EBS卷通过专用的网络协议挂载，数据按固定大小的块进行读写，非常适合数据库、消息队列这类对随机IOPS要求极高的应用。EBS卷有很多类型，简单分成四类：

• gp3：通用型SSD，默认3000 IOPS和125 MB/s吞吐，适合大多数普通业务。
• io2/io1：极速型SSD，专门为数据库设计，可以预置很高的IOPS。
• st1：吞吐优化HDD，适合日志存储、数据仓库这类顺序读写为主、对成本敏感的场景。
• sc1：冷数据HDD，是EBS里最便宜的类型，适合不常访问的数据。

选错类型最常见的后果就是性能瓶颈或者成本浪费。比如你用gp3跑高并发数据库，IOPS不够就会频繁产生慢查询；反过来你用io2存一堆三个月没动过的备份文件，性能是够，但费用会让人肉疼。

EBS有一个非常容易被误解的点：块存储绑定了可用区。也就是说，一块EBS卷只能在创建它的那个可用区里挂载到EC2上，跨可用区是挂不上的。如果你想让数据跨可用区备份，只能通过快照功能，把卷保存成S3里的快照，再用快照在别的可用区创建新卷。

耐久性方面，EBS靠的是在单个可用区内部的多副本冗余。但单AZ的容灾能力毕竟有限，所以最佳实践通常是定期给EBS做快照，快照存放在S3里，这样即便整个可用区挂掉，你也能用快照在其他可用区把数据恢复出来。这里顺带提醒一句：EC2实例停止或者甚至释放后，它的EBS根卷默认还是会保留并继续计费，很多人账单爆炸就是栽在这上面。

2.3 EFS文件存储的内在逻辑

EFS的全称是Elastic File System，它提供的是一种托管的网络文件系统，基于NFSv4.1协议对外提供服务。你只需要创建文件系统，然后在VPC里配置好挂载目标，就能让多台EC2用标准的mount命令把它挂载成本地目录。

EFS和EBS一个非常大的区别是：它天然支持多可用区。EFS文件系统默认把数据冗余存储在同一区域内的多个可用区，即使某个可用区故障，挂载在其他可用区的EC2还能继续通过EFS读写文件。这让EFS成了在云上构建高可用共享存储的首选。

EFS的容量不是预先分配的，它随数据量自动扩展，从几KB到PB级别都不用你操心扩盘。这一点跟EBS非常不一样，EBS是个固定大小的硬盘，空间用完得手动扩容，EFS则完全没有“分区满了”这个概念。

性能上面，EFS提供了两种性能模式：**通用模式（General Purpose）**适用于延迟敏感的Web服务和内容管理，Max I/O模式能支撑更高的吞吐和IOPS，但会有稍高的延迟。在吞吐配置上也分两种：一种是Bursting模式，你存的文件越多，积累的吞吐额度就越高，适合流量有波动的场景；另一种是Provisioned吞吐模式，你可以直接指定吞吐量，适合稳定高负载场景。

因为EFS保留了文件系统的完整语义，包括文件锁、权限、目录结构，所以很多传统应用几乎不需要改造就能直接迁移到云上，比如内容管理系统、大数据分析工作区、Web服务器共享目录、媒体处理中间文件存储等。它还支持EFS生命周期管理，可以把不常访问的文件自动转移到成本更低的IA存储层，省钱效果也很明显。

2.4 三种存储模式的核心对照表

把三者的关键特性放到一张表里看，差异会非常直观。

这是一张我反复用了很久的速查表。实际选型的时候，第一个问题不是“哪个便宜”，也不是“哪个性能强”，而是“我的数据要被谁来用、用什么方式访问”。把这个回答清楚，三选一基本就出来了。

3. 实战场景里的选型：什么时候用哪个

3.1 典型场景速查清单

拿我遇到过的真实业务场景来举例，你可以直接对号入座。

静态资源托管——比如网站的图片、CSS、JS、用户上传的PDF。这类文件量大、访问并发高、单个文件很少修改，直接放S3再套一层CloudFront做CDN，是最经典也最省钱的方案。S3本身支持静态网站托管，域名、证书、加速路径配置好以后，整套流程非常顺畅。

数据库存储——MySQL、PostgreSQL、MongoDB这类数据库，底层需要高性能、低延迟的块存储。在AWS上开RDS其实底层就是EBS，如果是自建数据库跑在EC2上，那一定要给它挂一块合适类型的EBS卷，而不是把数据库目录放在S3或者EFS上，否则性能和一致性都会出大问题。

多台服务器共享目录——比如你在多台EC2上部署了同一个Web应用，大家需要读取同一份配置、共享同一批上传文件，或者跑大数据分析时多台机器要处理同一批中间结果。这种跨机器共享文件的场景就用EFS，它能保证各台服务器看到同一份数据，写入后立即可见。

备份与归档——数据库备份、日志、环境快照这类低频访问的数据，首选S3，并且配合生命周期策略自动转冷。比如日志先放S3标准层存30天，然后转IA存90天，再之后转Glacier长期归档，全程不需要人工干预。

3.2 一个Web应用的存储组合案例

有个项目我印象很深，是一个用户量增长很快的内容社区。整套架构里有Nginx负载均衡、多台应用服务器、MySQL数据库，用户会上传头像和图片。

这套架构里三种存储全都用上了：每台应用服务器的操作系统和程序目录装在EBS上，保证系统盘性能稳定且可以随时创建快照；MySQL数据库的数据文件放在专门的EBS高IOPS卷上，保证事务性能；用户上传的头像和图片全部放到S3桶里，桶前面套CloudFront加速；而应用服务器之间需要共享的临时缓存目录则挂载了同一个EFS，多台机器读写一致，不会出现A机器写文件B机器看不到的情况。

这个例子很典型地说明了一个事实：在真实云架构里，三种存储往往是合作的，而不是互斥的。你在做存储选型时，脑子里要装的不只是“哪个存数据”，而是“这份数据在整个系统中扮演什么角色”。

3.3 成本模型和选型误区

成本是选型时绕不开的槛。三种存储的计费模型差异非常大，我经常见到有人因为没搞懂计费逻辑，月账单翻了好几倍。

S3的费用的主要构成是存储容量费、请求费、数据取回费和数据传输费。其中存储费是阶梯式的，不同存储类别单价不一样；请求费按PUT/GET这类操作的次数计费；取回费存在于IA和Glacier这类冷存储层，你取回数据时会产生额外费用。对于“写入频繁但读取少”的数据，如果长期放在标准层，存储费用会非常难看，所以S3生命周期策略一定要尽早配置。

EBS的费用主要看预置容量和预置性能。它不像S3那样按实际使用量计费，而是你创建多大容量、预置多少IOPS，就按那个规格一直收费，哪怕这块盘使用率只有1%，费用还是一分不少。这意味着块存储不适宜用来存放大量不活跃的冷数据，否则成本和资源浪费会很严重。

EFS的计费按实际存储量再加上吞吐模式来算。它的优势在于自动弹性扩展，没有预置容量的概念，存得少就付得少，存得多就付得多。它还提供了生命周期管理，自动把不活跃文件转到价格更低的IA层，适合数据量会起伏、不想手动管理容量的场景。

选型误区里最常见的有三种：一是用S3挂载成“本地盘”给传统应用直接读写，搞出一堆性能和一致性问题；二是把海量冷数据放在EBS上，容量费和IOPS费用双重浪费；三是在一个账号里无脑复制堆服务，没有结合数据的访问频率和共享需求做区分。

4. 实操演示：用CLI把这三种存储跑起来

光讲概念不练手，记忆永远不牢靠。下面我以AWS CLI为例，把三种存储从创建到使用的完整流程走一遍，你跟着操作基本就能有个直观体感。

4.1 环境准备

在开始之前，你需要在本地或者EC2上安装好AWS CLI，并通过aws configure配置好访问密钥和默认区域。配置完成后，先敲一个命令验证一下是否连通：

bash复制aws sts get-caller-identity

如果返回了Account和Arn信息，说明CLI已经就绪。平时我用AWS CLI比较多，是因为它能精确控制参数，也方便写脚本批量操作，比在网页控制台里点点点高效得多。

4.2 用S3做一个对象存储的完整操作

先创建一个桶，桶名得全局唯一，这个在S3里是比较特殊的要求：

bash复制aws s3 mb s3://my-example-bucket-2025

然后把本地一个测试文件上传到桶里：

bash复制aws s3 cp ./hello.txt s3://my-example-bucket-2025/data/hello.txt

再列出来看对象是否上传成功：

bash复制aws s3 ls s3://my-example-bucket-2025/data/

通过SDK或者CLI上传的对象，会附带元数据、版本ID等信息。如果你开启了桶的版本控制，那么同一个key每次覆盖写都会生成新版本，这个能力很适合用来做数据保护。

4.3 用EBS创建一块块存储并挂载

创建EBS卷时最关键的参数是可用区和卷类型。注意卷只能在指定的可用区内使用：

bash复制aws ec2 create-volume --availability-zone us-east-1a --size 20 --volume-type gp3

返回结果里会带一个VolumeId，拿这个ID把卷挂载到同一可用区的一台EC2实例上：

bash复制aws ec2 attach-volume --volume-id vol-xxxxxxxx --instance-id i-xxxxxxxx --device /dev/sdf

挂载完成后，进入EC2实例内部，在操作系统层面把这块空盘格式化并挂载到目录：

bash复制sudo mkfs -t xfs /dev/xvdf
sudo mkdir /mnt/data
sudo mount /dev/xvdf /mnt/data

到这里，一块EBS块存储就正式被你的EC2使用起来了。整个过程跟给物理服务器插硬盘再格式化差不多，只不过完全是通过API和命令来操作的。日常生产环境，我建议把EBS卷大小留出一定余量，并为关键数据配置自动快照策略。

4.4 用EFS创建文件系统并让多台EC2挂载

创建EFS文件系统需要一个创建令牌，用来防止重复创建：

bash复制aws efs create-file-system --creation-token my-efs-2025 --region us-east-1

拿到FileSystemId之后，需要在VPC的子网里创建挂载目标：

bash复制aws efs create-mount-target --file-system-id fs-xxxxxxxx --subnet-id subnet-xxxxxxxx --security-group sg-xxxxxxxx

创建完挂载目标后，在EC2实例上用标准的NFS方式挂载：

bash复制sudo mkdir /mnt/efs
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-xxxxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs

注意这个挂载命令有几个参数是用来优化性能和可靠性的，比如读写的rsize和wsize设置为1MB，挂载超时时间timeo设置为600秒，配合hard参数，哪怕瞬时网络波动也不会产生IO错误。你在第二台EC2上用同样的命令挂载同一个文件系统，然后在一台机器上写文件，另一台机器立刻就能看到，这种感觉是用EBS完全体会不到的。

5. 高频问题与避坑实战：这些坑我替你先踩了

5.1 六个我常被问到的存储疑难

EBS卷可以跨可用区挂载吗？ 不可以，EBS卷绑定创建时的可用区，同区域但不同可用区也挂不上。想跨可用区，必须先用该卷创建快照，再基于快照在目标可用区新建一块卷。

S3有11个9，那是不是所有数据都应该放S3？ 不是，S3的持久性确实惊人，但它不提供传统数据库所需的低延迟块级访问。你总不能让MySQL直接读写S3上的文件，性能和语义都不支持。持久性再高，也得匹配对应的工作负载。

实例存储（Instance Store）和EBS有什么区别？ 实例存储在部分EC2机型上自带，但它不具备持久性，实例停止或底层主机维护时数据会丢失。EBS则是独立于实例生命周期存在的持久化存储，实例释放以后卷还在，可以继续保留或者创建快照。

EFS挂载连接不上，怎么办？ 多半是安全组规则没放行NFS端口，EFS基于2049端口通信，安全组的入站规则必须允许来自目标EC2的TCP 2049流量。另外，挂载目标必须和EC2在同一个VPC和网络环境内。

能不能把S3挂载成文件夹来用？ 有一些工具如S3FS、Mountpoint for Amazon S3能做，但要清楚这不是S3的原生用法。S3FS会有缓存和一致性问题，性能一般，不适合跑数据库或对一致性要求高的应用；Mountpoint更适合大数据和机器学习场景下的只读居多的高吞吐访问。

为什么EC2停着没跑，EBS还在扣费？ 因为EBS是独立的计费资源，它不跟随实例的生命周期自动释放。如果你创建实例时没有勾选“实例释放时删除根卷”，停止或释放实例后EBS卷依然存在、依然计费。解决办法是定期清理不需要的卷，同时利用快照保留长期冷数据。

5.2 几个让我记忆深刻的失败案例

我第一次用AWS做项目时，为了图省事把一台EC2上所有数据都放在了实例存储里，结果机房维护导致底层主机重启，实例数据全部丢失，那感觉真的像被泼了一盆冷水。从那以后，我给自己定了一条铁律：实例存储只放临时数据，任何要长期保存的东西必须放EBS、S3或EFS。

还有一个教训来自S3版本控制。我为某个桶开启了版本控制防止误删，但没有配置任何生命周期清理策略。用户反复上传同名文件，历史版本越积越多，月底看到账单时我整个人是懵的。后来我学乖了，凡是开启版本控制的桶，一定同时配上生命周期规则，让旧版本在一段时间后自动删除或转冷归档。

EFS的Bursting额度也是容易忽略的点。Bursting模式虽然允许短时间内突破基线吞吐，但额度是有限且会累积消耗的。有次数据迁移任务一次性跑大量文件，把Bursting额度耗尽，文件系统吞吐瞬间掉到基线值，整个迁移过程拖了将近三倍时间。现在遇到这种大流量任务，我会提前切到Provisioned吞吐模式，或者做时间规划错峰处理。

快照和镜像的区别也经常有人搞混。EBS快照是某个时间点的卷数据备份，它存在S3里，可以用来恢复卷；AMI镜像则是一个完整的启动模板，包含操作系统、配置和应用，可以直接用来启动新的EC2。平时做数据备份重点用快照，做环境和实例复制重点用AMI，两者定位完全不一样。

5.3 避坑速查表

6. 综合实战：一个内容平台的存储设计

6.1 需求拆解

假设你现在要为一个图片分享平台设计存储方案。需求大概是：用户会上传图片原图，平台要把图片做多尺寸压缩和转码，多台EC2实例需要协同处理这些图片，最终生成的图片要提供给Web前端和App展示，还要保证用户上传的元数据能高效检索，并且整体成本要控制在合理范围。

6.2 三份存储的分配逻辑

这个场景里，我会这样分配三种存储：

用户上传的原图和转码后的成品图全部放在S3桶里。原图上传后直接进入S3，通过事件通知触发Lambda或者EC2转码任务；转码后生成的缩略图也写回S3。S3的价格便宜、容量够大，前端展示可以直接用CloudFront回源S3，同时S3的版本控制和生命周期策略能在铅笔误删和数据过期之间找到平衡。

元数据检索这块用数据库，数据库引擎如果自建在EC2上，那就挂一块EBS高性能卷，比如gp3或者io2。图片的URL、尺寸、上传时间这类需要频繁查询修改的数据，就应该放在低延迟的块存储上面，让数据库跑得动在线业务。

多台EC2共同处理图片时，原始文件和中间结果需要被所有机器读取。这里把待处理队列或者共享的工作目录放到EFS上，每台EC2挂载同一个EFS文件系统，A机器下载压缩脚本，B机器就能立即看到。这种共享文件系统的特性可以避免重复拷贝文件导致的存储浪费和数据不一致。

S3负责“存得下”，EBS负责“跑得快”，EFS负责“共享得了”，三者各司其职，恰好就是这套架构里最合理的存储搭配。

6.3 选型检查清单

每次给新项目定存储方案时，我都会快速过一遍检查清单，你也可以直接拿去用：

1. 这份数据需要挂载成磁盘吗？需要就选EBS，不需要就考虑S3或EFS。
2. 需要同时给多台机器共享访问吗？需要就选EFS，单机访问则EBS更合适。
3. 数据量会非常大且很少修改吗？比较大且偏静态，就优先S3。
4. 对延迟和IOPS的要求高吗？高延迟敏感就选EBS，且根据负载选gp3还是io2。
5. 数据需要跨可用区甚至跨区域容灾吗？S3和EFS天然跨AZ，EBS必须依赖快照。
6. 成本敏感度怎么样？S3配合生命周期最便宜，EBS适合高性能有保障的核心业务，EFS适合动态容量且需要共享的场景。
7. 现有应用是否强依赖文件系统接口？如果是，EFS是最平滑的迁移路径。

我自己在实际做存储选型时，最常说的一句话就是：先别纠结参数，先想清楚数据怎么被使用。把使用方式定下来，选型难度瞬间就降了一半。剩下的性能、成本和可用性，都是可以在使用方式确定后继续调优的环节。

最后再分享一个实操小技巧：如果你中了不止一套方案，比如S3加EFS都行，那就做个小规模的压力测试或者成本模拟。AWS有个Simple Monthly Calculator，可以粗略估算不同存储组合的月度费用，结合读写频率数据，很快就能看出哪种组合更划算。存储选型是一个动态的过程，不要指望一次性选对永不调整，实际情况里业务增长和访问模式变了，存储方案也得跟着调整。