Your First AWS Lambda Function: Handlers, Triggers, Roles & Logs Hands-On

You have a small job to run — resize an uploaded image, validate a webhook, return some JSON to a browser — and you do not want to rent, patch, scale or babysit a server to do it. That is exactly the itch AWS Lambda scratches. Lambda is Function-as-a-Service (FaaS): you hand AWS a single function, tell it what event should wake the function up, and AWS runs your code on demand — zero copies when nothing is happening, thousands of copies under a spike — and bills you only for the milliseconds it actually executes. No EC2 instance, no operating system to update, no idle capacity to pay for at 3 a.m.

The trade for that magic is a very specific mental model, and this article installs it end to end by having you build the thing. Every Lambda invocation is the same three-beat rhythm: an event (a JSON document describing what happened) arrives, Lambda calls your handler (the one function it knows to call) with that event, and your handler returns a response (or throws). Around that beat sit the pieces that trip up every beginner: the execution role that decides what your code is allowed to touch, the CloudWatch Logs group where every print() and crash lands, the environment variables you configure without redeploying, the runtime that turns your .py or .js into a running process, and the trigger that decides how the function is invoked — synchronously (a caller waits for the answer), asynchronously (fire-and-forget, retried for you), or by a poller that reads a queue or stream on your behalf.

By the end you will have written a Python handler, deployed it two ways (a raw aws CLI zip upload and Terraform), invoked it synchronously with a test event, put an HTTPS Function URL in front of it and curled it, set an environment variable, read the START/END/REPORT lines it wrote to CloudWatch, and torn it all down — every step free-tier-friendly. Then, because your next Lambda will inevitably break in one of about a dozen classic ways, you get a symptom-to-fix troubleshooting playbook: AccessDenied because the role can’t write logs, Unable to import module because you zipped the package wrong, Handler not found because you named it file.handler when the function is called something else, a 502 from the Function URL because you returned the wrong shape, and the rest. Read the prose once; keep the tables open when your own function misbehaves.

What problem this solves

Traditional compute makes you the operator. Rent an EC2 instance to run a 200-millisecond job and you pay for 24 hours of an idle box, you patch its kernel, you scale it up before a traffic spike and down after, and you carry the pager when it runs out of memory at midnight. For work that is event-shaped — bursty, intermittent, triggered by “a file landed” or “a request came in” — that model is almost all waste. Lambda deletes the operator role: AWS owns the fleet, the OS, the scaling and the availability; you own a function and its configuration, and nothing else.

What breaks without this understanding is subtle, because Lambda is easy to start and easy to get silently wrong. A first-timer uploads code, invokes it, sees nothing happen, and has no idea whether the function ran, crashed, was denied permission, or never got the event — because they do not yet know that the answer is always in CloudWatch Logs, that “nothing in logs” usually means the role can’t write logs, and that a trigger firing “in the console” but not “from S3” is a resource-policy problem, not a code problem. The service did not fail; the mental model was missing.

Who hits this: literally everyone starting with serverless, plus every developer who has to debug a colleague’s function. It bites hardest on four things a beginner has never had to think about before — the handler string must exactly match file.function; the execution role is a separate identity from your own user and starts with no permissions; the deployment package must contain your dependencies laid out exactly where the runtime looks; and the invocation type changes whether errors come back to you or get retried behind your back. Get those four right on your first function and every later one is a variation on the same theme. This article’s job is to make all four boringly obvious.

Here is the whole field on one screen — the pieces you will meet, what each one is, and the classic beginner trap attached to it:

Learning objectives

By the end of this article you can:

• Explain event-driven FaaS and the Lambda execution lifecycle — init → invoke → freeze/thaw, and how the execution context (globals, /tmp, connections) is reused between invocations on a warm sandbox.
• Name every supported runtime (Node.js, Python, Java, Go, .NET, Ruby, the OS-only custom runtime, and container images) and write the correct handler signature for each.
• Distinguish the three invocation types — synchronous, asynchronous, and poll-based event-source mapping — and predict each one’s retry, error and payload behaviour.
• Wire the IAM execution role with AWSLambdaBasicExecutionRole for logs plus a least-privilege statement for a downstream call, and add a resource-based policy so a trigger is allowed to invoke the function.
• Deploy a function three ways — console, aws CLI zip, and Terraform — set environment variables (and understand their encryption), and pick sensible memory, timeout and /tmp values.
• Add a Function URL for instant HTTPS, curl it, and read the START/END/REPORT lines in CloudWatch Logs to confirm duration, memory and cold-start time.
• Run a symptom → cause → confirm → fix troubleshooting playbook for the dozen failures that hit every first Lambda, and know which ones point you to the memory/timeout tuning sibling.

