How to Deploy Your First AWS Lambda Function from Scratch

Imagine you need to do a single, complex calculation. You don't buy a calculator, keep it on your desk, and pay for its electricity every month. Instead, you walk up to a public kiosk, use its calculator for 10 seconds, and walk away. You only pay for those 10 seconds of use. The kiosk owner handles all the maintenance, power, and repairs.

Serverless computing is exactly that, but for code. You write a small, self-contained function, and a cloud provider runs it only when a specific event happens. You pay only for the milliseconds your code runs, not for idle servers.

If Serverless is the concept, AWS Lambda is the specific machine that makes it happen. Think of Lambda as a vending machine for code.

You stock it with your function (the snack), configure a specific button to press (the trigger), and it dispenses the result only when that button is pressed. You don't own the machine, you don't pay for its electricity when it's idle, and if 100 people press your button at once, 100 identical machines appear instantly to serve them.

How Lambda Works: The Lifecycle

When an event source (like an S3 upload) triggers Lambda, a specific chain of events happens automatically. You don't manage the servers; you just manage the code inside this flow.

Your First Lambda Handler

In AWS Lambda, your code is called a Handler. It is simply a function that accepts two arguments: event (the data from the trigger) and context (info about the runtime environment).

exports.handler = async (event, context) => {
    
    // 1. Log the incoming event data
    console.log('Received event:', JSON.stringify(event));

    // 2. Your business logic here
    const message = 'Hello from Lambda!';

    // 3. Return a response
    return {
        statusCode: 200,
        body: JSON.stringify(message)
    };
};

Before we can deploy our first function, we need to prepare the environment. Think of this like moving into a new house. You need the house keys (your AWS Account) and a toolbelt (the AWS CLI) to build things inside.

Step-by-Step: The Real Setup

While the simulation above shows the flow, here is exactly what you need to do on your actual machine:

Think of creating your first Lambda function as writing a single, precise instruction on a notecard. You don't build a whole factory; you just write the instruction.

When Lambda "picks up" that card (via a trigger), it reads exactly what you wrote, runs it, and puts it down. For your first card, let's keep it simple: a function that takes a name and says "Hello".

exports.helloWorld = async (event) => {
    
    // 1. Get a name from the event, or use 'World'
    const name = event.name || 'World';
    
    // 2. Create a friendly message
    const message = `Hello, ${name}!`;

    // 3. Return the result
    return {
        statusCode: 200,
        body: JSON.stringify(message)
    };
};

The "Handler" Connection

In the code above, the magic line is exports.helloWorld. This is your Handler.

When you deploy this code to AWS, you must tell the Lambda service exactly where to find this instruction. You do this by combining the File Name and the Function Name.

The "Handler" Pitfall

The most common mistake beginners make is a mismatch between the code and the deployment command.

Now that we have our code, we need to tune the engine. Think of your Lambda function's memory setting like adjusting the wattage on a power tool.

Give it more power (memory), and it runs faster—but you pay more per millisecond. Set it too low, and it might run slowly or even time out. The timeout is simply how long you'll wait for it to finish before Lambda pulls the plug. You're trading off speed against cost.

Technical Reasoning: The Scaling Knob

Why does memory affect speed? In Lambda, memory is the primary scaling knob. When you allocate 256 MB, you get a proportional share of CPU and network bandwidth.

• Double the memory: Your code generally runs roughly twice as fast (though not always linearly).
• Billing Math: You pay for GB-seconds. A function that uses 512 MB for 100ms costs exactly twice as much as the same function using 256 MB for 100ms.
• Timeout Safety Net: The timeout (default 3 seconds, max 15 minutes) is a hard limit. If your function runs longer, Lambda terminates it and logs a Task timed out error.

aws lambda update-function-configuration \
    --function-name my-first-function \
    --memory-size 512 \
    --timeout 10

Setting Environment Variables

Environment variables are key-value pairs injected into your function's runtime environment at invocation. They're perfect for configuration that changes between deployments (like database names, feature flags, or API keys) without hardcoding them.

