跳到正文Seminar Week 9 Summary · Jimmy Huang's BlogSeminar Week 9 Summary
本页目录· 128 条
这一页有部分内容暂时无法显示，其余内容完整。
ChatGPT 说›Learning Outcomes
理解无服务器计算（Serverless Computing）的核心思想：开发者关注应用逻辑，而不是服务器和底层基础设施。
理解函数即服务（Function as a Service, FaaS）与 Serverless 的关系：FaaS 是 Serverless 的一种重要实现形式，但二者不完全等同。
掌握 FaaS 的基本工作流程：部署代码、定义触发器、由事件触发函数执行、自动扩缩容。
能够解释 AWS Lambda 的使用方式、适用场景、价格模型和限制。
能够说明 Amazon API Gateway 在 Serverless 架构中的作用。
能够比较传统架构、微服务架构和 Serverless 架构的差异。
根据课堂补充，理解虚拟私有云（Virtual Private Cloud, VPC）、公有子网、私有子网、NAT Gateway、Security Group、Network ACL 和 VPC Peering 的基本概念。
能够从“架构设计取舍”的角度判断：什么时候适合使用 FaaS，什么时候传统服务器或 EC2 可能更合适。
本周在课程中的位置
本周内容是在前几周 AWS 基础服务之后进一步扩展到更高级的云架构模式。
前面课程已经讲过：
EC2：自己管理虚拟机实例。
S3：对象存储。
数据库服务，例如 DynamoDB。
IAM：身份与权限控制。
REST API、微服务、基本云架构设计。
传统云服务分类：
基础设施即服务（Infrastructure as a Service, IaaS）
平台即服务（Platform as a Service, PaaS）
软件即服务（Software as a Service, SaaS）
1. 什么是 Serverless?
1.1 基本定义
无服务器计算（Serverless Computing）并不是真的“没有服务器”，而是指：
Serverless 是一种隐藏服务器使用细节的平台，它按需运行代码，自动扩缩容，并且通常只按照代码运行时间计费。
1.2 Serverless 解决什么问题？
传统云服务中，即使使用 EC2、S3、数据库等服务，开发者仍然需要理解很多基础设施配置，例如：
EC2 实例规格如何选择；
服务器如何部署；
存储如何配置；
数据库如何管理；
是否需要高可用；
如何扩缩容；
如何监控和打补丁；
如何处理操作系统和运行环境。
如果开发者只想写业务逻辑，而不想花大量时间管理服务器和基础设施，那么云平台可以替开发者管理这些底层部分。
1.3 Serverless 的核心思想
Focus on application logic Hide infrastructure management
2. Serverless 和 FaaS 的关系
2.1 FaaS 是什么？
函数即服务（Function as a Service, FaaS）是一种 Serverless 计算平台。
在 FaaS 中，最小的计算单位不是虚拟机，也不是容器，而是：
HTTP 请求来了；
文件上传到 S3；
数据库新增了一条记录；
消息队列收到消息；
定时任务时间到了；
监控系统发现某个指标超过阈值。
2.2 Serverless 不等于 FaaS
3. FaaS 的核心特点
3.1 计算单位是 Function
课堂中老师用 Kubernetes 的 Pod 做类比：
处理一张上传的图片；
生成缩略图；
验证用户请求；
查询数据库；
处理一条消息；
调用另一个服务；
执行一小段业务逻辑。
3.2 事件触发
HTTP 请求；
存储事件，例如文件上传；
数据库事件，例如插入新行；
事件流；
队列或消息系统；
定时任务；
监控事件；
基础设施事件；
代码构建事件。
3.3 Fully Managed
资源供应（Provisioning）
补丁更新（Patching）
自动扩缩容（Scaling）
监控（Monitoring）
日志（Logging）
高可用（High Availability）
运行环境管理
写函数代码；
打包上传；
定义触发条件；
配置必要的权限；
观察日志和结果。
3.4 按实际使用付费
4. Serverless 的演进位置
4.1 Bare Metal Servers
裸金属服务器（Bare Metal Servers）表示组织自己拥有或直接管理物理服务器。
控制权最高；
运维成本最高；
需要管理硬件、操作系统、网络、部署等全部内容；
扩展速度慢。
4.2 Virtual Machines
虚拟机（Virtual Machines, VMs）在物理服务器上虚拟化硬件资源。
比物理机更灵活；
多个 VM 可以共享同一批硬件；
但仍然需要管理操作系统、补丁、运行环境。
4.3 Containers
更轻量；
部署更快；
应用和依赖可以打包在一起；
但仍然需要管理容器平台、集群、扩缩容等。
4.4 Functions
函数（Functions）进一步把关注点推向应用逻辑。
不需要关心服务器；
不需要直接管理容器；
写函数、定义触发器即可；
平台负责运行和扩缩容。
从 Bare Metal 到 Functions，是云计算不断把“底层复杂度”往平台侧转移的过程。
5. 软件架构演进：Monolith → Microservices → Serverless
5.1 Monolithic Architecture
单体架构（Monolithic Architecture）把大部分功能放在一个整体系统里。
单体系统像一栋大楼，如果内部关键部分出问题，可能整栋楼一起受影响。
5.2 Microservices Architecture
微服务架构（Microservices Architecture）把系统拆成多个小服务。
每个服务负责一个较独立的功能；
服务之间通过 API 或消息通信；
更容易独立部署和扩展；
但系统整体复杂度上升；
需要管理服务发现、通信、监控、部署和容错。
5.3 Serverless Architecture
Serverless 架构继续把应用逻辑拆成更小的函数，并把运行管理交给平台。
6. FaaS 的工作流程
6.1 Step 1: Deploy Your Code
函数接收输入参数；
从参数中读取 name 和 place；
返回一段消息；
每次函数被触发时，都会根据传入参数生成结果。
6.2 Step 2: Define Triggers
有 HTTP 请求时运行；
有图片上传到 S3 时运行；
DynamoDB 表有新增记录时运行；
CloudWatch 监控发现异常时运行；
定时任务时间到了运行。
6.3 Step 3: Code Execution
函数被触发后，平台会创建或复用运行环境来执行函数。
短暂的；
无状态的；
自动管理的；
可以根据请求量扩展多个实例。
“ephemeral instance” 可以理解为：
7. FaaS 的优点
7.1 降低运维负担
服务器创建；
操作系统维护；
安全补丁；
基础监控；
日志基础设施；
扩缩容；
高可用部署。
7.2 自动扩缩容
如果请求量增加，平台可以自动创建更多函数实例处理请求。
7.3 对低频或波动负载更省钱
FaaS 不要求服务器一直运行，所以对以下场景更合适：
请求不连续；
流量波动大；
只在某些事件发生时运行；
执行时间短；
平时空闲时间多。
偶尔上传图片后生成缩略图；
定时执行清理任务；
用户偶尔触发支付处理；
文件上传后自动处理。
7.4 部署更快
8. FaaS 的限制与取舍
8.1 Stateless：默认不保存状态
FaaS 函数通常是无状态的（Stateless）。
8.2 No Sticky Sessions
传统 Web 应用中，有时会让同一个用户固定访问同一台服务器，这叫粘性会话（Sticky Session）。
8.3 Provider Limits
最大执行时间；
最大内存；
最大临时磁盘；
上传包大小；
并发数量；
请求大小；
环境变量大小。
课堂中还有一个问题提到 package size：
50MB 这类限制主要是函数代码包限制；
不代表图片、训练数据、大文件都要放进函数包；
大文件应该放到 S3 等外部存储中；
函数只负责读取、处理或触发逻辑。
8.4 Cold Start
冷启动（Cold Start）是 FaaS 的重要限制。
当函数第一次被调用，或者长时间没有被调用后再次调用时，平台可能需要：
准备运行环境；
加载代码；
初始化依赖；
启动函数实例。
如果之后请求连续到来，平台可能复用已有运行环境，延迟会降低。
8.5 Vendor Lock-in
供应商锁定（Vendor Lock-in）指的是系统越来越依赖某个云厂商的服务和接口，迁移到其他平台会变困难。
真正的锁定往往不是函数代码本身，而是函数周围集成的服务。
8.6 成本不一定永远更低
长期高并发；
长期高利用率；
请求持续不断；
每次执行时间较长；
需要 GPU 或特殊硬件；
需要长时间运行任务；
不是看到 Serverless 就一定选 Serverless。
9. AWS Lambda
9.1 AWS Lambda 是什么？
AWS Lambda 是 AWS 提供的 FaaS 服务。
在事件发生时运行代码；
自动管理底层计算资源；
自动扩缩容；
提供高可用；
让开发者不用管理服务器；
按实际计算时间和请求数收费。
9.2 Lambda 的两种主要使用方式
方式一：作为事件驱动计算服务
S3 Bucket 中有文件上传；
DynamoDB 表发生变化；
CloudWatch 监控事件触发；
其他 AWS 服务产生事件。
方式二：作为 HTTP 请求的计算后端
REST API；
Web 后端；
Mobile App 后端；
简单业务服务；
Serverless Web 应用。
9.3 Lambda 支持的语言
Node.js
Java
Python
C#
Go
PowerShell
10. Amazon API Gateway
10.1 API Gateway 是什么？
Amazon API Gateway 是 AWS 的完全托管 API 服务。
创建 API；
发布 API；
维护 API；
监控 API；
保护 API；
支持大规模访问。
10.2 API Gateway 可以连接什么？
Lambda 函数；
EC2 后端服务；
DynamoDB；
容器化服务；
Serverless workload；
Web 应用；
其他后端服务。
10.3 RESTful API 的特点
API Gateway 可以创建 RESTful API。
基于 HTTP；
支持无状态客户端-服务器通信；
使用标准 HTTP 方法。
10.4 API Gateway 在 Serverless 中的作用
在 Serverless 架构中，API Gateway 常用于：
用户如何通过 HTTP 访问函数；
如何暴露 REST API；
如何管理 endpoint；
如何做请求路由；
如何统一监控和保护 API。
11. Lambda 如何扩缩容？
平台可以创建多个函数实例；
请求可以被分配到不同函数实例；
开发者不需要手动创建服务器；
扩缩容由平台自动处理。
12. Serverless 的常见 Use Cases
课件列出了很多适合 Serverless / FaaS 的场景。
12.1 Multimedia Processing
多媒体处理（Multimedia Processing）是典型场景。
事件明确；
每次处理相对独立；
不需要服务器一直运行；
可以按上传数量自动扩缩容。
12.2 Database Changes / Change Data Capture
数据库变化或变更捕获（Change Data Capture）也适合 FaaS。
DynamoDB 新增一条记录；
数据库某个字段更新；
触发函数做审计；
检查数据质量；
同步到其他系统。
12.3 IoT Sensor Input
物联网传感器消息（IoT Sensor Input）适合事件驱动处理。
传感器上传数据；
函数根据数据执行报警；
根据消息量自动扩展处理能力。
12.4 Stream Processing
流处理（Stream Processing）适合处理不断到来的消息流。
12.5 Chat Bots
聊天机器人（Chat Bots）可能在某些时间段请求量很高。
高峰时自动扩容；
低谷时不需要持续运行服务器；
成本更符合实际使用。
12.6 Scheduled Batch Jobs
每天凌晨清理数据；
每小时同步数据；
定期生成报告；
定期扫描文件。
12.7 HTTP REST APIs and Web Apps
FaaS 可以用于传统 request-response 风格的 Web API。
12.8 Mobile Backends
用户登录；
获取内容；
上传文件；
推送通知；
处理简单业务逻辑。
12.9 Business Logic Orchestration
12.10 CI/CD Pipeline
持续集成流水线也可以用 Serverless 触发任务。
代码提交后触发构建；
构建完成后触发测试；
测试完成后触发部署；
不需要一直预留构建服务器。
13. 真实案例
课件中列出了一些使用 Serverless 的公司案例。
13.1 Coca-Cola
Coca-Cola 使用 Serverless Framework 来降低 IT 运维成本并加速服务部署。
自动售货机；
loyalty program；
每月大量访问；
通过 Serverless 获得明显成本节约。
13.2 Expedia
Expedia 使用大量 Lambda 调用处理：
CI/CD 平台事件；
基础设施治理；
自动扩缩容相关任务。
Serverless 不只是小项目可以用，大型企业也会在合适场景中使用。
13.3 A Cloud Guru / Heavywater / IoT 场景
视频课程平台中的受保护操作；
移动后端；
IoT 消息平台；
训练课程网站；
成本敏感、请求波动大的服务。
14. FaaS 的平台选择
14.1 Public Cloud FaaS
14.2 自建或开源 FaaS Framework
OpenWhisk
OpenFaaS
OracleFN
Kubeless
Fission
Iron Functions
Nuclio
如果使用 AWS Lambda，是把 FaaS 平台交给 AWS 管。
15. 什么时候适合用 FaaS？什么时候不适合？
15.1 适合使用 FaaS 的情况
请求量不稳定；
有明显事件触发；
每次任务执行时间较短；
不需要长期保存本地状态；
可以接受一定冷启动延迟；
希望减少服务器管理工作；
希望快速开发和部署；
负载有高峰和低谷；
成本按实际使用更划算。
上传图片后生成缩略图；
API Gateway 触发后端函数；
定时清理任务；
数据库变化后审计；
IoT 消息处理；
简单移动后端；
CI/CD 事件处理。
15.2 不适合使用 FaaS 的情况
长时间运行任务；
持续高负载；
几乎一直满负载运行；
需要 GPU 或特殊硬件；
需要大量本地状态；
对冷启动延迟极其敏感；
执行时间超过平台限制；
依赖非常大的运行包；
请求量巨大且每次都要付费，导致成本高。
16. 课堂补充：VPC 为什么本周提前讲？
课堂 transcript 中老师提到，VPC 和 Cognito 原本可能在后续周讲，但因为 Assignment 2 会用到，所以提前介绍。
Cognito 只被提到与 Assignment 2 有关，本段课堂内容没有深入展开 Cognito 的技术细节。
17. 什么是 VPC？
17.1 基本定义
虚拟私有云（Virtual Private Cloud, VPC）是在云平台中创建的逻辑隔离网络空间。
VPC 像是在 AWS 里划出一个属于你自己的虚拟数据中心网络。
IP 地址范围；
子网划分；
路由表；
网络网关；
安全组；
Network ACL；
公有资源和私有资源的隔离。
17.2 VPC 解决什么问题？
Web Server / API Gateway 等面向外部的组件放在 public subnet；
Database、internal backend、private service 放在 private subnet；
私有资源不能直接从公网访问；
需要通过受控路径访问，例如 Bastion Host、NAT Gateway 或内部路由。
18. Public Subnet 与 Private Subnet
18.1 Public Subnet
公有子网（Public Subnet）是可以和互联网通信的子网。
Web Server；
Load Balancer；
面向公网的 API；
Bastion Host / Jump Box；
需要公网入口的服务。
通常连接 Internet Gateway；
资源可以拥有 Public IP；
可以从互联网访问，但需要安全规则控制。
18.2 Private Subnet
私有子网（Private Subnet）不直接暴露到公网。
18.3 API Gateway 应放 public 还是 private？
如果 API Gateway 用来接收用户请求，它应该在 public subnet 还是 private subnet？
核心不是死记 public 或 private，而是看：
19. VPC 中可以配置什么？
19.1 在指定 Subnet 中启动 EC2
哪个 VPC；
哪个 subnet；
是否有 public IP；
使用哪个 security group。
同样是 EC2，放在 public subnet 和 private subnet 中，网络暴露程度完全不同。
19.2 配置 Route Table
路由表（Route Table）决定流量往哪里走。
Route Table 就像网络地图，告诉数据包应该走哪条路。
19.3 创建 Internet Gateway
互联网网关（Internet Gateway）让 VPC 中的资源能够与互联网通信。
Public subnet 需要通过 Internet Gateway 出入公网；
没有 Internet Gateway 的 subnet 通常不能直接访问公网；
只连接 Internet Gateway 还不够，还需要路由表和安全规则允许流量。
19.4 配置 Security Group 和 Network ACL
20. Default VPC vs Custom VPC
20.1 Default VPC
默认 VPC（Default VPC）是 AWS 自动创建的 VPC。
课堂中老师提到，之前很多操作其实都是直接用了 Default VPC。
20.2 Custom VPC
自定义 VPC（Custom VPC）需要自己配置更多内容。
IP 地址范围；
子网数量；
哪些是 public subnet；
哪些是 private subnet；
路由表怎么写；
是否配置 Internet Gateway；
是否配置 NAT Gateway；
安全组如何设置；
Network ACL 如何设置。
21. NAT Gateway
21.1 NAT Gateway 是什么？
网络地址转换网关（Network Address Translation Gateway, NAT Gateway）用于让 private subnet 中的资源访问互联网，同时不把这些资源直接暴露给互联网。
私有子网中的 EC2 或后端服务，有时需要访问外部网络，例如下载更新、调用外部 API。
21.2 NAT Gateway 的工作方式
NAT Gateway 会把私有 IP 转换为公网可用的地址进行对外访问。
返回流量再通过 NAT Gateway 回到私有资源。
21.3 NAT Gateway vs NAT Instance
NAT Gateway 是云平台托管的 NAT 服务；
22. Security Group vs Network ACL
22.1 Security Group
安全组（Security Group）是 AWS 中常用的访问控制机制。
Security Group 像一个“智能门卫”。
22.2 Network ACL
网络访问控制列表（Network Access Control List, Network ACL / NACL）通常作用在子网层面。
是无状态的（Stateless）；
入站规则和出站规则需要分别配置；
允许请求进来，不代表返回流量自动出去；
规则有编号；
编号越小，优先级越高；
一个 NACL 可以关联多个子网；
一个子网只能关联一个 NACL。
22.3 对比总结
22.4 NACL Rule Priority
因为 50 小于 100，所以 Rule 50 优先级更高。
23. Bastion Host / Jump Box
堡垒机（Bastion Host）或跳板机（Jump Box）用于从公网安全访问 private subnet 中的资源。
24. VPC Peering
24.1 VPC Peering 是什么？
VPC 对等连接（VPC Peering）允许两个 VPC 通过私有网络直接通信。
两个 VPC 中的服务需要互相访问；
不同团队的 VPC 需要通信；
不同 AWS 账户中的 VPC 需要连接；
系统按网络边界隔离，但部分服务需要互通。
24.2 VPC Peering 的关键限制：No Transitive Peering
VPC Peering 不支持传递性连接（No Transitive Peering）。
如果 VPC 2 要和 VPC 3 通信，必须单独建立：
25. VPC Flow Logs
课堂最后提到 VPC Flow Logs，但 transcript 中没有展开详细内容。
本次课堂重点不是 Flow Logs，重点还是 VPC、Subnet、Route、NAT、Security Group、NACL 和 Peering 的关系。
26. 老师课堂强调的重点
26.1 FaaS 和 Serverless 不是完全等同
26.2 FaaS 的核心单位是 Function
FaaS 的重点不是 VM，不是 container，而是 function。
小；
独立；
事件触发；
无状态；
短时间运行；
可自动扩缩容；
由平台托管。
26.3 “It depends” 是架构设计的核心
请求量；
请求是否连续；
单次执行时间；
是否需要状态；
是否需要 GPU；
是否能接受冷启动；
是否会产生 vendor lock-in；
成本模型是否合适。
26.4 Cold Start 和 Stateless 是必须理解的限制
冷启动会影响首次或低频调用延迟；
无状态意味着不能依赖本地内存保存长期数据。
26.5 API Gateway 是 Serverless API 的前门
API Gateway 负责暴露 API，Lambda 负责执行逻辑。
26.6 VPC 是 Assignment 2 相关基础
课堂中老师明确提到 VPC 和 Cognito 与 Assignment 2 有关。
public subnet 和 private subnet 的区别；
Internet Gateway 和 NAT Gateway 的区别；
Security Group 和 Network ACL 的区别；
Default VPC 和 Custom VPC 的区别；
VPC Peering 不支持 transitive peering。
26.7 AI 可以用，但必须理解自己提交的内容
27. 本周核心知识点速记
27.1 Serverless 一句话总结
Serverless 是一种让开发者不直接管理服务器、只关注应用逻辑的云计算模式。
27.2 FaaS 一句话总结
FaaS 是 Serverless 的一种形式，它以函数作为计算单位，由事件触发执行，并由云平台自动管理运行环境。
27.3 Lambda 一句话总结
AWS Lambda 是 AWS 的 FaaS 服务，用于在事件或 HTTP 请求发生时运行函数代码。
27.4 API Gateway 一句话总结
API Gateway 是应用的 API 前门，负责接收 HTTP 请求并把请求连接到 Lambda 或其他后端服务。
27.5 VPC 一句话总结
VPC 是云中的逻辑隔离网络，用于控制资源如何被放置、访问和保护。
27.6 NAT Gateway 一句话总结
NAT Gateway 让 private subnet 中的资源可以访问互联网，但不直接暴露给互联网。
27.7 Security Group 一句话总结
Security Group 是有状态的访问控制，常用于控制实例或资源级别的流量。
27.8 Network ACL 一句话总结
Network ACL 是无状态的子网级访问控制，需要分别配置入站和出站规则。
Summary
本周 Seminar 的主线是 Serverless 和 FaaS。Serverless 的核心目标是隐藏服务器管理，让开发者专注于应用逻辑；FaaS 是 Serverless 的一种重要实现方式，它以函数为基本单位，由事件或 HTTP 请求触发运行，并由云平台负责扩缩容、监控、补丁和运行环境管理。AWS Lambda 是 AWS 中的典型 FaaS 服务，常与 API Gateway、S3、DynamoDB 等服务组合，用于构建事件驱动系统和 Serverless API。
本周最重要的理解不是“Serverless 一定更好”，而是架构取舍：FaaS 适合低频、波动、事件驱动、短任务场景；但对于长期高负载、强状态、低延迟敏感或特殊硬件需求的系统，EC2、容器或传统架构可能更合适。
课堂 transcript 还补充了 VPC。VPC 是云中的逻辑隔离网络，核心是通过 public subnet、private subnet、route table、Internet Gateway、NAT Gateway、Security Group 和 Network ACL 控制资源访问。对于后续 Assignment 2，尤其要掌握 public/private subnet 的区别、NAT Gateway 的作用、Security Group 与 Network ACL 的区别，以及 VPC Peering 不支持 transitive peering。
例子
最容易混淆的几个点
1. API Gateway 不是 Internet Gateway
一个是应用层 API 入口，一个是网络层公网出口/入口。
2. NAT Gateway 不是 Internet Gateway
3. Public subnet 不是“名字叫 public 就 public”
一个 subnet 真正 public，通常需要同时满足：
4. Private subnet 不是完全不能上网
Private subnet 可以通过 NAT Gateway 访问互联网：
但互联网不能直接主动进来访问 private subnet。
5. Security Group 和 NACL 不是同一个东西
最后用一句话串起来
Bare Metal Servers
↓
Virtual Machines
↓
Containers
↓
Functions
越往右：越关注业务逻辑
越往右：越少关心底层技术栈实现
Monolith
↓
Microservices
↓
Serverless
Deploy Your Code
↓
Define Triggers
↓
Code Execution
(ephemeral instance)
少量请求 → 少量函数实例
大量请求 → 多个函数实例并行处理
请求减少 → 实例减少甚至归零
Convenience ↑ → Control / Portability ↓
用户上传图片
↓
图片进入 S3 Bucket
↓
S3 产生 file upload event
↓
触发 Lambda
↓
Lambda 生成缩略图
↓
缩略图保存回存储服务
用户发送 HTTP 请求
↓
API Gateway 接收请求
↓
API Gateway 触发 Lambda
↓
Lambda 执行业务逻辑
↓
返回 HTTP Response
User
↓
API Gateway
↓
Backend services
├── Lambda
├── EC2 / container service
└── Database
HTTP request → API Gateway → Lambda → response
多个用户发送 HTTP request
↓
API Gateway 接收请求
↓
API Gateway 产生 HTTP event
↓
触发多个 Lambda function instances
用户上传图片
↓
触发 Lambda
↓
压缩图片 / 生成缩略图 / 提取元数据
↓
保存处理结果
Mobile App / Web Frontend
↓
API Gateway
↓
Lambda
↓
Database / Storage
用户下单
↓
检查库存函数
↓
支付处理函数
↓
发送邮件函数
↓
更新数据库函数
Internet
↓
Public Subnet
↓
Private Subnet
Public subnet route table:
0.0.0.0/0 → Internet Gateway
Private subnet route table:
0.0.0.0/0 → NAT Gateway
Private EC2
↓
NAT Gateway
↓
Internet
Rule 100: Allow HTTP from 0.0.0.0/0
Rule 50: Deny traffic from a specific IP range
Your Laptop
↓ SSH
Bastion Host in Public Subnet
↓ internal SSH
Private EC2 in Private Subnet
VPC 2 ↔ VPC 1
VPC 1 ↔ VPC 3
Client
↓
API Gateway
↓
Lambda
↓
Database / Storage
API Gateway:
处理 HTTP API 请求，例如 /login, /orders, /upload
Internet Gateway:
让 VPC 和公网网络连通
Internet Gateway:
让 public subnet 里的资源可以直接和公网通信
NAT Gateway:
让 private subnet 里的资源可以主动访问公网，但不允许公网主动访问它们
Route Table 有 0.0.0.0/0 → Internet Gateway
资源有 public IP
Security Group / NACL 允许访问
Private Subnet → NAT Gateway → Internet Gateway → Internet
Security Group:
资源级别
有状态
常用于 EC2 / RDS / Lambda ENI 等资源
Network ACL:
Subnet 级别
无状态
入站和出站都要写
规则有优先级编号
用户请求先进 API Gateway；
API Gateway 把请求转给 VPC 里的后端；
VPC 里分 public subnet 和 private subnet；
public subnet 通过 Internet Gateway 面向公网；
private subnet 放后端和数据库，不直接暴露公网；
private subnet 如果要主动访问外网，就走 NAT Gateway；
route table 决定每个 subnet 的流量走 IGW、NAT 还是 local；
security group 控制具体资源能被谁访问；
network ACL 控制整个 subnet 的进出流量。
Internet
↓
API Gateway
↓
VPC
├── Public Subnet
│ ├── NAT Gateway
│ └── Route: 0.0.0.0/0 → Internet Gateway
│
└── Private Subnet
├── App Service
├── Database
└── Route: 0.0.0.0/0 → NAT Gateway
function main(params, context) {
return {
payload: 'Hello, ' + params.name + ' from ' + params.place
};
}