Prerequisites & where this fits

You need an AWS account with permission to create IAM roles and Lambda functions (an admin or power-user sandbox account is fine — do this in a personal or dev account, never straight into production). You need the AWS CLI v2 installed and configured (aws configure with an access key or, better, aws sso login), and for the Terraform half, Terraform ≥ 1.5. Everything here fits inside the always-free Lambda tier, so the running cost is effectively zero; the only line items that could bill a few paise are CloudWatch Logs storage and, if you leave it running, nothing else. You should be comfortable reading JSON and running commands in a shell; you do not need prior Lambda experience.

Where this sits: it is the on-ramp to the serverless track. The AWS Compute: EC2, Lambda, ECS and EKS — Which One to Choose? decision is upstream of it — read that if you are still deciding whether a function is even the right shape for your workload. Once you can build one function, AWS Lambda Patterns: Event-Driven Functions That Scale to Zero teaches how to wire many of them into a pipeline (fan-out, DLQs, idempotency), and AWS Serverless Web Application Architecture: CloudFront, API Gateway, Lambda and DynamoDB End to End shows the full web-app shape. Two wave siblings go deeper on the two things you will tune first: AWS Lambda Memory, Timeout & Concurrency Tuning for the performance dials this article only points at, and AWS API Gateway REST & HTTP APIs Hands-On for the most common production trigger (this article uses the simpler Function URL to stay beginner-friendly).

A quick map of who owns what, so when your function misbehaves you look in the right place first:

Core concepts

Five ideas make everything later obvious. Read them once; the deep sections just expand each.

Lambda runs a function, not a server. You never see or manage a host. You give Lambda a deployment package (a zip of your code, or a container image), tell it the runtime (e.g. python3.12), the handler (which function to call), the execution role (what it may do), and a little config (memory, timeout, env vars). When an event arrives, Lambda finds or creates a micro-VM sandbox (built on Firecracker), loads your package, and runs your handler. You are billed per GB-second of execution plus a tiny per-request fee — and nothing while idle. That “scale to zero, pay per invocation” property is the whole point.

Every invocation is event → handler → response. The trigger produces a JSON event; Lambda calls your handler with two arguments — the event (the payload) and a context (metadata: request id, time remaining, log group). Your handler does its work and returns a value (serialised to JSON for the caller) or raises an exception (which Lambda records as an error). That is the entire contract. Ninety percent of “why doesn’t it work” is a mismatch in one of those three: the event wasn’t shaped as you assumed, the handler string didn’t point at your function, or the response wasn’t the shape the caller needed.

The sandbox has a lifecycle, and it gets reused. A brand-new sandbox goes through Init (download package, start the runtime, run your module-level/import code — this is the cold start), then Invoke (run the handler), then Freeze — the sandbox is paused, not destroyed. The next event may Thaw the same sandbox and skip Init entirely (a warm start). This is why code outside your handler (global variables, an initialised SDK client, a cached DB connection) survives between invocations and is the single biggest performance lever you have. Eventually an idle sandbox is shut down.

The execution context is reused — use it deliberately. Anything you set up at module load or in a global runs once per sandbox and is reused across every invocation that sandbox serves. Put expensive, reusable setup there (SDK clients, config parsing); never store per-user state there (the next invocation is a different user on the same warm sandbox). /tmp (ephemeral disk) also persists across warm invocations, which is a feature for caching and a footgun for anyone who assumes a clean disk.

The execution role is a separate identity that starts empty. Your function does not run as you. It assumes an IAM execution role, and that role has no permissions until you grant them. The very first grant every function needs is permission to write logs — that is what the AWS-managed AWSLambdaBasicExecutionRole policy is for. Forget it and your function runs but is invisible: no log group, no lines, no clue. Every other AWS call your code makes (read S3, write DynamoDB) needs its own statement on that role.

The vocabulary in one table

Pin every moving part down before the deep dive. The glossary at the end repeats these for lookup; this is the mental model side by side:

The execution model: event JSON → handler → response

Anatomy of a single invocation

When Lambda invokes your function it calls your handler with two arguments. In Python that is def lambda_handler(event, context):. Everything you need is in those two objects plus what you return.

The context object carries small but useful metadata. You rarely need all of it on day one, but knowing it exists saves you later:

The lifecycle: init → invoke → freeze/thaw

