AWS 存储和数据库服务覆盖了块存储、对象存储、文件存储、关系数据库、NoSQL 和缓存。
块存储
EC2 Instance Store 是临时本地存储，实例停止或终止后数据可能丢失。
EBS 是持久块存储，常挂载给 EC2 使用，适合操作系统盘和数据库磁盘。
对象存储
S3 是对象存储服务，适合图片、日志、备份、静态文件和数据湖。
S3 特点：
- 高持久性
- 按对象存储
- 支持版本控制
- 支持生命周期策略
- 可与 CloudFront 配合分发内容
文件存储
EFS 是弹性文件系统，可以被多个 EC2 实例共享挂载。
FSx 提供面向特定文件系统的托管服务。
关系数据库
RDS 是托管关系数据库服务，支持 MySQL、PostgreSQL、MariaDB、Oracle、SQL Server 等。
Aurora 是 AWS 云原生关系数据库，兼容 MySQL/PostgreSQL，性能和扩展能力更强。
NoSQL 与缓存
DynamoDB 是托管 NoSQL 键值/文档数据库，适合高并发低延迟场景。
ElastiCache 提供 Redis/Memcached 缓存能力。
DocumentDB 兼容 MongoDB。
Neptune 是图数据库，适合复杂关系数据。
AWS Backup 是集中化备份服务。
延伸理解
复习这篇时，不要只记住名词，要把重点放在 块存储、对象存储、文件存储、RDS、DynamoDB、缓存和分析型数据库的选择。这类知识如果只停留在定义层面，很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景：谁在调用它，输入从哪里来，失败后谁负责恢复，数据或状态会不会被重复处理。
- 数据库选型要从查询模式、写入模式、一致性要求、数据规模和团队运维能力出发。
- 关系数据库适合强约束和复杂查询，NoSQL 更适合特定访问模式下的扩展性。
- 索引、事务、隔离级别、备份恢复和迁移策略通常比单纯语法更影响系统稳定性。
在真实项目中，可以把它当成一个判断框架：先确认输入、约束、失败场景和可观测性，再决定具体工具或写法。 如果一个方案看起来很简单，要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。
实践检查清单
- 明确这个知识点在系统中的位置：是开发时约束、运行时能力、基础设施能力，还是协作流程。
- 写出一个最小可运行例子，并补一个失败例子；只会写 happy path 说明理解还不够稳。
- 记录常见误用：例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
- 把概念和项目经历关联起来：如果面试被追问，可以用自己的项目说明为什么这样选。
- 最后用一句话总结取舍：它牺牲了什么，换来了什么。
自测问题
- 这个主题解决的核心问题是什么？
- 如果不用当前方案，还有哪些替代方案？代价是什么？
- 最容易出错的边界条件在哪里？
- 如何在代码、测试或监控中验证它真的可靠？
项目化应用场景
可以把这类知识放到订单、用户或内容系统中理解：关系数据库适合保存强一致、强约束的数据，例如用户、订单和支付记录；NoSQL 适合访问模式明确、扩展压力大的数据，例如缓存、会话、时间线或键值配置。数据库设计不是先选工具，而是先写出主要查询：按什么字段查、是否分页、是否需要事务、写入频率多高、历史数据如何归档。
常见误区：
- 没有查询模式就先建表或集合。
- 滥用 JSON 字段导致查询和约束失控。
- 以为加索引一定更快，却忽略写入成本。