AWS Lambda Web Functions as a Contract - Endpoint Types, Authentication, Scaling Limits, 429s and 503s, and What Is Fixed at Creation

First Published: 2026-10-19
Last Updated: 2026-10-19

AWS Lambda announced Lambda Web Functions on October 12, 2026. This feature allows developers to run HTTP server code that listens on a port directly within Lambda. The announcement highlighted the ability to use existing frameworks like Express and Hono, with no adapters or custom configuration. Alongside this announcement, existing Lambda functions were formally designated as Lambda Event Functions.

Transitioning to Web Functions involves changes in how endpoints are defined. The changes include who handles authentication, how many requests a single execution environment can handle concurrently, what is returned when the limit is exceeded, and what aspects cannot be modified after creation. This article extracts these details from the Lambda developer guide, presenting them as a "contract" in a table. It compares Web Functions against three alternatives: Event Functions (synchronous invocations), Function URLs, and Lambda Managed Instances.

This article does not cover usage instructions, framework development, performance, or pricing. It also does not offer recommendations on which entry point is better. The information presented in this article was verified on October 18, 2026. The results in Section 8 were obtained from a small configuration created for this article in the US East (N. Virginia) Region on October 18, 2026.

Related articles on this site:

1. Scope and Assumptions
2. How to Read the Tables
3. Three Resources and Three Endpoint Types
4. Authentication with ApplicationManaged and IamAuth
5. Concurrency and Limits
6. When a Request Is Turned Away: 429 and 503
7. Next to the Existing Entry Points
8. What This Configuration Returned
9. Failure Modes
10. Frequently Asked Questions About Lambda Web Functions Endpoints
11. Summary
12. References

1. Scope and Assumptions

This section will first define the intended audience for this article, the scope of its content, the materials referenced, the availability status, and the naming. The key conclusions are as follows:

The endpoint type (HomeRegion, MultiRegion, PerRegion) and its Regions cannot be changed after creation. Authentication type, automatic deployment, scaling, and throttling settings can be modified for existing endpoints. The maximum number of requests a single execution environment can handle concurrently is a revision setting, and changing it requires creating a new revision.
For ApplicationManaged endpoints, Lambda does not perform authentication and does not evaluate resource-based policies for the Web Function. Authentication responsibility stays in the user's code.
Requests exceeding a limit receive an HTTP 429 response, whose lambda-web-error-type header has one of five values. Lambda does not queue throttled requests. However, while a new execution environment is initializing, requests queue instead of being throttled immediately. When rateLimit is set to 0, Lambda returns a 503 response instead of 429.
MultiRegion endpoints select a Region based on latency. Lambda does not perform failover based on health status.

1.1 Intended Audience

This article is intended for the following readers.

Developers who want to deploy Express or Hono HTTP servers on Lambda. This includes those who previously used Lambda Web Adapter, Function URLs, or Amazon API Gateway as intermediaries.
Individuals responsible for operating these HTTP servers as the primary endpoint in a production environment.
Those who believe that "Web Functions automatically provide redundancy across multiple Regions," "even with ApplicationManaged, resource-based policies can be used to restrict access," "requests exceeding the limit are queued," and "the endpoint type can be changed later."

However, these assumptions are not consistent with the information presented in the official documentation. The developer guide states Lambda doesn't perform health-based failover. regarding MultiRegion. It also states You can't use a resource-based policy to restrict who invokes an ApplicationManaged endpoint. regarding ApplicationManaged. Regarding throttling, the documentation states Lambda does not queue throttled requests., and concerning endpoint types, it states The endpoint type cannot be changed after creation.

1.2 What This Article Covers, and What It Does Not

This article focuses on the contract of the HTTP entry point of Web Functions. Specifically, it covers three resources (Web Function, Revision, Endpoint), endpoint types, aspects that can be modified after creation versus those that cannot, authentication, concurrency and limits, and responses when limits are exceeded. For the three entry points it compares, the article keeps only the rows that correspond to its columns.

This article does not cover:

Pricing and billing details.
Performance comparisons and cold start metrics.
How to write code using frameworks like Express and Hono, and migration procedures.
Lambda MicroVMs.
The metadata endpoints for Web Functions. See Section 6.6 of Metadata Endpoints Across AWS Compute on this site.
Detailed information about connecting to VPCs (briefly mentioned in Section 4.1).
The two throttling paths and reserved concurrency details for Event Functions. See Section 5 of AWS Lambda Concurrency and Scaling Guide on this site.
The capacity providers for Lambda Managed Instances, and the design considerations for handling multiple invocations within a single execution environment. See AWS Lambda Managed Instances on this site.
A list of supported Regions. While What's New lists five Regions, the current list can be found on the AWS Capabilities by Region page.

1.3 Sources Read and What Was Run

On October 18, 2026, this article read the following AWS documentation: sections of the Lambda Developer Guide, specifically the chapter on Web Functions (covering concepts, endpoints, scaling, access control, permissions, networking, runtime, architecture, monitoring, testing, and troubleshooting); the Lambda quotas page; the pages on Function URLs and Lambda Managed Instances; the Invoke section of the Lambda API Reference; three CloudFormation resource types (AWS::Lambda::WebFunction, AWS::Lambda::WebFunctionRevision, and AWS::Lambda::WebFunctionEndpoint); the AWS::Serverless::WebFunction section in AWS SAM; the page on Web Functions origins in the Amazon CloudFront Developer Guide; and two What's New announcements from October 12, 2026 (Web Functions, and CloudFront support for Web Functions origins).

The Web Functions pages of the Lambda Developer Guide did not display a revision date. The Document History section of the Lambda Developer Guide also did not list any entries related to Web Functions as of October 18, 2026. Therefore, this article specifies the verification date as October 18, 2026. Given that this feature was released on October 12, 2026, the content on these pages may have changed since the verification date.

The results presented in Section 8 were obtained using a configuration created specifically for this article. In the US East (N. Virginia) Region (us-east-1), CloudFormation created one Web Function, two revisions, and three HomeRegion endpoints, and requests were sent from a local device. Section 8 details the configuration and procedures. No performance measurements were conducted.

