Introduction
To expose a Lambda function over HTTP, we had to set up API Gateway. It worked, but it was overkill for simple cases. Too much configuration for what should be straightforward.
Lambda Function URLs cut through that, we get a direct HTTPS endpoint for our function with basically zero setup, no API Gateway, no extra infrastructure, just a URL that works.
What is a Lambda Function URL
A Lambda Function URL is an HTTPS endpoint automatically attached to a specific Lambda function. When we enable it, AWS gives us a link that looks like this: https://random-id.lambda-url.region.on.aws/

We can then send any HTTP request (GET, POST, PUT, DELETE) directly to that link our Lambda function will run and it’s the simplest way to expose a Lambda function to the internet.
When Should We Use It
Lambda Function URLs are perfect when we want a simple and fast way to call a function over HTTP, here are a few good use cases:
- Webhooks for services like Stripe, GitHub, or Slack
- Internal automation or admin tasks
- Lightweight APIs or prototypes
- AI or ML inference functions that just need an endpoint
If we need advanced API features like request validation, custom domain names, or caching, we should stick with API Gateway. But for quick and simple HTTP access, Function URLs are a great fit.
Authentication and Security
When creating a function URL, we can choose between two authentication types:
Auth Type | Description |
---|---|
AWS_IAM | Requires AWS IAM authentication |
NONE | Public access, anyone with the URL can invoke it |
Even with NONE, we can still protect it using CORS rules, IP-based resource policies, or by putting CloudFront and WAF in front.
Creating a Lambda Function URL
In this section, we'll walk through creating a Lambda function URL using the Node.js runtime.
Step 1: Create a Simple Function
Create a file named index.js with the following code:
module.exports.handler = async (event) => {
console.log('Received event:', event);
const response = {
statusCode: 200,
headers: {
'Content-Type': 'application/json',
},
body: JSON.stringify({
message: 'Hello from doodooti Function URL',
method: event.requestContext.http.method,
time: new Date().toISOString(),
}),
};
return response;
};
This handler responds to HTTP requests from a Function URL, it takes the incoming request, logs it, and returns a JSON response.
Step 2: Deploy the Lambda
To create a Function URL, we need to deploy our Lambda function on AWS first using the AWS CLI. Before we can do that, we need to compress our index.js file into a zip file. If our function uses any dependencies, we need to include those in the zip file too.
aws lambda create-function \
--function-name doodooti-fn \
--runtime nodejs20.x \
--role arn:aws:iam::<ACCOUNT_ID>:role/<LAMBDA_ROLE> \
--handler index.handler \
--zip-file fileb://function.zip

As we can see the doodooti-fn function has been successfully deployed to AWS
Step 3: Create the Function URL
There are several ways to create a Function URL in this example, we will continue using the AWS CLI.
aws lambda create-function-url-config \
--function-name doodooti-fn \
--auth-type NONE \
--cors '{
"AllowOrigins": ["*"],
"AllowMethods": ["GET", "POST"]
}'
As we see in the command, we use the AWS CLI to create a Function URL for our doodooti-fn function. We set the auth type to NONE, which makes it publicly accessible. We also configure CORS to allow requests from any origin and accept GET and POST methods.

Result of the command execution
If we go to the AWS Console, we can see that the Function URL has been created, as shown in the image below

Result from the Console
Testing the URL
Now we can test it using curl or Postman
curl -X POST https://ixori5b2d667t3qz77wv7vvxwy0qwrsz.lambda-url.us-east-1.on.aws/ \
-H "Content-Type: application/json" \
-d '{"name": "Ridha"}'
If we execute this command we will get the following error or message:

That's because in order to invoke the Lambda function via the Function URL with NONE auth type, we need to configure our Lambda to allow this invocation via a resource policy. We need to add lambda:invokeFunction and lambda:invokeFunctionUrl permissions.
To solve this, we go to the Resource-based policy statements in the Permissions tab of the function and add a permission. We select the option for Function URL with the NONE auth type.

Config added
Let's test it now. The expected response will look like this:
{
"message": "Hello from doodooti Function URL",
"method": "POST",
"time": "...."
}
Managing Function URLs with the AWS SDK
We can also manage Lambda Function URLs directly in our Node.js scripts using the AWS SDK v3
//Install the dependency
npm install @aws-sdk/client-lambda
Then create a simple script like this:
import {
LambdaClient,
CreateFunctionUrlConfigCommand,
} from '@aws-sdk/client-lambda';
const client = new LambdaClient({ region: 'us-east-1' });
const params = {
FunctionName: 'doodooti-fn',
AuthType: 'NONE',
Cors: {
AllowOrigins: ['*'],
AllowMethods: ['GET', 'POST'],
},
};
const command = new CreateFunctionUrlConfigCommand(params);
const response = await client.send(command);
console.log('Lambda Function URL:', response.FunctionUrl);
Adding Simple Protection
If we’re using AuthType=NONE, anyone with the URL can trigger the function. That’s fine for some cases, but if we want basic protection, we can easily add our own check.
if (event.headers['x-api-key'] !== process.env.API_KEY) {
return { statusCode: 403, body: 'Forbidden' };
}
We can also place CloudFront or WAF in front of the URL for more advanced control
Calling the Function from a Frontend
From a React or any frontend app, we can simply call it like this:
const response = await fetch(
'https://ixori5b2d667t3qz77wv7vvxwy0qwrsz.lambda-url.us-east-1.on.aws/',
{
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ message: 'Hello' }),
}
);
const data = await response.json();
console.log(data);
No API Gateway, no routing setup, just a simple function call.
Conclusion
Lambda Function URLs are one of those small but powerful AWS features that make serverless development smoother. They’re great for webhooks, prototypes, or internal tools where we just need a quick HTTPS entry point.
They’re not a replacement for API Gateway, but they fill a nice gap between “I just need an endpoint” and “I need a full REST API.”