Published on · Updated on
Replaced retired runtime and IAM steps with a current Node.js 24 console walkthrough, working test event, logging guidance, and safer cleanup.
This walkthrough creates a small Node.js Lambda function in the AWS console, deploys it, invokes it with a test event, checks its logs, and removes the resources created for the exercise. You do not need to create an HTTP endpoint or connect another AWS service to run this example. If you want the concepts and choices before the hands-on steps, read AWS Lambda Fundamentals: Core Concepts and First Setup.
Lambda runs your handler when it is invoked and manages the underlying compute environment. Your account can incur charges for Lambda usage and CloudWatch Logs, so check the current Lambda pricing and CloudWatch pricing for your account and usage before you begin.
index.mjs.The function does not need administrator permissions. It uses a separate execution role that grants only the permissions its code needs.
Free usage eligibility and account offers can change, and they do not make every related service or usage pattern free. Review AWS's current pricing and billing information for your account rather than assuming this exercise has no cost. You can also review AWS Budgets if you want an alert for estimated charges.
Lambda functions are regional resources. A function in one region is separate from a function with the same name in another region; check the regional requirements when connecting other services.
An execution role controls which AWS services and resources your function code can access. For this example, the function only needs permission to write logs. Under Permissions, choose the console's default option to create a role with basic Lambda permissions (AWS documents this as Create default role). The console can attach a role automatically in accounts where IAM role manager is enabled; confirm the attached role has basic logging permissions. The basic role does not grant access to other AWS services. See AWS's execution-role guidance.
If a later function needs to read a specific S3 bucket or write to a DynamoDB table, add only the required actions for those resources to its role. Do not attach broad administrator permissions to make an access error disappear.
first-lambda-hello.nodejs24.x. AWS currently lists Node.js 24 as a supported runtime; runtime availability changes, so check the supported runtimes table when following this guide later. Do not use preview runtimes for production code.The runtime provides the language environment that runs your code. The console's Node.js starter uses an ES module file named index.mjs and a handler named handler. Lambda's handler setting is the file name and exported function name; the default setting is index.handler. Keep those names aligned. AWS documents this format in Defining a Lambda function handler in Node.js.
In the function's Code tab, open index.mjs and replace its contents with:
export const handler = async (event) => {
const name = typeof event?.name === "string" ? event.name : "world";
const message = `Hello, ${name}!`;
console.log(JSON.stringify({ message }));
return { message };
};
The handler reads an optional name field from the event, writes one log entry, and returns a plain object. When invoked directly in the Lambda console, that object appears as the function result. It is not an HTTP response: to serve web requests, connect the function to a Lambda function URL or API Gateway and use the response format required by that integration.
Open the function's permissions or configuration view and confirm that it has the basic execution role created by the console. This role lets Lambda write the function's logs. It does not give the code permission to call other AWS services, and it does not control which people or services can invoke the function.
Choose Deploy in the code editor. Wait for the console to confirm the update before testing. If you edit the code again, deploy that change before invoking the function so the test runs the saved version.
greeting-test.{
"name": "Ada"
}
Select the saved test event and run it. The result should be:
{
"message": "Hello, Ada!"
}
The console displays the invocation result and function logs. This confirms that the handler can process this sample JSON event; it does not test an API, scheduled rule, or another service integration.
| What you see | What to check |
|---|---|
| Handler not found | Confirm the file is index.mjs, it exports handler, and the handler setting is index.handler. |
| The result is unexpected | Check the saved test event. This handler uses event.name when it is a string and otherwise returns the default greeting. |
| Your code edit has no effect | Choose Deploy after editing, then run the test again. |
| AccessDenied while creating the function | The identity signed in to the console needs permission to create the function and its execution role, including permission to pass the selected role to Lambda (iam:PassRole). Ask your account administrator to grant the required access to the intended function and role. |
| No CloudWatch logs appear | Confirm the invocation ran and the attached execution role has basic CloudWatch Logs permissions. The default log group is created on the first invocation. |
For an iam:PassRole denial, change the permissions of the identity creating the function; adding permissions to the function's execution role does not fix that setup error. See AWS's Lambda and IAM troubleshooting guidance.
After the first invocation, CloudWatch creates the default log group /aws/lambda/first-lambda-hello if one does not already exist. In CloudWatch, choose Logs, then Log groups, open that group, and inspect its newest log stream. The console.log entry should contain the greeting. Lambda sends logs to CloudWatch Logs when the execution role has the required permissions; see Lambda logging.
For a first function, start with these CloudWatch invocation metrics. Errors includes exceptions from your code and the Lambda runtime, including timeouts and configuration errors. Duration measures handler processing and excludes initialization time; see AWS's metric definitions and log report fields.
After a test, confirm that the invocation count increased and that the error count stayed at zero. A failed invocation's execution result and log stream usually provide the first useful clue.
Concurrency is the number of function invocations running at the same time. For this single manual test, you do not need to configure provisioned concurrency. Revisit concurrency settings only when a real workload or service limit requires it.
Memory and timeout are function settings, not direct measures of CPU use. If a real workload approaches its timeout or memory limit, use its invocation results and metrics to decide what to investigate. This hello-world example is too small to establish production capacity settings.
When you finish, remove the function and any dedicated role or log data you no longer need. Deleting a Lambda function does not delete its CloudWatch log group or execution role. Delete only the role created for this exercise if no other function uses it.
In the Lambda console's Functions page, select first-lambda-hello, choose Actions, then Delete, and confirm in the dialog.
In CloudWatch Logs > Log groups, select /aws/lambda/first-lambda-hello and delete it if you no longer need the records. CloudWatch Logs retains log data indefinitely by default, but you can set a retention period instead. See CloudWatch log-group retention.
In the IAM console's Roles page, find the role Lambda created for this function. Delete it only after the function is removed and only if it is not shared with another function or application.
These steps remove the resources this exercise created. If you later add a trigger or another AWS service, review and remove those resources separately.
You created a Node.js 24 Lambda function, deployed an ES module handler, invoked it with JSON, checked its result and logs, and removed the dedicated resources. The function ran from a console test event; Lambda did not create a public web endpoint or connect a trigger automatically.
For local Lambda development, see AWS SAM CLI: Local Development Tips. To learn what to monitor as a function takes on real work, read AWS Lambda Metrics Explained.