1.4 Availability and Naming

What's New (the postDateTime is 2026-10-12T19:30:00Z) states that Web Functions are available today. This page contains neither the term generally available nor the term preview. This article uses the exact wording "available today" and does not refer to "general availability" (GA). What's New lists the supported runtime as Node.js. As of October 18, 2026, the table on the runtime page in the developer guide shows a single entry for nodejs24.x.

What's New also mentions that existing Lambda functions are now referred to as Lambda Event Functions. This is a naming change only that requires no code changes or redeployments for your existing functions. This article uses the term "Event Functions" after its initial mention. The names of APIs, CloudFormation resource types, and the function portion of ARNs have not changed. For example, Invoke and AWS::Lambda::Function remain unchanged. The term "Lambda function" used in previously published articles on this site refers to the older name and is not incorrect.

2. How to Read the Tables

This section defines the columns and terms used in the table presented in this article.

2.1 Common Columns

The tables in this article use the following six column names. The first five are shared with two related articles on this site, and the contract table in Section 7.1 lists these five. The sixth is specific to this article and appears in the tables in Sections 3.3 and 5.1.

Column	What the cell holds
`AWS Runs`	What AWS operates for this entry point
`You Set`	What the user can configure, and on which resource
`If You Set Nothing`	The behavior or default when the user configures nothing, with the source of that statement
`Where It Shows`	Where a limit or a rejection becomes visible: status codes, `lambda-web-error-type`, metrics
`What Stays With You`	What AWS does not take over and remains the user's responsibility
`Changeable After Creation`	Whether the setting can be changed on an existing resource, and how

The values in the Changeable After Creation column are one of three options: Yes (update the endpoint), New revision, or No (create a new endpoint).

2.2 Where Defaults Come From, and How "Not Set" Is Written

The If You Set Nothing column includes the source of the value in parentheses. The developer guide (the scaling, endpoint, and quota pages) and the CloudFormation property descriptions detail the default values for Web Functions.

The developer guide uses None to indicate the default values for maxEnvironments and rateLimit. This does not represent 0 or an unlimited value. When a value is not set, it means the endpoint operates under the account's quotas. This article uses Not set, and the corresponding upper limit will be specified in the same cell.

2.3 Values from the Sources and Values Returned in This Configuration

The tables in Sections 3 through 7 of this article contain only the values from the sources. In the table in Section 8, the values returned in this article's configuration are kept in a column of their own, next to what the developer guide says. The two are not mixed in one column. The values in Section 8 are a record of that configuration on that day, not values the sources guarantee.

When no statement is found, this article says so, with the sources searched and the date checked. It does not say that the feature does not exist.

3. Three Resources and Three Endpoint Types

This section describes the three resources that comprise a Web Function, and the different types of endpoints.

3.1 Web Function, Revision, Endpoint

According to the developer guide's Concepts page, a Web Function consists of three types of resources that have a parent-child relationship. The Web Function is the top-level resource, while Revision and Endpoint are its child resources.

Web Function: This is the top-level resource that represents an application. It has a name, ARN (Amazon Resource Name), and a status.
Revision: This represents an immutable snapshot of your code and configuration (immutable snapshots of your code and configuration). A new revision is created whenever you modify the code or the revision's configuration (such as request timeouts, the maximum number of concurrent requests per environment, or environment variables).
Endpoint: This serves as an entry point that routes HTTP requests to revisions. The developer guide states An endpoint is a child resource of a Web Function that provides a network entry point for HTTP traffic. Each endpoint has its own unique domain name, as well as settings for TLS, authentication type, and scaling.

The developer guide also states A Web Function can have up to 10 endpoints, each with independent configuration. A single endpoint can route requests to one or two revisions. When it routes to two revisions, the revisionWeights parameter determines the weighting. The quotas page specifies that each endpoint can route to a maximum of two revisions, and the weighting range is 1–100.

How a Lambda Web Function Is Built: Web Function, Revisions, and Endpoints

3.2 HomeRegion, MultiRegion, PerRegion

Endpoint types are selected when creating them. These types determine which Regions your Web Function will run in and how requests are routed.

Endpoint type	Regions	Domain name	Who routes requests to a Region	Signing for `IamAuth`	`autoDeploymentMode`
`HomeRegion`	The home Region only	One regional domain	Not applicable	SigV4	`LatestRevision` or `Disabled`
`MultiRegion`	The home Region and at least one other Region	One global domain	Lambda, by latency; no health-based failover	SigV4a	`Disabled` only
`PerRegion`	The home Region and at least one other Region	One regional domain per Region	The user, for example with Route 53 or CloudFront	SigV4	`Disabled` only

Regarding MultiRegion, the developer guide states:

Lambda allocates a single global domain name. It uses latency-based routing to send each request to the Region that typically provides the lowest latency for the caller. Lambda doesn't perform health-based failover.

The Concepts page describes this routing as on a best-effort basis. The Multi-Region deployment page states routes by latency, not by Region health. In other words, the documentation does not describe MultiRegion as a mechanism that automatically switches to another Region in the event of a Region failure. With PerRegion, Lambda does not make routing decisions based on latency. The user determines how requests reach each Region's domain, using Route 53 routing policies or CloudFront. The developer guide lists geographical restrictions and custom failover logic as potential uses for PerRegion.

You manage both MultiRegion and PerRegion Web Functions from the home Region. Resources are not visible, and changes cannot be made, in the replica Regions. The developer guide states that all API requests for management are sent to the home Region.

The domain name format is as follows: for HomeRegion and PerRegion, it is domain-id.shard-id.lambda-web.region.on.aws; for MultiRegion, it is domain-id.lambda-web.global.on.aws. Lambda manages the TLS certificates. It is not possible to directly attach a custom domain to the endpoint. To serve traffic on your own domain, the developer guide says to put a CloudFront distribution in front of the endpoint and use the Lambda-assigned domain name as the origin. When an endpoint is deleted, that domain name is no longer used. The developer guide states, Lambda never assigns a deleted endpoint's domain names to another endpoint in any account.

