AWS Lambda Function URLs were released on the 6th of April 2022 as an infrastructure configuration that gives you public URLs to directly trigger AWS Lambda Functions.
This service provides a faster and simpler way to trigger AWS Lambda Functions than AWS API Gateway or AWS Application Load Balancer (ALB). The URLs follow a standard structure as follows:
https://**<url-id>**.lambda-url.**<region>**.on.aws
Pro: Fast Implementation & Deployment
AWS Lambda Function URLs are very quick to configure and deploy whilst requiring less set up than the other alternatives. When I set up the endpoint it is almost instantly available for use and only really requires a few configuration values.
AWS API Gateway takes longer to deploy and requires a more complex set of resources to set up. The API, Resources, Methods, Deployment, Stage, and Lambda Permissions are all part of setting this up.
AWS ALB requires additional underlying resources to be configured and has an upfront cost to using it. There is quite a bit that goes into designing AWS networks but at a minimum they contain a VPC, Subnets, IGW, and Security Groups. AWS ALBs also require multiple different resources to make up a working system.
Pro: IAM for Access Control
The options for AWS Lambda Function URLs authentication are None or using IAM. When you use None any additional security should be within the code. However, when you use IAM you can reference IAM resources with significant granularity. This means that if you and your customers both use AWS there is a strong and simple integration point for security by just referring to their AWS IAM resources directly.
Pro: AWS Lambda Alias Support
AWS Lambda Aliases are also supported by the new URLs which means that you can keep a consistent public facing URL when replacing the underlying infrastructure. This isn’t as practical as if it was done with DNS but can work if you don’t mind the AWS Lambda alias and versioning system.
Con: No Custom DNS Support
As mentioned previously DNS can’t be used for AWS Lambda Function URLs which can be an issue for both releases and the presentation of the service to customers.
The lack of custom DNS is similar to the Private AWS API Gateway and can cause issues if you use DNS automation for release processes.
It is possible to work around the custom DNS issue by deploying AWS CloudFront and pointing at the URL on the backend. This is about the same effort as deploying AWS API Gateway, which negates the benefits of using the new feature.
Con: AWS Account ID Exposure
According to AWS the new URLs expose the AWS Account ID used for the service which can provide information to any malicious actors. AWS Account IDs are not considered a credential for security purposes but publishing this information should probably be avoided where possible.
Con: Limited Network Controls
Due to the implementation of AWS Lambda Function URLs there is no way to implement network controls based on IP or any lower level than the prior mentioned authorisation. This is a limitation that could be an issue depending on your environment. For large enterprises like I have worked for in the past it is not acceptable but if you are running a start up it may be worth sacrificing for the speed to implementation.
Summary
It is always good to see more functionality being added to AWS Lambda and serverless solutions. However, the new AWS Lambda Function URLs leave a lot to be desired in their access controls and DNS implementation. Hopefully we will get custom DNS as a feature in the near future so that we don’t have to use AWS Aliases and the AWS provided URLs.
More Information
Follow me here for more content or contact me on:
- Twitter: @BenTorvo
- Email: ben@torvo.com.au
- Website: torvo.com.au
Top comments (3)
Thank you for sharing your knowledge. How are you using Lambdas? Are they being used from your backend?
For really cheap public websites I just use them with API Gateway as a frontend, making sure to proxy every request to the Lambda and handle it in code.
For internal services or more security focused environments I would recommend using the ALB integration so that you can use network controls.
In my own projects I prefer EC2 based hosting as it is more cost effective after minimum scaling and is more portable.
If you are using a framework such as SAM or Serverless Framework, setting up an HTTP API Gateway is just as easy. With HTTP, in comparison to REST, you don't have as much configuration to do (methods, integrations, responses, etc.).
There are not many places I'd actually use the function URLs in their current form (due to the cons listed above).
Below is what I'd usually use:
Public Production APIs: I'd use REST API Gateway, for access to WAF and other must-haves.
Internal APIs: I'd use HTTP API Gateway if possible for lower latency and cheaper cost. With Cognito or IAM authorization.
WebHooks that require more than 30 seconds: Lambda Function URLs with IAM auth.