Deploy Your First AWS Lambda Function with AWS CLI | CloudWebSchool

Simple explanation

AWS Lambda runs your code on demand without you managing any servers. Deploying a Lambda function means:

1. Writing the code locally.
2. Packaging it as a zip file.
3. Creating an IAM execution role so Lambda has permission to write logs.
4. Telling Lambda which runtime to use, where your code is, and which function to call.
5. Invoking it with a test event to confirm it works.
6. Reading the output in CloudWatch Logs.

That is the full cycle. Once you understand it once, everything else (triggers, permissions, environment variables) slots in naturally on top of it.

What you will build

• A simple Python Lambda function that reads a name from an event and returns a greeting.
• An IAM execution role with the minimum permissions Lambda needs to run.
• A zip deployment package created with the CLI.
• A test invocation using a JSON event file.
• A log inspection in CloudWatch Logs.
• An update to the function code after initial deployment.

Before you start

You need:

• The AWS CLI installed and configured. See Installing the AWS CLI if you have not set it up yet.
• An IAM user or role with permission to create Lambda functions and IAM roles. If you are unsure about the difference, see IAM users vs roles.
• Python 3 installed locally to write and test the function code.

How it works

The deployment flow from start to finish:

1. Write the function. A Python file with a handler that accepts an event and a context object.
2. Create an execution role. An IAM role Lambda assumes when running your code, granting it permission to write CloudWatch logs.
3. Zip the code. Lambda accepts code as a zip archive. For simple functions this is just the Python file. Functions with dependencies also include installed packages.
4. Create the function. Register it with Lambda by specifying the runtime, handler, role ARN, and zip file.
5. Invoke it. Send a test JSON event and inspect the response.
6. Check the logs. CloudWatch Logs receives all function output automatically. It is the first place to look when something goes wrong.
7. Update. Rezip and push updated code, or change configuration independently without touching the code.

Step 1: Write the function code

Create a file called lambda_function.py. The handler receives an event (the data passed by whatever triggered the function) and a context (runtime metadata Lambda provides), then returns a response.

# lambda_function.py

import json
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

def handler(event, context):
    """
    Simple Lambda function that greets a user.
    """
    logger.info(f"Received event: {json.dumps(event)}")

    name = event.get('name', 'World')
    message = f"Hello, {name}! Your Lambda function is working."

    return {
        'statusCode': 200,
        'body': json.dumps({
            'message': message,
            'function_name': context.function_name,
            'aws_request_id': context.aws_request_id
        })
    }

A few things to note:

• The handler string you pass to Lambda is lambda_function.handler: the filename (without .py) dot the function name. Any mismatch causes a “handler not found” error at runtime.
• Use Python’s logging module rather than print(). Lambda captures both, but the logging module preserves log levels so you can filter output in CloudWatch later.
• The return value uses statusCode and body. This is the format API Gateway expects. For direct invocations and other triggers you return whatever format the caller expects.

Step 2: Create the execution role

Lambda cannot run without an execution role. This is an IAM role that Lambda assumes when it starts your function. It gives the function an identity and controls what AWS services it can call. At minimum the role needs permission to write logs to CloudWatch Logs. Without it, your function will fail silently with no output anywhere.

Create the role with a trust policy that allows the Lambda service to assume it:

aws iam create-role \
  --role-name MyLambdaExecutionRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "lambda.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'

Attach the AWS-managed policy that covers CloudWatch Logs writes:

aws iam attach-role-policy \
  --role-name MyLambdaExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

Retrieve the role ARN. You will need it when creating the function:

aws iam get-role \
  --role-name MyLambdaExecutionRole \
  --query "Role.Arn" \
  --output text

This returns something like: arn:aws:iam::123456789012:role/MyLambdaExecutionRole

Step 3: Package the code

Lambda receives your code as a zip archive. For a single-file function with no external dependencies this is a one-liner:

zip function.zip lambda_function.py

If your function uses external Python packages (anything not in the standard library), you must include them in the zip. Install them into a local directory and zip from inside it:

# Install dependencies alongside the function file
pip install requests -t package/
cp lambda_function.py package/

# Zip from inside the directory so files sit at the root of the archive
cd package
zip -r ../function.zip .
cd ..

Step 4: Create the Lambda function

aws lambda create-function \
  --function-name my-first-function \
  --runtime python3.12 \
  --role arn:aws:iam::123456789012:role/MyLambdaExecutionRole \
  --handler lambda_function.handler \
  --zip-file fileb://function.zip \
  --timeout 30 \
  --memory-size 128 \
  --description "My first Lambda function"

Key parameters explained:

• —handler lambda_function.handler: the dot-separated path to your function. Filename (without .py) dot function name. If this does not match exactly, Lambda returns a “handler not found” error.
• —runtime python3.12: the execution environment. Use the latest supported Python version for new functions.
• —timeout 30: maximum seconds before Lambda forcibly terminates the invocation. The default is 3 seconds, which is easy to hit when making any network call. Set it higher than you expect to need.
• —memory-size 128: MB of RAM allocated. Lambda CPU scales proportionally with memory. 128 MB is the minimum.
• —zip-file fileb://: the fileb:// prefix reads the file as binary data. Using file:// instead silently corrupts the zip.

