Written by Albert Friedman
on June 15, 2026

Serverless 101: Deploying your first AWS Lambda with a Function URL

Getting started with AWS Lambda usually means wiring an event source (API Gateway, S3, or a stream) and a function. For an introductory, low-friction path to an HTTP endpoint, Lambda Function URLs give you a built-in HTTPS endpoint that calls a single Lambda function — no API Gateway required. This makes them a great first serverless project: simple to create, fast to test, and easy to understand. (aws.amazon.com)

Why choose a Function URL for your first Lambda?

Minimal surface area: one function, one URL. Great for learning the request → handler → response loop. (aws.amazon.com)
Easy to create and manage through the console, AWS CLI, or IaC (CloudFormation / SAM / CDK). That means you can practice both manual and automated deployments. (docs.aws.amazon.com)
Configurable security: you can make the URL public or require AWS_IAM auth for tighter access control. This lets you experiment safely with authentication modes. (docs.aws.amazon.com)

Prerequisites

An AWS account with permissions to create Lambda functions and IAM roles.
AWS CLI configured locally (optional but recommended for the step-by-step commands below).
Node.js or Python installed if you want to run the example locally before packaging.

Quick architecture overview

When you enable a Function URL, AWS provides a stable HTTPS endpoint like: https://.lambda-url..on.aws

Invocations to that endpoint are routed directly to the specified Lambda function or alias. You still control the function’s execution role, timeout, and memory — the Function URL is simply the HTTP trigger. (docs.aws.amazon.com)

Example: Deploy a simple Node.js function and expose it with a Function URL

Below is a compact, hands-on flow you can follow in the AWS Console or replicate with the CLI.

Create a function handler (index.js)

// index.js
exports.handler = async (event) => {
  const name = (event.queryStringParameters && event.queryStringParameters.name) || "world";
  const body = { message: `Hello, ${name}!`, received: event };
  return {
 statusCode: 200,
 headers: { "Content-Type": "application/json" },
 body: JSON.stringify(body),
  };
};

Zip and upload (or use the console to paste code). If using the CLI to create the function:

zip function.zip index.js
aws lambda create-function \
  --function-name helloFunctionUrl \
  --runtime nodejs18.x \
  --handler index.handler \
  --zip-file fileb://function.zip \
  --role arn:aws:iam::123456789012:role/lambda-exec-role

(Replace the role ARN with a role that has the AWSLambdaBasicExecutionRole policy.)

Add a Function URL (CLI example)
```
aws lambda create-function-url-config \
  --function-name helloFunctionUrl \
  --auth-type NONE \
  --cors '{"AllowOrigins":["*"],"AllowMethods":["GET","POST"]}'
```
This returns the function URL you can call directly. Use auth-type NONE for an open endpoint while learning; switch to AWS_IAM before production. See the AWS docs for the exact flag names and syntax in your CLI version. (docs.aws.amazon.com)
Test it Open the returned URL in a browser or:
```
curl "https://<url-id>.lambda-url.<region>.on.aws?name=Alice"
```
You should get the JSON response from the Lambda handler.

Security notes

Function URLs support two authentication modes:

NONE: no AWS auth required. Good for demos, webhooks, or public endpoints, but only when the payload and public access are acceptable.
AWS_IAM: requires SigV4-signed requests (the same signature scheme used by other AWS APIs). This is suitable if only IAM principals should invoke the function. (docs.aws.amazon.com)

If you need richer authentication (OAuth, user pools, JWTs) or advanced API features (rate limiting, usage plans, custom request/response transformations), place API Gateway or CloudFront in front of the Function URL or integrate with Cognito. The AWS Compute Blog has patterns for securing Function URLs with Cognito, CloudFront, and WAF if you want to learn more about protecting public endpoints. (aws.amazon.com)

When a Function URL is the right tool — and when it isn’t

Use Function URLs when:

You want a quick HTTP endpoint for a single Lambda function (webhooks, internal tools, simple microservices). (aws.amazon.com)

Avoid Function URLs if you need:

Advanced API management: API Gateway provides request/response mapping, authorizers, usage plans, and more.
Fine-grained throttling or transformation: API Gateway or a fronting service (CloudFront + WAF) are better fits.
Multi-function routing under the same API surface: API Gateway or an application load balancer can host many routes.

Deployment and IaC

Function URLs are supported in CloudFormation, SAM, and CDK, so you can (and should) automate deployments once you understand the manual flow. That allows repeatable environments and safer rollouts as you iterate. The official Lambda docs include CloudFormation/SAM examples for creating and configuring Function URLs. (docs.aws.amazon.com)

Practical tips for beginners

Start with NONE authentication for quick feedback loops, but test AWS_IAM to learn signed requests.
Use small, focused handlers that return JSON — it’s easy to debug and inspect responses.
Add CORS only if you plan to call the Function URL from browser-based client code. A permissive CORS config is fine while learning but tighten origins for real apps. (docs.aws.amazon.com)

Limitations and considerations

Function URLs are single-function endpoints; they aren’t a drop-in replacement for a full API management layer. Use them for simple use cases and prototypes. (aws.amazon.com)
Consider putting CloudFront in front of a Function URL if you need global caching, DDoS protection, or to integrate custom TLS/domains. The compute blog shows common security fronting patterns. (aws.amazon.com)

Final thoughts

Lambda Function URLs make the first serverless HTTP experience straightforward: write a handler, enable a URL, call it. This low-friction path helps you learn the core Lambda model — event in, code runs, response out — without the additional complexity of API Gateway. Once you’re comfortable with that loop, you can explore more advanced triggers, authentication models, and infrastructure-as-code deployments to expand your serverless skillset. (docs.aws.amazon.com)

← → Top