AWS Lambda Explained: Triggers, Runtimes and Use Cases

AWS Lambda is a serverless compute service that runs code in response to events. It removes the need to provision or manage servers, but engineers must still design permissions, concurrency, error handling, monitoring and event flow correctly.

Lambda is an important service for anyone studying cloud architecture through an AWS Solutions Architect course. It is commonly used with Amazon API Gateway, Amazon S3, Amazon EventBridge, Amazon SQS and other AWS services.

What is AWS Lambda?

AWS Lambda runs a function when it receives an event or an invocation request. AWS manages the underlying compute infrastructure, while you provide the code, runtime configuration, permissions and event source.

A Lambda function normally contains one focused unit of logic. Examples include resizing an uploaded image, validating an API request, processing a queue message or running a scheduled maintenance task.

Think of the architecture as this diagram in words:

Event source or application
          |
          v
     Lambda trigger
          |
          v
   Lambda function code
          |
          v
AWS service, database, API or log destination

Lambda is described as serverless because customers do not manage its operating system or EC2 instances. Servers still exist behind the service, but AWS handles provisioning, patching and much of the scaling process.

Lambda charges are mainly based on the number of requests and execution duration. Duration depends on the configured memory, execution time and processor architecture. Engineers should check the current AWS pricing page before estimating production costs.

How does an AWS Lambda invocation work?

A Lambda invocation begins when a service or application sends an event to the function. Lambda creates or reuses an execution environment, calls the configured handler and returns or records the result according to the invocation type.

The main steps are:

1. A trigger or client sends an event.
2. Lambda checks whether the caller has permission to invoke the function.
3. Lambda selects an existing execution environment or creates a new one.
4. The runtime loads the function code and dependencies.
5. Lambda calls the handler with an event object and context object.
6. The function returns a response or raises an error.
7. Logs are sent to Amazon CloudWatch Logs when the execution role permits it.

Cold starts and warm starts

A cold start happens when Lambda must create and initialise a new execution environment. It includes runtime startup, code loading and any initialisation outside the handler.

A warm start reuses an existing environment. Objects created outside the handler may remain available, but applications must never assume that an environment will be reused.

For example, an SDK client can be created outside the handler:

import boto3

s3 = boto3.client("s3")

def lambda_handler(event, context):
    return {
        "request_id": context.aws_request_id,
        "message": "Function completed"
    }

This allows later invocations in the same environment to reuse the client. It does not create permanent application state.

Which Lambda runtimes are available?

A Lambda runtime supplies the language environment that executes the function. AWS provides managed runtimes for languages such as Python, Node.js, Java, .NET, Ruby and PowerShell, while custom runtimes and container images support other requirements.

Runtime versions change over time and eventually reach deprecation. Always verify the currently supported versions in the AWS Lambda documentation before selecting a runtime for a new workload.

A function deployed as a ZIP archive uses a managed or custom runtime. A container-based function is packaged as an image and stored in Amazon Elastic Container Registry. Lambda container images are not general-purpose, continuously running containers.

Handler and execution environment

The handler is the function entry point. For a Python file named lambda_function.py, the common handler value is:

lambda_function.lambda_handler

The first part is the module name and the second part is the Python function name. An incorrect handler value causes errors such as Runtime.HandlerNotFound.

Lambda provides temporary storage through the /tmp directory. Its configurable capacity ranges from 512 MB to 10,240 MB, but it should be treated as temporary rather than durable storage. Persistent data belongs in services such as Amazon S3, DynamoDB or a database.

How do AWS Lambda triggers work?

A trigger connects an event source to a Lambda function. The exact invocation and retry behaviour depends on whether the source invokes Lambda synchronously, asynchronously or through an event source mapping.

With asynchronous invocation, Lambda normally retries a function error twice by default. Event age, retry attempts, dead-letter queues and destinations can be configured where supported.

For SQS, Lambda polls the queue and processes messages in batches. A message becomes visible again if processing fails and its visibility timeout expires. Partial batch response can prevent successful records from being retried with failed records.

For stream services such as Kinesis and DynamoDB Streams, ordering, batch size, shard concurrency and checkpoint progress affect processing. A repeatedly failing record can block later records in the same shard unless appropriate failure controls are configured.

