企业官网建设流程全解析

Serverless Framework 如何配置 AWS Lambda Managed Instances 容量提供程序？

【免费下载链接】serverless⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.项目地址: https://gitcode.com/GitHub_Trending/se/serverless

如果你要把高流量 Lambda 函数迁移到 AWS Lambda Managed Instances（基于 AWS 托管 EC2 基础设施运行、支持单执行环境并发处理多请求的容量模式），需要做的事就是在serverless.yml里配置容量提供程序（Capacity Provider），并通过serverless deploy把对应的 CloudFormation 资源创建出来。本文基于 Managed Instances 官方文档 和 serverless.yml 配置参考，给出从最小配置到完整配置的连续操作路径。

适用前提：函数需要 VPC 配置（子网 + 安全组），且所在区域支持 Lambda Managed Instances（文档提示该功能仅在特定区域可用，具体区域列表以 AWS 文档为准）。

先满足一个硬性前提：VPC 配置

容量提供程序要求 VPC 配置，缺少subnetIds和securityGroupIds时，框架会在打包阶段直接报错（错误码LAMBDA_CAPACITY_PROVIDER_MISSING_VPC），不会继续部署。VPC 可以写在provider.vpc下由所有容量提供程序继承，也可以在单个容量提供程序下单独覆盖。

最小配置：使用内置的 default 提供程序

最简单的写法是给函数指定capacityProvider: default，框架会自动创建一个默认容量提供程序：

provider: name: aws vpc: subnetIds: - subnet-xxx securityGroupIds: - sg-xxx functions: api: handler: handler.api capacityProvider: default

其中subnet-xxx、sg-xxx需要替换为你账号中实际的子网 ID 和安全组 ID。文档中的最小配置示例仅展示结构，实际部署时请填入真实值。

使用最小配置时的默认行为（均出自文档）：

• 自动创建default 容量提供程序，继承provider.vpc的 VPC 配置；
• 自动创建Operator Role（信任lambda.amazonaws.com，附加AWSLambdaManagedEC2ResourceOperator托管策略）；
• Scaling Mode默认为auto；实例要求默认为任意兼容实例类型；maxVCpuCount默认无上限；
• 使用该提供程序的函数默认memorySize为2048MB，memoryPerVCpu为每 vCPU 2 GB；
• maxConcurrency默认为 Lambda 服务默认值：Node.js 64、Java 32、.NET 32、Python 16；
• 扩展方面，AWS 默认维持最少 3 个执行环境且无上限（这是 AWS 服务默认，不是 Serverless Framework 设置的）。

定义自定义容量提供程序

需要控制实例类型、扩缩容方式时，在provider下定义capacityProviders。下面是一个完整字段示例，各字段在文档中标注为可选：

provider: name: aws runtime: nodejs24.x vpc: subnetIds: - subnet-xxx securityGroupIds: - sg-xxx capacityProviders: highMem: # 可选：自定义 Operator Role ARN。 # 省略时自动创建信任 lambda.amazonaws.com、 # 附加 AWSLambdaManagedEC2ResourceOperator 的角色。 permissions: operatorRole: arn:aws:iam::123456789012:role/MyOperatorRole # 可选：该提供程序专属 VPC。省略时使用 provider.vpc。 vpc: subnetIds: - subnet-aaa - subnet-bbb securityGroupIds: - sg-aaa # 可选：EC2 实例要求。省略时可使用 x86_64 架构的任意实例类型。 # allowedInstanceTypes 与 excludedInstanceTypes 二者只能配其一。 instanceRequirements: allowedInstanceTypes: - r7g.large - r7g.xlarge architectures: - arm64 # 省略时默认取 provider.architecture # 可选：扩缩容配置。 # 'auto' -> 服务托管扩缩容；'manual' -> 由 scaling.policies 控制 scaling: mode: manual # 该提供程序的最大 vCPU 数（12–15000） maxVCpuCount: 200 # manual 模式下的目标跟踪策略 policies: - predefinedMetricType: LambdaCapacityProviderAverageCPUUtilization targetValue: 70 # 可选：客户自管的 KMS 密钥 kmsKeyArn: arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012

配置时注意两个会被框架提前校验的规则：

• scaling.mode设为manual时，必须至少提供一条scaling.policies，否则框架抛出错误LAMBDA_CAPACITY_PROVIDER_MANUAL_SCALING_REQUIRES_POLICIES；
• instanceRequirements中allowedInstanceTypes和excludedInstanceTypes不能同时设置，否则抛出LAMBDA_CAPACITY_PROVIDER_INVALID_INSTANCE_REQUIREMENTS。

把容量提供程序挂到函数上

函数通过capacityProvider字段引用，支持三种写法：

