Your First AWS Lambda Function: A Hands-On Guide

AWS Lambda lets you run code without provisioning or managing servers. You upload a function, define what triggers it, and AWS handles everything else, including, scaling, patching, and availability. You pay only for the milliseconds your code actually runs. For a lot of workloads, that means your compute bill drops from dollars per hour to fractions of a cent per invocation.

What Lambda Actually Does

Think of Lambda as a vending machine for code execution. You don't own the machine, you don't maintain it, and you don't pay rent on the space it occupies. You just put in a request (a trigger), and it gives you a result (your function's output). When nobody's using it, it costs you nothing.

Traditional servers are more like renting an apartment where you pay whether you're home or not. Lambda flips that model entirely.

Lambda supports Python, Node.js, Java, Go, .NET, and Ruby. Each function runs in its own isolated environment with up to 10 GB of memory and a maximum execution time of 15 minutes.

Your First Lambda Function in 5 Minutes

Here's what a basic Lambda function looks like in Python. This one processes an event and returns a response:

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

That's it. No web server setup, no port configuration, no deployment pipeline. You paste this into the Lambda console, create a test event, and click "Test." Your function runs, returns the response, and shuts down.

Practice this yourself:

Triggers: What Makes Your Function Run

Lambda functions don't run on their own. They respond to events from other AWS services. The most common triggers:

• API Gateway - run your function when someone hits an HTTP endpoint. This is how you build serverless APIs.
• S3 - run your function when a file is uploaded to a bucket. Useful for image processing, data transformation, or validation.
• CloudWatch Events (EventBridge) - run your function on a schedule or in response to AWS account events.
• SQS - run your function when a message arrives in a queue. Perfect for background processing.
• DynamoDB Streams - run your function when data changes in a DynamoDB table.

Each trigger passes an event object to your function containing the relevant data - the HTTP request body, the S3 file key, the SQS message, etc.

Want to see triggers in action? The Running Lambda Functions on a Schedule lab walks through CloudWatch-triggered execution, and the Launch EC2 with Lambda lab shows how Lambda can automate infrastructure tasks.

IAM Roles: Lambda's Permission System

Every Lambda function needs an execution role. An IAM role that defines what AWS services your function can access. If your function reads from S3, the role needs s3:GetObject permission. If it writes to DynamoDB, it needs dynamodb:PutItem.

This is where most beginners get stuck. Your function code might be correct, but if the execution role doesn't have the right permissions, you'll get AccessDenied errors.

If IAM roles are new to you, read our IAM explainer first. It covers users, roles, and policies in plain terms.

What Lambda Costs

Lambda pricing has two components:

• Requests: $0.20 per 1 million invocations (first 1 million per month are free)
• Duration: $0.0000166667 per GB-second (first 400,000 GB-seconds per month are free)

For a function with 128 MB of memory running for 200ms per invocation:

• 1 million invocations/month = approximately $0.20 for requests + $0.42 for duration = $0.62 total
• The same workload on an always-on EC2 t3.micro would cost roughly $7.59/month

The free tier is generous enough that many small projects run entirely free. Our Understanding AWS Free Tier guide breaks down exactly what's included and what triggers charges.

When Lambda Is the Wrong Choice

Lambda isn't for everything. Know when to use something else:

• Long-running processes (over 15 minutes) - Lambda has a hard timeout. Use ECS, Fargate, or Step Functions for longer workflows. The Introduction to AWS Step Functions lab shows how to orchestrate multi-step workflows.
• High-throughput, steady-state workloads - if your function runs 24/7 at full capacity, a dedicated container or EC2 instance is cheaper.
• Applications that need persistent connections - WebSockets, long-polling, or database connection pools don't work well with Lambda's ephemeral execution model.

For a comparison of Azure's equivalent service, read Building Serverless APIs with Azure Functions and API Management - the concepts map directly.

Common Mistakes

Setting memory too low. Lambda allocates CPU proportionally to memory. A function with 128 MB gets less CPU than one with 1024 MB. If your function is slow, increasing memory often makes it both faster and cheaper because it finishes sooner.

Not handling cold starts. The first invocation after a period of inactivity takes longer because AWS needs to initialize your function's runtime. For latency-sensitive APIs, use provisioned concurrency or keep functions warm with scheduled pings.

Logging everything to CloudWatch without limits. Lambda automatically sends console output to CloudWatch Logs. If your function logs verbose debug data on every invocation, your CloudWatch bill can exceed your Lambda bill.

Build Something Real

The fastest way to understand Lambda is to build with it. Start here:

• Create Your First AWS Lambda Function — deploy a function, configure a test event, and see it execute
• Launch EC2 with Lambda — automate infrastructure with Lambda + IAM roles
• Lambda on a Schedule — build a scheduled task with CloudWatch Events

If you're preparing for the AWS Solutions Architect or Developer Associate certification, Lambda is a heavily tested topic. CloudLearn's certification practice exams score you per domain so you can see exactly how your serverless knowledge stacks up. Learn more about how practice exams work and which assessment type fits your study style.