What the Three Endpoint Types Route and Sign

3.3 What Is Fixed at Creation and What You Can Change Later

The developer guide's endpoint page lists six items that can be modified for existing endpoints, and two that cannot. Regarding the two items that cannot be changed, it states:

The Regions and endpoint type cannot be updated after creation. To change these, create a new endpoint with the configuration that you want, migrate traffic to the new endpoint's domain name, and then delete the old endpoint.

Because a new endpoint will have a new domain name, changing the type or the Regions will also change the domain name that clients call.

Setting	Resource	`Changeable After Creation`	Source
`endpointType`	Endpoint	`No (create a new endpoint)`	Developer guide (endpoints); CloudFormation: `Update requires: Replacement`
`regions`	Endpoint	`No (create a new endpoint)`	Developer guide (endpoints); CloudFormation: `Update requires: Replacement`
`authType`	Endpoint	`Yes (update the endpoint)`	Developer guide (endpoints, access control)
`autoDeploymentMode`	Endpoint	`Yes (update the endpoint)`	Developer guide (endpoints)
`revisionWeights`	Endpoint	`Yes (update the endpoint)`	Developer guide (endpoints)
`scalingConfig` (`maxEnvironments`)	Endpoint	`Yes (update the endpoint)`	Developer guide (endpoints, scaling)
`throttleConfig` (`rateLimit`)	Endpoint	`Yes (update the endpoint)`	Developer guide (endpoints, scaling)
`description`	Endpoint	`Yes (update the endpoint)`	Developer guide (endpoints)
`maxConcurrencyPerEnvironment`	Revision	`New revision`	Developer guide (scaling)
Code, timeout, environment variables	Revision	`New revision`	Developer guide (core concepts); CloudFormation: all revision properties are `Replacement`

The autoDeploymentMode setting determines whether Lambda automatically routes traffic to a new revision when it is created. LatestRevision directs 100% of traffic to the most recent, valid revision. Disabled allows users to specify traffic destinations using revisionWeights. The developer guide states that if the autoDeploymentMode is omitted in an API request, it defaults to Disabled. Both the Lambda console and the aws lambda-web deploy command use LatestRevision for new HomeRegion endpoints. Because LatestRevision is only available for HomeRegion endpoints, endpoints configured for MultiRegion and PerRegion always operate in Disabled mode. As of October 18, 2026, the autoDeploymentMode property is not listed among the properties for AWS::Lambda::WebFunctionEndpoint in CloudFormation, and CloudFormation examples use RevisionWeights to specify revisions.

The deployment page indicates that while using LatestRevision, you cannot configure revision weights, and any request that attempts to set weights alone will fail. Therefore, the page's procedure sets the mode to Disabled and the weights in a single request.

Whether traffic is routed to a new revision with a modified maxConcurrencyPerEnvironment depends on the endpoint's autoDeploymentMode. The developer guide states Whether the new revision receives traffic depends on the endpoint's auto-deployment mode.

4. Authentication with ApplicationManaged and IamAuth

This section describes two authentication types for endpoints, explaining what Lambda verifies and what stays with the user's code.

4.1 What Lambda Checks and What Stays with Your Code

The authType value can be either ApplicationManaged or IamAuth.

`authType`	What Lambda checks	Resource-based policy on invoke	What stays with your code
`ApplicationManaged`	Nothing; every request reaches the function	Not evaluated	All authentication and authorization
`IamAuth`	The SigV4 or SigV4a signature, and the `lambda:InvokeWebFunctionEndpoint` permission	Evaluated	Authorization inside the application, if the application needs it

Regarding ApplicationManaged, the developer guide's endpoint page states:

Lambda does not authenticate incoming requests. All HTTP requests are forwarded directly to your application. You are responsible for handling authentication in your application code.

The note on the access control page indicates that for invoke requests to ApplicationManaged endpoints, Lambda does not evaluate the Web Function's resource-based policy.

You can't use a resource-based policy to restrict who invokes an ApplicationManaged endpoint. To restrict invocation, use IamAuth instead. The resource-based policy still applies to management actions.

IamAuth ensures that Lambda authenticates and authorizes requests using IAM. The caller must have the lambda:InvokeWebFunctionEndpoint permission. If the caller is in the same account as the Web Function, either an identity-based policy or a resource-based policy can be used to grant permission. If the caller is in a different account, both are required.

With either authentication type, the endpoint's domain is accessible from the internet. The networking page states IamAuth controls who can invoke an endpoint, but it does not make the endpoint private at the network layer. A note on the same page clarifies that AWS PrivateLink interface endpoints cannot be used for the domain names of Web Functions' endpoints. Even if you configure an egress network connector to route traffic to a VPC, the endpoint remains publicly accessible.

4.2 SigV4 and SigV4a

The caller must sign requests to IamAuth endpoints. The developer guide states that there is no dedicated SDK for calling these endpoints; callers send standard HTTP requests and sign them with the service name lambda. The signing method depends on the type of endpoint.

For HomeRegion and PerRegion endpoints, use AWS Signature Version 4 (SigV4).
For MultiRegion endpoints, use Signature Version 4a (SigV4a), which signs for a set of Regions instead of one Region. The developer guide says to use the Region set *.

The developer guide also details the following regarding signing:

All signed requests, regardless of whether they include a request body, must include the X-Amz-Content-SHA256 header. Lambda verifies the signature by reading the value of this header as the hash of the payload, rather than reading the request body itself. Lambda rejects requests without this header with a 403 Forbidden error.
When not signing the request body (e.g., during streaming), use UNSIGNED-PAYLOAD in the X-Amz-Content-SHA256 header. Lambda does not support signing chunked request bodies.
Lambda does not compare the request body with the value in the X-Amz-Content-SHA256 header. If you require full payload integrity beyond TLS, you must implement this within your application.

This site's AWS Signature Version 4 Request Signer and Explainer details the specific steps for signing.

4.3 The Authorization Header on Each Path

