Cloud Object Storage

基本概念¶

Object

在 Amazon S3 中，一个 Object 由三部分组成：数据本身（Data）、元数据（Metadata）和唯一键（Key）；其中 Metadata 不包含 bucket 信息，它只描述对象自身属性，包括系统定义元数据（如 Content-Type、Content-Length、Last-Modified、ETag、Storage Class 等）以及用户自定义元数据（以 x-amz-meta- 开头的键值对），而对象的完整定位依赖于 Bucket + Key，Metadata 仅用于描述该对象的属性信息。

Pre-Signed URL

Pre-Signed URL 是由服务器使用 AWS 凭证预先生成的一种临时授权访问链接，允许他人在不直接拥有 AWS 账号权限的情况下，在限定时间内对指定的 S3 对象执行操作（如 GET 下载或 PUT 上传）；它通过在 URL 中加入签名参数（基于 IAM 权限和过期时间）来实现安全控制，一旦超过设定的有效期链接即失效，常用于前端直传文件、临时下载私有文件或安全共享资源等场景，本质上是“带时间限制的授权访问链接”。

Versioning

Versioning（版本控制） 是一种功能，用于在同一个 Bucket 中为同一个对象保存多个版本；开启后，每次对对象进行覆盖上传或删除操作，S3 都不会真正替换或删除原文件，而是生成一个新的 Version ID，从而保留历史版本，删除操作则会生成一个 Delete Marker。这样可以防止误删或误覆盖，支持数据恢复和回滚；如果未开启 Versioning，对象被覆盖或删除后将无法找回，因此 Versioning 主要用于提升数据安全性与可恢复性。

Multipart Upload

Multipart Upload（分段上传） 是指把一个大文件拆分成多个独立的 Part 并行上传，全部上传完成后再由 S3 在服务端合并成一个完整对象；它适用于大文件（特别是超过 100MB 或必须分块上传的场景），优点包括支持并发提高速度、失败时只需重传失败的分段而不是整个文件、以及在网络不稳定环境下更可靠；每个 Part 最小 5MB（最后一块可小于 5MB），最多 10,000 个 Part，最终对象大小可达 5TB，如果上传未完成且未主动 Abort，对已上传的分段仍会产生存储费用，因此通常会结合生命周期规则自动清理未完成的分段上传。

CRR和SRR

在 Amazon S3 中，CRR（Cross-Region Replication） 和 SRR（Same-Region Replication） 都是基于 Versioning 的自动复制机制，用于把一个 Bucket 中的对象异步复制到另一个 Bucket，但区别在于复制目标所在区域不同；CRR 是跨 Region 复制（例如从 ap-southeast-1 复制到 us-east-1），常用于跨地域容灾、合规或降低访问延迟，而 SRR 是同一 Region 内复制（例如两个都在 ap-southeast-1），常用于日志集中管理、不同账户数据隔离或测试环境同步；两者都要求源和目标 Bucket 开启 Versioning，复制是异步进行的，并且复制后的对象会成为目标 Bucket 中的一个新版本。

Batch Replication

S3 Batch Replication 是一种用于补复制已有对象或复制失败对象的功能，它允许你在已经启用 Replication 规则的前提下，把规则生效之前存在的对象版本或历史未成功复制的对象批量复制到目标 Bucket；它基于 S3 Batch Operations 运行，通过生成任务对指定对象列表进行复制操作，适用于数据迁移、补齐历史数据或修复复制缺失的场景。

Lifecycle Rules

用于根据时间自动管理对象生命周期，包括两类核心操作：一是 Transition（转换），将对象在创建一定时间后自动迁移到更低成本的存储类别（例如 60 天后转为 Standard-IA，6 个月后转为 Glacier）；二是 Expiration（过期），在指定时间后自动删除对象（如日志 365 天后删除），同时也可用于删除旧版本文件（启用 Versioning 时）或清理未完成的 Multipart Upload；此外，Lifecycle 规则可以基于特定前缀（prefix）或对象标签（tag）进行精细化配置，实现自动化的成本优化与数据治理。

Requester Pays

S3 Requester Pays 是一种计费模式，在这种模式下，请求访问 Bucket 中对象的请求方（requester）而不是 Bucket 拥有者来承担数据传输和请求费用；也就是说，下载数据、发起 GET 请求或产生数据出站流量的账户需要为这些操作付费，而不是数据所有者付费。这种模式常用于开放数据集或跨账户共享数据的场景，例如企业对外共享大量数据但不希望自己承担高额下载费用；使用时，请求方必须在请求中显式声明 x-amz-request-payer: requester（或在 CLI 中加参数），否则请求会被拒绝。

