AWS Lambda Function URLs

One of the drawbacks of AWS Lambda over an alternative like Azure Functions was that all HTTP invocations had to pass through the API Gateway. Not only did it add to the overall execution costs, but it also brought in other limitations (like the 30 seconds execution time limit). Also, it required you to learn about API Gateway even if all you wanted to do was invoke a lambda in an ad-hoc manner. This changed on the 6th of April 2022, when AWS announced Lambda Function URLs.

The Function URLs are essentially built-in HTTPS endpoints, that are globally unique. They can then be invoked in your server or client application like a normal API endpoint. You can even test it out in Postman or equivalent.

Enabling Function URLs for a new function through AWS Lambda Console

In the AWS Lambda console, click on Create Function and select ‘Author from Scratch’. In the screen that opens up, click on ‘Advanced settings’ tab, and you will see the option to enable the function URL. You can either restrict access to only authenticated IAM users and roles by selecting AWS_IAM in the auth type, or select NONE if you want the URL to be globally accessible. You can enable CORS if this URL will be accessed from a frontend application.

Once the function is created, the URL will be visible beside the function.

You can now use this URL in your application and perform requests like GET and POST. Here’s an example using Postman.

Enabling Function URLs for an Existing Function through AWS Lambda Console

Navigate to your existing function on the Lambda console, and click on the ‘Configuration’ tab. You’ll see the ‘Function URL’ option in the left menu. Click on ‘Create Function URL’. The rest of the steps remain the same as in the above subsection.

Once the URL is configured, the CORS and authorization settings can be modified.

Enabling Function URLs through Serverless Framework

If you are using a serverless.yml file to deploy your lambda functions, you can configure function URLs directly in that file. All you need to do is add a url property.

    handler: handler.hello
    url: true

The URL is public by default. You can restrict it to IAM access. Similarly, CORS can also be configured.

    handler: handler.hello
    # Public by default
    url: true
    handler: handler.hello
    # This URL is protected by IAM authentication
      authorizer: aws_iam

    handler: handler.hello
      # Allow CORS for all requests from any origin
      cors: true
    handler: handler.hello
      # Configure CORS in details:
        allowCredentials: …
        allowedHeaders: …
        allowedMethods: …
        allowedOrigins: …
        exposedResponseHeaders: …
        maxAge: ….

The various options for configuring CORS can be found here.

Updating functions with Function URLs

By default, a Function URL gets mapped to the function’s unqualified ARN (i.e. the ARN without the version suffix), which implicitly invokes the latest version of the function. Thus, every change you make to the function automatically gets reflected in the execution and response of the Function URL invocation.

However, it is possible the map the Function URLs to a specific ALIAS (a pointer to a specific version) of the lambda. This way, the updates to the function get reflected in the function URL invocation only when you update the ALIAS (i.e. update the version the ALIAS points to). Thus, your Function URL doesn’t get affected until you are sure of the changes made to the lambda function.

Function URLs or API Gateway?

API Gateway offers a lot of useful features like throttling, request validation, caching, custom authorizers, etc. Only when you don’t need these features should you opt for the Function URLs. That being said, Function URLs help save the massive cost associated with API Gateway, and also don’t have the 30-second execution limitation. So if either the cost or the time limit are hindering factors, then go for the Function URL.

Best Practices

  • Implement validation and authorization when providing public access to the Function URL. Otherwise, the public URL can be a vulnerability in your system
  • Map Function URLs to an ALIAS especially in production workloads, so that you have time to test your changes before making them live.
  • Avoid exposing Function URLs in public GitHub repositories, or blog posts (like this one)
  • Make a careful cost-benefit analysis and then decide whether to use Function URLs or the API Gateway

I hope you liked this article. For more tutorials on AWS, check out Also, if you are planning to become a certified AWS Solutions Architect, I’d recommend that you check out this course on Udemy. I took this course and found the lectures to be lucid, to-the-point, and fun. I hope they will help you as well.

Leave a comment

Your email address will not be published. Required fields are marked *