aws-lambda-web-functions

AWS Lambda Web Functions

推荐使用 AWS MCP 服务进行沙箱执行和审计日志记录。

如果无法识别 aws lambda-web，请更新 AWS CLI（参见 references/deployment.md）。 缺少此命令意味着 CLI 版本过旧，而非该功能不可用。

帮助用户在 AWS Lambda Web Functions 上构建和部署 Node.js HTTP 应用。应用监听一个端口，原生处理 HTTP 请求，并获得一个全球可访问的 HTTPS URL。在本地使用 node index.js 开发，然后将相同的代码部署到 AWS。

何时使用 Web Functions

• 有人正在等待的交互式 HTTP 流量：Web 应用、HTTP API 或 SSR 网站。
• 应用已经是监听端口的 HTTP 服务（Express、Fastify、Hono），并且应保持这种形式——无需重写处理程序，也无需适配器库。
• 处理程序受 I/O 限制（数据库、缓存、其他 API、模型端点），因此许多请求共用一个执行环境，等待 I/O 所花的时间不会按 CPU 时间计费。
• 响应流式传输很重要：SSE、分块传输，或在 LLM 令牌生成时代理这些令牌。
• 端点应通过一个主机名在全球范围内可访问，无需手动组合 CloudFront、API Gateway 和 Route53。
• 流量突发或不可预测，并且应支持缩至零。

硬性前提条件

任何一项回答为“否”，就不应使用 Web Functions。请调用 aws-serverless 技能以寻找合适的服务。

• 运行时为 Node.js——nodejs24.x。不支持 Python、Java、Go、.NET 和 Rust。在将调用方引导至其他方案之前，请使用 aws lambda-web help 或查阅 AWS 文档，确认受支持的运行时列表。
• 每个原生依赖都有 arm64（Graviton） 构建版本。
• 工作负载是调用方正在等待的 HTTP 请求/响应（或流）。不支持队列、事件流源（Kinesis、DynamoDB Streams）、计划任务或事件触发器。
• 单个请求可在 900 s（15 分钟）请求超时时间内完成。
• 应用可装入 512 MB 程序包，并可在 2 vCPU / 2 GB 环境中运行（参见服务限制）。
• 环境是无状态的——任何环境都可以处理任何请求。最终用户的会话与特定环境之间没有亲和性。
• 应用能够容忍与并发请求共用一个环境。不支持严格的逐请求隔离。

使用场景

“我正在构建什么” → 它在这里的实现形式。