functions: # 1. 按名字引用（字符串形式） my-function: handler: index.handler capacityProvider: highMem # 2. 函数级精细控制 etl: handler: handler.etl memorySize: 4096 capacityProvider: # provider.capacityProviders 中定义的名字， # 也可以是外部容量提供程序的 ARN 或内建函数 name: highMem # 单执行环境并发（1–1600） maxConcurrency: 100 # 每 vCPU 内存（GiB），只能是 2、4 或 8 memoryPerVCpu: 4 # 函数级执行环境扩缩容（0–15000）。 # 注意：min 设为 0 时，max 也必须设为 0 scaling: min: 5 max: 10 # 3. 直接引用服务外部创建的容量提供程序 my-other-function: handler: index.handler capacityProvider: arn:aws:lambda:us-east-1:123456789012:capacity-provider:external-provider

函数级配置的约束条件（来自文档与编译逻辑）：

• memoryPerVCpu只能是2、4、8，其他值会报错LAMBDA_MANAGED_INSTANCES_INVALID_MEMORY；
• 使用容量提供程序的函数内存必须至少 2048 MB。如果没有显式配置内存，框架会自动把该函数的内存提升到 2048 MB；如果显式配置了低于 2048 的值，会报错LAMBDA_MANAGED_INSTANCES_INVALID_MEMORY_SIZE；
• 多个函数可以引用不同提供程序，例如按内存密集型和成本优化型分别定义high-memory、cost-optimized两个提供程序，各自通过instanceRequirements.allowedInstanceTypes限定实例族（文档中给出了r7g.large/r7g.xlarge与t3.small/t3.medium的示例划分）。

部署与验证

配置写完后，用标准部署命令把服务连同容量提供程序一起推送到 AWS（详见 deploy 命令参考）：

# 使用默认 stage（dev）和区域（us-east-1） serverless deploy # 指定 stage 与区域 serverless deploy --stage production --region eu-central-1

serverless deploy会先执行打包，再通过 CloudFormation 部署整个栈，因此容量提供程序这类基础设施变更必须走deploy，而不是只更新代码的deploy function。

部署前后的验证方式：

1. 变量解析检查：运行serverless print（见 print 命令参考），它会打印变量全部解析后的配置，可以确认capacityProviders下各字段没有被变量解析吞掉或拼错。

2. 检查生成的 CloudFormation 资源：定义容量提供程序后会生成AWS::Lambda::CapacityProvider资源，未显式提供 Operator Role 时还会额外生成一个AWS::IAM::Role。按命名规则，服务my-service下名为default的提供程序对应的资源物理名示例为：

   • 容量提供程序：DefaultLambdaCapacityProvider
   • Operator Role：LambdaCapacityProviderOperatorRole

   可以在 CloudFormation 栈或本地生成的模板中核对这两个资源是否存在。

3. 部署输出：serverless deploy --verbose会展示部署过程中的全部栈事件和 Stack Output，可用于定位失败环节。

常见问题与限制

删除旧提供程序时被函数版本卡住。当provider.versionFunctions启用（默认）或函数显式设置versionFunction: true时，每次发布的函数版本都会关联当时使用的容量提供程序。如果之后更换了函数的capacityProvider并从provider.capacityProviders删掉旧条目，CloudFormation 可能报类似这样的错误：

The capacity provider is currently in use by 1 functions. To delete this capacity provider, first remove its association with arn:aws:lambda:REGION:ACCOUNT:capacity-provider:my-service-dev-HighMemLambdaCapacityProvider-XXXXXXXX.

原因是旧的函数版本仍关联着旧提供程序。文档给出的解决路径：确认流量不再走旧函数版本后，先删除旧版本再删提供程序；如果只依赖$LATEST，可以直接关闭自动版本化：

provider: versionFunctions: false

代码必须线程安全。Managed Instances 支持单执行环境并发处理多个请求，执行环境中的全局变量和共享资源会被并发访问，文档明确要求函数代码保持 thread-safe 且无状态。

Operator Role 权限。每个容量提供程序都需要一个带AWSLambdaManagedEC2ResourceOperator托管策略的 Operator Role；自己提供 ARN 时，该角色必须附加此策略或等效权限。

区域可用性。Lambda Managed Instances 只在特定区域提供，部署前先确认目标区域的支持情况（以 AWS 文档为准）。

文档中的最佳实践建议（出自 managed-instances.md）：多数场景先用auto模式；网络相同时用默认 VPC 继承；用maxVCpuCount控制成本上限；函数级min/max做细粒度控制；通过 Savings Plans 或预留实例优化成本；并监控执行环境使用量来调整资源分配。

【免费下载链接】serverless⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.项目地址: https://gitcode.com/GitHub_Trending/se/serverless