All cheat sheets
Serverless & AIcheat sheet

Lambda Function URLs

Every Lambda can have a free built-in HTTPS endpoint — no API Gateway, no per-request routing fee, 10–30 ms less latency. The right tool for webhooks, internal service calls, and simple endpoints that were never using gateway features.

Last reviewed: July 11, 2026

TL;DR: A Function URL gives any Lambda a direct HTTPS endpoint — https://<id>.lambda-url.<region>.on.aws/ — with zero routing cost and 10–30 ms less latency than going through API Gateway. For webhook receivers, internal service-to-service calls, and single-endpoint backends that never used gateway features, API Gateway is a paid hop doing nothing. The cargo-cult habit of "gateway in front of every Lambda" is the whole reason this sheet exists.

The numbers

  • Routing cost: Function URL $0 vs HTTP API $1.00/M requests vs REST $3.50/M vs ALB's fixed ~$16+/month regardless of traffic
  • 100M requests/month → $100/month of pure routing tax removed (1B → $1,000/month); Lambda compute is identical either way
  • Field examples: 30 webhook receivers migrated in an afternoon ($600/year + ~15 ms faster + one less service in the debugging path); an internal 8-service mesh dropped $200/month of API Gateway spend on traffic that never left AWS, with 20–25 ms lower inter-service latency
  • Response streaming supported — lower time-to-first-byte for big responses and AI output, same cost

Do this

  1. Find the "dumb proxy" endpoints: API Gateway APIs with one route to one Lambda — webhook receivers (Stripe/GitHub/Slack/Twilio), internal callbacks, single-endpoint app backends, IoT ingestion. Those use no gateway feature you'd miss.

  2. Enable the URL (console: Configuration → Function URL, or two lines of SAM):

    FunctionUrlConfig:
      AuthType: NONE   # or AWS_IAM
    
  3. Pick auth deliberately: AWS_IAM (SigV4) for internal service-to-service via execution roles; NONE for third-party webhooks — then validate the provider's signature in code, which you should be doing behind API Gateway anyway.

  4. Configure CORS on the URL itself for browser SPAs — allowed origins/methods/headers are native settings, no OPTIONS-route wiring.

  5. Migrate incrementally: default every new simple endpoint to a Function URL; move existing ones opportunistically. No big-bang required.

  6. Add the missing safety net: without gateway throttling, CloudWatch alarms on Lambda errors and concurrency matter more — set them as part of each migration.

Gotchas

  • No throttling, usage plans, API keys, VTL, WebSockets, or native custom domains. Any of those being load-bearing keeps that endpoint on API Gateway — and that's fine.
  • Custom domain or DDoS shielding wanted? CloudFront in front of a Function URL adds domains, WAF, and caching — still usually cheaper than REST.
  • NONE auth is public to anyone with the URL — exactly like a default API Gateway endpoint; the security is your signature/token validation, not obscurity.
  • ALB remains competitive only at high steady volume where its fixed cost amortizes; spiky/low traffic favors URLs decisively.

Skip this if

  • The API is a real multi-route product API with per-consumer throttling, keys, or transformation needs — that's gateway work.
  • You need WebSockets — API Gateway only.
  • Traffic is enormous and you already negotiated gateway pricing — run the math; free routing still usually wins, but migration effort counts.

Run this audit with your AI assistant

Paste this into Claude, ChatGPT, or any agent that can run the AWS CLI with read-only credentials. It audits your account for exactly the waste this sheet describes — and changes nothing.

You are auditing an AWS account for endpoints that could move from API
Gateway (or ALB) to free Lambda Function URLs. Use the AWS CLI with
READ-ONLY credentials. Do not create, modify, or delete anything.

1. Map current routing:
   - aws apigatewayv2 get-apis + get-routes / aws apigateway
     get-rest-apis + get-resources — find APIs that are effectively a
     single route (or a trivial route set) proxying to one Lambda:
     webhook receivers, internal callbacks, single-endpoint backends.
   - aws elbv2 describe-load-balancers + describe-target-groups —
     Lambda-target ALBs with low request volume (fixed ~$16+/mo
     hourly cost regardless of traffic).
   - aws lambda list-function-url-configs per function — what's
     already migrated.
2. Per candidate: request volume (CloudWatch Count), current routing
   cost (HTTP API $1/M, REST $3.50/M, ALB hourly + LCU), and the
   feature check — candidates must NOT need: custom domains (unless
   CloudFront exists/planned), per-key throttling, usage plans,
   WebSockets, VTL transformations.
3. Auth mapping: internal service-to-service → AWS_IAM auth (SigV4);
   third-party webhooks → NONE + provider signature validation in
   code (note which providers: Stripe/GitHub/Twilio all support
   signatures).
4. Ops caveat to include: no gateway throttling safety net — flag
   candidates that need CloudWatch alarms on errors/concurrency as
   part of migration.

Report: candidate table (endpoint | current routing | req/mo | $/mo
now | $/mo after (=$0 routing) | auth mode | caveats), total savings,
and a keep-on-gateway list with reasons. Change nothing.
Works with any assistant that can run shell commands.

Want the guided version?

The Lambda Function URLs walkthrough covers this topic interactively — it asks about your setup, branches to what’s relevant, and quizzes you on the tricky parts. Free and anonymous.

Start the walkthrough