AWS抵扣券 亚马逊云 AWS 账号 S3 存储管理

如果你刚注册完 AWS 账号，点开 S3 控制台，看到那个空荡荡的「创建存储桶」按钮，心里默念的是「我终于要开始云存储了！」——恭喜，你已成功踏入全球最优雅也最易翻车的存储迷宫入口。

别急着建桶：先搞懂「AWS 账号」和「S3」到底谁管谁

很多人以为：「我有个 AWS 账号，那 S3 就是我的私人保险柜，钥匙在我手里，密码我设，桶我建，数据我扔——完事！」

错。大错特错。这就像以为买了整栋楼的产权证，就自动拥有了每扇门的指纹锁权限+地下室的温湿度控制器+屋顶直升机停机坪的调度权一样离谱。

AWS 账号是顶层身份容器，S3 是它麾下一位脾气古怪、记性超好、从不主动提醒你干过啥的管家。它不阻止你建 1000 个桶，也不拦你把密钥明文写进桶名里（比如 prod-db-backup-20240415-root-access-key-abc123），更不会因为你删了最后一个桶就发封慰问信说「节哀，您的对象存储已断联」。

所以第一课不是「怎么用」，而是「谁在用、凭什么用、能用到哪」。

桶 ≠ 账号附属品，桶是独立资源实体

每个 S3 存储桶（Bucket）都是全球唯一的 DNS 名称资源——注意，是「全球唯一」，不是「你账号内唯一」。你起名 my-awesome-app-data？如果已被巴西某初创公司注册，AWS 会温柔但坚定地告诉你：「抱歉，这个名字已被占用，请换一个（比如加个随机后缀、年份、或者你家猫的名字拼音）」。

这意味着：你的账号可以拥有 100 个桶，也可以只有 1 个；可以跨区域建桶（us-east-1、ap-southeast-1、eu-central-1……），但每个桶只属于一个区域；你可以把桶授权给另一个 AWS 账号读取，甚至允许匿名 GET（别试，除非你想上热搜）。

一句话总结：账号是身份证，桶是房产证——你有身份证，不代表你天然拥有某套房；你建了房，也不代表邻居不能来敲门（只要门没锁好）。

权限三件套：桶策略、IAM 策略、ACL——别再靠猜了

权限混乱，是 S3 最常见的「慢性自杀式操作」。有人删库跑路，不是手滑，是权限配得太宽；有人数据泄露，不是黑客入侵，是桶策略写着 "Principal": "*" 还点了「保存」。

记住这个铁律：最小权限不是口号，是保命符；显式拒绝永远胜过隐式允许。

桶策略（Bucket Policy）：桶的「对外公告栏」

这是挂在桶身上的公开声明，告诉全世界（或特定账号/用户）：「欢迎谁来，禁止谁进，允许干啥，禁止干啥。」它只对这个桶生效，不管你是 root 用户还是刚创建的 IAM 用户。

经典反面教材：
→ 允许所有 IP 访问所有对象："Principal": "*" + "Action": "s3:GetObject"
→ 开放整个桶给外部账号："Principal": {"AWS": "arn:aws:iam::123456789012:root"} 却忘了加 "Condition" 限制 Referer 或 IP 段。

正解姿势：用 aws s3api put-bucket-policy 命令前，先本地跑一遍 Policy Generator（官方生成器），再粘贴进 VS Code，Ctrl+F 搜 "*" 和 "Allow"——出现三次以上？删掉重写。

IAM 策略：人的「工作证+门禁卡」

这是绑在 IAM 用户/角色上的权限说明书。它决定「张三」能否执行 s3:ListBucket，能否在 arn:aws:s3:::finance-reports-2024 下执行 s3:PutObject。

致命误区：给开发组全员授予 AmazonS3FullAccess。结果小王误删了生产桶的 lifecycle 配置，小李把测试日志同步到了财务桶，而监控告警邮件被静音了三天。

实操建议：
• 按职能切组：dev-s3-ro、ops-s3-rw、audit-s3-list-only
• 所有策略加 "Condition": {"StringEquals": {"s3:ExistingObjectTag/environment": "prod"}} 类标签校验
• 用 aws iam simulate-principal-policy 提前沙盒验证——比上线后跪着改策略体面十倍。

ACL（访问控制列表）：S3 的「上古遗物」

ACL 是 S3 初代设计，粒度粗、难审计、已不推荐用于新项目。它直接挂在对象（Object）上，比如给某个 log 文件设为 public-read。

