亚马逊云企业认证 AWS亚马逊云磁盘类型对比

各位在AWS上挂过EBS卷的兄弟姐妹们，有没有过这种体验：

——明明选了“高性能”io1卷，数据库查询还是慢得像在煮泡面；
——测试环境用gp2跑得好好的，上线后突然IO告警红得刺眼；
——花了大价钱买st1冷存储，结果发现它连日志轮转都卡顿……

别急着怀疑人生，也别急着给AWS客服打电话（他们大概率会回你一句：“请检查您的实例类型和队列深度”——翻译过来就是：“锅不在我们这，但也不在你那，中间那段黑盒您自己照照镜子。”）

今天咱们就掀开AWS磁盘的底裤，把gp3、gp2、io1/io2、st1、sc1这五位“卷界爱豆”拉出来挨个盘问：谁是真·性能怪兽？谁是性价比之王？谁表面光鲜实则暗藏玄机？谁适合当冷数据仓库里的佛系咸鱼？——不讲概念，只讲人话；不列公式，只说实战。

第一幕：先搞清一个底层真相——EBS不是硬盘，是“云硬盘服务”

亚马逊云企业认证 很多人一上来就对比“吞吐量”“IOPS”，却忘了最根本的一点：EBS压根不是插在服务器主板上的物理硬盘，而是通过网络挂载的远程块存储。它的性能受三重枷锁制约：
① 卷自身规格（比如你买的gp3到底配了多少IOPS）；
② 实例的EBS带宽上限（比如t3.micro最多只能吃掉75MB/s，你挂个1000MB/s的io2也是白搭）；
③ 网络链路质量（尤其跨可用区挂载时，延迟直接翻倍）。

所以——别迷信卷型号，先看你的实例能不能“喂饱”它。

第二幕：五大卷型逐个扒皮

▶ gp3：新晋顶流，理性之选

2020年横空出世，直接干掉了老前辈gp2。优势就仨字：自由、透明、不坑爹。
• IOPS和吞吐量可独立调整（gp2是绑定死的，容量越大IOPS越高，但你可能根本不需要）；
• 最低3000 IOPS起步，最高16万，吞吐最高1000 MB/s；
• 按需付费：IOPS 0.005美元/1000单位/小时，吞吐0.04美元/GB/月——账单清晰得像超市小票。

适合谁？90%的通用场景：Web服务器、中小数据库、CI/CD构建盘、容器持久化存储。一句话：你要稳定、要灵活、不想半夜被IOPS告警惊醒，选gp3准没错。

▶ gp2：退休老干部，谨慎接盘

已进入维护模式，新账户甚至默认不显示。它的逻辑是“容量决定性能”：每GB提供3 IOPS，最大10000 IOPS（即3334GB以上才封顶）。听起来很美？错！
• 小于1TB的卷，IOPS随容量线性增长——但1TB卷只有3000 IOPS，而gp3同容量起步就是3000，还能往上加；
• 更致命的是“Burst Balance”机制：低于基准IOPS时攒积分，高负载时透支。一旦积分耗尽，IOPS暴跌到基准值——你数据库正跑高峰，它突然降速，场面一度十分尴尬。

劝退理由：除非你在维护十年老系统且迁移成本极高，否则别碰。就像坚持用诺基亚砸核桃——能用，但没必要。

▶ io1/io2：性能特种兵，专治不服

io1是老牌企业级卷，io2是它的Plus版（支持更高耐久性、更低延迟、更强一致性）。共同特点是：IOPS硬保底，不靠“攒积分”。
• io1：最高64000 IOPS（需搭配i3.metal等高端实例）；
• io2：分Block Express（io2 Block Express）和普通io2，前者单卷最高256K IOPS+4GB/s吞吐，后者最高64K；
• 价格贵出一截：io1约0.125美元/IOPS/月，io2略高。

适合谁？OLTP数据库（PostgreSQL/MySQL主库）、高频交易系统、实时分析引擎。但注意：必须配够实例带宽（比如c5.4xlarge才能喂饱64K IOPS），否则性能全浪费在排队上。

▶ st1：冷数据搬运工，速度与价格的折中体

定位“吞吐密集型、访问不频繁”的场景，比如大数据ETL、数据湖原始层、媒体转码缓存。
• 基于HDD，随机读写弱（<100 IOPS），但顺序读写猛（500MB/s吞吐）；
• 价格极低：约0.045美元/GB/月；
• 关键限制：单卷最大16TB，且IOPS随容量增长（但天花板仅500 IOPS）。

血泪教训：千万别拿st1跑WordPress后台——用户上传一张图，PHP要读配置、写日志、查数据库、生成缩略图……全是随机IO，你会看到“504 Gateway Timeout”比呼吸还勤快。

▶ sc1：真正的冷存储咸鱼

比st1更冷，价格再砍一刀（0.015美元/GB/月），但性能也更佛系：
• 最大吞吐250MB/s，IOPS基本忽略不计（<25）；
• 专为“一年访问不超过几次”的归档数据设计，比如法规备份、旧项目源码、离职员工邮箱镜像。

灵魂拷问：你真需要把它挂进EC2当盘用？还是直接丢S3 Glacier更省心？

第三幕：避坑指南——那些文档里不会写的潜规则

✅ gp3扩容不中断，但gp2扩容后必须reboot才能生效（文档小字第87行写着，但没人告诉你）；
✅ 所有卷的“预置IOPS”在实例重启后自动继承，但如果你用AMI创建新实例，记得检查卷属性——有些AMI会把IOPS重置为默认值；
✅ st1/sc1卷首次访问有“唤醒延迟”（可达数秒），不适合做系统盘或启动盘；
✅ 不要在单个实例上挂20个gp3卷指望叠加IOPS——实例总带宽才是瓶颈，挂再多也白搭。

终章：一句话决策树

• 要省心、要通用、要未来可扩展 → gp3（闭眼入）；
• 要极致低延迟、强一致性、扛住百万QPS → io2 Block Express（配i4i.2xlarge以上实例）；
• 要存海量日志/备份/归档 → S3 + Lifecycle策略（别硬刚EBS，那是拿火箭送快递）；
• 不确定选啥 → 先上gp3，监控CloudWatch的VolumeReadOps/VolumeWriteOps指标，连续一周峰值超80%再升级。

最后送大家一句AWS老运维的箴言：
“别跟磁盘谈恋爱，它不值得。监控它、度量它、换掉它——这才是云时代的浪漫。”