The single most important diagram in your head is the sandbox lifecycle. Each phase has different billing and different rules about what your code can assume.

Three rules fall out of this table and are worth memorising:

1. Code above the handler runs once per cold start, not once per request. Initialise your boto3 client, parse config, and open connections there — they survive warm invocations for free.
2. After you return, the sandbox freezes immediately. A background thread or an un-awaited task started in the handler may be paused mid-flight and never resume. Finish your work before returning.
3. Warm sandboxes carry state. Globals keep their last value; /tmp keeps its last files. That is a caching gift and a correctness trap — never store one user’s data in a global and read it for the next.

What the execution context reuses

Runtimes and the handler signature

A runtime is the language environment Lambda starts inside the sandbox. AWS provides managed runtimes for the mainstream languages; for anything else you bring your own via the OS-only runtime (provided.al2023) or a container image. The runtime dictates two things you must get right on your first function: the exact handler string format and how you package dependencies.

Supported runtimes

At the time of writing, the current managed runtime identifiers look like this (AWS deprecates old minor versions on a schedule, so always check the console’s dropdown for the latest):

Two beginner clarifications. First, Go no longer has its own managed runtime — you compile a static binary called bootstrap and run it on the OS-only provided.al2023 runtime (the aws-lambda-go library implements the loop for you). Second, a container image is just an alternative package format, not a different service: same handler concept, same role, same logs — but you can ship up to 10 GB and use any base image, which is how teams package heavy ML dependencies.

The handler signature, language by language

The handler string in the function config must resolve to a real function in your package. Here is the shape per language so you can see why file.handler is a format, not a magic word:

Read the Python row carefully because you will use it in the lab: the string lambda_function.lambda_handler means “in the file lambda_function.py, call the function lambda_handler.” If your file is app.py and your function is main, the handler string must be app.main. This one mismatch is the most common first-day error, and its signature is Runtime.HandlerNotFound.

How the runtime finds and runs your code

Event sources and triggers

A trigger (a.k.a. event source) is whatever causes your function to run. The crucial thing a beginner must internalise is that how the source invokes Lambda — the invocation type — changes the behaviour more than which source it is. There are exactly three invocation types.

The three invocation types

This single table explains a mountain of “vanishing event” confusion. If you invoke a function synchronously and it throws, you see the error — nothing is retried unless you retry. If a source invokes it asynchronously (S3, SNS, EventBridge) and it throws, Lambda retries it twice more behind your back, and if you never attached a dead-letter queue (DLQ) the event is silently dropped after the third failure. If a poller (SQS, Kinesis, DynamoDB Streams) is involved, Lambda’s own service reads the source and invokes your function synchronously in batches — and a poison record on a stream can block the whole shard.

Which source uses which type

Asynchronous retry and destinations

For async invocations the behaviour is configurable, and knowing the defaults stops you from losing events:

The rule: an async function with no DLQ or on-failure destination will silently drop events it can’t process. Add one before you rely on the function.

Poll-based (event-source mapping) knobs

When a source is polled, you create an event-source mapping with its own tuning. You do not need these on day one, but recognise them:

The IAM execution role and resource-based policy

Two different IAM concepts sit on every function, and confusing them is a rite of passage. Get them straight now.

The execution role must (a) trust the Lambda service so it can be assumed, and (b) carry permissions for everything your code does. The resource-based policy is the other direction — it says which principal is allowed to call your function; that is what “Add trigger” quietly creates, and its absence is the exact reason a function “works in the console but not from S3.”

The managed policies you’ll actually attach

AWS ships managed policies so you don’t hand-write the common ones. For logs you attach exactly one:

The three actions in AWSLambdaBasicExecutionRole are worth memorising, because when a function is invisible the culprit is always one of them missing:

Resource-based policy — letting a trigger call you

For push sources you must grant the source permission to invoke the function. The aws lambda add-permission call (or aws_lambda_permission in Terraform) writes a statement onto the function’s resource policy:

Configuration: memory, timeout, env vars, /tmp and packaging

A function is code plus a handful of configuration values. Here are the ones you set on your first function, with real ranges and defaults.

The core settings

Memory and timeout are the two dials you’ll reach for first, but they have their own deep article — set them sensibly here (128–256 MB and a timeout comfortably above your real runtime) and see AWS Lambda Memory, Timeout & Concurrency Tuning when latency or cost matters.

Environment variables and their encryption

