aws-serverless

AWS Serverless

概述

此技能是 AWS 无服务器工作的路由器。对于每个应用组件和每个提出的决策维度（形态 + 容量提供方 + 编排 + 功能选择），它都会给出一个明确的建议，然后交由该组合所需的所有专用技能处理。不要强行让多组件应用采用同一种形态。此技能仅保留没有专用技能的 Lambda 共用参考资料。

搭配 AWS MCP server 使用效果最佳 — 推荐用于沙盒化命令执行和审计日志记录。所有指导也适用于标准 AWS CLI 访问方式。

**如何使用此技能：**第 0 步确定入口（新建、优化、迁移）；第 1 步路由已明确指定技术的组件；第 2 步针对每个组件逐层走完计算决策流程（第 1 层 → 第 3 层），直至确定其形态和容量提供方；第 4 层边缘情况详见 compute-decision-edge-cases.md；仅当请求涉及编排、事件处理和 HTTP 前端时，才执行第 3–5 步进行决策，完整对比详见 orchestration.md 和 api-gateway.md。随后交由所有适用的专用技能处理，并对没有专用技能的内容使用共用参考资料。

如果你的环境中无法使用某个路由到的技能，此处做出的决策仍然有效：根据下方的决策流程和共用参考资料作答，指出建议的形态及负责该形态的技能，不要因为其他形态的文档更容易找到就改用其他形态。特别是，对于 Node.js HTTP 应用，Lambda Web Adapter 不能替代 Web Functions — 它是面向非 Node.js 运行时、容器映像或现有 API Gateway 集成的 Event Functions 路径。

规则（适用于每项建议）

1. 针对每个组件和已确定的维度，明确给出建议。 写明 “使用 X，因为……”。不同组件有不同需求时，不要强行使用同一项服务，也不要用中立的对比表代替答案。对于 已确定 的维度，补充一句说明最接近的替代方案为何不适用（例如，Event 和 Web Functions 无法访问操作系统级别的 eBPF；Durable Functions 没有原生 .sync 集成，无法启动 Glue 或 ECS 任务并等待其完成），并且即使在查阅其他技能或文档后，也要在最终回复中保留建议及其理由。

2. 分别解决所有提出的组件和决策维度。 部署形态、容量提供方、编排和功能限制是彼此独立的决策；确定其中一项并不意味着其他项也已确定。不同组件可以采用不同的部署形态，一个组件也可以将计算部署形态与编排层搭配使用。

3. 推断事实，而非边界：回答前先对每个提出的维度进行分类。

   • 已确定 —— 请求给出了区分候选方案的事实（运行时、触发方式、明确的时长或大小、“所有步骤都是 Lambda 函数”、“持续运行”）→ 直接做出选择，不要就该维度提问。
   • 倾向性判断 —— 请求仅给出定性线索（“突发性”、“不均衡”、“夜间较空闲”、“依赖项较大”、“不可信”、“数千个短任务”、“需要一段时间”），而候选方案仍取决于某个未说明、可观察的事实 → 先给出暂定选择及理由，再直接向用户询问缺少的事实（以“？”结尾），并说明哪种回答会改变选择。说明哪些情况会改变答案，不能代替提问。线索可以支持倾向，但不能代替决定性事实。
   • 开放 —— 没有可用线索 → 使用该层级的缩小范围问题。
   • 未提出 —— 请求既未询问某个维度，也未提供相关信号 → 直接应用该维度的默认选项，不要提问（例如，没有流量、时长、实例类型或定价相关信号的事件触发函数，默认采用 Event Functions · On-Demand）。

   不要重新讨论未提出或已确定的维度；总体提问不得超过 3–4 个；绝不要只回复问题。当数值阈值决定方案时，在问题中写明该阈值，以便客户根据指标作答（例如，Managed Instances 的 Tier 3 要求 5–10 分钟内的峰值与均值之比低于 2）。

4. 根据新信息调整。 有新信息时，重新评估受影响的层级并更新建议。

5. 不要猜测事实。 有关限制、运行时、定价和超时的信息，应以以下共享参考资料为依据；精度至关重要时，应向当前 AWS 文档核实。

6. 按路径分流，不要重复推导。 选定专用技能后，遵循该技能的内容，不要在此重复推导。

