AWS S3 适合存放图片、视频、附件、备份、日志、静态资源和数据集。
S3 的核心价值是把文件从 EC2 服务器里独立出来，用对象存储管理，再按访问频率、权限和生命周期控制成本。
AWS S3 是什么
S3 不是 EC2 云盘
EC2 是云服务器，EBS 是挂载到 EC2 上的云硬盘，S3 是对象存储。
EC2 负责运行程序。
EBS 负责系统盘、程序盘、数据库盘。
S3 负责保存文件、备份、静态资源、日志和数据对象。
网站图片、用户上传文件、下载包、日志归档、备份文件，不应该长期堆在 EC2 系统盘里。系统盘空间会越来越乱导致迁移和备份也会变麻烦。
更好的做法是程序在 EC2运行，文件放进 S3，访问加速交给 CloudFront。
购买 EC2 时就应该一起规划文件存储。
服务器区域、系统盘大小、S3 区域、备份策略和 CDN 分发会影响后期架构，单独看服务器配置不够。
关于服务器开通流程可以阅读 亚马逊云服务器购买。
Bucket、Object、Key、Region 怎么理解
S3 的基础结构很简单。
Bucket 是存储桶，可以理解为一个独立的文件空间。
Object 是具体文件，例如图片、PDF、视频、备份包。
Key 是对象路径和文件名，例如 images/product-01.jpg。
Region 是数据所在区域，例如新加坡、东京、美国东部。
Bucket 名称需要全局唯一，创建时要选择 Region。
正式项目建议按项目、环境和用途命名，例如 project-prod-assets、project-backup-sg、project-log-archive。
名称混乱会影响权限管理、账单核对和生命周期规则维护。
S3 适合哪些业务
S3 适合保存“文件型数据”，不适合直接当服务器硬盘或数据库使用。
适合放在 S3 的内容包括：
使用上下箭头键调整元数据面板的大小。上移下移切换面板：WPCode Page Scripts
| 场景 | 用法 |
| 网站图片和附件 | 用户上传文件、产品图、文章图片 |
| 静态资源 | JS、CSS、安装包、下载文件 |
| 备份文件 | 数据库备份、系统备份、业务归档 |
| 日志归档 | 访问日志、程序日志、审计日志 |
| 数据集 | 训练数据、分析数据、原始文件 |
| CDN 源站 | 配合 CloudFront 做全球分发 |
数据库文件、频繁随机读写文件、程序运行目录，不适合直接放 S3。S3 的访问模型是对象读写，不是本地文件系统。
创建 S3 存储桶前要确认什么
先选 Region
S3 bucket 创建时要选 Region。
网站服务器在新加坡，S3 可以优先选新加坡；用户主要在日本，可以考虑东京；面向美国用户，则根据业务区域选择美国节点。
Region 影响数据存放位置、回源延迟、合规要求和部分费用。
配合 CloudFront 后，终端用户访问会被边缘节点加速，但源站位置仍然影响回源效率和管理策略。
Bucket 名称要有规则
正式项目不要随便命名 bucket。建议按“项目 + 环境 + 用途”组合：
| 用途 | 命名示例 |
| 生产图片资源 | brand-prod-assets |
| 数据库备份 | brand-db-backup-sg |
| 日志归档 | brand-log-archive |
| 测试环境文件 | brand-test-upload |
使用上下箭头键调整元数据面板的大小。上移下移切换面板：WPCode Page Scripts
使用上下箭头键调整元数据面板的大小。上移下移切换面板：WPCode Page Scripts
不要在 bucket 名称里放个人隐私、客户信息、随机字符或无法识别的缩写。
后期做权限、生命周期、账单拆分时，清晰命名能减少很多管理成本。
默认不要开放公共访问
新建 bucket 时，Block Public Access 默认应保持开启。AWS 官方说明，S3 Block Public Access 可以在账号、bucket、access point 等层级阻止公开访问；新建 bucket、access point 和 object 默认不允许公开访问。
公开访问不是不能用，但必须按场景处理。
网站公开图片、私有备份文件、程序读取文件、临时下载文件，权限设计完全不同。最差的做法是为了让图片能打开，直接关闭整个 bucket 的公共访问限制。
AWS S3 基础配置流程
创建 Bucket
进入 AWS S3 控制台，选择 Create bucket，填写 bucket name，选择 Region。权限部分先保留 Block Public Access，不要为了测试直接开放整个 bucket。
创建后进入 bucket，可以按用途创建文件夹前缀，例如：
使用上下箭头键调整元数据面板的大小。上移下移切换面板：WPCode Page Scripts
| 前缀 | 用途 |
| images/ | 网站图片 |
| uploads/ | 用户上传文件 |
| backup/ | 备份文件 |
| logs/ | 日志归档 |
| dataset/ | 数据集文件 |
S3 里的“文件夹”本质上是 key 的前缀，不是传统服务器目录。
这个区别会影响权限策略、生命周期规则和批量管理。
上传文件
少量文件可以通过控制台上传。程序、批量任务、自动化部署应使用 AWS CLI 或 SDK。
CLI 示例：
aws s3 cp ./logo.png s3://your-bucket-name/images/logo.png
批量同步示例：
aws s3 sync ./static s3://your-bucket-name/static/
控制台适合测试。生产环境不要靠人工上传维护，应该让程序、部署脚本或 CI/CD 流程处理文件同步。
设置访问方式
S3 的访问方式要按场景设计。
| 场景 | 推荐方式 |
| 私有备份 | Bucket 保持私有，只给指定 IAM 角色权限 |
| 网站图片 | S3 保持私有，通过 CloudFront 分发 |
| 程序读取 | EC2 使用 IAM Role 访问 S3 |
| 临时下载 | 使用 Presigned URL |
| 静态网站 | 单独配置静态网站托管和权限策略 |
Presigned URL 适合临时下载或上传。AWS 文档说明，S3 对象默认是私有的，object owner 可以创建 presigned URL，把对象在限定时间内分享给其他人访问。
S3 权限怎么设置才安全
Block Public Access 默认不要关
新手最常见错误是直接关闭 Block Public Access，再给 bucket 加公开读权限。
这样能解决访问问题，但会扩大暴露面。
更安全的做法是：
| 文件类型 | 权限处理 |
| 备份文件 | 保持私有 |
| 日志文件 | 保持私有 |
| 用户上传文件 | 默认私有，按业务授权访问 |
| 网站图片 | 通过 CloudFront 分发 |
| 下载文件 | 用 Presigned URL 或指定路径策略 |
AWS 也建议通过 Block Public Access 防止 S3 资源被错误公开，并在需要公开访问前确认应用是否真的依赖公共访问。
IAM Policy、Bucket Policy、ACL 的区别
IAM Policy 控制某个用户、角色或程序能访问哪些 AWS 资源。
Bucket Policy 控制某个 bucket 对哪些主体开放什么权限。
ACL 是较旧的对象级访问控制方式，新项目不应优先依赖 ACL。
一般项目按这个顺序设计权限：
| 需求 | 优先方案 |
| EC2 程序访问 S3 | IAM Role |
| 某个团队访问指定 bucket | IAM Policy |
| 指定 bucket 允许 CloudFront 访问 | Bucket Policy |
| 临时给外部用户下载 | Presigned URL |
不要为了省事把 s3:*、Resource:* 给到长期 Access Key。权限越大，泄露后的损失越大。
Access Key 不要写进代码
程序访问 S3 时，不要把 Access Key 写进代码仓库、配置文件或镜像里。AWS S3 安全最佳实践明确建议，不要在应用程序或 EC2 实例中直接存储 AWS credentials，因为这类长期凭证不会自动轮换，泄露后可能造成严重业务影响。(AWS 文档)
EC2 上的程序访问 S3，优先使用 IAM Role。AWS 文档说明，IAM roles for EC2 可以让实例上的应用安全发起 AWS API 请求，而不需要开发者管理长期安全凭证。(AWS 文档)
S3 存储类型怎么选
S3 Standard 适合频繁访问文件
S3 Standard 是默认存储类型，适合频繁访问的数据。网站图片、常用附件、活跃业务文件、近期日志、热门下载资源，优先用 Standard。
不要为了降低每 GB 存储单价，直接把频繁访问文件放到低频或归档类型。低频和归档存储可能涉及取回费用、最短存储周期和访问延迟，真实成本未必更低。
Intelligent-Tiering 适合访问规律不稳定的数据
S3 Intelligent-Tiering 适合访问模式不稳定或难以预测的数据。AWS 官方说明，S3 Intelligent-Tiering 用于根据未知或变化的访问模式自动优化存储成本。(Amazon Web Services, Inc.)
适合使用 Intelligent-Tiering 的内容：
| 场景 | 原因 |
| 用户生成内容 | 上传后访问规律不固定 |
| 新业务数据 | 不清楚后续访问频率 |
| 数据湖文件 | 部分文件活跃，部分文件沉淀 |
| 长期保存资料 | 后续可能偶尔访问 |
它不是所有小文件的默认答案。Intelligent-Tiering 有监控和自动分层相关费用，小文件、短周期文件、访问规律明确的文件，要先算成本。
IA 和 Glacier 适合低频和归档
S3 Standard-IA 和 One Zone-IA 适合低频访问文件。它们不是“便宜版 Standard”，而是针对不经常访问的数据设计。
访问频繁时，取回和请求成本会抵消存储单价优势。
Glacier 系列适合长期归档和历史备份。AWS 官方说明，S3 Glacier Instant Retrieval、Glacier Flexible Retrieval 和 Glacier Deep Archive 面向长期保存、不常访问的数据，取回能力和成本结构不同。(Amazon Web Services, Inc.)
简单判断：
| 数据类型 | 存储类型 |
| 经常访问 | S3 Standard |
| 访问规律不确定 | S3 Intelligent-Tiering |
| 低频访问 | S3 Standard-IA |
| 可接受单可用区风险的低频数据 | S3 One Zone-IA |
| 长期归档 | S3 Glacier 系列 |
S3 费用
S3 不只按容量收费
S3 费用不只来自存储容量。AWS S3 Pricing 页面说明，费用会受到对象大小、存储时长、存储类型等因素影响，也涉及请求、数据传输、管理、复制等项目。(Amazon Web Services, Inc.)
实际账单通常由这些部分组成：
| 成本项目 | 说明 |
| 存储容量 | 每月保存了多少 GB / TB |
| 请求次数 | PUT、GET、LIST 等请求 |
| 数据取回 | 低频和归档类数据取回 |
| 数据传输 | 公网下载、跨区域传输 |
| 生命周期转换 | 不同存储类型之间转换 |
| 管理功能 | 分析、清单、监控等 |
| 复制功能 | 跨区域复制或同区域复制 |
只看每 GB 存储单价会低估真实成本。大量小文件、高频读取、跨区域访问、下载量增长，都会让账单上升。
价格要和 EC2、CloudFront 一起算
网站项目不能只算 EC2 实例价格，也不能只算 S3 容量价格。真实成本通常来自多服务组合：
EC2 运行程序。
S3 保存文件。
CloudFront 分发静态资源。
CloudWatch 保存日志。
EBS 保存系统盘和数据盘。
关于服务器、存储、流量和日志的项目，可以阅读 亚马逊云服务器价格。
把 EC2、S3、CloudFront 和流量放在同一张成本表里评估。
生命周期规则可以降低长期成本
S3 Lifecycle 可以根据对象生命周期自动转换存储类型、归档或删除对象。AWS 文档说明，Lifecycle rules 可以把对象转到成本更低的存储类型，也可以在指定时间后删除对象。(AWS 文档)
常见规则示例：
| 文件类型 | 生命周期策略 |
| 临时上传文件 | 30 天后删除 |
| 访问日志 | 90 天后转 IA，180 天后归档 |
| 数据库备份 | 保留最近 30 天，历史备份转 Glacier |
| 静态资源旧版本 | 保留一段时间后删除 |
| 数据集 | 长期保存，按访问频率分层 |
生命周期规则不要照抄模板。图片、日志、备份、数据集的访问规律不同，应该分别设置前缀规则。
S3 和 EC2、CloudFront 怎么配合
EC2 负责程序，S3 负责文件
一个标准网站架构可以这样拆：
| 层级 | 服务 |
| 应用运行 | EC2 |
| 数据库 | RDS 或自建数据库 |
| 图片和附件 | S3 |
| 静态资源加速 | CloudFront |
| 日志和备份 | S3 |
这种结构比“所有东西放在一台服务器”更容易扩展。
EC2 系统盘不会被用户文件拖满，图片和附件也更方便做 CDN 分发和生命周期管理。
CloudFront 负责加速访问
S3 可以作为 CloudFront 源站。
用户访问图片、JS、CSS、下载文件时，CloudFront 会从边缘节点返回缓存内容，减少源站压力，也改善跨区域访问体验。
公开资源不一定要公开整个 S3 bucket。
更常见的做法是 S3 保持私有，由 CloudFront 访问 S3，再由 CloudFront 面向用户提供访问入口。
这样方便后续配置缓存、HTTPS、自定义域名和访问控制。
长期项目要把账单和权限一起规划
项目长期使用 EC2、S3、CloudFront、RDS 后，账单会从单一服务器费用变成多服务费用。
账号主体、付款方式、权限分配、发票、预算提醒和充值续费都要一起规划。
需要长期稳定使用 AWS 的团队，可以通过 AWS代理 协助账号开通、权限规划、充值续费、账单核对和基础技术支持。
企业付款、USDT 充值或信用卡支付不方便时，可以在账单规划阶段了解 AWS代付。
具体优惠和适用范围应按账号类型、充值金额、产品范围和实际规则确认。
新手使用 S3 常见错误
把 S3 当成服务器硬盘
S3 不是挂载盘。程序不能把 S3 当成本地目录做高频随机读写。
数据库文件、系统文件、程序运行目录，不应该直接放 S3。
S3 更适合对象级读写。
上传一个文件，读取一个文件，按 key 管理一个对象。这是它和本地文件系统的核心区别。
为了访问图片公开整个 Bucket
图片可以公开，不代表整个 bucket 都要公开。公开整个 bucket 后，后续上传的备份文件、日志文件、用户文件可能被误暴露。
正确做法是按路径、对象和访问方式设计权限。网站静态资源可以走 CloudFront，临时下载可以用 Presigned URL，程序访问用 IAM Role。
只看容量，不看请求和流量
S3 容量不大，账单也可能增加。原因通常在请求次数、下载流量、跨区域传输、取回费用和日志存储。
大量小文件比少量大文件更容易产生请求费用。低频存储如果经常被读取，也可能不省钱。归档存储适合长期保存，不适合频繁恢复。
S3 的实际选择思路
频繁访问的图片、附件、静态资源，先用 S3 Standard。
访问规律不清楚的数据，用 Intelligent-Tiering 做成本优化。
低频访问文件，再考虑 Standard-IA 或 One Zone-IA。
长期归档和历史备份，放 Glacier 系列。
私有文件保持私有，公开访问优先通过 CloudFront 或 Presigned URL 处理。
程序访问 S3，优先用 IAM Role，不要把 Access Key 写进代码。
S3 配置不难，真正影响长期使用的是权限、访问方式、生命周期和费用模型。正式项目不要等 EC2 磁盘快满了才迁移文件，也不要等账单异常后才拆存储类型。服务器、对象存储、CDN、备份和账单应该在项目开始时一起规划。
