AWS S3图片公网访问链接从0到1：权限配置与Bucket Policy实战

前阵子有个朋友问我，怎么把一张图片传到 Amazon S3 上，然后拿一个链接直接发给别人，对方在浏览器里就能打开，不需要登录、不需要下载、不需要配什么复杂的权限。这个问题听起来简单，但在实际操作里，新手最容易卡在几个地方：存储桶建好了但链接打不开、明明点了公开按钮却还是 Access Denied、搞不懂 Bucket Policy 和 ACL 到底要配哪个。今天我就把这套流程完整拆开，从建桶到拿到可访问链接，每一步都给你讲清楚，包括里面的坑和原理，保证你照着做就能通。

先说清楚这套方法适合谁。如果你在做个人网站、作品集、小程序临时展示图、活动海报托管、给客户发文件预览，或者只是想让一张图片有个公网地址，这篇就是给你准备的。如果你以后要做电商、视频、海量图片的 CDN 分发，思路也是一样的，只是后面要接 CloudFront，这个我会在最后提一句。读这篇不需要你有 AWS 基础，但至少你得有一个 AWS 账号，注册这个我就不展开了，照着官网流程走就行。

1. 先把需求理清楚：你要的到底是“Public 链接”还是“公开整个桶”

很多人在第一步就搞混了一个概念：S3 里的对象（Object）默认是私有的，只有存储桶（Bucket）的拥有者或者被授权的人才能读取。你要做的，是把“某一个对象”变成可以被任何人通过 URL 访问，而不是把“整个桶”敞开让别人随意列出所有文件。

这两个听着差不多，实际上差别非常大。如果你把桶的策略写成了 s3:ListBucket 对所有主体开放，那别人只要知道你的桶名，就能列出来你里面到底存了什么文件，等于把你的图片库整个裸奔了。而你只是想让某张图片能通过链接打开，那只需要给这个对象或者这一类对象加上 s3:GetObject 的公开读权限就够了。

我在实际的项目里见过太多反面案例：有人图省事，直接把 Block Public Access 全部关掉，把 ACL 设成 Public Read，结果第二天账单上多出几百刀的请求费用，因为他的图片被别人拿去批量刷接口了。也有人正好相反，文件传上去之后怎么改权限都不生效，后来发现是 AWS 账号级别默认开了四层“阻止公有访问”，把路全堵死了。

所以读完这篇之后，你一定要带着一个清晰的边界：我要公开的是特定文件，不是整个桶的列举权限。在这个前提下，后面的所有操作都围绕“最小权限 + 对象可读”来展开。

2. 创建 S3 存储桶：账号、权限和关键参数一次配齐

2.1 创建存储桶之前，先把账号权限检查一遍

这一步看着有点多余，但很多人后面遇到权限错误，根源其实在 IAM 账号上。如果你用的是 AWS 根账号登录控制台操作，那基本没什么问题，根账号默认拥有一切权限。但如果你是用 IAM 子账号操作的，比如公司给你的开发账号，就要先确认这个子账号至少有 s3:CreateBucket、s3:PutBucketPolicy、s3:PutObject、s3:GetObject 这几项权限。

你可以用 AWS 官方的托管策略 AmazonS3FullAccess 来临时验证流程，不过在生产环境里我建议你自己写一个最小权限策略，别直接挂 FullAccess。下面这个是我常用的一个 IAM 策略模板：

json复制{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:CreateBucket",
                "s3:PutBucketPolicy",
                "s3:GetBucketPolicy",
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": "*"
        }
    ]
}

注意，s3:PutBucketPolicy 和 s3:GetBucketPolicy 的动作资源是指向 Bucket 的，而 s3:PutObject、s3:GetObject 是指向 Object 的。如果你后面要用 CLI 或者程序代码操作，建议先把 IAM 的权限边界给划清楚，不然程序跑起来会一脸懵。

2.2 创建存储桶时，区域、名称、版本控制怎么选

登录 AWS 控制台，在搜索框输入 S3，进入 S3 服务主页，点击“创建存储桶（Create bucket）”，这时候你会看到一长串配置项。大多数教程会让你一路默认，但我建议你对下面几个选项有自己的判断。

存储桶名称（Bucket name） 必须是全 AWS 唯一的，不能跟其他任何人的桶重名。命名规则是 3 到 63 个字符，只能包含小写字母、数字、点号（.）和连字符（-），不能以下划线结尾，也不能像 IP 地址那样命名。这点很坑，很多人在命名上会被反复弹窗提醒。

