Lambda URLs are a simpler, more direct way to expose Lambda functions as HTTP endpoints compared to API Gateway.
Let’s see one in action.
Imagine you have a simple Lambda function that just echoes back whatever it receives in the request body.
import json
def lambda_handler(event, context):
return {
'statusCode': 200,
'headers': {
'Content-Type': 'application/json'
},
'body': json.dumps({
'message': 'Hello from Lambda URL!',
'received_body': event.get('body')
})
}
To expose this via a Lambda URL, you navigate to your Lambda function in the AWS console, go to the "Configuration" tab, and then select "Triggers." You’ll add a new trigger and choose "Application Load Balancer" (this is where you find the Lambda URL option). You’ll select "Create a new Lambda URL," choose an authentication type (most commonly AWS_IAM for programmatic access or NONE for public access), and a method (ANY is often used for simplicity, or GET/POST if you want to be more specific).
Once created, AWS gives you a unique URL like https://<random-id>.lambda-url.us-east-1.on.aws/. You can then curl this URL:
curl -X POST -d '{"name": "Alice"}' https://<random-id>.lambda-url.us-east-1.on.aws/
The output will be:
{
"message": "Hello from Lambda URL!",
"received_body": "{\"name\": \"Alice\"}"
}
This is incredibly straightforward. You get an HTTP endpoint, and requests are directly routed to your Lambda function. The event object passed to your Lambda function contains the request details, including headers, query parameters, and the body.
Now, let’s contrast this with API Gateway. API Gateway is a much more feature-rich service. It acts as a full-fledged API management layer. While it can also expose Lambda functions via HTTP, it provides a lot more.
The problem Lambda URLs solve is the need for a quick, simple HTTP endpoint for a single Lambda function without the overhead of setting up a full API. If you just need to hit a Lambda function with a POST request or serve a static HTML file from a Lambda, Lambda URLs are fantastic. They bypass the need for creating an API, resources, methods, integrations, and stages that API Gateway requires.
API Gateway, on the other hand, is for building robust APIs. It handles authentication (API keys, Cognito, IAM), authorization, request validation, throttling, caching, request/response transformations, WAF integration, and sophisticated routing. You can expose multiple Lambda functions under a single API endpoint, with different paths and HTTP methods mapping to different functions or different integrations.
Consider an API Gateway setup. You’d create an API, define resources (e.g., /users, /products), methods for those resources (e.g., GET /users, POST /users), and then configure an integration for each method to point to your Lambda function. You’d also need to deploy the API to a stage (e.g., dev, prod). This gives you a URL like https://<api-id>.execute-api.us-east-1.amazonaws.com/<stage>/users.
The key difference lies in the complexity and feature set. Lambda URLs are ideal for simple, single-function endpoints where you don’t need advanced API management features. Think of them as a direct pipe from the internet to your Lambda. API Gateway is a traffic cop, a security guard, a transformer, and a performance optimizer for your APIs.
When you use a Lambda URL with AWS_IAM authentication, the event object in your Lambda function will contain identity information, specifically cognitoIdentityPoolId, accountId, cognitoIdentityId, caller, apiKey, principalOrgId, and userArn. This allows your Lambda function to inspect who is making the request and authorize accordingly, directly within the function’s logic. If you use NONE authentication, the identity field is absent, and the request is considered public.
A subtle but important distinction is how request bodies are handled. For Lambda URLs, the raw request body is passed directly in the event['body'] field, and you’ll need to parse it yourself (e.g., json.loads(event['body'])). API Gateway, by default, also passes the body, but it offers more control over content types and can perform transformations before invoking the Lambda.
If you need to integrate with services that expect specific HTTP headers or have complex routing logic based on request parameters, API Gateway offers far more flexibility. Lambda URLs are very much a "fire and forget" solution for simple HTTP-triggered Lambdas.
The most surprising true thing about Lambda URLs is that they are built on top of Application Load Balancers (ALBs) under the hood, but AWS abstracts away almost all of the ALB configuration. You don’t see target groups, listeners, or security groups; it’s a managed experience.
The next step after mastering Lambda URLs and API Gateway is understanding how to combine them, perhaps using API Gateway to front multiple Lambda URLs for more complex routing and management.