S3 Storage Lens

一个用于可视化和分析 S3 使用情况与成本优化情况的监控与分析工具，它可以从组织级（AWS Organization）或账户级聚合多个 Bucket 的数据，提供存储使用量、对象数量、版本分布、未完成 multipart 上传、加密状态、公开访问风险等指标，并通过仪表盘和详细指标帮助你发现成本浪费或安全问题。

S3 Access Log

S3 Access Log（Server Access Logging）是 Amazon S3 提供的一种日志功能，用于记录对某个 S3 Bucket 或对象的访问请求详情，包括访问时间、来源 IP、请求者身份、请求类型（如 GET/PUT）、访问的对象 Key、HTTP 状态码以及传输字节数等；开启后，日志会被写入到你指定的另一个 S3 Bucket 中，主要用于安全审计、访问分析和问题排查，与记录管理操作的 CloudTrail 不同，它侧重于记录对数据本身的访问行为。

Glacier Vault Lock

用于实现 WORM（Write Once Read Many，写一次读多次） 的合规数据保护机制。它允许你创建一个不可更改的保留策略，一旦锁定后，数据在规定保留期内不能被删除或修改，哪怕是管理员也不行，用于长期归档数据保护。

Object Lock

用于在普通 S3 Bucket 上实现 WORM（Write Once Read Many）不可篡改存储，而且必须开启 Versioning（版本控制） 才能使用。它可以在指定时间内防止对象版本被删除或覆盖，用于合规和数据保留场景。有两种模式：Compliance 模式是在保留期内任何人（包括 root）都不能删除或覆盖对象版本且不能缩短保留时间的强制合规模式；Governance 模式是在保留期内大多数用户无法删除或修改对象版本，但具备特殊权限的用户可以绕过限制的较灵活模式。Retention Period 是为对象版本设定的固定保护时间，在此期间对象不能被删除或覆盖且通常只能延长不能缩短；Legal Hold 是一种与保留期无关的无限期锁定机制，只要开启对象版本就不能被删除，直到被手动移除。

Access Point

S3 Access Point 是为同一个 S3 Bucket 提供多个独立访问入口的机制，每个 Access Point 都可以配置单独的访问策略和网络限制（例如仅允许特定 VPC 访问），从而避免在一个复杂的 Bucket Policy 中集中管理所有权限；其工作方式是先将 Access Point 关联到某个 Bucket，AWS 会为其生成一个独立的专属 DNS 访问地址，应用通过该地址访问底层 Bucket，而访问权限由 Access Point Policy 与原有 Bucket Policy 共同控制。

疑难问题¶

Bucket名字为什么需要全球唯一？

Bucket 在创建时必须指定一个 Region，并且数据实际存储在该 Region 内；但其名称必须全球唯一，是因为它本质上属于 AWS 的全局命名空间，并且会直接作为访问 URL 的一部分参与 DNS 解析（如 bucket-name.s3.amazonaws.com），系统需要通过这个唯一名称在全球范围内准确定位到对应账户和区域的存储资源；如果名称不唯一，就会导致路由冲突、访问歧义以及潜在的安全问题，因此 AWS 设计为全球唯一以保证架构简洁、高效且安全。

S3 的安全机制是什么？

首先是 用户级（User-Based）控制，通过 IAM Policy 决定某个 IAM 用户或角色可以调用哪些 S3 API；其次是 资源级（Resource-Based）控制，包括 Bucket Policy（作用于整个 bucket，支持跨账户访问）、Object ACL（对象级更细粒度控制，可禁用）以及 Bucket ACL（较少使用，也可禁用）；然后说明访问判断规则：一个 IAM 主体能访问 S3 对象的前提是“用户 IAM Policy 允许 或 资源策略允许”，并且不能存在显式的 Deny（显式拒绝优先级最高）；最后提到 加密（Encryption），即使用加密密钥对对象进行加密以保护数据安全。

S3 设置为公开访问（public access），是否直接外部就能访问？

仅关闭 “Block Public Access” 并不等于对象自动可访问，你仍然需要有允许公共访问的策略（通常是 Bucket Policy 或对象 ACL）；也就是说，必须存在一条 Principal: “*” 且 Effect: Allow 的策略允许 s3:GetObject，外部用户才能匿名访问。即便 BPA 关闭了，你还需要明确授权。拒绝优先原则：在 AWS 中，显式的 Deny（拒绝）永远大于 Allow（允许）。