区域（AWS Region） 的选法有个原则：离你的目标用户越近，访问速度越快；离你越近，你操作管理的延迟越低，费用也相对便宜一些。如果你不确定，就选一个离你常驻地域比较近的节点，个人练手随便选一个也没事。要注意一点，S3 的访问链接里会带上区域名，比如 s3.ap-northeast-1.amazonaws.com，如果你后面要用自定义域名或者接 CloudFront，区域选错会带来迁移成本。

对象所有权（Object Ownership） 默认是“仅限 Bucket 拥有者”。在旧版本里，如果你是用另一个 AWS 账号跨账号上传对象，可能会遇到“上传成功但读不了”的怪问题。我们现在只需要自己的账号单账号上传，保留默认设置就好。

版本控制、默认加密、服务端日志 这些选项，建议按你的实际场景决定：版本控制能防误删但会增加存储成本，默认加密建议直接开 AES-256，这个不影响你后续做公有读链接。至于对象锁定、智能分层那些，个人项目可以先不理会，保持默认关闭。

2.3 阻止公有访问（Block Public Access）这个坑长什么样

创建存储桶的页面里有一大块叫“Block Public Access settings for this bucket”，默认是全部勾选的。AWS 在 2023 年之后，新建的存储桶默认会开启 Block All Public Access，也就是说，就算你在后面配了公有读策略，这一层开关没关掉，请求还是会被挡在门外。

这个设计是 AWS 出于安全考虑故意做的“默认安全”，但也确实让很多新手在第一次做公有链接时被卡住。你可以理解成它有四道锁，从账户口子到大门口一层层拦住，任何一层说 No，请求就进不来。

我个人的建议是：不要全关，关掉你需要的那一层就行。如果你打算走桶策略（Bucket Policy）路线，把“阻止新公有存储桶策略”和“阻止对存储桶和对象的公有访问”这两项关掉，保留“通过访问控制列表 (ACL) 授予的公有访问权限”相关的锁定项，因为你根本用不到 ACL。后面我会在策略部分详细展开。

3. 配权限：搞清楚 Bucket Policy 和 ACL 的关系，一次配对

3.1 控制台里“公开”按钮的两种理解

现在打开你刚创建的存储桶，切到“权限（Permissions）”标签页，你会看到几块内容：Block Public Access、Object Ownership、Bucket Policy、Access Control List (ACL) 等。

很多老的 S3 教程会教你：选中文件 -> 操作 -> 设为公有读取（Make public using ACL）。这种方式在旧控制台很好用，但在新版本里，AWS 已经不建议继续用 ACL 来做公开读权限，因为 ACL 的粒度太粗，你一旦给某个对象开了 Public Read，它的权限管理就脱离了 Bucket Policy 的统一管控。而且当 Bucket 的 Object Ownership 默认是“仅 Bucket 拥有者”时，ACL 的生效逻辑也会变得混乱，搞得你明明点了公开，别人照样 Access Denied。

所以我更推荐用 Bucket Policy 来控制公开读。这么做的最大好处是，你能精确地指定：这个桶里的哪些路径允许匿名读取，其他路径还是私有的。配合前面的最小对象暴露原则，比 ACL 那种一刀切的方式安全得多。

3.2 网上很多教程不会告诉你的最小公开读策略

在 Bucket Policy 编辑框里，我们要填一段 JSON。先直接给你一个可以复制粘贴的模板，假设你的桶名是 my-public-demo-2024，你只想公开 uploads/ 这个前缀下面的图片：

json复制{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadForUploads",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::my-public-demo-2024/uploads/*"
        }
    ]
}

看懂这段 JSON 的几个关键点就够了：