步骤 0 — 入口：用户要做什么？

如果不明确，只问一次：“你是要启动新项目、调整现有工作负载，还是将现有工作负载迁移到无服务器架构？”

情境	线索	路径
新建应用	“正在构建”、“开始”、“新项目”、“从零开始”，未提及现有计算资源	步骤 1，然后进入步骤 2 的决策流程
优化现有工作负载	“账单太高”、“冷启动”、“太慢”、“延迟”，提及当前的 Lambda 配置	步骤 2 第 3–4 层（容量、冷启动、吞吐量），然后参阅 lambda.md、concurrency.md、troubleshooting.md
重新平台化／迁移	“从 EC2/ECS 迁出”、“容器化”、“摆脱服务器”、“现代化改造”	在步骤 2 中优先考虑运行时、时长和打包方式，然后进行优化

步骤 1 — 直接路由（请求已指明技术）

路由至	当请求提到或明确暗示	不要在以下情况路由
Event Functions — 此技能：lambda.md、event-sources.md	由事件源或触发器（SQS、Kinesis、Kafka、S3、DynamoDB Streams、EventBridge、SNS、API Gateway、ALB、IoT、Function URL）调用的 Lambda 函数、非 Node.js 运行时中的 HTTP 处理程序、容器映像、Lambda 层	监听端口的 Node.js HTTP 服务（Web Functions）、由客户管理的环境（MicroVMs），或尚未确定的计算方案 — 参见步骤 2。第 3 层仍负责确定容量提供方
aws-lambda-web-functions	Lambda Web Functions、aws lambda-web、在 Lambda 上部署 Node.js HTTP 服务（Express、Hono、Fastify）、由 CloudFront 提供服务的 Node.js 应用、多区域 HTTP 端点、按活跃 CPU 计费、原生 HTTP 响应流式传输	非 Node.js 运行时、容器映像、事件驱动触发器（SQS、Kinesis、S3、DynamoDB Streams）— 这些属于 Event Functions
aws-lambda-microvms	Lambda MicroVMs、Firecracker microVM 映像、launch/suspend/resume/terminate、可通过快照恢复的环境、VM 级隔离、不受信任的代码或 AI 生成代码执行、交互之间保留的文件／进程、操作系统访问（FUSE、eBPF）、使用自定义端口的 gRPC 或 WebSocket 服务、最长 8 小时的会话	仅提到普通请求／响应处理程序或事件处理程序的“隔离”。Event Functions 默认按函数隔离；只有环境必须专属于一个调用方时，才使用租户隔离模式
aws-lambda-managed-instances	Lambda Managed Instances（LMI）、容量提供方、CapacityProviderConfig、PerExecutionEnvironmentMaxConcurrency、由 EC2 支持的 Lambda、Lambda Savings Plans／Reserved Instances、函数指定实例类型、最长 90 分钟的异步执行或 ESM 执行	流量突增且可缩容至零，并且不要求指定实例类型或承诺用量
aws-lambda-durable-functions	持久执行、检查点与重放、context.step／context.wait／context.invoke、withDurableExecution、durable-execution-sdk、以代码形式编写的 Lambda Saga、LocalDurableTestRunner	可视化／ASL 工作流、Distributed Map，或对 AWS 服务及非 Lambda 计算资源进行广泛编排 — 参见步骤 3
aws-step-functions	状态机、Amazon States Language（ASL）、JSONata、Distributed Map、.sync／waitForTaskToken、编排 ECS/Fargate、Glue、SageMaker、Batch	由 Lambda 应用代码管理的代码优先编排 — 参见步骤 3
amazon-eventbridge-event-bus	新版 EventBridge 自定义事件总线（eventsv2）、任何发布自身应用事件的新工作负载（包括单账户工作负载）、发布／订阅、独立订阅者、基于事件的协作、由多个团队／账户共享的中央总线、按事件组有序传递、重放、保留、去重、采用开放格式（CloudEvents、Avro、Protobuf）的架构注册表，或从经典自定义总线迁移到上述功能	运维现有的带有规则和目标的经典自定义总线、EventBridge Scheduler、Pipes、Global Endpoints、单独使用 Schema Registry、API Destinations 或 Connections — 这些仍由此技能负责（步骤 4 和 orchestration.md）