Environment variables let you change behaviour (a table name, a log level, an endpoint) without editing or redeploying code. They are always encrypted at rest: by default with an AWS-managed KMS key, or with your own customer-managed key (CMK) if you want to control access and, optionally, encrypt the values in transit to the console too.

Lambda also injects a set of environment variables the runtime and SDK read automatically. You don’t set these — you consume them:

The filesystem: read-only code, writable /tmp

If your code tries to write a file outside /tmp, you get a read-only-filesystem error — a very common surprise for libraries that cache to ~/.cache or the working directory.

The deployment package: zip vs container

How you actually deploy it (IaC options)

CloudWatch Logs and the START/END/REPORT lines

Every invocation writes to a CloudWatch Logs log group named /aws/lambda/<function-name>, in the function’s region, in a per-sandbox log stream. Your print()/console.log() lines land there, uncaught exceptions land there as tracebacks, and Lambda itself frames every invocation with three system lines.

The REPORT line is the one you read constantly — it is your cost-and-performance receipt for every call:

Two config choices make logs sane from day one:

Free tier and pricing basics

Lambda’s free tier is always free (not a 12-month trial), which is why this whole article costs you effectively nothing.

The billing formula is worth seeing once: cost ≈ requests × per-request price + Σ(memory_GB × billed_seconds) × per-GB-s price. A 128 MB function that runs 200 ms uses 0.125 GB × 0.2 s = 0.025 GB-s; you get 400,000 of those free every month — that’s ~16 million such invocations before compute costs a rupee. The deeper cost/right-sizing discussion (why more memory sometimes lowers the bill) lives in the tuning sibling.

Architecture at a glance

The diagram below is the exact shape you build in the lab, drawn as a request path you can follow left to right. An event enters from the left — either an HTTPS call to the function’s Function URL (synchronous), or a push/poll from an event source like S3, SQS or EventBridge (asynchronous or poll-based). Lambda turns it into a JSON event and invokes your function, which runs under its IAM execution role and reads its environment variables. As it runs, the function writes START/END/REPORT and your own lines to CloudWatch Logs, and makes one downstream SDK call (here, PutItem to DynamoDB) to show where the execution role’s permissions actually bite.

The six numbered badges mark the six places a first Lambda fails, and the legend narrates each as symptom · confirm · fix — this is the same map as the troubleshooting playbook, drawn onto the architecture so you can see where each failure lives.

Real-world scenario

KloudMart, a small e-commerce startup in Bengaluru, needed to generate a thumbnail every time a seller uploaded a product photo to their S3 bucket. Their first instinct was a t3.small EC2 instance running a Python worker on a cron loop — which cost about ₹1,100/month to sit idle 95% of the day and still added latency because it polled S3 every minute. A new engineer, Aditi, was asked to “make it serverless” as her onboarding task, and she hit every beginner wall in this article, in order.

She wrote a 40-line lambda_function.py using Pillow, zipped just the .py, and uploaded it. The first S3 upload produced nothing. CloudWatch showed the real error: Unable to import module 'lambda_function': No module named 'PIL' — she had never bundled Pillow (playbook row 3). She rebuilt the zip with pip install pillow -t . and the dependency at the package root, and the import error vanished — replaced by a new silence. This time there were no logs at all, because she had created the execution role by hand and forgotten AWSLambdaBasicExecutionRole; the function was running and failing invisibly (row 1). Attaching the managed policy made the logs appear, and those logs showed AccessDeniedException on s3:GetObject — the role could log, but couldn’t read the very object that triggered it (row 6). She added a least-privilege s3:GetObject/s3:PutObject statement scoped to the one bucket ARN.

The function now worked when she invoked it from the console with a hand-crafted test event — but still did nothing on a real upload. The trigger fired in the console yet was silent from S3 because the S3 bucket had no permission to invoke the function: the resource-based policy was missing (row 11). Adding the S3 principal via add-permission (which the console’s “Add trigger” does automatically, but her hand-built setup had skipped) closed the last gap. Finally, large photos tripped Task timed out after 3.00 seconds — the default timeout (row 4). She raised it to 30 s and bumped memory to 512 MB, which also halved the duration because CPU scales with memory.

The result: thumbnails generated in ~800 ms per image, the EC2 instance deleted, and the monthly bill for this workload dropped from ₹1,100 to effectively ₹0 — comfortably inside the free tier at their volume. Aditi’s takeaway, which she wrote on the team wiki, was the thesis of this article: “Lambda didn’t fail once. Every failure was me missing one of four things — packaging, the role’s permissions, the resource policy, or the timeout. Read CloudWatch first, always.”

