AWS成品号 亚马逊云 AWS 账号文件存储服务
你的 AWS 账号里，文件到底该往哪儿塞？
刚开通 AWS 账号那会儿，我对着控制台左点右点，像进了一家没贴标签的五层仓库：S3、EFS、FSx、Storage Gateway……每个图标都闪着「我很厉害」的光，但没人告诉我——你那个正在跑 Django 的 Web 服务器，到底该把用户上传的头像存哪儿？是扔 S3 还是挂 EFS？又或者，你那个每天生成 2TB 日志的 Kafka 集群，真需要 FSx for Windows 吗？别急，这不是选择困难症，是 AWS 故意没把说明书印在界面上。
S3：不是「对象存储」，是「万物收纳盒」
先破个迷信：S3 不是给程序员用的「高级存储」，它是给所有人用的「数字抽屉柜」。你删掉本地相册前顺手拖进去的 500 张照片、CI/CD 流水线打包好的 .zip 包、甚至你写错三次密码后被自动归档的 CloudTrail 日志——它们都在 S3 里安详躺着，不抱怨，不崩溃，只收 0.023 美元/GB/月（标准存储，北弗吉尼亚区）。
但 S3 最反直觉的一点是：它根本不认「文件夹」。你看到的 images/avatar/jack.jpg，其实只是对象键名（Key）里带了斜杠；后台压根没目录结构，全是扁平命名空间。这导致新手常犯两个错：一是用 S3 当 NFS 挂载点（行不通），二是以为「删了 avatar 文件夹」就真删干净了（得手动删所有含 avatar/ 前缀的对象）。
实战建议：S3 是你的「冷热分层中枢」。热数据（如网站静态资源）放 Standard；半年不碰的日志压缩包，开个生命周期策略，90 天后自动转 Glacier IR（每 GB 0.004 美元）；敏感数据？KMS 加密一键勾选，连你自己都看不到明文——AWS 说「加密是默认选项」，但实际要你亲手点三下才生效。
权限陷阱：别让 IAM 策略变成「全公司都能删桶」
我见过最痛的翻车现场：某团队为图省事，给开发组分配了 s3:* 权限。结果实习生执行 aws s3 rm s3://prod-bucket --recursive 时多敲了个空格，删掉了整个生产环境的备份桶。补救？靠 Cross-Region Replication + 版本控制硬扛回来，花了 17 小时。
正确姿势：永远用最小权限原则。比如前端上传头像，只需授予 s3:PutObject 和 s3:GetObject，且限制 Key 前缀为 uploads/{user_id}/*；审计日志桶则锁定为只读 + MFA 删除保护。记住：S3 Bucket Policy 和 IAM Policy 是叠加生效的，二者冲突时，显式拒绝（Deny）永远胜出——这是救命稻草，不是装饰品。
EFS：Linux 服务器的「共享U盘」，但别当 NAS 使
如果你有 3 台 EC2 实例跑着同一个 Node.js 应用，想让它们共用一份 /var/www/uploads，EFS 就是答案。它本质是 NFSv4.1 协议的托管服务，挂载命令一行搞定：sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-xxxxxxx.efs.us-east-1.amazonaws.com:/ /mnt/efs。
但 EFS 不是「无限快」。它的性能模型很特别：吞吐量随存储总量线性增长（比如 1TB 存储≈100MB/s），而 IOPS 则依赖「突发模式」或「预置吞吐量」。曾有个客户把 500GB 的 WordPress 安装目录全放在 EFS 上，首页加载 8 秒——因为小文件随机读写触发了突发信用耗尽。解决方案？把 wp-content/cache 这类高频访问目录移到实例本地 SSD，EFS 只存用户上传的 PDF 和图片。
关键提醒：EFS 只支持 Linux。Windows Server 实例？直接死路一条。另外，跨可用区访问延迟高（哪怕同 Region），别指望用它做跨 AZ 的数据库共享存储——那是自杀行为。
FSx：当你要「真·Windows 文件服务」时
FSx 有两个主力选手：FSx for Windows File Server 和 FSx for Lustre。前者是微软认证的 SMB 共享服务，后者是 HPC 场景的高性能并行文件系统。普通人真正需要的，通常是前者。
举个真实案例：某游戏公司用 Unity 开发客户端，美术团队需实时协同编辑 20GB 的 .fbx 模型文件。之前用 S3 + 下载/上传流程，改一帧动画等 5 分钟。换成 FSx 后，直接映射为 Z:\ 盘符，Unity 编辑器毫无感知——因为 FSx 本质就是一台 AWS 托管的 Windows Server，自带 Active Directory 集成、NTFS 权限、卷影副本（VSS）备份。
但 FSx 价格感人：起步价约 $0.21/GB/月（SSD 存储），还强制要求部署在指定子网中。更致命的是——它不支持跨 Region 复制。某次区域故障，他们靠手动导出快照再重建，停服 4 小时。教训：FSx 必须搭配 Backup 服务每日快照，并测试恢复流程，否则就是把鸡蛋放进一个（昂贵的）篮子里。
别踩的三大坑：我们替你试过了
AWS成品号 坑一：用 S3 做数据库备份存储，却忘了开启版本控制
某金融客户用 mysqldump 每日生成 backup_20240501.sql.gz 上传到 S3。某天脚本 bug 导致覆盖上传，新文件损坏，旧版已消失——因为未开启版本控制，S3 默认「同名覆盖即删除」。解决方案：桶策略强制启用版本控制 + 生命周期设置「保留 30 个历史版本」。
坑二：EFS 挂载点配错安全组，EC2 死活连不上
挂载失败？八成是安全组没放行 NFS 端口（2049）。但注意：EFS 安全组必须允许来自 EC2 安全组的入站流量，且 EC2 安全组需放行出站到 EFS 安全组——双向放行，缺一不可。用 VPC Flow Logs 抓包比瞎猜快十倍。
坑三：FSx 权限继承混乱，美术和程序互相删文件
FSx 默认继承 AD 权限，但新建文件夹若未勾选「替换所有子对象权限」，就会出现「A 创建的文件，B 无法修改」。解决方法：在 FSx 控制台 >「文件系统设置」中启用「强制权限继承」，或用 PowerShell 脚本定期修复：icacls Z:\Projects /t /q /c /reset。
终极决策树：三步定乾坤
- 问自己：文件会被多个计算节点同时读写吗？ 是 → EFS 或 FSx；否 → S3。
- 问操作系统：是 Linux 还是 Windows？ Linux → EFS；Windows → FSx for Windows。
- 问访问模式：是 HTTP 直链下载（如 CDN 回源），还是程序内 fopen()？ 前者 S3；后者 EFS/FSx。
最后送一句 AWS 老司机私藏口诀：「S3 存东西，EFS 共享盘，FSx 救 Windows，别把日志当数据库」。下次再看到控制台里那些闪亮图标，你就知道——它们不是玩具，是工具箱里的扳手、电钻和游标卡尺，选对了，事半功倍；拿错了，螺丝拧歪，还得重来。