步骤 2 — 计算方案决策流程

对每个应用组件分别运行各层级的判断。只有在前一层未能为该组件得出有把握的匹配结果时，才进入下一层。首先确定其形态（第 1–2 层）；第 3 层确定 Event Functions 的容量提供方，步骤 3 确定编排方式。如果提示过于含糊，无法识别任何组件，请询问：“你想构建什么？”

第 1 层 — 根据工作负载选择形态

Lambda 有三种形态：事件函数、Web 函数和 MicroVM。根据请求检查以下信号；容量提供方（按需 vs 托管实例）是第 3 层中单独做出的决定。

形态	请求中出现以下情况时选择	典型用例
事件函数	事件源或触发器（SQS、Kinesis、Kafka、S3、DynamoDB Streams、EventBridge、SNS、API Gateway、ALB、IoT、Function URL）、用于 HTTP 处理程序的非 Node.js 运行时、容器镜像、Lambda 层、事件扇出、重试/DLQ/幂等语义	事件驱动处理、队列/流消费者、服务间胶合、API Gateway 后端
Web 函数	监听端口的 Node.js HTTP 服务器（Express、Hono、Fastify）、I/O 密集型请求/响应（大部分时间都在等待网络）、原生响应流式传输或 SSE、长时间保持或长轮询连接、在一个沙盒中处理多个并发请求、前置 CloudFront、多区域端点、“仅为活跃 CPU 付费”	Node.js Web 应用和 REST 后端、流式 AI 响应、将并行调用扇出到下游服务并组装响应的 Node.js 后端
MicroVM	客户管理的沙盒生命周期（启动/挂起/恢复/终止）、必须在会话间保留的状态（内存、磁盘、进程）、不受信任或由 LLM 生成的代码、OS 访问权限（FUSE、eBPF）、自定义端口、按会话或按租户隔离 VM、最长 8 小时的会话	AI Agent 代码沙盒、浏览器 IDE 和笔记本、CI/构建运行器、安全扫描器、临时开发环境

如果请求描述了多个组件，可能会匹配多行。应分别为每个组件选择方案，例如，使用 Web 函数控制平面 API 搭配 MicroVM 会话工作进程，而不是将这些行视为整个应用互斥的选项。

决定取舍的限制：Web 函数和 MicroVM 仅支持按需；托管实例是事件函数的容量提供方（第 3 层），不是一种形态；持久函数仅支持事件函数（按需或托管实例）。Web 函数仅支持 Node.js（zip，不支持容器镜像、事件源映射、预置并发或 SnapStart）。时长上限：按需调用、Web 函数调用以及托管实例上的同步调用，每次调用最多 15 分钟；托管实例上的异步或 ESM 调用最多 90 分钟；每个 MicroVM 会话最多 8 小时；超过此时长则不适用于 Lambda。

缩小范围的问题（仅当第 1 层无法根据请求判断组件类型时才提问；已提供的信息无需重复询问）：

1. 函数 vs MicroVM — 提问：“此组件只是处理单个请求/事件，还是每个会话都需要一个能在交互之间保留文件、内存或进程的环境？” → 保留环境/客户控制生命周期 = MicroVM（确认每个会话 ≤ 8 小时）。单次执行 = 函数 → 问题 2。
2. 事件 vs Web — 提问：“此组件是通过队列、流、事件源或 Lambda HTTP 集成调用，还是一个监听端口的 Node.js HTTP 服务器？” → 事件/处理程序集成 = 事件函数 → 第 3 层。Node.js HTTP 服务器 = Web 函数候选项 → 第 2 层。

持久性不是形态选择问题：工作是否以多个协调步骤运行且必须在崩溃后继续，或是否需要等待计时器、回调或审批后再恢复，应在确定形态和容量提供方后，于第 3 步决定（持久函数运行于事件函数，可使用任一受支持的容量提供方：按需或托管实例）。

第 2 层 — Web Functions 与 Event Functions

当 Web Functions 是候选方案时，或第 1 层无法区分 Web Functions 与 Event Functions 时，对相应组件运行此层。先根据请求或项目推断运行时、打包方式和现有集成；只询问会影响方案选择的第一个缺失信息。