Advantages and disadvantages

When each side matters: the advantages dominate for event-shaped, bursty, short work — webhooks, image/file processing, scheduled chores, glue between services, low-to-moderate-traffic APIs. The disadvantages start to bite when you need long-running processing (use a container/Batch), ultra-low predictable latency at high volume (a warm container may win, or use provisioned concurrency), or heavy stateful compute. The honest rule: reach for Lambda first for anything that reacts to an event and finishes quickly; reconsider when runtime, latency floors, or package size fight you.

Hands-on lab

You will build the diagram: a Python function, invoked synchronously via a test event and via an HTTPS Function URL, logging to CloudWatch, with an environment variable — first with the aws CLI + zip, then the identical thing as Terraform. Everything is free-tier. Pick a region and stick to it (this lab uses ap-south-1, Mumbai).

⚠️ Cost note: Lambda invocations and a Function URL are free at this volume. The only thing that can bill is CloudWatch Logs storage (paise), so we set a short retention and delete everything at the end.

What you’ll create

Part A — the CLI + zip path

Step 1 — Write the handler. Create lambda_function.py:

import os
import json

# Runs once per cold start (module load), reused on warm invokes.
GREETING = os.environ.get("GREETING", "Hello")

def lambda_handler(event, context):
    print(f"event received: {json.dumps(event)}")  # lands in CloudWatch
    name = event.get("name", "world")
    remaining_ms = context.get_remaining_time_in_millis()
    body = {
        "message": f"{GREETING}, {name}!",
        "request_id": context.aws_request_id,
        "remaining_ms": remaining_ms,
    }
    return body

Step 2 — Zip it. The zip must contain the file at its root (not inside a folder):

zip function.zip lambda_function.py
# adding: lambda_function.py (deflated 45%)

Step 3 — Create the execution role. Lambda needs a role it can assume. First a trust policy, then the role, then attach the logs policy:

cat > trust.json <<'JSON'
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "lambda.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }]
}
JSON

aws iam create-role \
  --role-name kv-lambda-first-role \
  --assume-role-policy-document file://trust.json

aws iam attach-role-policy \
  --role-name kv-lambda-first-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

Expected: create-role returns the role JSON with an Arn like arn:aws:iam::111122223333:role/kv-lambda-first-role. Wait ~10 seconds before the next step — new roles take a moment to propagate, and creating a function too fast gives The role defined for the function cannot be assumed by Lambda.

Step 4 — Create the function. Substitute your account id in the role ARN:

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

aws lambda create-function \
  --function-name kv-first-fn \
  --runtime python3.12 \
  --architectures arm64 \
  --handler lambda_function.lambda_handler \
  --role arn:aws:iam::${ACCOUNT_ID}:role/kv-lambda-first-role \
  --zip-file fileb://function.zip \
  --timeout 10 \
  --memory-size 128 \
  --region ap-south-1

Expected: JSON with "State": "Pending" then "Active", "Handler": "lambda_function.lambda_handler", "Runtime": "python3.12".

Step 5 — Invoke it synchronously with a test event. Note the --cli-binary-format flag — without it, CLI v2 expects the payload base64-encoded and you’ll get a confusing error:

aws lambda invoke \
  --function-name kv-first-fn \
  --cli-binary-format raw-in-base64-out \
  --payload '{"name": "Vinod"}' \
  --region ap-south-1 \
  response.json

cat response.json
# {"message": "Hello, Vinod!", "request_id": "…", "remaining_ms": 9987}

The command prints "StatusCode": 200. If you see "FunctionError": "Unhandled", open response.json for the error payload and read the logs (next step).

Step 6 — Read the logs. The easiest way is logs tail:

aws logs tail /aws/lambda/kv-first-fn --follow --region ap-south-1

Expected — the three system lines plus your print:

START RequestId: 7f3c… Version: $LATEST
event received: {"name": "Vinod"}
END RequestId: 7f3c…
REPORT RequestId: 7f3c… Duration: 1.83 ms  Billed Duration: 2 ms  Memory Size: 128 MB  Max Memory Used: 36 MB  Init Duration: 118.42 ms

The Init Duration line appears only on the cold start; invoke again and it disappears (a warm start). Set a retention so the group doesn’t accrue cost:

aws logs put-retention-policy \
  --log-group-name /aws/lambda/kv-first-fn \
  --retention-in-days 14 --region ap-south-1

Step 7 — Set an environment variable and re-invoke. Change behaviour with no code change:

