EC2 是虚拟服务器，但 AWS 还有很多更高层的计算服务。选择时要先判断你想管理多少基础设施。
Lambda
Lambda 是无服务器函数计算。你只上传函数代码，由事件触发执行。
AWS 负责：
- 准备服务器
- 扩容
- 运行环境
- 可用性
- 按毫秒计费
典型触发来源：
- API Gateway
- S3 事件
- SQS
- EventBridge
限制是单次执行最长 15 分钟，不适合长时间运行任务。
容器和编排
容器把应用、依赖、运行时和配置打包在一起，让应用在不同机器上表现一致。
编排负责管理容器生命周期，包括启动、停止、扩缩容、故障恢复和滚动更新。
ECS
ECS 是 AWS 自家的容器编排服务。
ECS on EC2：你管理底层 EC2，控制力更强。
ECS on Fargate：无需管理服务器，专注容器任务。
EKS
EKS 是托管 Kubernetes。
EKS on EC2：适合需要 Kubernetes 和底层控制的大规模工作负载。
EKS on Fargate：适合想用 Kubernetes 但不想管理节点的团队。
ECR
ECR 是容器镜像仓库，用于存储、管理和拉取镜像。
Fargate
Fargate 是容器的无服务器计算引擎。它不是编排器，而是运行容器的托管计算层，可以配合 ECS 或 EKS 使用。
其他计算服务
Elastic Beanstalk：上传代码后自动处理部署、扩容、负载均衡和健康检查。
AWS Batch：运行批处理任务，适合科学计算、转码、大规模并行处理。
Lightsail：轻量 VPS，价格可预测，适合小网站、博客、学习和测试环境。
Outposts：把 AWS 基础设施扩展到本地数据中心，适合低延迟、数据驻留或合规需求。
选择原则：
- 函数事件驱动：Lambda
- 容器但不想管服务器：ECS/EKS + Fargate
- Kubernetes 生态：EKS
- 简单 Web 应用部署：Elastic Beanstalk
- 批处理：AWS Batch
- 小型 VPS：Lightsail
- 本地混合云：Outposts
延伸理解
复习这篇时，不要只记住名词，要把重点放在 Lambda、容器、ECS、EKS、ECR、Fargate 和不同计算模型的运维边界。这类知识如果只停留在定义层面，很容易在面试或项目中答得很散。更好的理解方式是把它放进一个具体场景：谁在调用它，输入从哪里来，失败后谁负责恢复，数据或状态会不会被重复处理。
- AWS 复习不能只背服务名，要把服务放进真实架构：入口、计算、网络、存储、权限、监控和成本。
- 每个服务都应该问三个问题：解决什么问题、由谁运维、失败时影响范围是什么。
- 考试和实际项目都很重视边界：Region 与 AZ、托管服务与自管理服务、有状态与无状态资源。
在真实项目中，可以把它当成一个判断框架：先确认输入、约束、失败场景和可观测性，再决定具体工具或写法。 如果一个方案看起来很简单，要继续追问它在规模扩大、权限变化、异常恢复和团队协作下是否仍然成立。
实践检查清单
- 明确这个知识点在系统中的位置：是开发时约束、运行时能力、基础设施能力，还是协作流程。
- 写出一个最小可运行例子，并补一个失败例子；只会写 happy path 说明理解还不够稳。
- 记录常见误用：例如边界条件、权限假设、性能假设、同步/异步差异或环境差异。
- 把概念和项目经历关联起来：如果面试被追问，可以用自己的项目说明为什么这样选。
- 最后用一句话总结取舍：它牺牲了什么，换来了什么。
自测问题
- 这个主题解决的核心问题是什么？
- 如果不用当前方案，还有哪些替代方案？代价是什么？
- 最容易出错的边界条件在哪里？
- 如何在代码、测试或监控中验证它真的可靠？
项目化应用场景
可以把这类知识放到一个小型 SaaS 部署场景里理解：用户通过域名访问 CloudFront 或 Load Balancer，请求进入公有子网，应用运行在 EC2、ECS 或 Lambda，数据库和缓存放在私有子网，日志进入 CloudWatch，权限由 IAM 控制，静态文件放在 S3。复习每个 AWS 服务时，都要问它在这条链路中的位置是什么：入口、计算、网络、存储、安全、监控还是成本控制。这样比孤立背服务定义更容易判断选型。
常见误区：
- 只背服务名，不能画出请求链路。
- 忽略默认网络边界，把数据库放到公网。
- 没有估算成本和失败影响范围。