#	问题	答案 → 决策
Q1	应用使用什么运行时？	非 Node.js → Event Functions（例如，通过 API Gateway、ALB 或 Function URL 提供服务的 Flask/Django/Spring/.NET，可选用 Lambda Web Adapter）。Node.js → Q2
Q2	是否需要容器映像部署？	是 → Event Functions。否 → Web Functions
Q3	（仅当已有集成时）应用目前与什么集成？	CloudFront → Web Functions。API Gateway → Event Functions（现有集成会带来实际迁移成本；应有计划地迁移）

结果：Web Functions → 路由至 aws-lambda-web-functions（仅限 On-Demand；Provisioned Concurrency、SnapStart 和 Managed Instances 均不适用）。若尚未加载该技能，需了解要点：Node.js 服务器会继续在其端口上监听，无需重写处理程序；通过 aws lambda-web create-web-function 进行 zip 部署（若提示无法识别 lambda-web 命令，则说明 AWS CLI 版本过旧）；许多并发请求会共享一个执行环境，计费依据为活跃 CPU + 内存，因此因 I/O 阻塞的时间不计入 CPU 计费；支持原生响应流式传输（SSE、LLM 令牌）；提供全局 HTTPS 终端节点，可选多区域服务，并可在前端配置 CloudFront。Event Functions → 第 3 层。

第 3 层 — 容量提供方（仅限 Event Functions）

Event Functions 使用两种容量提供方之一运行。On-Demand 可缩至零，适合有明显空闲时段的突发或不可预测流量。Lambda Managed Instances 会在你账户中的 EC2 实例上运行函数，适合持续利用的流量（在 5–10 分钟内，峰均比低于 2）；需要指定 EC2 实例类型；使用 Savings Plans / Reserved Instance 定价；或单次执行时间长达 90 分钟（仅限异步或 ESM 调用）。典型的 Managed Instances 工作负载包括：持续繁忙的流消费者、通过 API Gateway 提供服务且始终繁忙的 API，以及长时间运行的异步批处理任务。

根据请求或指标推断流量模式。如果缺少相关信息且会影响决策，请用可观察的指标询问一次：“在任意 5–10 分钟的时间窗口内，峰值流量是否始终低于平均流量的两倍（峰均比低于 2）？还是流量会出现更高峰值，或骤降后长时间处于空闲状态？你是否需要承诺使用定价或指定实例类型？”

• 没有流量、执行时长、实例类型或定价方面的信号 → 推荐 Event Functions · On-Demand，不询问容量相关问题（规则 3，未触发）。
• 有突发流量或空闲时段，且不要求指定实例或承诺使用 → Event Functions · On-Demand。
• 持续利用，或要求指定实例／承诺使用 → Event Functions · Managed Instances → 转至 aws-lambda-managed-instances。

创建函数时就要选择 Managed Instances：创建一个附加到容量提供方的新函数，并将流量切换到该函数；不要把这描述为在现有的 On-Demand 函数上切换设置。

如果单次执行需要超过 15 分钟、最长可达 90 分钟（仅限异步或 ESM 调用；同步调用在两种提供方上都受 15 分钟上限约束），也应选择 Managed Instances。对于明确表示持续／始终繁忙的信号，不要仅为了询问实例类型或定价而重新提问。如果请求只说“稳定”，却没有可观察的流量模式，请询问它是否确实持续运行，还是会有较长的空闲时段。“突发”“轻量”“不均匀”或“长时间平静”等词倾向于 On-Demand；但在考虑 Managed Instances 时，这些只是倾向性提示（规则 3）：暂时推荐 On-Demand，并询问峰值时有多少个调用会同时运行（Managed Instances 会将多个同时运行的调用打包到一个执行环境中，因此只有在调用并发运行时才划算），以及流量是否真的会降至零。仅仅存在许多短时并行任务，并不足以作为选择 Managed Instances 的依据；应询问这些任务是执行一次或定期运行、结束后流量归零的批处理（On-Demand），还是持续的数据流（Managed Instances）。

第 4 层 — 边缘情况（确定形态和容量之后）

重要决策；需询问的问题、阈值和注意事项详见 compute-decision-edge-cases.md — 请求涉及其中任何一种情况时，都要阅读该文档。