aws lambda update-function-configuration \
  --function-name kv-first-fn \
  --environment "Variables={GREETING=Namaste}" \
  --region ap-south-1

# wait for LastUpdateStatus: Successful, then:
aws lambda invoke --function-name kv-first-fn \
  --cli-binary-format raw-in-base64-out \
  --payload '{"name": "Vinod"}' --region ap-south-1 out.json
cat out.json   # {"message": "Namaste, Vinod!", …}

Step 8 — Add a Function URL and curl it. For a public demo use AuthType NONE (⚠️ anyone with the URL can invoke it — fine for a throwaway, never for real data):

aws lambda create-function-url-config \
  --function-name kv-first-fn \
  --auth-type NONE --region ap-south-1

# NONE requires a resource-based permission for public invoke:
aws lambda add-permission \
  --function-name kv-first-fn \
  --statement-id FunctionURLAllowPublicAccess \
  --action lambda:InvokeFunctionUrl \
  --principal "*" \
  --function-url-auth-type NONE --region ap-south-1

The first command returns a FunctionUrl like https://abc123.lambda-url.ap-south-1.on.aws/. Call it:

curl -s -XPOST 'https://abc123.lambda-url.ap-south-1.on.aws/' \
  -H 'content-type: application/json' -d '{"name":"world"}'
# {"message": "Namaste, world!", …}

Step 9 — Verify and then tear down. Confirm the function is Active, then delete everything:

aws lambda delete-function-url-config --function-name kv-first-fn --region ap-south-1
aws lambda delete-function --function-name kv-first-fn --region ap-south-1
aws logs delete-log-group --log-group-name /aws/lambda/kv-first-fn --region ap-south-1
aws iam detach-role-policy --role-name kv-lambda-first-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
aws iam delete-role --role-name kv-lambda-first-role

Part B — the same thing as Terraform

The CLI is great for learning; Terraform is how you keep it. This main.tf reproduces the whole lab declaratively — note how the archive is built in-code so terraform apply is self-contained:

terraform {
  required_providers {
    aws     = { source = "hashicorp/aws", version = "~> 5.0" }
    archive = { source = "hashicorp/archive", version = "~> 2.4" }
  }
}

provider "aws" {
  region = "ap-south-1"
}

# 1. Zip the handler at apply time
data "archive_file" "fn" {
  type        = "zip"
  source_file = "${path.module}/lambda_function.py"
  output_path = "${path.module}/function.zip"
}

