VPC 可以理解为 AWS 里的私有网络空间。EC2 一定运行在某个 Subnet 中，Subnet 属于 VPC。
VPC 与 Subnet
VPC 是逻辑隔离的网络区域。Subnet 是 VPC 内的子网，用于按照安全或业务需求分组资源。
常见分法：
- Public Subnet：放 Web Server、Load Balancer 等面向公网资源
- Private Subnet：放数据库、内部服务等不直接暴露的资源
外部访问 EC2 的典型路径：
Internet -> Internet Gateway -> Network ACL -> Security Group -> EC2Internet Gateway
Internet Gateway 让 VPC 能与互联网双向通信。公有子网中的资源如果要被公网访问，需要：
- 子网路由表指向 IGW
- 资源有公网 IP
- 安全组允许入站
- NACL 允许进出
NAT Gateway
NAT Gateway 让私有子网中的实例访问互联网，但外部互联网不能主动访问这些实例。
典型用途：私有 EC2 下载补丁、调用外部 API。
VPN 与 Direct Connect
Client VPN：远程员工安全接入 AWS 或公司网络。
Site-to-Site VPN：公司本地数据中心和 VPC 之间建立加密隧道。
Direct Connect：专用物理链路，低延迟、高带宽，不走公网。
PrivateLink：通过私网访问 AWS、第三方或自建服务，不经过公网。
Transit Gateway
Transit Gateway 是连接多个 VPC 和本地网络的中心枢纽。它适合多 VPC、多账号、混合云环境。
Security Group 与 NACL
Security Group 是实例级防火墙。
- 有状态
- 只写允许规则
- 控制单个资源
- 返回流量自动允许
Network ACL 是子网级防火墙。
- 无状态
- 支持允许和拒绝
- 控制整个子网
- 入站出站都要写规则
简单记忆：
- Security Group 是实例门卫
- NACL 是子网海关
日常项目中安全组更常用，NACL 适合做更粗粒度的子网边界控制。
延伸理解
复习这篇时，不要只记住名词，要把重点放在 VPC、Subnet、路由表、IGW、NAT、VPN、Direct Connect、Security Group 与 NACL。这类知识如果只停留在定义层面，很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景：谁在调用它，输入从哪里来，失败后谁负责恢复，数据或状态会不会被重复处理。
- AWS 复习不能只背服务名，要把服务放进真实架构：入口、计算、网络、存储、权限、监控和成本。
- 每个服务都应该问三个问题：解决什么问题、由谁运维、失败时影响范围是什么。
- 考试和实际项目都很重视边界：Region 与 AZ、托管服务与自管理服务、有状态与无状态资源。
在真实项目中，可以把它当成一个判断框架：先确认输入、约束、失败场景和可观测性，再决定具体工具或写法。 如果一个方案看起来很简单，要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。
实践检查清单
- 明确这个知识点在系统中的位置：是开发时约束、运行时能力、基础设施能力，还是协作流程。
- 写出一个最小可运行例子，并补一个失败例子；只会写 happy path 说明理解还不够稳。
- 记录常见误用：例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
- 把概念和项目经历关联起来：如果面试被追问，可以用自己的项目说明为什么这样选。
- 最后用一句话总结取舍：它牺牲了什么，换来了什么。
自测问题
- 这个主题解决的核心问题是什么？
- 如果不用当前方案，还有哪些替代方案？代价是什么？
- 最容易出错的边界条件在哪里？
- 如何在代码、测试或监控中验证它真的可靠？
项目化应用场景
可以把这类知识放到一个小型 SaaS 部署场景里理解：用户通过域名访问 CloudFront 或 Load Balancer，请求进入公有子网，应用运行在 EC2、ECS 或 Lambda，数据库和缓存放在私有子网，日志进入 CloudWatch，权限由 IAM 控制，静态文件放在 S3。复习每个 AWS 服务时，都要问它在这条链路中的位置是什么：入口、计算、网络、存储、安全、监控还是成本控制。这样比孤立背服务定义更容易判断选型。
常见误区：
- 只背服务名，不能画出请求链路。
- 忽略默认网络边界，把数据库放到公网。
- 没有估算成本和失败影响范围。