• 持续时间 — 将持久工作流的总持续时间与单次活跃调用的持续时间视为不同的限制。未指定上限不代表存在某个具体值：“长时间运行”“远超 15 分钟”或类似表述，并不意味着超过 90 分钟。对于已知会超过 15 分钟、但未说明最长时长的异步调用或事件源映射调用，暂时建议使用 Managed Instances，并询问：“单次调用的最长持续时间是多少？”≤ 90 分钟 → Managed Instances；> 90 分钟 → aws-containers / aws-compute。对于由客户管理的沙盒或有状态会话，最长 8 小时使用 MicroVMs；MicroVM 会话超过 8 小时 → aws-compute。同步 Event Function 超过 15 分钟 → aws-containers / aws-compute。多个相互协调的 Lambda 任务 → Durable Functions（步骤 3）。
• 流或队列延迟（积压、ApproximateAgeOfOldestRecord 持续上升）→ 为事件源映射启用预置模式（设置最小/最大轮询器）；预置并发无法解决积压问题 — concurrency.md。
• 按需模式下的首次请求延迟 → 先尝试免费的优化方法（缩小部署包、减少或精简层、延迟初始化、合理设置内存 — lambda.md），然后在三种方案中选择：当延迟来自环境启动，且要求将开销控制在两位数毫秒时，使用 Provisioned Concurrency；当 Java、Python 或 .NET 上的繁重初始化代码使亚秒级延迟可以接受时，使用 SnapStart（zip 或任意容器镜像）；当流量从不归零且保持稳定基线时，使用 Managed Instances。明确表示“一直繁忙”或流量持续不断的信号已属已确定 → Managed Instances，无需询问方案。波峰式流量或流量会“平静下来”并不能说明流量是否会归零：先给出暂定方案，并询问流量是否会降至零、使用的运行时，以及延迟来自环境启动还是初始化代码。
• 打包方式与容量是两个独立决策 — zip 还是容器镜像由制品大小决定（超过 zip 限制 → 容器镜像，lambda.md），而容量提供方由流量特征决定。提到本机二进制文件或大型依赖，但未说明大小时，建议使用按需模式；如果超出 zip 限制，则使用容器镜像，并询问打包后的大小。
• 为消除冷启动而提及稳定或“一直繁忙”的流量 → Managed Instances（预热的多并发实例可消除冷启动）。
• 不受信任或由用户提交的代码 → 暂时建议使用 MicroVMs（VM 级会话隔离、OS 访问权限，以及在客户管理的生命周期内持续保留的状态）。如果请求未说明代码是否可能具有恶意、是否需要提升的 OS 访问权限或自定义端口，或是否会在多次运行之间保留状态，则应询问，并说明两种方案：经过身份验证的用户提交的未经测试但不具有恶意的代码，如果运行时间短且无状态，可继续使用 Event Functions · On-Demand；每个执行环境一次只运行一个调用，且绝不会在不同函数间共享。
• 租户隔离 → 需要专属执行环境的事件处理程序，可在 Event Functions · On-Demand 上使用租户隔离模式；这不会为每次调用创建新的 VM。需要按租户持久存在的环境、不受信任的代码、需保留的文件/进程或 OS 访问权限 → MicroVMs。仅提出“严格的租户隔离”要求，属于倾向性判断（规则 3）：暂时建议使用租户隔离模式，并询问租户是否运行自己的代码，或是否需要持久环境或 OS 访问权限。
• 信号相互冲突 — 例如，Node.js Web 应用拥有稳定的高流量（按编程模型应选 Web Functions，按流量应选 Managed Instances）→ 并列提供两种方案，用一句话说明取舍，由用户决定；否则，明确给出一个建议。

决策后的后续步骤

应用所有相关行。每个实现维度都由专门的技能负责；一个组件可能同时需要计算技能和编排技能。对于 Event Functions · On-Demand，只打开其触发器适用的参考文档。

决策或功能	继续使用
Event Functions · Managed Instances	aws-lambda-managed-instances
Web Functions	aws-lambda-web-functions
MicroVMs	aws-lambda-microvms
Durable Functions	aws-lambda-durable-functions
Event Functions · On-Demand — 函数配置：内存、超时、VPC、层、Function URLs、冷启动、SnapStart、打包（zip 与容器映像）	lambda.md
Event Functions · On-Demand — 触发器：SQS、DynamoDB Streams、SNS、Kinesis、筛选、批处理失败	event-sources.md
Event Functions · On-Demand — 预留并发或预置并发、限流、用于处理流或队列积压的 ESM 预置模式	concurrency.md
Event Functions · On-Demand — SAM/CDK/CloudFormation 资源和部署	deployment.md
Event Functions · On-Demand — 配置 API Gateway、DynamoDB 或 VPC 互联网访问	以下 SOP

