What is an AWS Lambda function URL, and when would you use one instead of putting API Gateway in front of the function?

## What it is Before function URLs existed, exposing a Lambda function over HTTP always meant putting another service in front of it. A function URL removes that: Lambda gives the function its own HTTPS endpoint on the `lambda-url` domain, and requests to it are turned into synchronous invocations. You create one against a function or a specific alias: ```bash aws lambda create-function-url-config \ --function-name my-function \ --auth-type AWS_IAM ``` A URL is bound to one function (optionally qualified by an alias), and it is always synchronous — there is no way to make an HTTP request to a function URL result in an asynchronous invocation. ## The two auth types, and what they really mean `AuthType` takes exactly two values. **`AWS_IAM`** requires the caller to sign the request with SigV4 and hold the `lambda:InvokeFunctionUrl` permission. Note that this is a distinct action from `lambda:InvokeFunction` — a policy that grants only the latter does not open the URL. This is a good fit for service-to-service calls inside an account or organisation, and for anything a signed SDK client will reach. **`NONE`** makes the endpoint publicly invokable by anyone who knows the URL. Lambda still requires a resource-based policy statement permitting public invoke, so it is an explicit act rather than an accident, but from that point on **all** authentication and authorization is your handler's job: verifying a webhook signature, checking a bearer token, whatever the caller uses. The URL's obscurity is not a security control. ## The event your handler receives A function URL delivers the request in the same payload format version 2.0 that an API Gateway HTTP API uses: method, raw path, query string, headers, and the body (base64-encoded when binary). The handler responds with a status code, headers and a body, or with a bare object that Lambda wraps as a 200 JSON response. Practically, this means a handler written for an HTTP API usually works unchanged behind a function URL — the migration cost between them is low, which is a reasonable argument for starting with the simpler one. CORS is configured on the URL itself rather than in your code: allowed origins, methods, headers, credentials and max age, with preflight handled for you. ## Response streaming A function URL's `InvokeMode` is `BUFFERED` by default, meaning Lambda collects the entire response and returns it in one piece. Setting it to `RESPONSE_STREAM` lets the function send bytes as it produces them, which matters for two cases: time-to-first-byte on a slow generation (an LLM-style token stream, a report assembled from several calls), and payloads larger than the buffered response limit of 6 MB. Streaming is available through function URLs and the `InvokeWithResponseStream` API — not through an API Gateway integration — so if you need streaming over HTTP, the function URL is not merely simpler, it is the mechanism. ## What you give up Everything API Gateway is for: - **Routing.** One URL, one function. There is no path-to-function mapping; the full path arrives inside the event and your handler routes it, or you deploy one function per endpoint. - **Access management.** No usage plans, no API keys, no per-client quotas. - **Custom authorizers.** No Lambda authorizer or JWT authorizer stage; token validation is handler code. - **Request validation and transformation.** Nothing rejects a malformed body before it reaches you — and you pay for that invocation. - **Custom domains.** The endpoint lives on the `on.aws` domain. - **WAF.** You cannot attach a web ACL to a function URL directly; the usual pattern is to put CloudFront in front of it, which also buys you a custom domain and caching. ## Choosing Reach for a function URL when the thing you are exposing is genuinely one function with one job: a webhook endpoint for a third-party provider, an internal callback, a small tool, a prototype, or anything that needs streamed responses. Reach for API Gateway when you are building an API — several routes, third-party consumers who need keys and quotas, request validation, a branded domain, or managed authorization. The decision is about how much of an API gateway's job you would otherwise be writing inside your handler.