Serverless 101: Expose Your First AWS Lambda with a Function URL

Serverless lets you run code without managing servers — and one of the quickest ways to expose a tiny HTTP endpoint is with an AWS Lambda function URL. Function URLs give a dedicated HTTPS endpoint for a single Lambda, removing the need to configure API Gateway for simple use cases such as webhooks, form validators, or quick proof-of-concept APIs. This guide walks through the concept, the minimal steps to deploy and call your first function URL, and important security and cost considerations to keep in mind. (docs.aws.amazon.com)

Why use a function URL?

• Fast to set up: you can create a function in the console and enable a URL in minutes (no API Gateway configuration required). (docs.aws.amazon.com)
• Good fit for single-purpose endpoints: webhooks, small public callbacks, or lightweight UI backends. (aws.amazon.com)
• Choose the auth you need: either public (no signing) or IAM-protected (signed requests). (docs.aws.amazon.com)

Note: function URLs are public HTTP(S) endpoints. If you need private-only access or richer API features (rate limits, authorizers, built-in WAF integration), consider API Gateway or place CloudFront in front of the URL. (docs.aws.amazon.com)

Prerequisites

• An AWS account and an IAM user with permissions to create Lambda functions and function URLs.
• AWS CLI configured locally (optional if you prefer the console).
• Node.js or Python installed if you want to test locally before deploying.

The AWS tutorial for building a webhook with function URLs is a handy step-by-step reference; much of this article borrows the same practical approach. (docs.aws.amazon.com)

Quick example: create a tiny Node.js function and add a function URL

1) Create a minimal handler (index.mjs)

// index.mjs
export const handler = async (event) => {
  return {
    statusCode: 200,
    headers: { 'content-type': 'application/json' },
    body: JSON.stringify({ message: 'Hello from Lambda function URL!', eventSummary: { method: event.requestContext?.http?.method || 'N/A' } })
  };
};

2) Zip and create the Lambda using AWS CLI (example; adjust function-name and role ARN)

zip function.zip index.mjs
aws lambda create-function \
  --function-name my-first-furl \
  --runtime nodejs24.x \
  --handler index.handler \
  --zip-file fileb://function.zip \
  --role arn:aws:iam::123456789012:role/lambda-exec-role

3) Add a function URL (public, no signing)

aws lambda create-function-url-config \
  --function-name my-first-furl \
  --auth-type NONE \
  --cors-config AllowOrigins="*"

The CLI call above creates an HTTPS endpoint (form: https://.lambda-url..on.aws) you can call immediately. For more configuration options (aliases, CORS, or IAM auth), see the Lambda function URL docs. ([docs.aws.amazon.com](https://docs.aws.amazon.com/lambda/latest/dg/urls-configuration.html?utm_source=openai))

Calling the function URL

• Public (auth type NONE): a simple curl call works.

curl -i https://<your-id>.lambda-url.us-east-1.on.aws

• IAM-protected (auth type AWS_IAM): requests must be signed with AWS Signature Version 4 (SigV4). The Lambda docs explain that IAM-authenticated function URLs require SigV4 signing; curl and other tools can sign requests when provided the credentials (the AWS CLI exposes convenience methods and curl supports –aws-sigv4 in recent builds). (docs.aws.amazon.com)

Example (IAM auth) using curl with SigV4 (replace region and URL):

curl --aws-sigv4 "aws:amz:us-east-1:lambda" --user "AKIA...:wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" https://<your-id>.lambda-url.us-east-1.on.aws

If you prefer, put the signing step behind CloudFront (see below) or use SDK clients that handle signing for you. (docs.aws.amazon.com)

CORS, resource policies and basic hardening

• CORS: Function URLs can include CORS configuration on creation or later; the console offers a quick “allow all origins” option but you should restrict origins in production. (docs.aws.amazon.com)
• Resource-based policies: function URLs use resource-based policies to control who can invoke the URL. Even with AWS_IAM, attach lambda:InvokeFunctionUrl and lambda:InvokeFunction permissions to calling principals. (docs.aws.amazon.com)
• Public vs. IAM: use NONE only for endpoints that are intentionally public (webhooks that verify a shared secret in the payload, static badges, etc.). For anything with sensitive behavior, prefer AWS_IAM or front the URL with CloudFront and other protections. (docs.aws.amazon.com)

Protecting a public endpoint with CloudFront (recommended pattern)

If you need to accelerate delivery and reduce the attack surface, put CloudFront in front of your function URL and enable Origin Access Control (OAC) for the Lambda origin. OAC configures CloudFront to sign origin requests with SigV4 so direct calls to the function URL can be blocked while CloudFront remains the only allowed client. This lets you use WAF, Shield, custom domains, and caching while keeping the function URL from being openly callable. (aws.amazon.com)

Cost and cold-start visibility: an important recent change

AWS standardized billing for the Lambda initialization (INIT) phase effective August 1, 2025. That means some time spent loading packages, native dependencies, or heavy initialization can now appear in billing. For small functions this won’t move the needle much, but for languages or packaging approaches that do heavy initialization you should measure INIT duration (CloudWatch metrics and logs) and optimize: smaller bundles, precompiled artifacts, or provisioned concurrency where appropriate. Track init times and factor them into your cost estimate as you experiment. (aws.amazon.com)

Practical tips for a smooth first deployment

• Keep your handler focused and small: require/import only what you need at module scope to reduce INIT time.
• Test locally and then deploy: zip a tiny function first to verify the endpoint. Use the Lambda console for quick iterations when learning. (docs.aws.amazon.com)
• Use IAM auth during development for anything that should not be public; use signed requests or put CloudFront in front. (docs.aws.amazon.com)
• Watch CloudWatch Logs and the function URL invocation metrics to confirm request details, status codes, and latency.

When not to use a function URL

• You need rate limiting, complex authorizers, usage plans, or large API surface (API Gateway or App Runner may be a better fit). (docs.aws.amazon.com)
• You need private-only connectivity (function URLs are public; PrivateLink is not supported for function URLs). Use private APIs or VPC-enabled services instead. (docs.aws.amazon.com)

Summary

Lambda function URLs are a pragmatic, low-friction path to expose a single serverless endpoint in minutes. They’re ideal for webhooks, tiny APIs, and quick prototypes. But remember: secure appropriately (NONE vs. AWS_IAM versus CloudFront OAC), watch initialization times now that INIT billing has been standardized, and pick API Gateway when you need a richer API feature set. The Lambda function URL docs and the webhook tutorial provide concise, step-by-step references for each command and configuration option. (docs.aws.amazon.com)

Happy building — keep the handler small, test the endpoint, and monitor init times as you iterate.