AWS 网络知识的核心是理解资源如何隔离、互联和对外访问。
Region 选择
选择 Region 时常考虑：
- 合规要求
- 离用户的距离
- 服务可用性
- 成本差异
高可用架构
高可用通常通过多 AZ 部署实现。多个可用区彼此隔离，可以降低单点故障风险。
多 Region 架构可以进一步提升灾备能力，但成本和复杂度更高。
边缘站点
边缘站点用于把内容缓存到离用户更近的位置。CloudFront 是 AWS 的 CDN 服务。
VPC
VPC 是 AWS 中的虚拟私有网络。你可以在 VPC 中创建子网、路由表、网关和安全规则。
子网
Public Subnet 通常可以通过 Internet Gateway 访问互联网。
Private Subnet 通常不直接暴露给互联网，需要通过 NAT Gateway 出站访问。
网关
Internet Gateway：让 VPC 连接互联网。
Virtual Private Gateway：连接本地网络和 VPC。
Transit Gateway：连接多个 VPC 和本地网络。
NAT Gateway：让私有子网访问互联网，但不允许互联网主动访问私有资源。
安全组与网络 ACL
安全组是实例级别、有状态防火墙。
网络 ACL 是子网级别、无状态防火墙。
安全组通常更常用，网络 ACL 更适合做子网级的粗粒度控制。
延伸理解
复习这篇时，不要只记住名词，要把重点放在 Region 选择、边缘节点、CloudFront、Route 53、Global Accelerator 和跨区域可用性。这类知识如果只停留在定义层面，很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景：谁在调用它，输入从哪里来，失败后谁负责恢复，数据或状态会不会被重复处理。
- AWS 复习不能只背服务名，要把服务放进真实架构：入口、计算、网络、存储、权限、监控和成本。
- 每个服务都应该问三个问题：解决什么问题、由谁运维、失败时影响范围是什么。
- 考试和实际项目都很重视边界：Region 与 AZ、托管服务与自管理服务、有状态与无状态资源。
在真实项目中，可以把它当成一个判断框架：先确认输入、约束、失败场景和可观测性，再决定具体工具或写法。 如果一个方案看起来很简单，要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。
实践检查清单
- 明确这个知识点在系统中的位置：是开发时约束、运行时能力、基础设施能力，还是协作流程。
- 写出一个最小可运行例子，并补一个失败例子；只会写 happy path 说明理解还不够稳。
- 记录常见误用：例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
- 把概念和项目经历关联起来：如果面试被追问，可以用自己的项目说明为什么这样选。
- 最后用一句话总结取舍：它牺牲了什么，换来了什么。
自测问题
- 这个主题解决的核心问题是什么？
- 如果不用当前方案，还有哪些替代方案？代价是什么？
- 最容易出错的边界条件在哪里？
- 如何在代码、测试或监控中验证它真的可靠？
项目化应用场景
可以把这类知识放到一个小型 SaaS 部署场景里理解：用户通过域名访问 CloudFront 或 Load Balancer，请求进入公有子网，应用运行在 EC2、ECS 或 Lambda，数据库和缓存放在私有子网，日志进入 CloudWatch，权限由 IAM 控制，静态文件放在 S3。复习每个 AWS 服务时，都要问它在这条链路中的位置是什么：入口、计算、网络、存储、安全、监控还是成本控制。这样比孤立背服务定义更容易判断选型。
常见误区：
- 只背服务名，不能画出请求链路。
- 忽略默认网络边界，把数据库放到公网。
- 没有估算成本和失败影响范围。