3.2 AWS 存储与数据库：S3 + RDS 实战路径

3.2 AWS 存储与数据库：S3 + RDS 实战路径

本节摘要：S3 和 RDS 是 AWS 上用得最多的两个数据服务——前者是对象存储的"行业标准"，后者是托管关系数据库的"事实标杆"。本节用真实工程链路"建 S3 桶 → 配生命周期 → 上传 → 生成预签名 URL"和"启 RDS 多可用区 → 备份 → 调优连接池"展开。学完本节，你应能用 AWS CLI 独立跑通一个最小可用的"应用 + 对象存储 + 数据库"三件套架构。

本节读完后能掌握什么

阅读完本节，你应当能够：

1. 用 AWS CLI 创建一个 S3 桶并配置生命周期规则，把 30 天前的对象自动转到 IA 层、90 天转到 Glacier。
2. 生成预签名 URL：让前端/客户端无需长期 AccessKey 即可临时下载/上传文件。
3. 启动一个 RDS 多可用区实例，配置自动备份、读副本、参数组。
4. 诊断 RDS 性能问题：用 Performance Insights、慢查询日志、连接数监控三件套定位瓶颈。

一、问题与直觉：S3 不是文件系统

很多新手把 S3 当作"无限大的网盘"用，结果在性能、成本、权限三方面都踩坑。

举一个反例：某公司 2021 年把所有产品图片放 S3，没配生命周期规则。3 年后桶里有 800TB 数据，其中 700TB 是 1 年前上传后再没访问过的。月存储费 7 万元——但其实这 700TB 应该早就降级到 Glacier（每 GB 0.004 USD/月，是标准存储的 1/25）。

正解：S3 的"对象"是不可变的大文件，配生命周期规则是头号降本技巧。没配生命周期规则的 S3 桶，几乎一定在烧钱。

二、核心原理：S3 与 RDS 的工程实操

2.1 S3 桶创建与生命周期配置

# 创建 S3 桶（注意桶名全球唯一）
aws s3 mb s3://my-app-images-2026

# 启用版本控制
aws s3api put-bucket-versioning \
  --bucket my-app-images-2026 \
  --versioning-configuration Status=Enabled

# 配置生命周期规则
cat > lifecycle.json <<EOF
{
  "Rules": [
    {
      "ID": "downgrade-old-images",
      "Status": "Enabled",
      "Prefix": "user-original/",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ]
    }
  ]
}
EOF
aws s3api put-bucket-lifecycle-configuration \
  --bucket my-app-images-2026 \
  --lifecycle-configuration file://lifecycle.json

# 上传文件
aws s3 cp ./local-image.jpg s3://my-app-images-2026/user-original/

# 列出桶内对象
aws s3 ls s3://my-app-images-2026/ --recursive --summarize
​

2.2 预签名 URL（Presigned URL）

# 生成 1 小时有效的下载链接
aws s3 presign s3://my-app-images-2026/user-original/photo.jpg \
  --expires-in 3600

# 生成 1 小时有效的上传链接（PUT）
aws s3 presign s3://my-app-images-2026/user-upload/tmp.jpg \
  --expires-in 3600 \
  --method put
​

预签名 URL 的真实价值：把"上传/下载授权"从"长期 AccessKey"换成"短时 URL"——前端不需要任何凭证。这是云上文件分发的标准做法。

2.3 RDS 多可用区部署

# 创建 RDS 子网组（多可用区）
aws rds create-db-subnet-group \
  --db-subnet-group-name my-app-subnets \
  --db-subnet-group-description "App subnets" \
  --subnet-ids subnet-aaa subnet-bbb subnet-ccc

# 创建 RDS MySQL 多可用区实例
aws rds create-db-instance \
  --db-instance-identifier my-app-db \
  --db-instance-class db.t3.medium \
  --engine mysql \
  --engine-version 8.0.32 \
  --master-username admin \
  --master-user-password 'MySecureP@ssw0rd!' \
  --allocated-storage 100 \
  --storage-type gp3 \
  --multi-az \
  --db-subnet-group-name my-app-subnets \
  --vpc-security-group-ids sg-database \
  --backup-retention-period 7 \
  --preferred-backup-window "03:00-04:00" \
  --preferred-maintenance-window "Mon:00:00-Mon:01:00" \
  --no-deletion-protection

# 创建读副本
aws rds create-db-instance-read-replica \
  --db-instance-identifier my-app-db-replica \
  --source-db-instance-identifier my-app-db \
  --db-instance-class db.t3.medium
​

2.4 S3 + RDS 的连接架构

三、工程实践要点：性能与成本治理

3.1 S3 性能优化三件套

3.2 RDS 性能诊断三件套

真实反例：某 RDS MySQL 实例 CPU 持续 90%，DBA 不知道是哪条 SQL。开了 Performance Insights 后发现是 SELECT * FROM orders WHERE user_id = ? 走了全表扫描（user_id 没建索引）。加索引后 CPU 降到 10%。Performance Insights 是 RDS 调优的必备工具。

3.3 RDS 连接池调优

RDS 的最大连接数有上限（db.t3.medium 默认 max_connections=150）。应用层忘记关连接 = 数据库连接数耗尽。

调优方法：

1. 应用层用连接池（HikariCP、DBCP），池大小 = (CPU 核数 × 2) + 有效磁盘数。
2. 监控 DBConnections 指标，超过 80% 触发告警。
3. 对长查询用 read-only 副本，避免影响主库。
4. 用 RDS Proxy 集中管理连接（db.t3.medium 上加 RDS Proxy 月费约 20 USD，节省 30-50% 连接资源）。

3.4 反例：S3 与 RDS 的常见误用

⚠️ 常见坑："S3 是 11 个 9 的持久性" ≠ "数据不会丢"。11 个 9 是"云厂商基础设施"的持久性，但你的 AccessKey 泄露、生命周期规则写错、桶策略公开读——这些是用户配置错误，不在 11 个 9 覆盖范围内。S3 数据丢失的 80% 案例都是用户配置错误，不是 AWS 故障。

💡 关键直觉：S3 的成本治理核心是"生命周期规则"；RDS 的性能治理核心是"慢查询日志 + 索引 + 连接池"。把这两件事做扎实，AWS 数据层就稳了。

本节要点回顾

• S3 桶配置三件套：版本控制 + 桶策略 + 生命周期规则，缺一不可。
• 预签名 URL 是文件分发的标准做法：替代长期 AccessKey，安全性提升一个量级。
• RDS 多可用区是工业级标配：multi-az 参数、备份周期、读副本三件套。
• 性能诊断三件套：Performance Insights + 慢查询日志 + Enhanced Monitoring。
• 连接池 + RDS Proxy 是高并发必备：避免连接数耗尽和频繁建连开销。
• S3 数据丢失 80% 是配置错误，不是基础设施故障——桶策略与生命周期是关键。

下一节切到 AWS 网络与监控——VPC 实战和 CloudWatch 告警闭环。