普通Replication和Batch Replication有什么区别？

普通 Replication（CRR / SRR）是在你开启复制规则之后自动生效，只会异步复制之后新产生的对象版本，适合持续性的实时同步；而 S3 Batch Replication 是一种补偿机制，用于批量复制规则生效前已存在的对象或之前复制失败的对象，它是一次性任务，需要显式创建批处理作业来执行，适合历史数据迁移或数据补齐场景，简单理解就是：普通 Replication 负责“以后新增的数据”，Batch Replication 负责“以前遗漏的数据”。

如果源 Bucket 开启了 Replication，在源中删除对象后，目标 Bucket 是否也会被删除？

当你在源 Bucket 执行普通删除（不指定 Version ID）时，会产生一个 Delete Marker；是否会同步到目标 Bucket，取决于你是否开启了“Delete Marker Replication”，如果开启，目标也会添加一个 Delete Marker（看起来也被删了），如果没开启，目标不会受影响。

当你在源 Bucket 执行指定 Version ID 的物理删除时，这种永久删除默认不会被复制到目标 Bucket，所以目标中的对应版本仍然存在。

常见的S3 Storage Class有哪些？

从 Standard（最热、最快、最贵）→ Deep Archive（最冷、最慢、最便宜），访问频率越低，成本越低，但取回时间越长；Intelligent-Tiering 则自动帮你在不同层级之间优化成本。取回速度（Retrieval Time）指的是当你请求读取一个对象时，从发起请求到数据可以被下载所需要的时间；对于 S3 Standard、Standard-IA、One Zone-IA 和 Glacier Instant Retrieval，这个时间是毫秒级（几乎立即可下载），而对于 Glacier Flexible Retrieval 和 Glacier Deep Archive，则需要先发起“恢复（Restore）”操作，等待几分钟到数小时后对象才会变为可下载状态。

S3 Glacier有哪些恢复速度选项？

见下表格

S3 Intelligent-Tiering有哪些特点？

通过小额监控费用自动根据对象访问模式在多个访问层之间切换（如 Frequent、Infrequent、Archive Instant、Archive、Deep Archive），无需手动配置生命周期规则且没有取回费用；对象默认处于 Frequent Access，30 天未访问转为 Infrequent，90 天未访问可转为 Archive Instant，另外还可以选择启用更深层的 Archive 或 Deep Archive 层（按可配置天数自动下沉），适合访问模式不可预测的数据以优化成本。

设置lifecycle转换存储方式的时候，对外地址保持不变吗？

是的，使用 Lifecycle 规则将对象转换到不同存储类别（例如从 Standard 转到 Standard-IA 或 Glacier）时，对象的对外访问地址（URL）、Bucket 名称和 Key 都保持不变；变化的只是对象的存储类别（Storage Class）属性，而不是对象标识，因此访问路径不受影响，不过如果转换到 Glacier 类（如 Flexible Retrieval 或 Deep Archive），在下载前需要先执行 Restore 操作，否则会报错，因为数据处于归档状态不可直接读取。

S3 事件通知结合 Amazon EventBridge 的机制是什么？

当 S3 Bucket 中发生事件（如对象创建、删除等）时，事件会被发送到 EventBridge，然后通过规则（rules）进行筛选和路由，最终分发到多个 AWS 服务作为目标（例如 Step Functions、Kinesis、Firehose 等）；相比传统的 S3 事件通知（只能发到 SNS/SQS/Lambda），使用 EventBridge 可以进行更高级的 JSON 规则过滤（基于对象名称、大小、元数据等），支持多个目标，并具备事件归档、重放（replay）和更可靠的投递能力。

S3 Transfer Acceleration的加速原理是什么？

S3 Transfer Acceleration 是一种利用 AWS 全球边缘节点（基于 CloudFront 边缘网络）来加速向 S3 上传和下载数据的功能；当开启后，客户端不再直接把数据发送到目标 Region，而是先上传到距离最近的 AWS Edge Location，然后通过 AWS 的专用全球骨干网络高速传输到实际的 S3 Bucket 所在区域，从而减少跨洲或长距离传输带来的延迟和丢包问题；它适用于跨国上传、大文件传输或网络质量不稳定的场景，但会产生额外加速费用，并且需要通过专用加速域名（如 bucketname.s3-accelerate.amazonaws.com）访问。