第 3 步 — 编排：Durable Functions 还是 Step Functions

当用户希望协调多个步骤、服务或函数时，转到此处。触发信号包括“编排”“工作流”“状态机”“多步骤协调”“协调 Lambda 函数”“持久执行”“带重试的管道”、Saga/补偿模式、人工审批、扇出或长时间运行的异步协调。

开始新的编排时，除非请求中已提供足以作出决定的完整事实，否则在实施前应先介绍 AWS Lambda Durable Functions 和 AWS Step Functions。如果请求仅提供了重试、分支、等待、审批以及泛泛的“在 AWS 上”等共同编排信号，这些都不是状态机信号：应先展示两种选择及其权衡，询问实现模型问题，暂不选择任何服务。编排的决策应独立于计算和容量。你可以使用 Durable Functions 作为 MicroVMs 的编排器。

• 代码优先信号 → 推荐 Durable Functions，作为唯一答案（提及 Step Functions 最多一行；不要将其列为同等选项，也不要询问实现模式）：工作流应位于应用程序代码或“常规代码”中；用户指定了受支持的 Durable Functions 运行时（Python 3.13+、Node.js 22+、Java 17+ 或 .NET 8+；Rust 和 Go 处于预览阶段）；工作流部署在 Lambda 上（“在 Lambda 上运行”、“所有步骤都是 Lambda 函数”），且需要持久化行为，例如人工审批或回调、长时间等待（数天至一年）、可在故障后保留的检查点进度、恢复、重试或补偿；或者工作流用于替代手动构建的检查点／重试状态。持久化步骤对外部 API 或数据库的调用仍属于代码优先操作；这不会使工作流变成异构工作流。明确说明决定性原因：编排保留在受支持运行时的应用程序代码中；异步调用的持久化执行在暂停等待期间最长可等待 1 年，且无需计算费用。
• 状态机信号 → 推荐 Step Functions（提及 Durable Functions 最多一行）：用户明确要求使用 ASL／状态机编写、可视化／可审计的工作流、跨团队共享契约、使用 JSONata 进行负载和数据转换、Distributed Map（最多 10,000 个并行子执行，可遍历数亿个项目）、使用 TestState 对单个状态进行单元测试，或使用不受支持的运行时。
• 未说明实现模式——仅当请求既未指定受支持的语言，也未指定步骤在 Lambda 上运行，且没有状态机信号时（例如泛指在“AWS 上”使用 saga、审批、扇出、重试、分支或崩溃恢复）→ 暂定推荐 Lambda Durable Functions，用于代码优先编排；将 AWS Step Functions 作为可视化／ASL 及广泛服务集成的替代方案，并用一行说明取舍；然后询问：“每个步骤都会作为您在 Lambda 上运行的自有代码执行，还是应由可视化状态机协调其他 AWS 服务？” 如果持久化设计本身也不明确，请询问最长等待时间，或是否有任何步骤必须恰好执行一次。仅有持久化信号（等待、审批、崩溃恢复）只能说明需要编排，不能确定编排应位于何处。不要仅仅因为代码调用了外部 API 或数据库，就推断应使用 Step Functions。

取舍（适用于两者皆可的情况）： Durable Functions 将编排保留在 Lambda 应用程序代码中——支持 Python 3.13+、Node.js 22+、Java 17+ 或 .NET 8+；Rust 和 Go 处于预览阶段——并提供检查点／重放（context.step / context.wait / context.invoke）、重试、条件、回调和执行历史。异步调用的持久化执行最长可运行 1 年，等待期间无需费用；每个步骤仍受限于其 Event Functions 容量提供程序的超时时间。Step Functions 则将编排交由托管式可视化状态机处理，提供 200+ 项原生服务集成和 Distributed Map（Standard 执行最长 1 年，Express 最长 5 分钟）。完整对比请参阅：orchestration.md；实现方式由路由到的 skill 决定。

