on
Serverless 101: Deploying your first AWS Lambda with a Function URL
Deploying your first AWS Lambda can feel like learning a new song on an unfamiliar instrument: a few awkward notes at first, then a satisfying groove. If you want a quick, low-friction way to put a tiny HTTP endpoint on the internet without wiring up API Gateway, AWS Lambda Function URLs are an excellent first riff. They give each function a built-in HTTPS endpoint, optional CORS, and a simple authentication model — perfect for demos, internal tools, and small single-function microservices. (aws.amazon.com)
In this guide you’ll get a conceptual map, a minimal Node.js example, and the exact CLI commands you can use to deploy a working function with a Function URL. I’ll point out pros, limits, and a couple of practical tips so your first serverless beat doesn’t skip.
What is a Lambda Function URL (quickly)
A Lambda Function URL is a native HTTPS endpoint that maps directly to a single Lambda function (or alias). It’s provided by the Lambda service itself, so you don’t need API Gateway or an ALB to expose a function over HTTP. You can optionally enable CORS or require AWS IAM for invocation. For many simple public or internal endpoints, Function URLs remove a lot of ceremony. (aws.amazon.com)
Why this matters for a first deployment:
- Fewer moving parts: skip API Gateway setup and the mental overhead of routes, stages, and usage plans.
- Faster feedback loop: modify code, zip, and update the function — call the URL with curl and see results.
- Native support for CORS and IAM-based invocation when you need them. (aws.amazon.com)
When Function URLs are a good fit (and when they aren’t)
Use Function URLs when your use case is small and focused:
- Single-function microservices or webhooks.
- Internal tooling or prototypes.
- Simple forms or webhooks fronted by a static site (S3 + CloudFront).
Avoid them when you need API management features:
- Fine-grained request validation, stages, usage plans, API keys, or built-in WAF integration — these are API Gateway territory. Function URLs trade advanced API features for simplicity. (aws.amazon.com)
A concrete practical note: Function URLs are low-friction but not a one-size-fits-all replacement for API Gateway. Think “acoustic guitar” rather than “full band.” (serverless.com)
The minimal example: a Hello handler (Node.js)
Here’s a tiny Node.js handler that returns a JSON greeting. Save as index.js:
exports.handler = async (event) => {
const name = event.queryStringParameters?.name || 'world';
return {
statusCode: 200,
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ message: `Hello, ${name}!` }),
};
};
Package this file into a zip (index.js at root) before deploying.
Steps & exact CLI commands (compact)
Below are the minimal steps using AWS CLI. You can also use the console, SAM, or CDK, but the CLI keeps the example explicit.
-
Create an IAM role for Lambda with basic execution permissions (AWSLambdaBasicExecutionRole). You can do this in the IAM console or with a CloudFormation/IaC template. (IAM setup is standard; the create-function command below requires the role ARN.)
-
Create the function (ZIP deployment). Replace the role ARN, region, and runtime as appropriate:
aws lambda create-function
–function-name hello-url
–runtime nodejs18.x
–handler index.handler
–zip-file fileb://function.zip
–role arn:aws:iam::123456789012:role/LambdaBasicExecutionRole
–region us-east-1
(create-function reference and Node.js packaging guidelines). (docs.aws.amazon.com)
- Add a Function URL to the function. This example makes the URL public (AuthType NONE) and enables permissive CORS:
aws lambda create-function-url-config
–function-name hello-url
–auth-type NONE
–cors AllowOrigins=’[“*”]’,AllowMethods=’[“GET”,”POST”]’
(The create-function-url-config API and CLI are documented in the Lambda docs; AuthType can be NONE or AWS_IAM, and you can choose buffered or response-stream invoke modes.) (docs.aws.amazon.com)
- Invoke with curl (example):
curl “https://
The Lambda docs show the shape of the event your function receives when invoked from a Function URL; for HTTP APIs you’ll see queryStringParameters, headers, etc. (docs.aws.amazon.com)
Notes on auth, CORS, and streaming
-
AuthType: NONE vs AWS_IAM. NONE lets anyone hit the URL (not recommended for sensitive endpoints). AWS_IAM requires SigV4-signed requests (or an AWS principal). The CreateFunctionUrlConfig and SDKs expose these choices. (app.unpkg.com)
-
CORS: If you plan to call the endpoint from browser JS, enable CORS in the Function URL configuration or handle CORS headers in the function response. Function URL configuration includes common CORS fields. (docs.aws.amazon.com)
-
Response streaming and invoke mode: Function URLs support different invoke modes (buffered by default, or response streaming). If you expect large or streaming responses, pick the appropriate invoke mode when configuring the URL. (app.unpkg.com)
Cost and operational reminders
Function URLs don’t add a separate per-request endpoint charge — you’re charged for the Lambda invocations as usual. That said, removing API Gateway also removes features like throttling and usage plans, so think about how you’ll control or observe traffic. For public endpoints, a CloudFront fronting layer is a common pattern if you need caching, WAF, or a custom domain. (aws.amazon.com)
Also keep deployment size and runtime choices in mind: large dependencies increase cold-start risk and deployment package size. For a first function, keep your package small, prefer higher-level runtimes (Node.js, Python), and use layers only when needed. (AWS Lambda runtime and packaging docs cover details.) (docs.aws.amazon.com)
A few troubleshooting tips (common bumps)
-
Permission errors: If the Function URL is set to AWS_IAM, unsigned curl requests will be rejected. Use the AWS CLI (aws –profile …) or sign requests with SigV4 libraries. (docs.aws.amazon.com)
-
“Cannot find module” on invocation: Ensure your zip file places index.js and node_modules at the root of the archive, not nested inside a folder. AWS docs show correct packaging for Node.js. (docs.aws.amazon.com)
-
CORS failing in the browser: Either configure CORS on the Function URL (recommended) or set headers from your function’s response. The Function URL CORS settings map to the HTTP response behavior. (docs.aws.amazon.com)
Final thoughts — a parable for context
Think of Function URLs as the busker’s compact amp: small, quick to set up, and great for solo performances. API Gateway is the venue’s PA system — more features, heavier setup, and better for big, paying crowds. For your first Lambda, a Function URL will get you playing in public in minutes and teach you the shape of Lambda events and responses without scaffolding.
If you enjoy the hands-on path, try the minimal flow above: handler → zip → create-function → create-function-url-config → curl. The pieces are simple, and each step illuminates a core concept of serverless: packaging, roles, invocation, and observability. The Lambda docs and the original Function URL announcement are friendly companion reads as you go. (aws.amazon.com)
References
- AWS announcement: “Announcing AWS Lambda Function URLs: Built-in HTTPS Endpoints for Single-Function Microservices.” (aws.amazon.com)
- Lambda documentation: Invoking Lambda function URLs and configuration guide. (docs.aws.amazon.com)
- CLI/API reference: create-function-url-config and create-function. (docs.aws.amazon.com)
- Notes on trade-offs vs API Gateway and securing Function URLs. (aws.amazon.com)
Enjoy the small, immediate victories — a single endpoint responding with “Hello” is the simplest jam session that teaches the whole band.