什么是S3的强一致性？

Read-after-write consistency（写后读一致性） 指的是当你向 S3 成功写入（PUT）一个新对象后，紧接着立即发起读取（GET）请求，一定能够读到刚刚写入的最新数据，而不会出现读到旧数据或读不到数据的情况；目前 Amazon S3 在所有区域对新对象的 PUT、覆盖写入和删除操作都提供强一致性（strong consistency），也就是说写成功后，后续的读取和列表（LIST）操作都会立即反映最新状态，不再像早期那样存在最终一致性延迟。

S3对象的加密有哪些方式？

1. SSE-S3（服务器端加密，使用 S3 托管密钥）：由 Amazon S3 自动管理和拥有加密密钥，对对象进行加密。该方式默认启用，使用 AES-256 算法，无需额外配置，适合对密钥管理要求不高的场景。

2. SSE-KMS（服务器端加密，使用 AWS KMS 密钥）：使用 AWS Key Management Service（KMS）管理加密密钥。支持更精细的访问控制、密钥轮换和审计日志（CloudTrail 记录），适用于对安全合规要求较高的场景。

3. SSE-C（服务器端加密，使用客户自提供密钥）：加密和解密由 S3 执行，但密钥由客户在每次请求时提供，AWS 不存储该密钥。适用于需要完全自行管理密钥的场景。

4. 客户端加密（Client-Side Encryption）：数据在上传到 S3 之前由客户端本地完成加密，S3 仅存储加密后的数据。密钥完全由用户控制，安全性最高，但实现和管理复杂度也更高。

S3客户端上传时是否需要指定加密参数？

如果 S3 Bucket 已经启用了默认加密（例如默认的 SSE-S3 或配置好的 SSE-KMS），那么在上传对象时不需要在请求 Header 中显式指定加密参数，S3 会自动对新对象进行加密；只有在你想覆盖默认加密方式（例如改用特定的 KMS Key），或者使用 SSE-C（客户自提供密钥）时，才需要在请求中显式添加相应的 x-amz-server-side-encryption 等 Header。

访问bucket资源会有CORS问题吗？

当访问是由浏览器发起（直接在地址栏输入URL的情况不算），并且请求的 S3 资源与当前网页的域名不同（即跨域请求），同时该 S3 Bucket 没有配置允许该来源的 CORS 规则时，就会出现 CORS 问题；本质上这是浏览器的同源策略限制，而不是 IAM 权限本身导致的。

大文件前端分片直传 S3 标准流程的流程是什么？

前端先请求后端创建 multipart 上传（后端调用 CreateMultipartUpload 获取 uploadId 并返回给前端），前端根据文件大小按固定分片大小切片，然后针对每个 partNumber 向后端请求对应的 presigned URL，前端使用这些 presigned URL 直接将每个分片 PUT 到 S3 并记录每个分片返回的 ETag，当所有分片上传成功且收集齐 {partNumber, ETag} 列表后，前端调用后端的 complete 接口，后端再调用 CompleteMultipartUpload 将所有分片合并为最终对象，若过程中需要取消，则由后端调用 AbortMultipartUpload 清理未完成分片。

在大文件前端分片直传S3时候，如何处理预签名URL过期？

预签名不要给太长：按业务把 expiresIn 设成“够用但不浪费”的短时间（常见是分钟级到 1 小时以内），因为预签名 URL 本质是谁拿到谁能用的限时通行证。

分片级签名、失败就续签重传：不要一次性生成所有 part 的 URL 然后祈祷不超时；更稳的是“按需生成/批量生成一小段窗口”，某个 part 403/过期就向后端再拿该 part 的新 URL，然后只重传这个分片。AWS 官方示例也常见这种“为各 part 生成 presigned URL”的模式。

Complete/Abort 放到服务端做更稳：服务端负责 CreateMultipartUpload / CompleteMultipartUpload / AbortMultipartUpload（或至少 Complete），前端只做 UploadPart，这样权限更好收敛、也方便统一处理异常和审计。

一定要配“清理未完成分片”的生命周期规则：S3 未完成的 multipart 会占用存储成本；官方明确建议用 Lifecycle 的 AbortIncompleteMultipartUpload 来自动清理。

权限最小化 + 约束上传范围：给生成签名的主体（后端角色/函数）最小权限，只允许特定 bucket/prefix、必要的 actions；预签名无法突破签名者本身的权限，所以“签名者权限做小”就是护栏。