exports.handler = async (event) => {
    const stage = process.env.STAGE; // Reads from Environment
    console.log(`Running in ${stage} mode`);
    
    return {
        statusCode: 200,
        body: `Environment: ${stage}`
    };
};

The "Identity Crisis": IAM Roles

Here is the most common pitfall for beginners. Your function has an Execution Role (an IAM Role). This is its digital identity card.

The Mistake: Assuming that because you (the developer) have permission to access S3, your function does too. It does not. The function is a separate entity. It must have its own explicit policies attached to its role.

You've written the code. Now, how do you know it works? You don't need to wait for a user to visit your website. You can press the "Call Button" yourself.

In the AWS Lambda world, this is called Invoking your function. You can do this visually in the console or programmatically via the command line. Let's see how the "Test Console" works.

Invoking via AWS CLI

While the console is great for manual testing, developers prefer the Command Line Interface (CLI). It allows you to automate tests and scripts.

aws lambda invoke \
    --function-name my-first-function \
    --payload '{"name": "CLI User"}' \
    response.json

Common Pitfall: "Function Times Out"

The most common runtime error is "Task timed out". This happens when your code takes longer to run than the Timeout setting you configured.

While the CLI is powerful for automation, the AWS Console is your visual workshop. It's a guided wizard that walks you through the deployment process, handling the heavy lifting of packaging and configuration for you.

Think of this as packing a suitcase. You need to put your clothes (code) and toiletries (dependencies) into the bag (zip file) correctly before you check it in. If you pack it wrong, the airline (AWS) rejects it.

The Deployment Wizard

Once your zip file is ready, the console guides you through the setup. You'll define the function's identity (Name, Runtime) and its permissions (Role).

Common Pitfall: The "Zip" Trap

The most frequent error beginners face is the "Nested Folder" Error.

Think of your Lambda function as an autonomous delivery drone. Once it's airborne, you can't see inside it. CloudWatch is the control tower's radar and flight recorder.

It automatically captures two critical things:

1. Metrics: The "vital signs" (how many times it flew, how long each flight took, how much memory it used). This is your high-level health dashboard.
2. Logs: The "black box" — a detailed, chronological transcript of everything your function console.log-ed, plus system messages. This is your primary debugging tool.

Setting Up Logs and Metrics

Logs are automatic, but structured access is key. Every time your Lambda runs, AWS creates a log stream in a CloudWatch Logs group named /aws/lambda/your-function-name.

To see logs for a specific invocation, go to the Monitor tab in the Lambda console and click View logs in CloudWatch. You will see entries like:

START RequestId: 8675309 Version: $LATEST
INFO Received event: {"name": "Professor Pixel"}
Processing logic...
END RequestId: 8675309
REPORT RequestId: 8675309  Duration: 1.23 ms  Billed Duration: 2 ms  Memory Size: 128 MB  Max Memory Used: 75 MB

Pro Tip: If you prefer the command line, you can "tail" your logs in real-time (like tail -f) using:

aws logs tail /aws/lambda/my-first-function --follow

The Cost Trap: Log Retention

Here is a critical lesson for your wallet: CloudWatch Logs retain data forever by default.

Every console.log accumulates in S3-backed storage. For a busy function, this can grow to gigabytes per day. You pay for this storage. A common beginner surprise is an unexpectedly high AWS bill because log data was never cleaned up.

aws logs put-retention-policy \
    --log-group-name /aws/lambda/my-first-function \
    --retention-in-days 30

Welcome to the FAQ corner! Even the best developers have questions when they start with Lambda. Here, we'll tackle the most common hurdles: from "How do I trigger this?" to "Why is it so expensive?" Let's clear up the confusion.

exports.handler = async (event) => {
    const name = event.name || 'World';
    return {
        statusCode: 200,
        body: `Hello, ${name}!`
    };
};

def lambda_handler(event, context):
    name = event.get('name', 'World')
    return {
        'statusCode': 200,
        'body': f'Hello, {name}!'
    }