Wait for the function to reach active state before invoking it:

aws lambda wait function-active --function-name my-first-function

Step 5: Invoke and test the function

Create a test event file with the JSON payload you want to send:

cat > test-event.json <<'EOF'
{
  "name": "Alice"
}
EOF

Invoke the function synchronously and capture the response:

aws lambda invoke \
  --function-name my-first-function \
  --payload file://test-event.json \
  --cli-binary-format raw-in-base64-out \
  response.json

cat response.json

A successful response looks like:

{
  "statusCode": 200,
  "body": "{\"message\": \"Hello, Alice! Your Lambda function is working.\", \"function_name\": \"my-first-function\", \"aws_request_id\": \"abc-123-def\"}"
}

Now check CloudWatch Logs to see what the function printed internally:

# Lambda creates the log group automatically on first invocation
aws logs describe-log-groups \
  --log-group-name-prefix /aws/lambda/my-first-function

# Get the most recent log stream
LOG_STREAM=$(aws logs describe-log-streams \
  --log-group-name /aws/lambda/my-first-function \
  --order-by LastEventTime \
  --descending \
  --query "logStreams[0].logStreamName" \
  --output text)

# Read the log events
aws logs get-log-events \
  --log-group-name /aws/lambda/my-first-function \
  --log-stream-name "$LOG_STREAM"

Every invocation writes a START, END, and REPORT line automatically, plus anything your function logs. When something fails, the error message and stack trace are here. CloudWatch Logs is the primary debugging surface for Lambda. Always check it first.

Step 6: Update the function code

After modifying lambda_function.py, repackage and push the updated zip:

# Repackage
zip function.zip lambda_function.py

# Deploy the update
aws lambda update-function-code \
  --function-name my-first-function \
  --zip-file fileb://function.zip

Wait for the update to complete before invoking again:

aws lambda wait function-updated --function-name my-first-function

Configuration changes (timeout, memory, environment variables) are separate from code updates and do not require a rezip:

aws lambda update-function-configuration \
  --function-name my-first-function \
  --timeout 60 \
  --memory-size 256 \
  --environment "Variables={LOG_LEVEL=DEBUG,TABLE_NAME=my-table}"

Environment variables

Use environment variables to pass non-sensitive configuration to your function without hardcoding it in the source:

import os

TABLE_NAME = os.environ.get('TABLE_NAME', 'default-table')
LOG_LEVEL = os.environ.get('LOG_LEVEL', 'INFO')

def handler(event, context):
    # Use TABLE_NAME and LOG_LEVEL here
    pass

Adding permissions to the execution role

If your function needs to call other AWS services (read from S3, write to DynamoDB, publish to SQS), add those permissions to the execution role. Grant only what the function actually needs on the specific resources it accesses. The principle of least privilege applied consistently here limits the blast radius if the function is compromised or misconfigured:

aws iam put-role-policy \
  --role-name MyLambdaExecutionRole \
  --policy-name DynamoDBReadAccess \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query",
        "dynamodb:Scan"
      ],
      "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/my-table"
    }]
  }'

For a fuller picture of how Lambda’s security model works, covering resource-based policies, VPC placement, and production secrets management, see the Lambda security model guide.

When to use this approach

Good fit

• First Lambda deployments where you want to understand the mechanics before adding frameworks.
• Simple event-driven functions with few or no external dependencies.
• Lightweight Python utilities: data transformation, scheduled notifications, file processing.
• Proof-of-concept workloads where fast iteration matters more than deployment automation.
• Low-ops production functions that run infrequently and do not need a managed CI/CD pipeline.

Not a good fit

• Long-running workloads. Lambda times out at 15 minutes. For longer jobs consider AWS Batch or EC2.
• Heavy dependency trees. When the unzipped package exceeds 250 MB, zip deployment is no longer viable. Container images support up to 10 GB.
• Custom runtimes or binary dependencies. If your code requires compiled binaries or a specific OS configuration, a container image gives you full control over the environment.
• Production at scale with frequent deploys. At scale, infrastructure-as-code tools (SAM, Terraform, CloudFormation) are more reliable and auditable than manual CLI commands.

If you are deciding whether Lambda is the right compute option for your workload, see choosing between EC2, Lambda, and containers.

Lambda zip deployment vs container images

Lambda supports two deployment package types: zip archives (used in this tutorial) and container images. Both run the same way once deployed. Lambda handles scaling and infrastructure regardless of which you use. The difference is how you package your code and dependencies.

This tutorial uses zip deployment because it is the fastest path for a first Lambda function with no infrastructure overhead. Once your packaging needs grow (more dependencies, custom runtimes, larger artifacts), see container images in AWS for how to build and deploy Lambda container images.