Whether an application can receive an Authorization header depends on the route of the request. The developer guide's access control page describes three routes separately. It is important not to generalize statements from one route to apply to others.

Path	What Lambda does with `Authorization`	Source
`IamAuth`, signed directly by the caller	Removes the header after it validates the SigV4 or SigV4a signature	Developer guide (access control)
`IamAuth`, through CloudFront with OAC	Removes only a value that is itself an AWS signature (starts with `AWS4-`); other values such as a JWT reach the function when CloudFront forwards the header (Section 4.4)	Developer guide (access control, CloudFront integration)
`ApplicationManaged`	Forwards the caller's header; removes a SigV4 signature and any `X-Amz-Security-Token` header	Developer guide (access control)

Regarding the first route, the developer guide states

After Lambda validates the SigV4 or SigV4a signature, it removes the Authorization header before forwarding the request to your function.

The same page continues that if you want your function to receive the Authorization header on an IamAuth endpoint, you can send requests through CloudFront, which signs them on your behalf. In the second route, CloudFront signs the request to the origin while the application keeps its own authentication, such as a JWT or cookies.

4.4 CloudFront and OAC

When placing CloudFront in front, you can use custom domains and AWS WAF. You can restrict access to Web Functions endpoints using CloudFront's Origin Access Control (OAC). The developer guide and CloudFront developer guide specify the following conditions:

The authentication type for the endpoint is IamAuth.
Configure OAC with an origin type of lambda and a signing behavior of always-amz-auth. CloudFront does not accept other signing behaviors for Web Function origins.
Apply a resource-based policy to the Web Function, granting the CloudFront service principal (cloudfront.amazonaws.com) permission to lambda:InvokeWebFunctionEndpoint, and restrict this permission using aws:SourceArn to your specific distribution.
Do not send the viewer's Host header in requests to the origin. The CloudFront developer guide recommends using AllViewerExceptHostHeader instead of AllViewer when using a managed origin request policy.
To let the function receive the viewer's Authorization header (e.g., a JWT), include that header in the cache policy for all cache behaviors that use the origin. The CloudFront developer guide states that, for GET and HEAD requests, CloudFront removes an Authorization header that is not in the cache policy before forwarding the request.
The CloudFront developer guide states that OAC cannot be used with global endpoints that include opt-in Regions.

Even when placing CloudFront in front, the endpoint's domain remains accessible from the internet. The developer guide states

The endpoint domain stays reachable on the internet, and Lambda also accepts direct signed requests from any principal that your policies allow.

Regarding ApplicationManaged endpoints, the note states:

Lambda doesn't authenticate requests to an ApplicationManaged endpoint or evaluate the Web Function's resource-based policy for them. Such an endpoint stays publicly reachable at its own domain, even behind CloudFront.

The networking page also states that, when using ApplicationManaged, direct requests do not go through CloudFront and AWS WAF. This site's Amazon CloudFront Origin Architecture Guide covers the overall details of OAC.

4.5 Governance with Condition Keys and SCPs

You can restrict which authentication types endpoints can use with IAM condition keys. The developer guide lists two condition keys.

Condition key	Value it reflects	Actions
`lambda:Request/WebFunctionAuthType`	The authentication type in the request	`CreateWebFunction`, `CreateWebFunctionEndpoint`, `UpdateWebFunctionEndpoint`
`lambda:Resource/WebFunctionAuthType`	The authentication type configured on the endpoint	`InvokeWebFunctionEndpoint` (evaluated only on `IamAuth` endpoints), `UpdateWebFunctionEndpoint`, `GetWebFunctionEndpoint`, `DeleteWebFunctionEndpoint`

The developer guide provides an example of a service control policy (SCP) that AWS Organizations administrators can use to prevent the creation of public endpoints. This SCP denies the creation and updating of endpoints when lambda:Request/WebFunctionAuthType is set to ApplicationManaged. The denial includes lambda:CreateWebFunction because this operation creates the initial endpoint from the request's endpointConfig. The developer guide states that with this SCP in place, the aws lambda-web deploy command will fail with an access denied error unless developers explicitly include --auth-type IamAuth. It continues By default, the command creates an ApplicationManaged endpoint.

5. Concurrency and Limits

This section describes three settings that determine the volume of requests an endpoint can handle, as well as information about your account's quota.

5.1 Three Settings

Web Functions scale in two dimensions: the number of execution environments and the number of requests a single execution environment can handle concurrently. The developer guide's scaling page lists these three settings in the table below.

Setting	Configured on	Valid range	`If You Set Nothing`	`Changeable After Creation`
`maxConcurrencyPerEnvironment`	Revision	1–128	Default 64 (developer guide, scaling; CloudFormation)	`New revision`
`maxEnvironments`	Endpoint	Optional, 2–10,000	Not set: the endpoint scales within the account quotas, always bounded by the account vCPU quota (developer guide)	`Yes (update the endpoint)`
`rateLimit`	Endpoint	Optional, 0–10,000 requests per second	Not set: the per-endpoint quota of 10,000 requests per second and the account quotas apply (developer guide)	`Yes (update the endpoint)`

maxConcurrencyPerEnvironment sets the upper limit for a dynamic limit managed by Lambda. Lambda automatically adjusts the number of requests a single execution environment can handle concurrently based on the function's resource usage. The developer guide states Lambda's dynamic limit can be lower than this value, but never exceeds it. For new Web Functions, Lambda starts with a conservative value and gradually increases it based on usage patterns. Lambda retains this learning even after the function scales to zero.

The rateLimit value has specific increments. The scaling page states that values up to 1,000 must be multiples of 100, while values above 1,000 must be multiples of 1,000. The quotas page describes valid values as 0, 100–1,000 in steps of 100, and 2,000–10,000 in steps of 1,000. The CloudFormation description for RateLimit indicates that Supported values can vary by Region, and that specifying an unsupported value will result in an error indicating the valid values for that Region. Setting rateLimit to 0 will block all requests (see Section 6.3).

