S3 + SNS 实时文件上传通知实战

不用写一行代码就能实现文件上传后的实时邮件提醒，其实直接把 S3 Event Notifications 挂到 SNS Topic 上是最快的方案。很多人习惯性地在中间加个 Lambda，但如果你的需求仅仅是“通知”，加 Lambda 反而增加了维护成本和冷启动延迟。

这次复盘下我的部署流程，避坑点主要在权限和区域一致性上。

部署步骤

一、配置 S3 存储桶
在创建 Bucket 时，建议直接开启 Bucket versioning，防止备份文件被意外覆盖。另外，记得在 Management 标签页配置生命周期规则（Lifecycle rules），比如 30 天后转到 Standard-IA，90 天后进 Glacier，否则存储账单会让你心疼。

二、创建 SNS Topic
创建 Standard 类型的 Topic（注意 S3 不支持 FIFO Topic）。创建完后，记得手动创建 Subscription 并验证邮箱，否则你永远收不到通知。

三、打通 S3 与 SNS
这是最容易踩坑的地方。在 S3 存储桶的 Properties -> Event notifications 里创建通知时，必须确保 SNS Topic 的 Access Policy 允许 S3 发送消息。

如果报错权限不足，需要给 SNS Topic 添加如下策略：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "s3.amazonaws.com"
      },
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:region:account-id:topic-name",
      "Condition": {
        "ArnLike": {
          "aws:SourceArn": "arn:aws:s3:::your-bucket-name"
        }
      }
    }
  ]
}

方案对比

• SNS 直接推送： 无需代码，配置快（约15分钟），天然支持扇出（Fan-out），一份通知可以同时发给邮件、短信和 HTTP Webhook。
• Lambda 中转： 需要写代码，适合需要对文件内容做预处理或过滤逻辑的场景。

对于纯备份通知，直接用 SNS 足够了。记得所有资源必须在同一个 Region，不然 S3 找不到对应的 SNS Topic。