AWS 计算服务

考证时整理的 AWS 计算类服务笔记，涵盖无服务器、容器与批处理、工作流编排、弹性伸缩、轻量级实例以及 EC2 启动优化。重点放在容易混淆的服务边界和考点。

无服务器：Lambda

Lambda 是无服务器计算服务，运行代码无需管理服务器，按事件触发、按计算时间计费。工作流程：

1. 上传代码与配置：支持 Python、Node.js、Java、Go 等多种语言，同时配置触发器、执行角色、超时、内存大小等。
2. 事件触发：事件可来自 API Gateway 请求、S3 文件上传、DynamoDB 表更新、CloudWatch 定时触发等。
3. 调用执行环境：事件发生时调用执行环境运行代码，首次调用会创建新环境（Cold Start，冷启动）。
4. 执行与自动扩展：自动按请求量水平扩展并发实例，单次执行时间最长 15 分钟。
5. 结果返回与日志：返回结果并把日志发到 CloudWatch Logs。
6. 按需计费：按运行时间（毫秒计）和分配内存计费，闲置不收费。

Lambda@Edge

Lambda@Edge 是 Lambda 的扩展，专为 CloudFront 设计，让函数在离用户更近的边缘节点运行，实现对请求/响应的低延迟自定义处理。

它响应四类 CloudFront 事件：

• Viewer Request：观众请求到达边缘节点时
• Viewer Response：边缘节点向观众发送响应时
• Origin Request：边缘节点向源站请求内容时
• Origin Response：边缘节点收到源站响应时

常见用途：动态改 HTTP 请求/响应头、基于地理位置定制内容、A/B 测试和蓝绿发布、URL 重写重定向、安全认证和访问控制、处理 Cookie 和请求参数。

限制要记牢：运行时只支持 Node.js 和 Python，函数包大小和超时规定较严（最大 1 秒超时），代码更新需要时间传播到所有边缘节点。

举个考题场景：某社交应用在 ALB 后的 EC2 上运行，ALB 是 CloudFront 分发的源，存了数十亿张图、每秒处理数千张，想动态调整图像尺寸和格式且运维开销最小。方案是用带外部图像处理库的 Lambda@Edge 函数，关联到提供图像的 CloudFront 行为——直接在边缘处理图像请求，不用在 EC2 上装库，省运维也降延迟。

容器与批处理

Fargate

Fargate 是为容器设计的无服务器计算引擎，运行容器化应用而无需管理底层 EC2 实例。用户只需定义任务和服务，Fargate 负责启动、管理和扩展容器，自动处理集群规模、调度和环境维护。

常用场景：

• Web 应用和 API：快速部署和扩展，免去管理服务器。
• 微服务架构：自动扩展并管理容器。
• 数据处理：可与 AWS Batch 集成做无服务器并行处理。
• 机器学习：提供灵活可扩展的资源用于训练、测试、部署。
• 应用现代化：把传统应用迁移上云，更轻松地运行和扩展容器化负载。

AWS Batch

AWS Batch 是完全托管的批处理服务，自动化规划、安排和运行成千上万的批处理计算任务，并动态调整计算资源匹配作业需求，兼顾性能和成本。

工作机制围绕三个核心概念分工协作：

1. 作业定义（Job Definition）：定义作业需要的容器镜像、资源需求（CPU、内存）、环境变量、命令等，相当于作业模板。
2. 提交作业（Job Submission）：提交具体作业实例，指定作业定义、参数和队列，等待调度。
3. 作业队列（Job Queue）：作业进入队列，按优先级和资源可用性管理；可有多个队列对应不同优先级。
4. 计算环境（Compute Environment）：实际运行作业的资源池，基于 EC2 或 Fargate，支持托管和非托管两种，按队列需求自动扩缩。
5. 作业调度（Job Scheduling）：调度器从队列取可运行作业，综合资源需求、优先级、并发限制分配到计算环境。
6. 作业执行（Job Execution）：在分配的实例上运行作业代码（通常在容器中），并监控状态、日志、健康信息。
7. 状态管理与通知：跟踪作业状态（等待、运行、成功、失败），可配 SNS 通知或触发后续操作。

要注意 Batch 不是纯无服务器服务。它的计算环境主要依赖 EC2 实例或 Fargate，不像 Lambda 那样完全隐藏服务器基础设施，用户某种程度上仍需关注资源配额和类型。但通过自动扩展和管理，它确实大幅减轻了批处理环境的运维负担。

