Published on · Updated on
Reframed the article around Lambda's event, handler, runtime, and IAM model, with current console setup choices and a separate deployment walkthrough.
Before writing a Lambda function, decide what starts it, what data it receives, which permissions its code needs, and what the handler should return. This guide explains those choices and the initial console setup. For a full code, deploy, test, logging, and cleanup walkthrough, continue with Deploy Your First AWS Lambda Function.
Lambda is a good fit for bounded work that starts from an event, such as a file upload, a scheduled task, a queue message, or an application request. Lambda runs your handler in a managed execution environment and can run additional function instances as demand changes. Requests may run concurrently or out of order, so keep each handler focused on the event it receives.
Assume an execution environment may disappear after an invocation, even though Lambda can reuse it to improve performance. Store durable application state in a data service such as Amazon S3 or DynamoDB; do not depend on a global variable or temporary file to preserve user data between invocations. AWS explains this model in its guides to designing Lambda applications and the Lambda programming model.
A caller can invoke a function synchronously and wait for its result. With asynchronous invocation, the caller hands off an event and does not wait for the handler to finish. For queues and streams, Lambda can poll through an event source mapping and invoke the function with records. The event shape and retry behavior depend on the integration and invocation type; see AWS's guide to Lambda invocation methods.
Some delivery paths can retry or deliver the same event more than once. If a handler makes a change outside Lambda, such as writing an order or charging a customer, make the operation safe to repeat. AWS recommends idempotent function code because duplicate events can occur.
You need an AWS account, access to the AWS Management Console, and a region in which to create the function. Lambda functions are regional; when you connect another service, check that integration's regional requirements. Check the account's billing terms and current service pricing before experimenting; older free-tier descriptions may not apply to your account.
A Lambda execution role is an IAM role that Lambda assumes when it runs your function. It controls what the function's code can access in AWS, such as CloudWatch Logs or a particular S3 bucket. The Lambda console's default role grants basic permissions to write logs. Add permissions only when the code needs them, and scope them to the actions and resources it uses. See AWS's execution-role documentation.
The execution role answers “what may this code access?” It does not grant a person or another service permission to invoke the function; invocation access is configured separately.
The exact permissions for creating and assigning a role depend on your account setup. A console user generally needs Lambda permissions, and assigning an execution role can also require iam:PassRole. If you receive an AccessDenied error, ask your account administrator to grant the required actions for the intended function and role. Do not broaden the function's execution role to solve a console-user permission problem; see AWS's Lambda and IAM troubleshooting guidance.
This creates a function resource with starter code and a role. It does not add an HTTP endpoint or connect a trigger.
Sign in to the AWS Management Console, open Lambda, and confirm the region where you want the function to live.
On the Lambda Functions page, choose Create function and select Author from scratch.
Give the function a clear name and choose a supported managed runtime that matches your language and dependencies. As of October 4, 2026, AWS's getting-started tutorial uses Node.js 24 or Python 3.14; Node.js 26 and Python 3.15 are listed as preview runtimes. Check the current Lambda runtime table when creating a function, because supported versions and lifecycle dates change. Keep the console's default architecture for a first experiment unless your package and dependencies require another one.
Use the default option to create a role with basic Lambda permissions, or confirm the role that the console attaches automatically if role manager is enabled in your account. In the code editor, note the file and exported handler name; Lambda's handler setting must point to them. For Node.js, the current getting-started example uses index.mjs, an exported handler, and the setting index.handler. The companion deployment walkthrough shows how to edit and deploy a working example.
These three parts form the basic contract between an invocation and your code: a caller or trigger supplies an event, Lambda calls the configured handler, and the handler's return value is delivered according to the invocation method.
The handler is the function Lambda runs for an invocation. In Node.js, index.handler points to the exported handler in the index.mjs file. If the file name, module format, configured handler, and export do not match, Lambda cannot find the entry point. See Defining a Lambda function handler in Node.js.
Lambda passes the handler an event object containing input for that invocation. A direct console test can use JSON you write yourself. An S3 notification, an API request, a scheduled event, or records read from a queue each have their own event structure. Check the format for the service you connect rather than assuming a hand-written test event matches production.
A synchronous caller can receive the function's result; an asynchronous caller does not wait for the handler's result. Returning an object alone does not create an HTTP status code or public URL. To accept HTTP requests, configure a Lambda function URL or API Gateway integration and follow its request and response format. AWS compares these options in its guide to choosing an HTTP invocation method.
A console test directly invokes the handler with sample data. It helps check that the code understands its input and returns the expected result, but it does not verify a production trigger, its permissions, or its retry behavior.
Use a small JSON event containing the fields your handler expects. For example, if the code reads event.name, include a string named name. Use a service-shaped event only when you are deliberately testing that integration format.
Run the saved test event after deploying code changes. Compare the displayed result with the expected value. If it fails, inspect the execution result for handler, runtime, or event-shape errors before changing permissions.
When the execution role permits CloudWatch logging, Lambda writes invocation logs to a default log group named /aws/lambda/<function-name>, created on first invocation. The log group shows messages from the code and Lambda's execution report. CloudWatch Logs retains data indefinitely by default unless you set a retention period; see AWS's log-retention instructions.
Deleting a function does not automatically remove its CloudWatch log group or an execution role the console created. For a temporary exercise, remove resources you no longer need, and delete a role only if it is dedicated to that function. The deployment walkthrough gives the cleanup steps for its example.
To learn by deploying and invoking a small function, follow Deploy Your First AWS Lambda Function. For a local development workflow, read AWS SAM CLI: Local Development Tips. Once a function handles real work, AWS Lambda Metrics Explained introduces the metrics to monitor.