AWS launched Lambda Web Functions on 13 October. Four access facts matter more than the rest: the endpoint auth type defaults to none, the execution role is shared by every request in an environment, existing lambda:* policies already cover the new actions, and the posture scanners cannot see the resource yet.

A Node server on a port, behind a Lambda domain.

A Web Function is a standard Node.js HTTP server that Lambda runs behind a managed HTTPS domain. One execution environment serves many requests concurrently (default cap 64, configurable to 128, with Lambda adjusting the real limit as it learns), global state and /tmp persist across requests, and a single request can run 15 minutes. Code comes from a versioned S3 object and the service runs on Firecracker. Aidan Steele's launch day notes add two things from inside the sandbox: the VM had five hours of uptime before his first request, which points to a pre booted pool, and a one line index.js can execve any binary in the zip as long as that binary posts its own readiness to the runtime API. The Node only label is packaging, not enforcement.

The default auth type is none.

Each endpoint is IamAuth (SigV4 checked against identity and resource policy) or ApplicationManaged (no authentication, resource policy not evaluated for invokes). aws lambda-web deploy creates ApplicationManaged unless told otherwise. There is no PrivateLink and no direct WAF association, and the origin domain stays reachable behind CloudFront, so for a public endpoint the WAF only protects clients that choose to go through it. The one strict control is that a resource policy public by principal is rejected at write time, which is a better default than function URLs had.

One execution role, every request.

Role credentials are plain environment variables, with AWS_ACCOUNT_ID alongside them. Because many users share one process, bugs that single request Lambda used to mask now cross tenants: a module scoped user object, a cache keyed wrong, a logger that captures the previous request. Prototype pollution, deserialization flaws and any dependency that prints process.env all resolve to the execution role of whichever revision served the request, and code execution persists for the life of the environment, which in Steele's probing was minutes on an idle endpoint and is unbounded on a busy one. The execution role is the primary access enabler on this resource and should be reviewed as such.

Your existing lambda:* policies already grant all of this.

The new actions live in the lambda namespace. Any identity holding lambda:*, including the AWSLambda_FullAccess managed policy and most developer roles, now has CreateWebFunction, CreateWebFunctionEndpoint, PutResourcePolicy, CreateNetworkConnector and InvokeWebFunctionEndpoint without anyone granting them. lambda:Create* and lambda:Invoke* prefixes behave the same way. The asymmetry runs the wrong direction: broad grants on Resource: * include Web Functions, while least privilege grants scoped to function:* ARNs exclude them, so the careful policies miss the resource and the careless ones cover it.

The same applies to guardrails. The widely deployed SCP that denies CreateFunctionUrlConfig and UpdateFunctionUrlConfig when lambda:FunctionUrlAuthType is NONE does not match CreateWebFunction or CreateWebFunctionEndpoint. Every organization that closed public Lambda that way is open again until a second statement is added.

Posture tooling cannot see it as of launch.

IAM Access Analyzer enumerates Lambda functions and layers through the classic policy path and the function/ ARN, Prowler inventories with list-functions, the IaC linters validate AWS::Lambda::Function rather than the new AWS::Lambda::WebFunction types, and AWS Config has no resource type to record. A public, data reaching Web Function produces no finding in any of them. Treat a clean scan as no signal until vendors ship support, and enumerate directly with list-web-functions, list-web-function-endpoints and get-resource-policy.

Two SCP statements, then an inventory.

Add a deny on CreateWebFunction, CreateWebFunctionEndpoint and UpdateWebFunctionEndpoint where lambda:Request/WebFunctionAuthType is ApplicationManaged, next to the existing function URL deny. Then enumerate every endpoint, join each one to the execution role of every revision it routes to (an endpoint can split traffic across two), and review each role as internet facing. Until the scanners catch up, that inventory is the only reliable view of exposure.

AWS controlled the parts it controls. The two it delegated decide the outcome.

Auth type and execution role are the decisions. Both default toward exposure, both are already reachable through wildcard grants that predate the launch, and neither shows up in the tools most teams use to check.