Run code in response to events without provisioning servers, paying only per 100ms.
Lambda is a vending machine - you put code in; AWS gives you compute only when someone presses the button.
Event source (S3, API GW, EventBridge, Schedule)
|
v
Lambda Function
memory: 128MB - 10GB (CPU scales with memory)
max runtime: 15 min
v
Side effects (DynamoDB write etc.)
Lambda runs in managed environments. Memory 128MB-10GB (CPU scales linearly). Max execution 15 minutes. Concurrency limit (account-level soft limit 1000 by default). Runtimes: Python, Node, Java, Go, .NET, Ruby, custom container. Cold start ~100ms-1s; warm invocations are ms. Event sources: sync (API GW, ALB, Cognito), async (S3, SNS, EventBridge), poll-based (SQS, Kinesis, DynamoDB Streams).
import json, boto3
def lambda_handler(event, context):
table = boto3.resource('dynamodb').Table('Orders')
for rec in event['Records']:
table.update_item(...)
return {'statusCode': 200, 'body': json.dumps('ok')}
minimal Python handler; receives event and context; returns a dict on API GW.
aws lambda create-function --function-name myfn \
--runtime python3.12 --role arn:aws:iam::...:role/myfn-role \
--handler index.handler --memory-size 512 --timeout 30 \
--zip-file fileb://function.zip
create Lambda with 512MB RAM and 30s timeout; role must allow resources accessed.
aws lambda create-event-source-mapping --function-name myfn \
--event-source-arn arn:aws:dynamodb:...:stream/... \
--starting-position LATEST --batch-size 100
wires DynamoDB Streams to Lambda; each new item triggers the function.
Tight loop inside Lambda that the runtime thinks is infinite (Lambda’s 15-min limit); over-allocating memory ‘just in case’; not handling cold-start latency in APIs.
right-size memory to balance cost vs cold-start latency; reserve concurrency for critical functions; Provisioned Concurrency for cold-start-sensitive APIs; use DLQ or Destinations for failures.
Task timed out after 900.00 seconds.TooManyRequestsException.