Both maxEnvironments and rateLimit can be modified without creating a new revision. You can pass --scaling-config or --throttle-config with the aws lambda-web update-web-function-endpoint command. Omitting the parameter will retain the current value, while passing an empty object ('{}') will clear the setting.

The developer guide states that these three settings operate independently. The maximum concurrency (the number of requests being processed simultaneously) is approximately maxEnvironments multiplied by maxConcurrencyPerEnvironment. The rateLimit separately limits the arrival rate (the number of requests accepted per second). In an example provided in the developer guide, when a request takes 200 ms, the maximum concurrency is reached first; however, when a request takes only 10 ms, the rateLimit is reached first.

5.2 Account Quotas

The scaling page lists the following three quotas, per AWS Region. These apply in addition to any limits you set for individual endpoints.

Quota (per AWS Region)	Value	Adjustable
Per-endpoint rate limit	10,000 requests per second	No (quotas page)
Account total rate limit	100,000 requests per second across all endpoints	Yes (quotas page)
Account vCPU limit	2,000 Arm64 vCPUs across all endpoints; each execution environment uses 2 vCPUs	Yes (quotas page)

Each execution environment uses 2 vCPUs. Therefore, the account's vCPU quota limits the total number of execution environments you can run within a Region. The quotas page also specifies 2 GB of memory per execution environment, a default request timeout of 30 seconds (range 3–900), and an initialization timeout of 10 seconds before the server begins listening. The Architecture page states that Web Functions only operate on Arm64 and do not offer options for selecting an instruction set.

The quotas page indicates that new accounts have reduced vCPU and request rate quotas for Web Functions, which AWS will automatically increase based on usage. You can verify the values applicable to your account with the GetWebAccountSettings operation.

5.3 Scaling from Zero, Temporary Overshoot, and Independence per Region

The developer guide states that there are no minimum or reserved environment settings.

There is no minimum or reserved-environment setting. An endpoint always scales from zero as traffic arrives.

Lambda increases the number of execution environments in anticipation of demand to handle small increases in traffic and maintain headroom. If the load increases faster than the headroom can absorb, requests wait for the cold start of new environments.

Lambda may temporarily exceed the maxEnvironments setting. The developer guide states Lambda might temporarily exceed maxEnvironments to prioritize availability. This can occur during revision weight changes, internal fleet cycling, and similar events, and the overshoot is brief; Lambda automatically returns to the configured setting.

For MultiRegion and PerRegion endpoints, Lambda applies scaling settings separately for each Region where the endpoint is running. Each Region maintains its own set of execution environments, and traffic in one Region does not use the capacity of another Region. In replica Regions, the account quota of that Region applies. Endpoints of the same Web Function, aside from account quotas, scale independently of each other.

6. When a Request Is Turned Away: 429 and 503

This section reads what is returned when a request exceeds a limit, and where that becomes visible.

6.1 Five 429 Error Types and Their Metrics

The scaling page details three conditions under which Lambda returns an HTTP 429 (Too Many Requests) error. These conditions occur when the arrival rate exceeds the rateLimit, when all execution environments are fully utilized (reaching maxEnvironments or when the account reaches its vCPU quota), or when an excessive number of execution environments are initializing concurrently. The troubleshooting and testing pages differentiate this 429 error using five distinct values in the lambda-web-error-type header. Dividing the conditions into those related to endpoint limits and account quotas results in a total of five.

Condition	`lambda-web-error-type`	Throttle metric (`AWS/Lambda/Web/Usage`)
The endpoint's request rate limit is exceeded	`Platform.EndpointRequestThrottle`	`EndpointRequestThrottles`
The account request-rate quota in the Region is exceeded	`Platform.AccountRequestThrottle`	`AccountRequestThrottles`
The endpoint reached `maxEnvironments` and all environments are fully utilized	`Platform.EndpointMaxEnvThrottle`	`EndpointActiveEnvironmentThrottles`
The account reached its Arm64 vCPU quota in the Region	`Platform.AccountActiveVCPUArm64Throttle`	`AccountActiveVCPUArm64Throttles`
Too many execution environments are initializing at the same time	`Platform.EndpointConcurrentInitThrottle`	None

Regarding the first row, the troubleshooting page states The endpoint's request rate quota was exceeded., and the monitoring page describes EndpointRequestThrottles as the number of requests throttled because the endpoint reached its rateLimit. For the final row, the scaling page states This throttle doesn't increment a throttle metric. The monitoring page also states that, because Lambda attributes each throttled request to one limit, a throttled request increments at most one throttle metric. Throttled requests are also counted in HTTPResponseStatusClass4XX in the AWS/Lambda/Web namespace.

The value of the lambda-web-error-type header begins with Platform., Runtime., or Application.. The troubleshooting page states that Lambda omits this header in cases of internal service errors and authorization failures, to prevent exposing details to unauthorized callers. Therefore, endpoints using IamAuth will not include this header in 403 responses returned for unsigned requests.

Regarding rateLimit, the developer guide states that the arrival rate is measured on a per-second basis, and requests that briefly exceed the limit may still be accepted. However, if the limit is consistently exceeded, requests will be throttled.

6.2 Queue or Throttle

Whether a request waits or is rejected immediately depends on which limit it hits. The same paragraph of the scaling page states these two sentences in a row:

Lambda does not queue throttled requests. If a new execution environment is initializing, requests queue instead of being throttled immediately.

Quoting only one of the two sentences changes what they say. When an endpoint can no longer scale and all existing execution environments are fully utilized, Lambda immediately throttles new requests with a 429 error. However, if a new execution environment is initializing, requests are queued and wait for that environment to become available.

There may also be instances where requests wait under dynamic limits. The scaling page states

When the limit prevents all existing environments from accepting more requests, requests queue, waiting for the next available environment.

This refers to a dynamic limit on the number of requests a single execution environment can handle, distinct from situations where maxEnvironments or quotas have been reached. The developer guide clarifies that Lambda only returns a 429 error when one of the throttling limit thresholds is exceeded.

6.3 Scaling Page: Two 503 Errors and Other Causes