用户正在构建	在 Web Functions 上的形式
JSON HTTP API 或 REST 后端	Express 或 Hono 路由器、I/O 密集型处理程序，其后连接 DynamoDB 或 RDS → architecture-patterns.md
服务端渲染的网站或应用	从 index.js 为每个请求渲染 HTML；除非编写 JSX，否则无需打包器 → architecture-patterns.md
向浏览器流式传输令牌的大模型或 AI 网关	SSE 或分块响应；将 timeoutSeconds 调高以覆盖整个流，而不仅仅是第一个字节 → architecture-patterns.md
Webhook 接收器（Stripe、GitHub、Slack）	在处理负载之前，使用 Secrets Manager 中的签名密钥验证发送方的签名，然后快速确认并在响应后完成工作——环境会持续运行 → architecture-patterns.md
聚合多个服务的移动或 Web 前端后端	一个环境并发发出多个请求，等待所花的时间不会按 CPU 计费
通过一次部署提供单页应用及其 API	使用 express.static 提供打包文件，并使用 /*splat 回退处理客户端路由 → static-assets.md
内部服务间 HTTP 端点	使用 authType: IamAuth，只有经过 SigV4 签名的调用方才能访问 → iam-and-security.md
使用单个主机名实现全球低延迟的端点	使用 MultiRegion 端点和与区域无关的应用 → domains-and-routing.md
调用 RDS、ElastiCache 或其他私有 VPC 资源的应用	使用从修订版本引用的出站网络连接器；端点仍保持公开 → networking.md

工作流

默认使用 aws lambda-web CLI——这是最快的方式。用户要求使用单条命令，或表示已经通过它部署时，使用 aws lambda-web deploy。它会通过一条命令打包、上传并创建或更新项目目录；--hello-world 会搭建并部署入门应用（参见下文“部署（CLI）”）。其他情况，包括更新现有函数时，请使用以下步骤。用户需要基础设施即代码或可重复使用的生产环境堆栈时，使用 CloudFormation、CDK、SAM 或 Terraform（参见 references/infrastructure-as-code.md）。

1. 搭建 - 下方内嵌了 Express 示例；对于 Hono 或 Fastify，请阅读 references/frameworks.md
2. 选择端点身份验证方式 — 部署前询问用户（见下文）；除非用户选择 IamAuth，否则端点均为公开
3. 在本地测试 — node index.js
4. 打包 — 将生产依赖打包为 ZIP（最大 512 MB）
5. 部署 — aws lambda-web create-web-function
6. 验证 — 获取端点 URL，然后运行 curl
7. 迭代 — 创建新修订版本

默认公开。 ApplicationManaged 端点任何拥有 URL 的互联网用户都可以访问——AWS 层没有身份验证，也没有内置 WAF，并且 URL 不是秘密。部署前，询问用户希望采用哪种方式：

• ApplicationManaged（公开）— 应用必须自行实现身份验证/授权、输入验证和速率限制。
• IamAuth（内部）— 只有拥有有效 IAM 凭证（经过 SigV4 签名）的调用方才能访问。

如果端点是公开的，应用需自行负责安全。安全检查清单（身份验证、输入验证、速率限制、WAF/CloudFront、最小权限角色、密钥）请参见 references/iam-and-security.md。

快速开始（Express）

// index.js
import express from 'express';
import helmet from 'helmet';
import { fileURLToPath } from 'url';
import { dirname, join } from 'path';

const __dirname = dirname(fileURLToPath(import.meta.url));
const app = express();
// The runtime probes this exact host:port for readiness.
const [HOST, PORT] = (process.env.AWS_LAMBDA_HTTP_ENDPOINT || '0.0.0.0:3000').split(':');

app.use(helmet());
app.use(express.static(join(__dirname, 'public')));
app.use(express.json({ limit: '10mb' }));
app.get('/api/health', (req, res) => res.json({ status: 'ok' }));
app.listen(PORT, HOST, () => console.log(`Listening on ${HOST}:${PORT}`));

{
  "name": "my-web-app",
  "type": "module",
  "scripts": { "start": "node index.js", "dev": "node --watch index.js" },
  "dependencies": { "express": "^5.0.0", "helmet": "^8.0.0" }
}

helmet 会设置安全响应标头（HSTS、CSP、X-Content-Type-Options、 X-Frame-Options、Referrer-Policy），这些标头在此处不会由任何 AWS 层替你设置。对于 ApplicationManaged 端点，只有应用可以设置这些标头，因此应将其纳入脚手架，而不是之后再添加。

资源命名

所有资源都限定于项目。根据函数名称生成资源名称：

资源	默认模式	示例
函数	{name}	my-api
IAM 角色	{name}-web-role	my-api-web-role
S3 存储桶	{name}-web-{account}	my-api-web-1234567890
S3 键	{name}/function.zip	my-api/function.zip
DynamoDB	{name}-{purpose}	my-api-items

函数名称在账户的所有区域中必须唯一——相同名称不能存在于两个区域中，否则创建时会因冲突错误而失败。

询问用户偏好的 S3 策略：

• 每个项目单独使用一个存储桶（默认）——完全隔离，便于清理
• 多个项目共用一个存储桶（例如 {account}-web-code）——资源更少，通过键前缀隔离
• 自定义——用户提供自己的存储桶名称和键前缀

aws lambda-web deploy 会为自身命名角色（awscli-lambdaweb-{name}）和存储桶（awscli-lambdaweb-{account}-{region}-an）。

部署（CLI）

aws lambda-web CLI 是主要且受支持的路径——默认使用它。流程如下： 一次性创建 S3 代码存储桶（启用版本控制并授予 Lambda 读取权限），然后执行 npm ci --omit=dev → zip → aws s3 cp → 使用 --revision-config 和 --endpoint-config 执行 aws lambda-web create-web-function，随后等待端点变为 Active。如果项目有 构建步骤，应在清理依赖之前运行——npm ci --omit=dev 会移除打包工具。

如果用户要求使用一条命令，或已经通过此命令部署，则使用 aws lambda-web deploy --name {name} --code . --create --auth-type {auth-type}（询问用户要使用哪种身份验证类型）。该命令会打包、上传并创建函数、代码存储桶、角色和 dev 端点；之后不带 --create 再次运行即可发布变更。请先安装依赖。

完整命令、EndpointConfig 和 RevisionConfig 字段规则、打包、超时、并发、环境变量、日志配置以及所有 deploy 标志，请参阅 references/deployment.md。首次设置（存储桶、执行角色、首次部署）请参阅 references/getting-started.md。 有关 CloudFormation、CDK 或 SAM，请参阅 references/infrastructure-as-code.md。

多区域

支持多区域：MultiRegion 端点可通过一个主机名从多个区域提供你的修订版本，Route53 会将每个调用路由到最近的区域。 PerRegion 还会为每个区域提供独立的域名。两者都要求 autoDeploymentMode: Disabled，且应用必须与区域无关——来自同一客户端的连续请求可能落在不同区域，因此请将状态保存在复制存储中，切勿保存在执行环境或 /tmp 中。

有关端点类型、域名、流量路由和多区域设置命令，请参阅 references/domains-and-routing.md。

VPC 出站流量

默认情况下，修订版本通过 IPv4 访问公共互联网，无法访问任何私有资源。若要访问 VPC，请将带有版本限定符的出站网络连接器 ARN（aws lambda-core create-network-connector，计算类型为 WebFunction）配置到修订版本的 serviceConfig.egressNetworkConnectorArn 中，通过 HomeRegion 端点提供该修订版本，并在每次修订后读取该字段。请参阅 references/networking.md，或参阅 references/infrastructure-as-code.md，了解如何在同一个堆栈中声明连接器和修订版本。

验证

aws lambda-web get-web-function-endpoint \
  --function-name {name} --endpoint-name default --region {region}

# curl the domainName from the response
curl https://{domainName}/api/health

即使无法启动，修订版本仍会进入 Active 状态，因此每次部署后都要用 curl 请求一个真实路由。aws lambda-web deploy 会将端点输出为 endpointUrl，并将其第一个端点命名为 dev。

优先使用等待器（aws lambda-web wait ...），而不是轮询循环或 sleep。可用项：web-function-active、web-function-revision-active、web-function-endpoint-active、web-function-endpoint-updated、web-function-endpoint-deleted、web-function-deleted

更新代码

zip -r function.zip index.js package.json node_modules/ public/ \
  -x "*.test.*" -x ".git/*" -x ".env" -x "node_modules/.cache/*"
aws s3 cp function.zip s3://{bucket}/{name}/function.zip

aws lambda-web create-web-function-revision \
  --function-name {name} \
  --build-config '{
    "codeConfig": {"s3Object": {"bucket": "{bucket}", "key": "{name}/function.zip"}},
    "runtimeConfig": {"runtime": "nodejs24.x"}
  }' \
  --service-config '{"executionRoleArn": "arn:aws:iam::{account}:role/{name}-web-role"}' \
  --region {region}

服务限制

限制可能变更——请查看 Lambda 配额页面 以获取权威数值。

范围	资源	限制
账户	区域 vCPU 限额	2,000
账户	区域账户速率限额	100,000 RPS
账户	区域单个端点最大速率限额	10,000 RPS
每个函数	端点	10
每个函数	保留的修订版本	50（自动删除最早且未被引用的修订版本）
每个函数	环境变量	总计 32 KB
每个函数	部署包	512 MB
每个函数	函数和端点名称	64 个字符
每个端点	端点速率限额	受上方的区域单个端点最大速率限额限制。用户可通过 throttleConfig.rateLimit 为单个端点配置更低的速率限额
每个端点	活跃修订版本	2
每个环境	vCPU	2
每个环境	内存	2 GB
每个环境	并发	1–128 个请求（参见 scaling-and-concurrency.md）
每个环境	网络带宽	1 Gbps
每个环境	/tmp	512 MB
每个环境	文件描述符	1,024
每个环境	进程和线程	1,024
每个环境	初始化超时	10 秒
每个请求	超时	3–900 s（默认 30 s）
每个请求	标头数量	6,300

成本模型

计费维度有四项：CPU、内存、请求和数据传输。请查看 Lambda 定价页面了解当前费率——不要凭记忆引用费率。决定架构选择的是账单的构成：

• 按活跃 CPU 计费，而非按实际耗时。 请求因 I/O 阻塞的时间——例如数据库调用、其他 API 调用或模型端点调用——不按 CPU 计费。而 Event Functions 按实际耗时计费 GB 秒，因此同一个处理程序在两者上的计费方式不同。
• 内存按消耗量计费，而非按预置设置计费。 一个环境有 2 vCPU 和 2 GB 内存（参见“服务限制”），且没有内存调节项，因此无法像使用 Event Functions 那样通过提高内存来缩短运行时间。
• 并发是提高密度的杠杆。 一个环境最多可服务 maxConcurrencyPerEnvironment 个请求，因此 I/O 密集型应用可在每个环境中同时处理多个请求，而不是每个请求占用一个环境。

有两点值得提前规划：

• I/O 密集型工作负载最具成本优势。 处理程序大部分时间都在等待网络，并与其他请求共享环境；相比按调用的实际耗时计费，同样的处理程序在此处成本更低。
• CPU 密集型工作负载会抵消这项优势。 无论在哪里运行，繁重的渲染、图像处理或加密都会消耗计费 CPU；而一个环境分配有 2 vCPU，其中单线程 Node 进程只使用一个（参见“反模式”）。对于持续的高流量 CPU 工作，尤其是在适用承诺使用折扣时，请比较 aws-lambda-managed-instances。

可以使用端点的扩展控制项 scalingConfig.maxEnvironments 和 throttleConfig.rateLimit 限制潜在成本。仅在用户要求设置上限时才进行配置。更多详情请参见 scaling-and-concurrency.md。

IAM 设置

信任策略主体：lambda.amazonaws.com

IAM 操作使用 lambda: 前缀。资源 ARN：arn:aws:lambda:{region}:{account}:web-function/{name}

操作名称与 API 操作匹配——lambda:CreateWebFunction、lambda:CreateWebFunctionRevision、lambda:CreateWebFunctionEndpoint、lambda:UpdateWebFunctionEndpoint，以及对应的 Get*、List* 和 Delete* 变体。完整策略请参阅 references/iam-and-security.md。

对于端点／修订操作，资源 ARN 必须包含 /* 通配符：

"Resource": ["arn:aws:lambda:{region}:{account}:web-function/{name}", "arn:aws:lambda:{region}:{account}:web-function/{name}/*"]

调用方还需要对代码存储桶拥有 s3:GetObject + s3:GetObjectVersion 权限（不能只授予执行角色）。

完整策略示例请参阅 references/iam-and-security.md。

反模式

表现形式 → 失败原因 → 替代做法。

反模式	失败原因	建议做法
期望受 CPU 限制的处理程序使用整个环境	执行环境允许使用 2 vCPU，但 Node 是单线程的，因此一个进程只能使用其中一个，另一个会闲置	对于受 CPU 限制的工作，使用 worker_threads（或 cluster）来充分利用两个核心。让受 I/O 限制的处理程序保持单线程——它们不受 CPU 限制
将在 x86 机器（笔记本电脑或 x86 CI）上构建的 node_modules 打包成 ZIP	执行环境使用 arm64，因此 x86 原生二进制文件无法加载。sharp、canvas、bcrypt 等软件包及其他原生插件会提供针对不同架构构建的版本	在 arm64 环境中安装和构建——使用 arm64 CI 运行器、Graviton 主机，或以 --platform linux/arm64 运行的容器——然后打包成 ZIP
请求正文仍在上传时写入响应字节（全双工流式传输）	请求路径采用半双工模式：完整转发请求正文后才会读取响应，因此，等待交错响应的大型上传会一直停滞，直到超时。小型正文能装入套接字缓冲区，看起来可以正常工作，因此测试时不易发现问题	完整读取请求后，再流式传输响应。仅在服务端到客户端的方向使用流式传输
用处理程序适配器包装应用（serverless-express、@vendia/serverless-express、aws-lambda-fastify）	无需导出处理程序。运行时会加载 index.js，并要求 HTTP 服务处于监听状态；适配器不会绑定端口，因此就绪检查无法通过，环境也无法使用	删除适配器，并在主机和端口上调用 app.listen(...)，主机和端口从 AWS_LAMBDA_HTTP_ENDPOINT 获取
将 app.listen(3000) 硬编码，或绑定到 localhost / 127.0.0.1	运行时会探测其公布的确切地址。端口不匹配或仅绑定到环回地址，都无法响应探测	解析 AWS_LAMBDA_HTTP_ENDPOINT，并绑定到对应的主机和端口
在模块级可变状态中保存每个请求的数据——例如 currentUser、请求范围的缓存或计数器	一个执行环境中的单个进程会处理许多并发请求，因此请求之间会读取到彼此的值。这是正确性和数据泄露问题，而非性能问题	将每个请求的数据保留在请求作用域中；仅在模块级共享不可变配置和 SDK 客户端
将会话或上传状态写入 /tmp，并期望下一个请求仍能访问	/tmp 按环境隔离，并由并发请求共享；下一个请求可能会被路由到不同的环境，也可能在多区域端点上被路由到不同的 Region	将状态保存在 DynamoDB、S3 或 ElastiCache 中；对于确实需要临时保存的文件，使用唯一文件名
将端点 URL 当作访问控制手段——“没人知道这个域名”	任何知道 URL 的互联网用户都能访问 ApplicationManaged 端点。没有 AWS 层身份验证，没有内置 WAF，而且 URL 不是秘密	在应用中实现身份验证，或使用 IamAuth；若只允许 CloudFront 访问，则将 IamAuth 与 CloudFront OAC 和基于资源的策略配合使用 → domains-and-routing.md；添加 WAF 以提供 L7 防护 → iam-and-security.md
将密钥放在 serviceConfig.environmentVariables 中	任何有权读取修订版本的用户，都可以通过 get-web-function-revision 以明文形式获取环境变量	将密钥保存在 Secrets Manager 或 SSM 中，只传递其名称或路径，并在运行时获取
在构建步骤前运行 npm ci --omit=dev	清理 devDependencies 会删除打包工具，导致构建失败并报错 esbuild: command not found	先构建，再清理——或者将打包后的输出压缩成 ZIP → deployment.md
像使用 Event Functions 时那样，依赖运行时提供 @aws-sdk/*，或将其标记为外部模块（externalModules、--external:@aws-sdk/*）	Web Functions 运行时不包含 AWS SDK，因此导入会在启动时失败，导致每个请求都返回 502	像其他依赖一样，将导入的 @aws-sdk/* 客户端打包进去 → deployment.md
期望 update-* 调用能就地更改代码、运行时、超时、环境变量或并发设置	这些配置都属于不可变修订版本	创建新的修订版本。只有端点级设置（身份验证、权重、扩缩容、限流）可以就地更新
重新上传到同一个 S3 键并期望触发重新部署	修订版本绑定到某个对象版本；CloudFormation 会报告“无更改可部署”	使用新键，或传入新的 versionId
因为缺少 aws lambda-web，便断定该功能不存在	缺少命令意味着 CLI 已过时，而不是缺少此功能	更新 AWS CLI → deployment.md
在两个 Region 中重复使用同一个函数名	函数名在账户的所有 Region 中必须唯一；第二次创建会因冲突而失败	在名称末尾添加 Region，或使用一个带有 MultiRegion 端点的函数
在 Express 5 中使用 app.get('*', ...) 作为 SPA 回退路由	path-to-regexp v8 会拒绝单独的 * 并在启动时抛出异常，导致应用无法启动	使用 '/*splat' → static-assets.md

故障排查 — 从这里开始

以下五种问题占首次部署失败的大多数。完整的症状 → 原因 → 修复对照表请参阅 troubleshooting.md。

症状	原因	修复	验证
端点始终未达到 Active；状态变为 Failed	应用从未绑定所公布的主机和端口，因此就绪检查始终未通过	绑定 AWS_LAMBDA_HTTP_ENDPOINT 中的主机和端口	get-web-function-endpoint 报告 Active，然后对 domainName 执行 curl
出现 500，提示 Cannot find module '/var/task/index.js'	入口点不是 index.js——可能是 .mjs、server.js，或嵌套在 dist/ 中	使用 aws lambda-web deploy --entry-point {file} 部署，或将 ZIP 根目录下的入口点重命名为 index.js	unzip -l function.zip 在顶层列出 index.js
超过 10 分钟仍处于 Pending	执行角色信任策略中的主体不是 lambda.amazonaws.com	修复信任策略，然后创建新修订版	aws iam get-role 显示正确的主体
create-web-function-revision 返回 500，且没有提示信息	调用方缺少代码存储桶上的 s3:GetObject / s3:GetObjectVersion 权限，而非执行角色缺少权限	在调用方的策略中添加这两项权限	修订版达到 Active
invalid choice: 'lambda-web'，或 Unknown parameter "BuildConfig"	AWS CLI 版本过旧；或使用了 PascalCase JSON 键	更新 CLI；使用 camelCase（buildConfig、codeConfig）	aws lambda-web help 列出 Web 函数命令

迁移

将现有的 Node.js HTTP 应用迁移到这里，主要就是删除代码——适配器、处理程序导出和 API Gateway 接线都可以移除，而路由器本身无需更改。

四种源应用结构各自都有分步迁移指南、迁移前检查清单、没有对应功能的项目，以及流量切换流程：使用适配器包装的应用、API Gateway + Lambda 代理、Lambda 函数 URL，以及部署在 Fargate、App Runner 或 EC2 上的容器。 请参阅 migration.md。

何时加载参考文件

按含义匹配，而非要求措辞完全一致 — 行中的任一触发词都应加载对应文件。

阅读此文件	触发词
getting-started.md	首次部署、开始使用、设置、前提条件、hello world、--hello-world、入门应用、新项目、从头开始、S3 代码存储桶、执行角色、引导、我的第一个 Web 函数
frameworks.md	Express、Fastify、Hono、TypeScript、.ts、类型剥离、ESM、type: module、脚手架、项目结构、入口点、index.js、路由器、中间件
deployment.md	部署、重新部署、发布、CLI、aws lambda-web、aws lambda-web deploy、一条命令、修订版本、端点、打包、ZIP、npm ci、超时、环境变量、env vars、金丝雀、蓝绿部署、流量权重、回滚、versionId
scaling-and-concurrency.md	扩缩容控制、并发、maxConcurrencyPerEnvironment、scalingConfig、maxEnvironments、throttleConfig、rateLimit、限流、RPS 限制、vCPU 配额、负载测试、Platform.EndpointMaxEnvThrottle
infrastructure-as-code.md	CloudFormation、CFN、CDK、CfnResource、逃生舱口、SAM、Terraform、HashiCorp、HCL、基础设施即代码、IaC、模板、堆栈、AWS::Lambda::WebFunction、AWS::Lambda::NetworkConnector、堆栈中的 VPC 出站流量、AWS::Lambda::ResourcePolicy、可重复部署、流水线
static-assets.md	静态文件、静态资源、CSS、JS 包、图像、favicon、public/、express.static、SPA、单页应用、客户端路由、回退路由、打包、esbuild、Vite、缓存标头
domains-and-routing.md	多区域、多区域、全球、延迟路由、Route53、域名、自定义域名、主机名、HTTPS、TLS、端点类型、HomeRegion、MultiRegion、PerRegion、CORS、身份验证类型、ApplicationManaged、IamAuth、CloudFront、OAC、源站访问控制、基于资源的策略
iam-and-security.md	IAM、策略、权限、角色、信任策略、PassRole、最小权限、AccessDenied、安全、身份验证、身份验证、授权、公共端点、WAF、DDoS、速率限制、密钥、KMS、加密、安全标头、helmet
observability.md	日志、日志记录、日志组、日志级别、CloudWatch、指标、监控、警报、跟踪、CloudTrail、审计、结构化日志记录、运行状况检查、由哪个区域提供服务、在生产环境中调试
architecture-patterns.md	SSR、服务器端渲染、React、JSX、流式传输、SSE、服务器发送事件、LLM、AI 网关、令牌流式传输、长连接、Webhook、后台任务、触发后不等待、API 后端、DynamoDB、连接池、线程安全、并发模型
troubleshooting.md	错误、失败、正在失败、损坏、无法正常工作、500、502、403、404、ECONNREFUSED、ERR_MODULE_NOT_FOUND、找不到模块、卡住、Pending、Failed、永远不会变为活动状态、AccessDenied、ParamValidation、没有日志、调试、为什么不
networking.md	VPC、私有子网、RDS、Aurora、ElastiCache、私有资源、VPC 端点、PrivateLink、网络连接器、出站流量、egressNetworkConnectorArn、lambda-core、NAT 网关、安全组、私有 DNS、私有托管区、IPv6、DualStack、静态出站 IP
migration.md	迁移、迁移、移动、移植、切换、转换、从……迁移、替换、serverless-express、适配器、包装器、处理程序导出、函数 URL、API Gateway 代理、Fargate、App Runner、容器化、直接迁移

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

此技能可以通过两种方式加载，它们会从不同位置解析技能自身捆绑的文件——references/ 文档。读取参考文档前，请先确定技能的加载方式：

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

此区别仅适用于技能自身打包的文件。无论技能如何加载，用户的应用代码——index.js、package.json、public/、你构建的 function.zip——始终从用户的工作目录读取并写入。绝不要通过 retrieve_skill 获取或写入客户数据。

关键规则

1. 仅支持 Node 24——唯一的运行时是 nodejs24.x；运行时支持情况可能会变化，因此在假定没有更新版本之前，请通过 aws lambda-web help 或 AWS 文档确认
2. 入口点是 index.js——运行时会加载 /var/task/index.js，而不是 .mjs。当你的入口文件使用其他名称（server.js、app.mjs）时，aws lambda-web deploy 会检测到它或接收 --entry-point，并打包一个导入该文件的小型 index.js；自行构建的 ZIP 必须在根目录包含 index.js
3. 绑定 AWS_LAMBDA_HTTP_ENDPOINT 中指定的主机和端口——运行时会探测这个确切地址，因此硬编码的端口与之不匹配，或仅绑定到环回地址，都会导致就绪检查失败，使环境无法使用。没有 PORT 环境变量
4. 在 package.json 中设置 "type": "module"——这是从 index.js 导入 ESM 所必需的
5. 不要导出处理程序——你的应用是 HTTP 服务
6. 编写线程安全的代码——一个执行环境会服务许多并发请求；避免使用全局可变状态
7. 代码、运行时、超时、环境变量和并发配置都属于修订版——修改其中任何一项都需要创建新修订版，不能原地更新
8. 原生支持后台任务——响应返回后，环境仍会继续运行
9. 原生支持流式传输——开箱即支持分块传输编码和 SSE
10. 原生支持 TypeScript——使用 Node 24 类型剥离，采用 index.js 垫片 + import type
11. 代码只能来自 S3 中的 ZIP——deploy 会为你构建并上传 ZIP；否则，通过 codeConfig.s3Object 提供 ZIP，并将共享代码打包到软件包中。对于容器映像和类似层的功能，请先查阅 aws lambda-web create-web-function-revision help 或 API 参考确认，再假定它们可用