Amazon S3 can invoke Lambda after object creation or deletion events. For a deeper explanation of bucket controls, see Amazon S3 classes, versioning and policies.

Triggers are not destinations

A trigger starts a function. A destination receives information after an asynchronous invocation succeeds or fails.

Supported destination designs can route results to services such as Amazon SQS, Amazon SNS, Amazon EventBridge or another Lambda function. A dead-letter queue generally captures failed event payloads, while a Lambda destination provides a richer invocation record.

What are practical AWS Lambda use cases?

Lambda is most useful for short-lived, event-driven and automatically scaling tasks. It works well when processing demand changes over time and the application does not require a permanently running process.

File processing

An S3 upload can trigger a function to validate file names, extract metadata, create thumbnails or start a workflow. Avoid writing results to the same triggering prefix unless filters prevent recursive invocations.

User uploads file
      -> S3 ObjectCreated event
      -> Lambda validates file
      -> Result stored in another prefix
      -> EventBridge or SNS sends status

Serverless APIs

API Gateway can accept an HTTP request and invoke Lambda synchronously. The function validates input, applies business logic and reads or writes data.

For latency-sensitive APIs, test cold-start behaviour and downstream connection limits. Lambda automatically scaling to many concurrent executions does not guarantee that a database can accept the same number of connections.

Queue-based background processing

An application can place tasks in Amazon SQS, allowing Lambda workers to process them independently. This design absorbs traffic bursts and separates the request path from background work.

Scheduled automation

Amazon EventBridge Scheduler can invoke Lambda on a schedule. Typical tasks include generating reports, checking resources or applying maintenance actions that complete within the function timeout.

Security and operations automation

Lambda can evaluate security events, enrich findings or forward selected data to another system. The function should use least-privilege permissions and must not place credentials directly in source code.

Deployment workflows

Lambda can support deployment notifications, validation steps and event-driven automation. Students learning automated delivery can combine these concepts with an AWS DevOps course, while keeping Lambda deployment packages under version control.

How can you build a Lambda and S3 trigger lab?

This lab creates a Python function that reads metadata for an uploaded S3 object. It demonstrates the execution role, deployment package, resource-based invocation permission and bucket notification.

You need AWS CLI credentials, an existing S3 bucket and permission to manage IAM, Lambda and S3. The bucket and function must be in the same AWS Region for an S3 notification trigger.

Step 1: Create the IAM trust policy

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

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

aws iam attach-role-policy \
  --role-name lambda-s3-lab-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

The managed policy permits basic CloudWatch logging. It does not grant access to S3 objects.

Step 2: Add least-privilege S3 access

Set the bucket name before creating the inline policy:

export BUCKET="your-existing-bucket-name"