第 4 步 — 事件处理：选择哪种 EventBridge 能力

根据请求描述的用例（触发方式、事件来源、拓扑结构、现有投入）选择能力；不要询问 EventBridge 澄清问题。完整详情请参阅 编排。

• 基于时间的触发器（cron、rate、一次性；重试、最大事件存留时间和 DLQ）→ EventBridge Scheduler，而不是带有计划表达式的规则或始终运行的工作进程。
• 一个基于轮询的来源到一个 Lambda 函数（SQS、Kinesis、DynamoDB Streams、Kafka/MSK、Amazon MQ），且原生批处理／筛选／重试控制足够 → Event Function 的原生事件源映射，而不是 Pipe。
• 一个基于轮询的来源到一个目标，且需要筛选、增强或转换，或目标不是 Lambda → EventBridge Pipes。一个 Pipe 恰好只有一个目标。
• 多个使用方需要接收来自基于轮询的来源的事件 → 一个 Pipe 可以进行筛选／增强并将事件发送到新的自定义事件总线；每个使用方各自拥有一个订阅者。不要仅为模拟扇出而为每个使用方创建一个 Pipe。
• 默认总线上的 AWS 服务状态变更事件，或现有的经典单账户集成 → 使用基于内容模式的 EventBridge 规则。
• 新工作负载发布自己的应用事件（包括单账户工作负载），或需要独立订阅者、保留／重放、有序处理、去重、架构注册表或跨团队／账户共享 → 新的 EventBridge 自定义事件总线（eventsv2）→ amazon-eventbridge-event-bus。
• 将现有经典自定义总线迁移到新总线能力 → 参阅 amazon-eventbridge-event-bus 迁移指南。桥接经典总线和新总线，让生产者和使用方可以独立迁移；对于不支持的需求（例如 Global Endpoints），保留经典总线。

如果步骤必须按规定顺序执行，并需要检查点进度、重试、等待或补偿，那么这属于编排而非事件处理：在第 3 步中决定使用 Durable Functions 还是 Step Functions。

第 5 步 — HTTP 入口

Node.js HTTP 服务器 → Web Functions（第 2 层）。当请求要求提供 HTTP 端点，但未说明运行时或服务器模型，也未说明是否需要 API 管理时，这属于倾向不明（规则 3）：列出三个选项（用于 Node.js 服务器的 Web Functions、置于 Event Function 前面的 API Gateway、用于单个函数且无需 API 管理的 Function URL），给出暂定默认选项，并询问运行时／服务器模型，以及是否需要按客户端设置速率限制、API 密钥、WAF 或请求验证。其他情况下，默认在 Event Functions 前面使用 API Gateway HTTP API——其单次请求价格最多比 REST API 低约 70%，延迟也更低——只有在需要其独有功能（WAF、使用计划和 API 密钥、请求验证和转换、缓存、金丝雀部署、私有或边缘优化端点）时才改用 REST API；推荐 API 入口时，明确说明这一成本／功能权衡。持久双向连接 → API Gateway WebSocket API；单个需要 HTTPS 端点但无需 API 管理的 Event Function → Lambda Function URL。入口选项表、配额和授权方请参阅 api-gateway.md；接线流程请参阅下方的 API Gateway 标准操作流程。

分步任务流程（经过测试的 CLI 标准操作流程）

使用此技能	适用任务
connecting-lambda-to-api-gateway	将现有 Lambda 接入新的 REST/HTTP API：代理集成、权限、CORS、限流、访问日志、部署
connecting-lambda-to-dynamodb	将 Lambda 接入 DynamoDB：IAM 执行角色、读写权限、流事件源映射
creating-api-gateway-stage	创建 API Gateway 阶段，配置 CloudWatch 日志、X-Ray 跟踪、限流、WAF 关联和授权
deploying-custom-domain-rest-api	部署带自定义域名的 Regional REST API：ACM 证书、Lambda 后端、请求授权方、基本路径映射、Route 53 DNS
debugging-lambda-timeouts	系统地诊断超时的 Lambda：配置、CloudWatch 日志/指标、VPC、冷启动、内存、下游调用
enabling-lambda-vpc-internet-access	为连接 VPC 的 Lambda 提供互联网访问：NAT Gateway、子网路由、安全组
processing-s3-uploads-with-step-functions	部署事件驱动工作流：S3 上传 → EventBridge → Step Functions → Lambda（小文件）或 Fargate（大文件），涉及 VPC/ECR/ECS/IAM