# 2. Execution role + trust policy (assumed by the Lambda service)
data "aws_iam_policy_document" "trust" {
  statement {
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["lambda.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "fn" {
  name               = "kv-lambda-first-role"
  assume_role_policy = data.aws_iam_policy_document.trust.json
}

# 3. Attach the managed logs policy
resource "aws_iam_role_policy_attachment" "logs" {
  role       = aws_iam_role.fn.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole"
}

# 4. Pre-create the log group so we control retention (avoids the auto-created, never-expiring one)
resource "aws_cloudwatch_log_group" "fn" {
  name              = "/aws/lambda/kv-first-fn"
  retention_in_days = 14
}

# 5. The function itself
resource "aws_lambda_function" "fn" {
  function_name    = "kv-first-fn"
  role             = aws_iam_role.fn.arn
  runtime          = "python3.12"
  architectures    = ["arm64"]
  handler          = "lambda_function.lambda_handler"
  filename         = data.archive_file.fn.output_path
  source_code_hash = data.archive_file.fn.output_base64sha256
  timeout          = 10
  memory_size      = 128

  environment {
    variables = { GREETING = "Namaste" }
  }

  # Ensure logs + policy exist before the function
  depends_on = [
    aws_iam_role_policy_attachment.logs,
    aws_cloudwatch_log_group.fn,
  ]
}

# 6. A public Function URL (demo only)
resource "aws_lambda_function_url" "fn" {
  function_name      = aws_lambda_function.fn.function_name
  authorization_type = "NONE"
}

output "function_url" {
  value = aws_lambda_function_url.fn.function_url
}

terraform init
terraform apply    # review the plan, type yes
curl -s -XPOST "$(terraform output -raw function_url)" -d '{"name":"TF"}'
# {"message": "Namaste, TF!", …}
terraform destroy  # clean teardown, one command

Common mistakes & troubleshooting

This is the section you’ll return to. It is a playbook: match your symptom, run the confirm command, apply the fix. Rows tagged (pointer) are covered in depth by the tuning sibling.

The invoke-time error reference

When a synchronous invoke fails, the response carries a structured error. Recognise the common errorType values:

Function URL HTTP status reference

The three nastiest, explained

“No logs at all” (row 1) is the one that wastes the most beginner hours, because your instinct is to debug the code when the problem is permissions. A function with no logs permission still runs and still fails — it just can’t tell you. Always confirm the role has AWSLambdaBasicExecutionRole first; it’s a five-second check that rules out the most common invisible failure. If logs exist but are empty of your lines while showing START/END, your handler is returning before your code runs (wrong handler) or logging at a filtered level.

“Works in console, silent from the trigger” (row 11) confuses people because the function is provably correct — you just invoked it successfully. But console/CLI invokes use your identity’s permission to call lambda:InvokeFunction; an event source uses a resource-based policy on the function. When you click “Add trigger” in the console, AWS silently writes that policy for you; when you wire things by hand (or in partial IaC), you must add it yourself with add-permission. aws lambda get-policy shows exactly which principals are currently allowed.

Duplicate side effects under retries catch teams moving from synchronous to asynchronous/poll triggers. Sync invokes don’t retry; async invokes retry twice and pollers can redeliver, all under at-least-once delivery. If your handler charges a card or inserts a row, the same event can run more than once. The fix is idempotency (a dedupe key, a conditional write) — not something you need for your very first sync function, but the moment you attach S3/SQS/EventBridge it becomes load-bearing; AWS Lambda Patterns: Event-Driven Functions That Scale to Zero covers the patterns.

Best practices

• Attach AWSLambdaBasicExecutionRole to every function, first. A function you can’t observe is a function you can’t debug. Add it before you write a line of handler logic.
• Keep the handler thin; do setup at module scope. Initialise SDK clients, parse config and open connections above the handler so warm invocations reuse them — it’s free performance.
• One function, one job, least-privilege role. Give each function its own role scoped to exactly the actions and ARNs it uses. Never reuse a broad “lambda-admin” role.
• Set a real timeout and a log retention. The 3 s default and never-expiring logs are footguns; pick a timeout comfortably above your real runtime and a retention like 14–30 days.
• Make handlers idempotent the moment a non-sync trigger is involved. At-least-once delivery means the same event can arrive twice; design for it with dedupe keys or conditional writes.
• Never bake secrets into env vars or code. Use Secrets Manager or SSM Parameter Store and fetch (and cache) at init; env vars are for non-secret config.
• Prefer arm64 (Graviton). It’s ~20% cheaper per GB-second and usually as fast or faster for interpreted runtimes — a free win on day one.
• Return the shape the caller expects. For a Function URL/API Gateway proxy, that’s often {"statusCode": 200, "body": "..."}; a raw dict from a URL can surface as a 502.
• Pin runtimes and watch deprecation. AWS deprecates old runtime versions; a deprecated runtime blocks code and config updates. Move up proactively.
• Deploy with IaC, not clicks. Console edits are lost on the next deploy and aren’t reviewable; use Terraform/SAM/CDK so the function is reproducible.
• Log structured JSON and a correlation id. Include context.aws_request_id (or the trigger’s id) so you can trace one request across services in Logs Insights.

Security notes

Lambda’s security model is refreshingly small, but each piece matters:

The two you’ll get wrong first: putting a database password in a plaintext env var (use SSM/Secrets Manager), and shipping a Function URL with AuthType NONE “just for testing” and forgetting it — that’s a public endpoint into your account. Delete demo URLs the moment you’re done.

Cost & sizing

Lambda cost has exactly two components plus a rounding rule, and the free tier swallows most beginner usage:

A worked example to make it concrete:

The counter-intuitive part — that raising memory can lower the bill when the extra CPU finishes the work in proportionally less time — is the whole subject of AWS Lambda Memory, Timeout & Concurrency Tuning. For your first function, 128–256 MB and a generous timeout is the right, cheap default.

Interview & exam questions

1. What is AWS Lambda in one sentence, and what do you not manage? Lambda is event-driven Function-as-a-Service: you provide a function and a trigger, and AWS runs it on demand, scaling from zero, billing per millisecond. You don’t manage servers, the OS, patching, scaling or availability — only the code and its config. (CLF-C02)

2. Explain the init → invoke → freeze lifecycle and why it matters. On a cold start Lambda runs Init (start runtime, run your module/global code), then Invoke (the handler), then Freeze (pause the sandbox, not destroy it). A later event may thaw the same sandbox and skip Init. It matters because module-scope setup is reused across warm invokes — the main performance lever — and background work after return may be frozen. (DVA-C02)

3. What are the three invocation types and how does each handle errors? Synchronous (caller waits, gets the error, no Lambda retries), asynchronous (queued, 202 returned, Lambda retries twice, then DLQ/destination), and poll-based event-source mapping (Lambda polls SQS/streams and invokes in batches; streams block on a poison record, SQS re-drives). (DVA-C02, SAA-C03)

4. Your function runs but produces no logs. First hypothesis? The execution role is missing CloudWatch Logs permission — attach AWSLambdaBasicExecutionRole. The function runs and can fail invisibly without logs:CreateLogGroup/CreateLogStream/PutLogEvents. (DVA-C02)

5. The handler is lambda_function.lambda_handler. What must be true in your package? A file lambda_function.py at the package root containing a function lambda_handler(event, context). A mismatch yields Runtime.HandlerNotFound. (CLF-C02)

6. Difference between the execution role and a resource-based policy? The execution role (with its trust policy) defines what the function can do and who can assume it; the resource-based policy on the function defines who can invoke it. A trigger firing in the console but not from S3 is usually a missing resource-based policy. (DVA-C02, SCS)

7. Why might an async-triggered function silently drop events? Async invokes retry twice then discard the event if no DLQ or on-failure destination is configured. Under at-least-once delivery you must attach a destination and design idempotent handlers. (DVA-C02)

8. What’s a cold start and how do you reduce it? The Init latency paid when a new sandbox starts (runtime boot + your module code). Reduce it by trimming the package and imports, initialising lazily, choosing a lighter runtime, or using provisioned concurrency for latency-sensitive paths. (DVA-C02)

9. How is Lambda priced, and what’s always free? Per request ($0.20/1M) plus per GB-second of compute, billed to the millisecond. Always free: 1M requests and 400,000 GB-seconds per month. (CLF-C02)

10. Where do you store a database password for a Lambda? In Secrets Manager or SSM Parameter Store, fetched (and cached) at init with the role granted secretsmanager:GetSecretValue / ssm:GetParameter and kms:Decrypt — never as a plaintext environment variable. (SCS, DVA-C02)

11. Zip vs container image — when would you pick each? Zip for small/medium functions and fast iteration (≤ 250 MB unzipped); container image for large dependencies (up to 10 GB), custom OS libraries, or an existing Docker workflow. (DVA-C02)

12. What does the REPORT log line tell you? Duration and Billed Duration (cost), Memory Size and Max Memory Used (right-sizing — raise memory if you’re near the ceiling), and Init Duration (present only on cold starts). (DVA-C02)

Quick check

1. What are the two arguments Lambda passes to your handler, and what does each contain?
2. Your Python file is app.py and the function is main. What is the correct handler string?
3. A function invoked by S3 throws an exception. How many times does Lambda retry, and where does the event go if you configured nothing?
4. You see Init Duration in the REPORT line of one invocation but not the next. Why?
5. A Function URL returns 403. Name the two most likely causes.

Answers

1. event (the input payload as a native object) and context (invocation metadata — request id, remaining time, log group). The handler does its work using both and returns a value or raises.
2. app.main — the format is file.function, so the file app.py and function main give app.main.
3. Twice (three attempts total) for async invocations; with no DLQ or on-failure destination configured, the event is dropped after the final failure.
4. The first invocation was a cold start (Init ran on a fresh sandbox, so Init Duration is reported); the second reused the now-warm sandbox and skipped Init.
5. AuthType AWS_IAM with an unsigned request (or a caller lacking lambda:InvokeFunctionUrl), or — for AuthType NONE — a missing resource-based add-permission statement.

Glossary

Next steps

• Wire a real trigger. Move from a Function URL to S3 or EventBridge and learn the async model hands-on with AWS Lambda Patterns: Event-Driven Functions That Scale to Zero.
• Put a proper API in front of it. Swap the Function URL for a managed API with routes, auth and throttling in AWS API Gateway REST & HTTP APIs Hands-On.
• Tune what you built. Turn the memory/timeout/concurrency dials this article only pointed at with AWS Lambda Memory, Timeout & Concurrency Tuning.
• See the full serverless shape. Assemble functions, an API, auth and a database into a working app in AWS Serverless Web Application Architecture: CloudFront, API Gateway, Lambda and DynamoDB End to End.
• Re-check the compute decision. Confirm a function is still the right tool as your workload grows with AWS Compute: EC2, Lambda, ECS and EKS — Which One to Choose?.