S3安全访问的两种思路：预签名还是边缘验证？

「真正的挑战不是分析每个单独的服务，而是如何正确组合它们。」一位云架构师在复盘S3安全方案时这样总结。当网站需要同时解决「上传文件」和「控制谁能看到」这两个问题时，技术选型往往比想象中更纠结。

本文拆解一个典型场景：用户登录后，才能看到特定图片或视频。这个需求背后，藏着两条完全不同的技术路线。

路线一：预签名链接，让S3自己把关

这是最常被采用的方案，核心逻辑是「让S3做最终裁决」。

上传环节，前端向受Cognito保护的API请求一个预签名链接（预签名链接，即嵌入临时签名、无需额外身份验证即可使用的网址）。后端Lambda生成一个带时限的PUT权限链接，有效期通常设为几分钟。前端拿到后直接上传至私有存储桶。

下载环节则依赖CloudFront的OAC（源访问控制）机制。OAC内部使用SigV4协议对请求签名，向S3安全取回对象。存储桶策略严格限定：只有特定CloudFront分配的ARN才能执行GetObject操作。

这里有个关键细节容易被忽略。预签名链接理论上既能用于上传也能用于下载，但上述方案只把它用在写入端。为什么？

因为预签名链接的本质是「把权限打包进URL」。任何人拿到链接就能用，直到过期。如果直接生成读取用的预签名链接发给用户，等于绕过了所有中间层的访问控制。所以读取路径改用OAC+CloudFront，让边缘网络承担第一道防线，S3只认CloudFront的身份。

代码层面，Python的Boto3库提供两种上传方式。简单场景用generate_presigned_url指定put_object操作，前端直接PUT文件。大文件或需要更多控制时，改用generate_presigned_post生成带策略的POST表单，可约束Content-Type和文件大小（如下例限制5MB以内）。

路线二：Lambda@Edge，在边缘节点验人

第一条路线解决了「S3只被CloudFront访问」的问题，但没解决「谁能访问CloudFront」。如果需要在分发层就拦截未授权请求，Lambda@Edge成为必选项。

这个方案把验证逻辑推到全球边缘节点。用户请求到达CloudFront时，Lambda函数在最近的边缘位置执行，检查Cookie或Token是否有效。未通过验证的请求直接返回403，连S3的边都碰不到。

代价同样明显：Lambda@Edge有运行时长限制（最大5分钟，但Viewer Request/Response触发器实际限制更严），调试困难，且部署到全球节点需要复制时间。更重要的是，它把「验证谁」的逻辑从应用层下沉到基础设施层，架构复杂度陡增。

两条路线的核心分歧

路线一信任预签名链接的时效性，把权限控制交给S3的策略引擎；路线二不信任任何直达S3的路径，坚持在边缘验明正身。前者实现简单、延迟更低，后者控制更细、审计更严。

实际选型取决于一个关键变量：你的「用户会话」有多长。如果内容需要按次授权、实时鉴权，Lambda@Edge几乎是唯一选择；如果登录态可持续数小时，预签名链接的临时性反而成为优势——即使链接泄露，窗口期也足够短。

更深层的判断在于团队能力。Lambda@Edge的调试和监控成本常被低估，而OAC+预签名的组合在AWS文档中路径清晰，故障排查有迹可循。除非延迟或合规要求逼到墙角，多数团队应从简单方案起步。

最终，S3安全不是单点技术问题，而是服务编排问题。预签名链接、OAC、Lambda@Edge都是工具，真正的设计发生在「谁在哪一层做什么决策」的边界划分上。