cat > s3-read-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::${BUCKET}/uploads/*"
  }]
}
EOF

aws iam put-role-policy \
  --role-name lambda-s3-lab-role \
  --policy-name ReadUploadedObjects \
  --policy-document file://s3-read-policy.json

Step 3: Write and package the function

# lambda_function.py
import boto3
import urllib.parse

s3 = boto3.client("s3")

def lambda_handler(event, context):
    record = event["Records"][0]
    bucket = record["s3"]["bucket"]["name"]
    key = urllib.parse.unquote_plus(record["s3"]["object"]["key"])

    metadata = s3.head_object(Bucket=bucket, Key=key)

    print({
        "bucket": bucket,
        "key": key,
        "size": metadata["ContentLength"],
        "request_id": context.aws_request_id
    })

    return {"status": "processed", "key": key}

Create the ZIP package:

zip function.zip lambda_function.py

Step 4: Create the Lambda function

export AWS_REGION="ap-south-1"
export ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
export ROLE_ARN="arn:aws:iam::${ACCOUNT_ID}:role/lambda-s3-lab-role"

aws lambda create-function \
  --function-name s3-metadata-reader \
  --runtime python3.12 \
  --handler lambda_function.lambda_handler \
  --role "$ROLE_ARN" \
  --zip-file fileb://function.zip \
  --timeout 15 \
  --memory-size 256 \
  --region "$AWS_REGION"

IAM role creation may take a short time to propagate. If Lambda reports that it cannot assume the role, wait briefly and retry the command.

Step 5: Permit S3 to invoke Lambda

export FUNCTION_ARN=$(aws lambda get-function \
  --function-name s3-metadata-reader \
  --query 'Configuration.FunctionArn' \
  --output text)

aws lambda add-permission \
  --function-name s3-metadata-reader \
  --statement-id AllowS3Invoke \
  --action lambda:InvokeFunction \
  --principal s3.amazonaws.com \
  --source-arn "arn:aws:s3:::${BUCKET}" \
  --source-account "$ACCOUNT_ID"

The execution role controls what the function can access. This resource-based permission controls whether S3 can invoke the function.

Step 6: Configure and test the notification

cat > notification.json <<EOF
{
  "LambdaFunctionConfigurations": [{
    "Id": "UploadMetadataTrigger",
    "LambdaFunctionArn": "${FUNCTION_ARN}",
    "Events": ["s3:ObjectCreated:*"],
    "Filter": {
      "Key": {
        "FilterRules": [{"Name": "prefix", "Value": "uploads/"}]
      }
    }
  }]
}
EOF

aws s3api put-bucket-notification-configuration \
  --bucket "$BUCKET" \
  --notification-configuration file://notification.json

echo "lambda lab" > sample.txt
aws s3 cp sample.txt "s3://${BUCKET}/uploads/sample.txt"

aws logs tail /aws/lambda/s3-metadata-reader --follow

put-bucket-notification-configuration replaces the bucket's existing notification configuration. Retrieve and merge existing settings before using it on a shared or production bucket.

How should Lambda security and scaling be configured?

Lambda security depends on identity policies, resource policies, network design and safe secret handling. Scaling also needs limits so that a sudden event volume does not overload downstream systems.

Use these controls:

• Give the execution role only the actions and resources required by the code.
• Use resource-based policies to restrict invoking services and accounts.
• Store secrets in AWS Secrets Manager or Systems Manager Parameter Store.
• Encrypt environment variables with AWS KMS when additional key control is required.
• Configure reserved concurrency to limit or protect function capacity.
• Use provisioned concurrency when predictable startup latency justifies the additional cost.
• Set queue visibility timeouts and retry policies to match function execution time.

A Lambda function connected to your VPC does not gain internet access merely by being placed in a public subnet. Private subnet routes and a NAT gateway or another suitable egress design are normally required for outbound IPv4 internet access.

Lambda and Amazon EC2 solve different compute problems. Review Amazon EC2 instances, AMIs, storage and security when comparing event-driven functions with long-running virtual machines.

How do you troubleshoot common Lambda errors?

Start with the CloudWatch log stream, invocation metrics and trigger configuration. Then separate permission failures, code failures, timeout problems and event-delivery problems instead of changing several settings at once.

Useful diagnostic commands include:

aws lambda get-function-configuration \
  --function-name s3-metadata-reader

aws lambda get-policy \
  --function-name s3-metadata-reader

aws logs tail /aws/lambda/s3-metadata-reader \
  --since 30m --format short

CloudWatch metrics such as Invocations, Errors, Duration, Throttles and ConcurrentExecutions help identify whether the problem is inside the code or in the service configuration.

When should you not use AWS Lambda?

Lambda is not the best choice for every workload. Consider another compute service when a process must run longer than 15 minutes, requires persistent local state, needs continuous background execution or depends on unsupported host-level control.

Containers or EC2 may be more suitable for long-running services, specialised operating system requirements and predictable compute-heavy workloads. The correct choice depends on execution pattern, operational needs, latency and cost rather than the label “serverless.”

Summary

AWS Lambda runs code in response to synchronous requests, asynchronous events and polled event sources. A production design must account for runtime lifecycle, permissions, retries, concurrency, observability, idempotency and downstream capacity.

The best way to learn Lambda is to build small event-driven labs and deliberately test failure conditions. To practise Lambda alongside IAM, VPC, S3, API Gateway and architecture design, enquire about AWS Solutions Architect course batch details.

Reviewed by Network Rhinos AWS and cloud trainers.