构建AWS S3预签名URL的.NET API重定向方案是否可行？

我有一个连接AWS S3存储桶的.NET API，多个客户端应用需要访问桶内的图片。计划编写API方法返回S3预签名URL并返回302重定向，伪代码如下：

[HttpGet("Image")]
public async Task<IActionResult> Image(string key)
{
    // 此处省略身份验证相关代码

    if (result.Succeeded)
    {
        GetPreSignedUrlRequest request = new GetPreSignedUrlRequest
        {
            BucketName = "mybucket",
            Key = key,
            Expires = DateTime.Now.AddMinutes(5)
        };

        string url = _amazonS3.GetPreSignedURL(request);
        return Redirect(url);
    }
    else
    {
        return StatusCode(401, "Unauthorized");
    }
}

客户端通过如下img标签展示图片：

<img src="@Url.Action("Image", "MyController", new { key = "123.png" })" />

假设客户端已完成身份验证，现咨询以下问题：

1. 该方案是否存在问题？
2. 暂不想搭建CloudFront，若一次性加载100+图片是否需担忧性能？
3. 能否用ResponseCache属性缓存控制器方法结果？

1. 方案的潜在问题 #

这个方案整体可行，但有几个细节需要注意：

• 预签名URL有效期限制：你设置的5分钟有效期，如果客户端的img标签在URL过期后才触发加载（比如用户打开页面后很久才滚动到图片位置），图片会加载失败返回403。可以根据实际场景延长有效期到15-30分钟，或者让前端缓存重定向后的预签名URL。
• S3桶权限必须私有：务必确保S3桶是私有访问配置，不能设为公开，否则用户可以绕开你的API直接访问S3，身份验证逻辑就形同虚设了。
• 极端场景的兼容性：大部分浏览器和客户端都支持302重定向加载图片，但极少数老旧设备可能存在兼容问题，不过这个概率极低。
• API负载压力：每一次图片加载都会先请求你的API生成预签名URL，后续流量大时，这部分请求会成为API的负载点。

2. 一次性加载100+图片的性能风险 #

需要担忧，但可以通过优化缓解：

• API并发压力：100+图片会同时发起100+请求到你的.NET API，如果服务器资源不足（CPU、带宽），可能出现响应延迟甚至超时。建议优化S3客户端配置，比如复用AmazonS3Client实例、启用连接池，提升预签名URL的生成效率。
• S3端压力：AWS S3本身支持高并发，默认单桶每秒可处理5500个GET/HEAD请求，100+并发远低于这个阈值，所以S3这边不会有太大压力。
• 前端层面优化：给图片加懒加载，避免一次性发起所有请求；或者控制并发请求数，减少同时打到API的请求量。

3. 能否使用ResponseCache缓存方法结果？ #

不建议直接用ResponseCache缓存这个方法的结果，原因如下：

• 预签名URL有有效期，缓存时长如果短于URL有效期，缓存意义不大；如果长于有效期，会导致客户端拿到过期URL，图片加载失败。
• 预签名URL和生成时的身份、时间绑定，若后续用户权限变化，缓存的URL依然能访问，存在安全风险。

如果想降低API负载，可以考虑：

• 让前端缓存重定向后的预签名URL，直到URL接近过期时间再重新请求API获取新链接。
• 自定义缓存逻辑：比如用Redis缓存预签名URL，缓存时长设置为比URL有效期短1-2分钟，既减少API压力，又避免返回过期链接。

内容的提问来源于stack exchange，提问作者Andrew