As you know, it recently announced that it has brought Function URL generation support for AWS Lambda service. With the Function URL property, there is now a new way to call a Lambda Function via HTTP API call.
This feature is actually not new, previously we had to integrate Lambda with API Gateway (v1 or v2) or Application Load Balancer to call a Function via HTTP request. API Gateway had a free tier, but after that free tier you would be charged a $1/million request fee, not including the time required for Lambda Function to run.
The main difference between API Gateway and Lambda Function URL;
Function URL is a FREE way to call Lambda Function via HTTP method. You only pay for the very small additional uptime that occurs by serializing the request and response.
Lambda Function URL is built into Lambda Function itself. So you don't need to configure an external API Gateway (v1)or HTTP API (v2).
You can generate a Function URL through the AWS console by creating a new Function or editing an existing Function.
Lambda URL - Timeout in seconds
- Rest API = 29
- HTTP API = 30
- Lambda URL = 900 (15min)
- CloudFront proxying to Lambda URL = 60 (by default)
Lambda Function Authentication Types
Authentication types are limited to Public or IAM authority.
- AWS_IAM -Lambda uses AWS Identity and Access Management (IAM) to authenticate and authorize requests based on the identity policy of the IAM principal and the resource-based policy of the function.
You should use this option if you only want authenticated IAM users and roles to call your Funtion with the Funtion URL.
- NONE-This authentication type does not authenticate any requests to your Lambda Function. So any user can call your Lambda Function.
In some cases, you may want your Function URL to be public.
For example, you may want to respond to requests made directly from a Web browser. In this case you should choose NONE authentication type to allow public access to your Function URL.
Function URLs are 32 characters randomly and are not easily guessed. So the risk of someone finding it's very small. They can only access if they know the URL and if AuthType=NONE.
AWS Lambda Function URL have this format;
https://<url-id>.lambda-url.<region>.on.aws
Not guessing the URL but a leak or accidentally making the URL public can be a problem.
So, what action can you take for such situations?
You can use the following Service Control Policy (SCP) to prevent users from creating or updating Function URLs that use a method other than the AWS_IAM authentication type:
You should review this document for sample SCPs.
Configure CORS
You can allow access to any specific domain with the Function URL. When you enable CORS configuration for your Lambda Function URL, the following settings become available.
You can also configure certain titles to be allowed or displayed as array list items.
Since Lambda Function requests are made over the HTTP method, we can also ensure that only the required HTTP method is allowed for the request.
Request allows cookies of credentials to be stored and we can also specify the maximum time for cached requests.
Lambda URL Use Cases
- Service to service integrations
- Webhooks
- Lambda function serving as Mono-Lambda function
Lambda URL Pricing
Function URLs are included in Lambda's request and duration pricing, so you don't pay extra. In this respect it is the cheapest way to call Lambda Function outside of the AWS cloud.
For example, let's say you deploy a single Lambda function in the Virginia region with 128 MB of memory and an average call time of 50 ms. The function receives 5 million requests each month; so the cost for requests is $1 and the duration is $0.53, so the grand total will be $1.53 per month.
Lambda URL - Pricing per million requests:
- Rest API (first 333 mil) = $3.5
- HTTP API (first 300 mil) = $1.0
- Lambda URL = Free
- CloudFront proxying to Lambda URL = ~ $1.0 to $1.2
Differences Between AWS Lambda Function URLs & Amazon API Gateway
If we look at the differences between Function URL and API Gateway in general;
Conclusion
In this article you've been given an initial idea about AWS Lambda Function URLs so that you are able to explore it and use it in production scenarios later.
AWS Lambda Function URLs should work well for use cases like APIs built with backend frameworks, webhooks, form validators, server-side website rendering, long-polling scenarios, single-function simple micro-service, and other relevant cases.
Amazon API Gateway should work well for advanced use cases like SaaS applications that need to track limit usage using API Gateway Usage Plans, real-time applications using WebSockets, cases where API response time is within 29 seconds, cases that require advanced authorization using AWS Cognito, Throttling, Caching, Service Proxy to other AWS services, and more.
Thank you for reading. I hope it was useful.
If you like this blog post, please like and share it to reach more people :)
Top comments (0)