• Principal: "*" 表示允许所有用户（匿名用户）访问，这是公开的关键。
• Action: "s3:GetObject" 表示只允许读取对象本身，不能模拟列出桶内容（ListBucket），也不能删除、上传。这样别人即使知道你桶名，也看不到这个桶里有什么其他文件，只能在明确拿到某个对象 URL 时才能读取那个文件。
• Resource 是 ARN，格式固定是 arn:aws:s3:::你在建桶时填的桶名/你要公开的具体路径/*。uploads/* 里最后的 *，是通配符，表示这个目录下所有对象。

如果你就是想全桶公开（比如整站静态资源托在 S3 上），可以把 Resource 写成 arn:aws:s3:::my-public-demo-2024/*。但我还是那句：能用前缀限制，就别把整个桶全公开。你没踩过“全桶公开后被恶意刷流量”的坑，是不知道那种感觉的。

点击“保存更改”，紧接着回到存储桶的“属性（Properties）”标签页最底部，看一眼“静态网站托管（Static website hosting）”。这里有一个很多人都没搞明白的点：如果你只是想让单张图片直接在浏览器里打开，其实不需要开启静态网站托管。开了托管之后，S3 会给你生成一个 http://bucket-name.s3-website-region.amazonaws.com 的地址，访问体验是“文件当作网页渲染”，但这里面的证书是 HTTP 而不是 HTTPS；而我们要做的是走 S3 的 REST API 端点，也就是 https://bucket-name.s3.region.amazonaws.com/object-key，这个端点自带 HTTPS。如果你不需要托管整站，别去开静态网站托管，否则后面证书、重定向规则会有一堆麻烦。

3.3 保存策略之前，看一眼控制台的提示

把上面那段 JSON 粘贴进去之后，AWS 控制台通常会在保存前弹一个提示，英文大意为“这个存储桶允许公网访问”。看到这个提示不要紧张，这不是报错，只是提醒你注意风险。你既然决定做公开资源，选择“确认”即可。

保存成功后，你会看到 Bucket policy 下面出现一条策略记录。这个时候，可以顺手点开旁边的“访问控制列表（ACL）”区域看眼，确认里面没有额外开“公开读取”。因为如果 ACL 也开着，和 Bucket Policy 双管齐下，权限范围会变得很难复盘，出事了不好查。

4. 上传图片：控制台、命令行、代码三种方式都跑一遍

4.1 网页控制台上传，顺便验证链接

权限配置完成后，进入“对象（Objects）”标签页，点击“上传（Upload）”，选一张你本地的图片，比如 demo.jpg。如果你想要前面的 Bucket Policy 精确匹配生效，上传时就要把文件放到对应的“uploads/”路径下。

最简单的做法是点击“创建文件夹”，键值（Key）填 uploads，然后在这个路径下上传图片。S3 本身没有真实的文件夹概念，控制台显示的“文件夹”本质只是对象 Key 的前缀，比如 uploads/demo.jpg。理解了这一点，你就知道为什么说“只公开 uploads/ 前缀”而不是真的去设目录权限了。

上传完成后，点击文件名，进入对象详情页，你能看到对象的“对象 URL（Object URL）”。这个 URL 的样子一般是：

text复制https://my-public-demo-2024.s3.ap-northeast-1.amazonaws.com/uploads/demo.jpg

你现在先在浏览器无痕窗口里打开它试一下。不出意外的话，应该能看到图片在浏览器里直接展示。

如果你打开是 XML 格式的错误，比如 AccessDenied，那说明权限还没配到位；如果打开是下载而不是预览，那可能是 Content-Type 没设置正确，这个我在后面第 5 章会细说怎么排查。

4.2 用 AWS CLI 批量和脚本化上传

控制台上传一两次还可以，如果你有几十上百张图片要传，或者你希望把上传流程固化到脚本里，那就得用命令行工具。先确保本机装好了 AWS CLI，并且已经用 aws configure 配好了密钥。

上传到指定前缀的关键命令是：

bash复制aws s3 cp ./local-images/demo.jpg s3://my-public-demo-2024/uploads/demo.jpg

如果你想把整个目录同步上去，可以用：

bash复制aws s3 sync ./local-images/ s3://my-public-demo-2024/uploads/

sync 会智能判断，只上传本地新增或修改过的文件，非常适合更新场景。

有一点容易忽略：命令行上传时，默认 Content-Type 可能是 binary/octet-stream，如果你的文件是 .jpg，但工具没有正确识别，那用户打开链接时可能被强制下载而不是在浏览器里预览。解决办法是在上传时显式声明 Content-Type：

bash复制aws s3 cp ./local-images/demo.jpg s3://my-public-demo-2024/uploads/demo.jpg \
  --content-type "image/jpeg"

对照片来说，更完整的 Content-Type 对照是：.jpg 和 .jpeg 用 image/jpeg，.png 用 image/png，.gif 用 image/gif，.webp 用 image/webp。上传错了也没关系，后面可以在对象属性里修改 Metadata 再保存。

4.3 用 Python boto3 把上传集成到自己的程序里

如果你写代码，比如做个后台管理系统，需要接收用户上传的图片并自动生成公开链接，那就得用 SDK 了。AWS 的 Python SDK 是 boto3。下面的代码是获取公开链接的最小示例：

python复制import boto3

s3_client = boto3.client(
    "s3",
    aws_access_key_id="你的 AccessKeyId",
    aws_secret_access_key="你的 SecretAccessKey",
    region_name="ap-northeast-1"
)

bucket_name = "my-public-demo-2024"
object_key = "uploads/demo.jpg"
file_path = "./local-images/demo.jpg"

s3_client.upload_file(
    file_path,
    bucket_name,
    object_key,
    ExtraArgs={"ContentType": "image/jpeg"}
)

url = f"https://{bucket_name}.s3.{region_name}.amazonaws.com/{object_key}"
print("公开访问链接:", url)

这里不再需要调用 put_object_acl 去设 PublicRead，因为公开读权限已经被桶策略统管了，你只管上传到 uploads/ 前缀下，这个对象天然就继承公开访问能力。这也是前面用桶策略而不是单文件 ACL 的另一个好处：以后你不管用什么方式上传，只要 Key 在规则范围内，链接全都可以直接访问，不用逐个设置。

有一类特殊场景是：你希望某些新上传对象在几个小时内可以公开访问，过期之后就自动变私有，或者下载次数达到上限就失效。这种需求桶策略本身做不到，需要生成预签名 URL（Presigned URL），它会带一串身份参数和过期时间。那套玩法跟“Public 公开”不同，本篇不展开，但需要你有这个意识：公开链接不等于“永久授权访问的唯一手段”。

5. 链接打不开？把这张排查表和思路收藏好

5.1 URL 拼写规则和两种域名风格

做 S3 访问链接，你可能会看到两种不同风格的域名：

1. 虚拟主机式（Virtual-hosted style）：https://bucket-name.s3.region.amazonaws.com/object-key
2. 旧式路径式（Path-style）：https://s3.region.amazonaws.com/bucket-name/object-key

从 2020 年 10 月之后，新创建的区域基本都不再支持 Path-style 方式访问，AWS 官方也把文档里的示例改成了 Virtual-hosted 风格。所以你现在拼接链接时，直接按第一种来就好。前面控制台生成的 Object URL 也是这种风格。

有人会拿“S3 静态网站托管域名”来跟这个对比，我再强调一次：S3 网站的终端节点格式是 bucket-name.s3-website-regation.amazonaws.com，默认只有 HTTP，不带 HTTPS。你做单图公开展示，请用 REST API 终端节点，也就是 .s3.region.amazonaws.com 这份，不然图片加载时浏览器地址栏很可能会有不安全的提示。

5.2 我压箱底的 5 个高频问题

很多人上传完图片、复制了链接，往浏览器里一贴，面对的不是图片，是白底黑字的 XML 错误。下面这五种情况，几乎占了新手问题的九成。

Access Denied

这个最常见，原因通常是 Block Public Access 还锁着，或者 Bucket Policy 没保存成功，或者 Policy 里的 ARN 前缀和你实际 File 的路径对不上。你检查的顺序应该是：先确认上传后的对象 Key 是不是 uploads/ 开头，再去存储桶的“权限”页看一眼 Block Public Access 有没有把你需要的那层关掉，最后确认Policy 里的 ARN 写的是否完整，尤其不要漏了 arn:aws:s3::: 后面那组 桶名/路径。

NoSuchKey

这个错误的意思是 Bucket 和策略都通了，但对象不存在。最常见的原因是你拼 URL 里的 Key 写错了，比如对象实际叫 uploads/demo.jpg，但你访问的是 uploads/demo.JPG，或者访问的是 uploads/demo.jpg/。S3 的对象 Key 是大小写敏感的，jpg 和 JPG 是两个完全不同的对象。

403 Forbidden

403 和 Access Denied 在观感上很像，但你细看错误码有区别。403 很多时候是签名问题，比如你给某个对象做了预签名链接，但链接过期了；或者你用了错误的凭证去请求私有对象。如果是匿名访问公开对象时返回 403，多半还是策略没生效，回到上一步检查。

图片不显示，而是被下载了

这说明对象读取成功，权限没问题，卡在 Content-Type 上。S3 返回给浏览器的是 binary/octet-stream，浏览器不认识，就只能下载。解决方式是在对象详情页的“属性 -> 元数据”里检查 Content-Type 是不是 image/jpeg/image/png，不对就修改保存；如果用 CLI/SDK 上传，就在上传时加 --content-type 参数或 ExtraArgs={"ContentType": "image/jpeg"}。

有些地区能打开，有些地区打不开

这种情况如果权限确认没问题，大概率是服务侧的网络节点差异。比如 S3 的新建存储桶在部分区域强制要求使用 Virtual-hosted 风格链接；又或者当前网络环境无法稳定访问 AWS 服务。这个属于环境层面，而不是你配置的问题。你可以让朋友在不同网络下试一下，排除自己本地网络的干扰因素。

5.3 用一条 curl 命令快速验证

排查时我一般不打开浏览器，直接 curl 一下看响应头和状态码，效率高得多：

bash复制curl -I "https://my-public-demo-2024.s3.ap-northeast-1.amazonaws.com/uploads/demo.jpg"

返回的 HTTP 头如果第一行是 HTTP/1.1 200 OK，说明链接已可公开访问。如果输出 403 Forbidden 或 AccessDenied，那就回到权限配置去查。如果输出 404 Not Found，那就是 Key 拼错了。这一步可以帮你把问题和网络环境彻底隔离开，快速定位到底是不是权限配置的锅。

6. 公开链接不是终点：安全收敛和后续扩展建议

6.1 公开了图片，也别踩这几条安全红线

虽然文章开头我就强调过“对象公开不等于桶列举公开”，但还是有一个常见翻车点：桶策略里 Action 写成了 ["s3:GetObject", "s3:ListBucket"]，Resource 里只写了 arn:aws:s3:::bucket-name/*。这样写其实是有问题的，因为 ListBucket 操作作用在桶这一层，Resource 需要单独写 arn:aws:s3:::bucket-name，如果你混在一起，AWS 控制台保存时可能报错，就算保存成功了，权限范围也难以理解，等于把自己的文件列表全部暴露出去。

我的建议是：如果你只需要单个链接，策略里只保留 s3:GetObject，Action 数组里不要出现 s3:ListBucket。别为了“以后可能要列举”而提前开权限，真到以后再说，权限永远是越收越安全。

另外，不要在代码里硬编码 AccessKey。我在很多项目里见过工程师把 aws_access_key_id 直接写进 Python 文件，然后不小心把代码提交到公开仓库，Key 泄露后被人刷了大量 S3 流量。正确的做法是用 IAM 角色的临时凭证，或者环境变量注入。如果只是个人学习，至少把密钥放到 .env 文件里，并且确保 .env 被 gitignore 忽略。

6.2 访问量大或想要自定义域名，优先接 CloudFront

文章标题说的是“可访问链接”，到这里基础目标已经完成了。但如果你这个链接要给很多人用，或者想绑定自己的域名，我强烈建议你加一层 CloudFront，也就是 AWS 的内容分发网络。

S3 的存储桶是有地域限制的，你把桶建在东京，那人在美国访问时可能要绕小半个地球，首字节延迟会很高，而且 S3 本身对流量也有费用，请求量大了账单会很难看。CloudFront 可以在全球边缘节点缓存你的图片，用户访问时从最近的节点返回内容，延迟降低，同时还能给 S3 源站加一层 OAI（Origin Access Identity），这样你甚至可以把 S3 桶重新设成私有，只允许 CloudFront 回源访问。既保住了性能，又补上了安全短板。

如果你要绑定自定义域名，还需要证书服务 ACM 给域名申请免费 HTTPS 证书，再把证书关联到 CloudFront 上。这整套做下来会别有一番折腾，但它是目前 AWS 官方推荐的对外分发静态文件的最佳实践。这篇先点到为止，有兴趣的话后续可以单独写一篇 CloudFront 接入教程。

6.3 我个人在实际操作中的最后一点体会

我从第一次用 S3 到现在踩过不少坑，最深刻的经验是：S3 本身并不难，难的是 AWS 把大量安全开关默认开到了最严格的状态，导致新手在面对“为什么链接打不开”时，分不清到底是策略写错了、Block Public Access 没放行、还是对象本身就传错了路径。

所以你在做任何一次“公开放通”操作前，先给自己 3 秒钟想清楚：我到底要公开的是什么？要不要保留列举权限？有没有更收敛的写法？这三个问题想清楚，你的 S3 权限配置基本不会出大岔子。真出了问题，也按着第 5 节的排查思路一步步走，不要一上来就把 Block Public Access 全关，那样可能临时能用，却给你埋下更大的安全隐患。最终你会发现在 AWS 上做一张图片的公开链接，核心流程就那么几步，难的不是操作，而是你想不想得明白权限模型。