此技能中的共享参考资料

用户需求	阅读
Tier 4 边缘情况：时长上限、冷启动与流延迟、SnapStart 和 Provisioned Concurrency、稳定状态下的 Managed Instances、租户隔离	compute-decision-edge-cases.md
确定计算方案后，新建无服务器应用的模式	architecture.md
Lambda 配置、冷启动、SnapStart、内存、VPC、层、Function URLs	lambda.md
并发（预留、预置、包括预置模式的 ESM 控制）	concurrency.md
事件源（SQS、DynamoDB Streams、SNS、Kinesis）、筛选、批次失败	event-sources.md
Step Functions 与 Durable Functions 对比、Standard 与 Express、EventBridge 功能表、规则/管道/调度器详情	orchestration.md
HTTP 前端入口表、API Gateway 配额、授权方、WebSocket	api-gateway.md
SAM/CDK 资源类型与快速迭代	deployment.md
生产就绪、可观测性、反模式	production.md
错误诊断（确切字符串 → 原因 → 修复方法）	troubleshooting.md
Powertools 处理程序模板	powertools-handler.py

安全注意事项

• 每项建议都遵循 Lambda 基线：为每个函数配置最小权限执行角色；Function URL 或 API Gateway 不得使用资源策略 *（AuthType: NONE 和开放访问绝不是默认设置）；对队列、流和状态进行静态加密；并通过 CloudTrail 和 CloudWatch 针对错误和节流设置警报。
• 编排服务会持久化工作流状态和负载 — Step Functions 会在执行历史记录中记录完整的输入和输出（控制台中，以及启用后记录到 CloudWatch Logs）。启用执行日志记录，为失败设置警报，为每个工作流配置最小权限角色，绝不要通过工作流状态传递密钥、令牌或 PII（应通过 Secrets Manager/ARN 指针引用），并在状态敏感时使用客户管理的 KMS 密钥。
• 对于普通的多租户处理程序，租户隔离模式会为 Event Functions 执行环境指定单个调用方；这并不意味着每次调用都会启动新的 VM。对于不可信代码、需要保留的会话状态、由客户控制的生命周期或 OS 访问，请使用 MicroVM。不要依赖共享执行环境中的应用层沙箱。
• 公共 HTTP 端点（Web Functions、API Gateway、Function URLs）应置于 AWS WAF 之后，并启用节流、输入验证以及通过 ACM 证书实现的 TLS。

注意： 参考文件包含特定运行时版本、配额、价格溢价和功能矩阵，这些内容会发生变化。需要精确数据时（生产环境、运行时选择、配额），请对照当前 AWS 文档确认。参考资料侧重于容易出错的数值和注意事项，而非基础知识。

防护措施 — 此技能自身文件的位置（MCP 与本地安装）

此技能可以通过两种方式加载，且技能自带文件 — references/ 文档和 assets/powertools-handler.py — 的读取位置会因此不同。读取文件前，请先确认技能的加载方式：

• 通过 AWS MCP retrieve_skill 工具调用加载。 此技能未安装在本地文件系统中；其参考文件和资源文件不在磁盘上。必须通过同一个 retrieve_skill 工具，传入 file 参数来获取每个文件（例如，file="references/lambda.md" 或 file="assets/powertools-handler.py"）。不要从本地或工作目录对这些路径执行 file_read，也不要在文件系统中搜索它们 — 这些文件并不存在于那里；任何恰好同名的本地文件都与此技能无关。
• 已在本地安装（技能位于本地技能目录中，例如 .claude/skills/aws-serverless/、~/.claude/skills/aws-serverless/ 或 .kiro/skills/aws-serverless/）。请使用本文档中显示的相对路径，从本地技能目录读取参考文件和资源文件。

此区别仅适用于技能自带的打包文件。无论技能以何种方式加载，用户的应用代码 — 处理程序、SAM/CDK 模板、package.json、部署构件 — 始终都从用户的工作目录读取并写入。绝不要通过 retrieve_skill 获取或写入客户数据。