The scaling page documents two instances of HTTP 503 (Service Unavailable) errors related to rate limits and load shedding.

Case	`lambda-web-error-type`	What the developer guide says to do
The endpoint's `rateLimit` is 0	`Platform.EndpointDisabled`	It continues until you set `rateLimit` to a nonzero value
Lambda sheds load to protect the service (or an internal error)	None	Retry with backoff and jitter

Regarding the case where rateLimit is 0, the developer guide states When an endpoint's rateLimit is 0, Lambda returns HTTP 503 (Service Unavailable) instead of HTTP 429. In other words, if you set rateLimit to 0 and disable an endpoint, the client will receive a 503 instead of a 429. When you stop a Function URL by setting reserved concurrency to 0, Lambda returns a 429 (see Section 7.3). The two ways of stopping result in different status codes visible to the client.

Concerning 503 responses without headers, the developer guide states Lambda can also return HTTP 503 when it sheds load to protect the service. It continues Retry a 503 that has no lambda-web-error-type header with backoff and jitter. The testing page recommends recording 503 responses without headers separately, as they may indicate temporary load shedding or internal errors.

The HTTP response table on the troubleshooting page expands the list of potential causes for a 503 error, stating:

The application crashed while handling a request, the endpoint is disabled, or Lambda could not obtain capacity or reach the application.

To identify the specific cause, it advises checking the lambda-web-error-type header, when present, and consulting application and system logs. In other words, a 503 error isn't limited to the two causes listed in the table. This article focuses solely on those two causes related to limits and load shedding, and does not cover the error types for the other causes.

6.4 What Stays with the Client

When your application receives HTTP 429 responses, the client handles the retry attempts. The scaling page states

When your application receives HTTP 429 responses, implement exponential backoff with jitter in your client code to retry throttled requests.

Regarding Platform.EndpointConcurrentInitThrottle, the troubleshooting page recommends retrying requests using exponential backoff.

No statement on whether Web Functions 429 responses include a Retry-After header was found in the Web Functions pages and the quotas page read on October 18, 2026. The retryAfterSeconds field of the TooManyRequestsException for the Invoke API in Event Functions is a field in a separate API response. In the configuration in Section 8, none of the 1,627 429 responses included a Retry-After header.

7. Next to the Existing Entry Points

This section places Web Functions endpoints next to three existing entry points, using the five common columns. It does not say which one is better.

7.1 The Contract Table

Entry point	`AWS Runs`	`You Set`	`If You Set Nothing`	`Where It Shows`	`What Stays With You`
Web Functions endpoint	The HTTPS domain and its TLS certificate; execution environments that each serve multiple concurrent requests, scaled from zero	Endpoint type and Regions at creation; `authType`; `maxEnvironments` and `rateLimit` (endpoint); `maxConcurrencyPerEnvironment` (revision)	`maxConcurrencyPerEnvironment` 64; `maxEnvironments` and `rateLimit` not set, so account quotas apply; `autoDeploymentMode` `Disabled` when omitted in an API request (developer guide)	HTTP 429 with five `lambda-web-error-type` values; HTTP 503 with `Platform.EndpointDisabled` or without the header; `AWS/Lambda/Web/Usage` metrics	Authentication with `ApplicationManaged`; failover between Regions; client retries with backoff and jitter
Event Functions, synchronous `Invoke`	Execution environments that each run one invocation at a time	Reserved concurrency and provisioned concurrency (function)	The account concurrency quota (default 1,000 concurrent executions, lower for new accounts, quotas page)	HTTP 429 `TooManyRequestsException` with `retryAfterSeconds` and a reason such as `ReservedFunctionConcurrentInvocationLimitExceeded` (API reference)	Retrying a throttled synchronous invocation
Function URL (on an Event Function)	An HTTPS URL in front of the function	`AuthType` `AWS_IAM` or `NONE`; reserved concurrency for throttling	With `NONE`, the resource-based policy is still in effect and must grant public access (developer guide)	HTTP 429 above reserved concurrency, or above 10 times reserved concurrency in requests per second (developer guide)	Authentication with `NONE`; retries
Lambda Managed Instances	Execution environments on instances of a capacity provider, each handling multiple invocations	`PerExecutionEnvironmentMaxConcurrency` (function configuration) and the capacity provider	A runtime-specific default; 64 concurrent requests per vCPU for Node.js (developer guide)	Throttles with reason metrics `ConcurrencyThrottles`, `CPUThrottles`, `MemoryThrottles`, and `DiskThrottles`	Planning for traffic that grows faster than the asynchronous scaling; thread safety and shared state

Each cell in the table is based on the developer guide and the API reference as read on October 18, 2026. This article organizes the What Stays With You cell of the Event Functions row according to Section 5.3 of this site's concurrency guide.

7.2 How It Differs from Synchronous Invocation of Event Functions

Event Functions' execution environments process only one invocation at a time. The Managed Instances page describes the default compute type as a single concurrency model where one execution environment can run a maximum of one invoke at a time. In contrast, Web Functions' execution environments can handle multiple requests concurrently. The settings listed on the Web Functions scaling page consist of three parameters: the maximum number of execution environments (maxEnvironments), the maximum request rate (rateLimit), and the maximum number of concurrent requests per execution environment (maxConcurrencyPerEnvironment). Reserved concurrency is not included in these parameters.

When Event Functions' synchronous invocations are throttled, the Invoke API returns an HTTP 429 error, specifically a TooManyRequestsException. The API reference documents this exception, indicating the number of seconds the caller should wait before retrying (retryAfterSeconds). Sections 5.2 and 5.3 of this site's AWS Lambda Concurrency and Scaling Guide cover the two throttling paths for Event Functions (how fast requests arrive and the concurrency ceiling) and the differences by invocation type. The 429 errors for Web Functions use a separate mechanism, distinguished by the lambda-web-error-type header.

7.3 How It Differs from Function URLs

Function URLs place an HTTPS URL in front of the function (either an alias or $LATEST) associated with an Event Function. There are two authentication types: AWS_IAM and NONE. Starting in October 2025, new Function URLs require two permissions: lambda:InvokeFunctionUrl and lambda:InvokeFunction.