考题场景：一个 CPU 密集型批处理作业每小时跑一次，本地在 64 vCPU、512 GB 内存的服务器上平均 15 分钟完成，要求迁到 AWS 后以最小运维开销在 15 分钟内跑完。方案是在 EC2 上用 AWS Batch——它专为批处理设计，自动管理 EC2 实例的启停，按需扩缩，能充分利用 64 vCPU 并行运行，在规定时间内完成且运维开销最少。

Fargate 与 Batch 的关系

Fargate 解决「跑容器不想管服务器」，Batch 解决「批量作业的排队、调度和弹性资源管理」。两者可组合：Batch 的计算环境可以选 Fargate 作为底层，做无服务器的并行批处理。

工作流编排：Step Functions

Step Functions 是完全托管的工作流编排服务，通过定义状态机（State Machine）以可视化方式串起分布式应用和微服务里的各个组件。

• 状态机编排：定义状态和转换规则，控制执行顺序、分支、并行、错误重试和异常处理。状态类型包括任务状态（调 Lambda 或其他服务）、选择状态（条件判断）、等待、并行、终止等。
• 可视化工作流：图形界面展示执行路径和状态，方便调试监控。
• 多种集成：原生集成 Lambda、ECS、Glue、SageMaker、SNS、SQS 等，也支持调 HTTP 端点和自定义活动。
• 可靠可扩展：内置自动错误处理、重试和并发控制，工作流状态最长保存一年。
• 按需计费：按状态转换次数计费。

典型场景有数据处理流水线、微服务编排、机器学习流程、订单处理和审批流程。比如一个 ETL 流程：从数据库抽取数据（Task 调 Lambda 或 Glue）→ 判断数据质量（Choice）→ 数据转换（Task）→ 加载到 S3（Task）→ 发通知（Task 调 SNS）。状态机用 JSON 或 Amazon States Language（ASL）定义。

弹性伸缩

Application Auto Scaling

Application Auto Scaling 基于 CPU 利用率、内存、请求速率等指标，按预定义策略自动增减资源规模，让应用在高负载时有足够容量、低负载时省成本。可管理的资源包括：

• EC2 Auto Scaling 组（传统 EC2 Auto Scaling 有自己的机制，Application Auto Scaling 可覆盖更多资源类型）
• ECS 服务的任务数量
• DynamoDB 表和全局二级索引的读写吞吐量
• Aurora 或 RDS 集群的只读副本数量
• SageMaker 端点实例数
• 自定义资源

举例：游戏服务器在玩家激增时自动增加容器任务或数据库吞吐量保证流畅，低峰时段减少资源降低成本。

轻量级：Lightsail

Lightsail 是 AWS 的简化版云计算服务，面向开发者、初创和小型应用，以低成本、易用、快速部署提供虚拟服务器（VPS）、存储、数据库和网络功能。

• 简单易用：预配置虚拟服务器实例，无需深入了解复杂的 AWS 计算和网络服务即可快速启动管理。
• 固定定价：清晰固定的套餐价（含计算、存储、带宽），便于预算，避开复杂的按量计费。
• 集成服务：除虚拟服务器外，还支持数据库实例、对象存储、静态 IP、DNS 管理。
• 适合小型应用：网站托管、小型应用、开发测试环境、轻量级业务负载。

和 EC2 相比，Lightsail 更简化、易用但灵活性低，不适合复杂、大规模或高度定制的云架构。需要快速、简单、经济的环境时选它，是入门和轻量级应用的理想选择。

EC2 启动优化

需求突增时要从 AMI 快速创建大型 EC2 实例并放进 Auto Scaling 组，关键是压低初始化延迟。

方案：在快照上启用 Amazon EBS 快速快照恢复（Fast Snapshot Restore），用该快照创建 AMI，再用新 AMI 替换 Auto Scaling 组里的 AMI。

原理是 EBS 快速快照恢复能显著缩短从快照创建 EBS 卷的时间，从而降低 AMI 启动实例的延迟。以这类快照为基础做 AMI 并更新 Auto Scaling 组，扩容时实例能快速就绪，满足需求突增场景下的最小初始化延迟要求。这是底层存储性能层面的优化，其他不涉及存储优化的做法达不到同等效果。