AWS抵扣券 现实是：99% 的 ACL 使用场景，都可以且应该用桶策略+IAM 替代。AWS 官方文档第 7 次更新时已悄悄标注：「For new applications, we recommend that you use bucket policies or IAM policies instead.」

所以——除非你在维护 2012 年上线的老系统，否则请把 ACL 当成博物馆展品，远观，勿碰。

安全不是选修课：加密、版本控制、MFA 删除全得上

S3 默认不加密？不，它默认「不帮你加密」。你的数据躺在磁盘上，像没锁门的抽屉——物理层可能加密（AWS 底层确实做了），但逻辑层裸奔。

服务端加密（SSE）：选 SSE-S3 还是 SSE-KMS？

• SSE-S3：AWS 托管密钥，免费，够用，适合非敏感数据（如静态网站资源）
• SSE-KMS：你可控的 CMK 密钥，支持审计、轮转、禁用，适合 PII、PCI、HIPAA 场景。但注意：KMS 调用按次计费，高频小文件上传？账单会笑出声。

冷知识：启用 SSE-KMS 后，s3:GetObject 权限必须额外加上 kms:Decrypt，否则下载直接 403——这不是 bug，是 KMS 的礼貌式拒载。

版本控制（Versioning）：你的「后悔药自动贩卖机」

开启后，每次覆盖上传都会生成新版本 ID，删除只是打个「删除标记」，原始对象依然可恢复。这是防误删的终极防线。

但！版本控制不等于无限存档。旧版本对象仍计费，且不自动清理。搭配生命周期规则使用才是王道：

{
  "Rules": [{
    "Status": "Enabled",
    "Expiration": {"Days": 365},
    "NoncurrentVersionExpiration": {"NoncurrentDays": 90}
  }]
}

意思是：当前版本满 1 年删；非当前版本（即被覆盖的老版）满 90 天删。干净利落，不拖泥带水。

MFA 删除：给「删桶」动作上把物理锁

仅对启用了版本控制的桶有效。开启后，删除桶或永久删除对象，必须输入 MFA 设备动态码——哪怕你是 root 用户。

配置命令一行搞定：
aws s3api put-bucket-versioning --bucket my-bucket --versioning-configuration Status=Enabled,MFADelete=Enabled --mfa "arn:aws:iam::123456789012:mfa/root-account-mfa-device 123456"

别嫌麻烦。2023 年某公司因运维脚本硬编码了 aws s3 rb s3://prod-logs --force，又没开 MFA 删除，一跑就是 2TB 日志灰飞烟灭。事后复盘，大家一致认为：「早装 MFA，晚哭三年。」

钱不是省出来的，是管出来的：S3 成本三大黑洞

你的账单里藏着三个幽灵：请求费用（GET/PUT/LIST）、存储类型错配、以及——最阴险的——未清理的旧版本和碎片上传。

别让 STANDARD 成为你的默认习惯

STANDARD 存储贵，但快；STANDARD_IA 便宜 40%，但取回贵、有最低容量和时长要求；GLACIER_IR 几乎白送，但取回要分钟级延迟。

正确姿势：
• 新上传文件 → 自动打标签 env=prod / type=logs
• 配置生命周期规则：logs 类型 30 天后转 STANDARD_IA，90 天后转 INTELLIGENT_TIERING（自动降冷）
• 关键报表类文件？保留 STANDARD，加 Object Lock 防篡改。

警惕「僵尸分段」：Multipart Upload 的幽灵遗产

大文件上传中断？S3 会留下未完成的分段（Part）。它们不计入对象数，但按实际存储量收费，且永不自动清理。

解决方案：
• 每周跑一次清理脚本：
aws s3api list-multipart-uploads --bucket my-bucket --query 'Uploads[?Initiated<`2024-01-01`].{Key:Key,UploadId:UploadId}' --output table
• 配合 aws s3api abort-multipart-upload 批量清除。

最后送你三条祖传口诀

① 桶名别用敏感词，别含日期，别学极客起 my-s3-bucket-v2-final-really-prod——运维看到会沉默，审计看到想报警。
② 权限宁缺毋滥，策略宁繁勿简；删桶前先 aws s3 ls s3://bucket-name，再 aws s3api get-bucket-policy --bucket bucket-name，最后深呼吸三次。
③ 每季度做一次「S3 健康快照」：查未加密桶、查 public ACL、查无生命周期规则的桶、查 MFA 删除是否开启——把它写进你的 OKR，比写「提升团队凝聚力」实在多了。

毕竟，在云上，真正的安全感，从来不是「我什么都没干」，而是「我干的每件事，都经得起回溯、审计和凌晨三点的电话轰炸。」