The handling of cases where no authentication is required differs from Web Functions. Regarding Function URL's NONE authentication type, the developer guide states that while Lambda does not perform authentication,

your function's resource-based policy is always in effect and must grant public access before your function URL can receive requests

. In contrast, with Web Functions using ApplicationManaged, Lambda does not evaluate the resource-based policy for invoke requests (see Section 4.1).

The throttling configuration also differs. Reserved concurrency limits Function URL throughput, and the maximum number of requests per second is ten times the reserved concurrency. If either of these limits is exceeded, Lambda returns an HTTP 429 error. The developer guide notes that to completely block requests to a Function URL in an emergency, you can set the reserved concurrency to 0, in which case Lambda returns a 429 error. For Web Functions, setting rateLimit to 0 results in a 503 error (see Section 6.3).

7.4 How It Differs from Lambda Managed Instances

Lambda Managed Instances also process multiple invocations concurrently in a single execution environment. The function's PerExecutionEnvironmentMaxConcurrency setting sets the limit, and its default varies by runtime. For Node.js, the default is 64 per vCPU. The developer guide states that Managed Instances scale asynchronously, based on factors such as CPU utilization rather than invocation arrival, and that throttling may occur if traffic more than doubles within 5 minutes. The metrics ConcurrencyThrottles, CPUThrottles, MemoryThrottles, and DiskThrottles differentiate the reasons for throttling.

Both the metrics indicating the reasons for throttling in Managed Instances and the values in Web Functions' lambda-web-error-type identify "which limit was reached." However, the resources and metrics themselves are distinct. Sections 5.2 and 6 of this site's AWS Lambda Managed Instances discuss the handling of concurrent execution and saturation within Managed Instances environments.

8. What This Configuration Returned

The values presented in this section were obtained on October 18, 2026, using the following configuration. These values are not guaranteed by the documentation. Response times were not recorded.

Region: us-east-1. Created using three resource types within CloudFormation.
One Web Function, two revisions (Revision A uses default settings, Revision B sets maxConcurrencyPerEnvironment to 1), and three HomeRegion endpoints.
iam: IamAuth, Revision A, rateLimit 100.
app: ApplicationManaged, Revision A, rateLimit 100, maxEnvironments 2.
envcap: ApplicationManaged, Revision B, rateLimit 100, maxEnvironments 2.
The application is a Node.js HTTP server with no dependencies. The /headers path returns only whether headers such as Authorization were received (and, for Authorization, its first word), and the /slow path waits without using CPU.

The requests were sent from a local terminal. The first column lists the requests sent, the second what the developer guide says, and the third what this configuration returned.

Request	Developer guide	Returned in this configuration
`iam`, unsigned	`IamAuth` requires a SigV4 signature; the header is omitted for authorization failures	HTTP 403, no `lambda-web-error-type`
`iam`, SigV4 with `X-Amz-Content-SHA256`	Accepted when signed and permitted	HTTP 200
`iam`, SigV4 without `X-Amz-Content-SHA256`	Rejected with `403 Forbidden`	HTTP 403, no `lambda-web-error-type`
`iam`, SigV4, `/headers`	`Authorization` is removed after validation	`Authorization` did not reach the server; `X-Amz-Content-SHA256` did
`app`, `Authorization: Bearer` with a placeholder value	The caller's `Authorization` is forwarded	`Authorization` reached the server (`Bearer`)
`app`, SigV4	A SigV4 signature is removed	`Authorization` did not reach the server
`app`, about 250 requests per second for 10 seconds (2,500 requests)	HTTP 429 above `rateLimit`	850 × HTTP 200; 1,592 × HTTP 429 `Platform.EndpointRequestThrottle`; 29 × HTTP 429 `Platform.EndpointMaxEnvThrottle`; 29 × HTTP 503 without `lambda-web-error-type`
`app`, metrics after the run	One throttle metric per throttled request	`EndpointRequestThrottles` 1,592; `EndpointActiveEnvironmentThrottles` 29; `AccountRequestThrottles` 0; `AccountActiveVCPUArm64Throttles` 0; `EndpointActiveEnvironments` maximum 2
`envcap`, 4 concurrent requests to `/slow` (5 seconds), 3 times	HTTP 429 when the endpoint reached `maxEnvironments` and all environments are busy	6 × HTTP 200; 6 × HTTP 429 `Platform.EndpointMaxEnvThrottle`; `EndpointActiveEnvironmentThrottles` 6; `EndpointActiveEnvironments` maximum 2
`app` after `rateLimit` was set to 0	HTTP 503 with `Platform.EndpointDisabled`	HTTP 503, `Platform.EndpointDisabled`
`Retry-After` on HTTP 429	No statement was found (Section 6.4)	Absent on all 1,627 HTTP 429 responses
CloudFormation change set that changes `EndpointType` of `envcap` to `PerRegion` (created, not executed)	`EndpointType`: `Update requires: Replacement`	`Action` `Modify`, `Replacement` `True`

No row in the table runs against the developer guide. However, the following three points should be noted:

In the run that sent approximately 250 requests per second to app, in addition to Platform.EndpointRequestThrottle, 29 instances of Platform.EndpointMaxEnvThrottle (429 errors) and 29 instances of 503 errors (without a lambda-web-error-type) were returned. The testing page indicates that you should record these 503 errors, lacking headers, separately, as they may indicate temporary load shedding or internal errors. This article does not investigate the reasons behind these two groups of 29 instances.
The number of instances for each type of 429 error corresponded to the total of the respective throttle metrics (1,592 and 29 for app, and 6 for envcap).
Of the 12 requests to envcap, 6 returned 200 and 6 returned 429. The breakdown per round was not recorded.

The data obtained through this configuration and procedure includes only the status codes, lambda-web-error-type, counts, and the total of the metrics. Response times were not recorded, and therefore this data cannot be used for performance comparisons.

9. Failure Modes

Here are some common errors that can occur when misinterpreting the tables in this article:

Reading MultiRegion as redundancy to handle Region failures: Lambda selects Regions based on latency and does not perform failover based on health checks. The developer guide suggests using PerRegion for custom failover logic (Section 3.2).
Reading ApplicationManaged as allowing caller restriction through resource-based policies: The policy is not evaluated for invoke requests. To restrict access, use IamAuth. Resource-based policies apply to management operations (Section 4.1).
Reading that placing CloudFront in front of an ApplicationManaged endpoint hides it: The endpoint domain remains visible to the internet, and direct requests do not pass through CloudFront and AWS WAF (Section 4.4).
Reading that requests exceeding the limit are queued: Lambda does not queue throttled requests. Requests are queued during new execution environment initialization and when waiting under dynamic limits (Section 6.2).
Reading that endpoint type and Region can be changed later: To make changes, create a new endpoint and migrate traffic, then remove the old one. The domain name will also change (Section 3.3).
Reading that if maxEnvironments and rateLimit are not set, they default to 0 or unlimited: If not configured, the endpoint operates under the account's quotas (Sections 5.1 and 5.2).
Reading that setting rateLimit to 0 results in a 429 error: Lambda returns a 503 error instead. The lambda-web-error-type is Platform.EndpointDisabled. This is different from a 429 error when a Function URL is stopped with reserved concurrency set to 0 (Sections 6.3 and 7.3).
Reading a headerless 503 error as a configuration error: The developer guide recommends retrying with backoff and jitter for 503 errors returned when Lambda sheds load (Section 6.3).
Reading that all 429 errors appear in throttle metrics: Platform.EndpointConcurrentInitThrottle does not increment a throttle metric (Section 6.1).

10. Frequently Asked Questions About Lambda Web Functions Endpoints

Q1. Are Lambda Web Functions generally available (GA)?

The What's New post from October 12, 2026, states that Web Functions are available today. This page contains neither the term generally available nor the term preview. This article will reproduce the wording from the documentation (Section 1.4).

Q2. Does a `MultiRegion` endpoint switch to another Region when a Region goes down?

The developer guide states Lambda doesn't perform health-based failover. regarding MultiRegion. Routing is best-effort and based on latency. For scenarios where you want to decide routing per Region, the developer guide mentions PerRegion (see Section 3.2).

Q3. Can you prevent public endpoints from being created?

Yes. The developer guide provides an example of an SCP that prevents the creation and modification of endpoints with the condition key lambda:Request/WebFunctionAuthType set to ApplicationManaged. Since aws lambda-web deploy creates endpoints with ApplicationManaged by default, it will fail (returning an error) unless you include the --auth-type IamAuth option (as described in Section 4.5). Here, public endpoints is the developer guide's term for endpoints that use ApplicationManaged. With either authentication type, the endpoint's domain is accessible from the internet (Section 4.1).

Q4. When a request is turned away, how do you tell which limit it hit?

You can identify the limit by examining the value of the lambda-web-error-type header in the 429 response and by checking the throttle metrics in the AWS/Lambda/Web/Usage namespace. There are five possible values, but only Platform.EndpointConcurrentInitThrottle does not appear in the metrics (see Section 6.1).

Q5. How do you stop an endpoint temporarily?

To temporarily disable an endpoint, you can set the rateLimit to 0. This will block all requests. Clients will receive a 503 error with the lambda-web-error-type value Platform.EndpointDisabled until the value is set to a non-zero number (see Section 6.3).

Q6. How do you change the number of concurrent requests one execution environment takes?

maxConcurrencyPerEnvironment is a revision setting, so to change it you create a new revision. The endpoint's autoDeploymentMode determines whether traffic shifts to the new revision. The dynamic limit for Lambda can be lower than this value, and it will not exceed this value (see Sections 3.3 and 5.1).

Q7. With Web Functions, is the Lambda Web Adapter still needed?

The runtime page of the developer guide states that when using Web Functions, you do not need the AWS Lambda Web Adapter or another event-to-HTTP adapter (You don't need the AWS Lambda Web Adapter or another event-to-HTTP adapter.). This refers to running an HTTP server with Web Functions. This article does not cover configurations that use the Lambda Web Adapter with Event Functions.

Q8. When was this article checked?

Both the information in the supporting documents and the results presented in Section 8 are dated October 18, 2026. The Web Functions page does not display a revision date, and since the feature was released on October 12, 2026, the content on the page may change after the verification date (as noted in Section 1.3).

11. Summary

Endpoint type and Region are fixed during creation. To change these, you must create a new endpoint, which will also change the domain name. Authentication type, automatic deployment, scaling, and throttling settings can be modified for existing endpoints. maxConcurrencyPerEnvironment is changed with a new revision (see Section 3.3).
With ApplicationManaged, authentication stays in the user's code. Lambda does not perform authentication, and resource-based policies are not evaluated during invocations. Even behind CloudFront, the domain remains publicly accessible. IamAuth verifies SigV4 or SigV4a signatures and the lambda:InvokeWebFunctionEndpoint permission (see Section 4).
Limits are determined by three settings and your account quota: maxConcurrencyPerEnvironment (default 64, range 1–128), maxEnvironments (2–10,000, not set by default), and rateLimit (0–10,000, not set by default). If these settings are not configured, the endpoint operates within your account quotas (see Section 5).
Requests exceeding the limit receive a 429 error (five types). A 503 error can have causes beyond the two on the scaling page. Lambda does not queue throttled requests, but it queues requests while a new execution environment is initializing. A rateLimit of 0 results in a 503 error with Platform.EndpointDisabled (see Section 6).
MultiRegion selects based on latency and does not perform health-based failover. The user builds failover between Regions with PerRegion and services like Route 53 and CloudFront (see Section 3.2).
Existing entry points differ in what an authentication type that checks nothing does, and in the response when you stop them. With a Function URL set to NONE, the resource-based policy is still in effect. Stopping it with reserved concurrency set to 0 results in a 429 error (see Section 7).

12. References

References:
Tech Blog with curated related content

Written by Hidekazu Konishi